Вызов MemoryStream.GetBuffer() завершается успешно даже после MemoryStream.Close(); Почему?

1. Это не нужно. Буфер является управляемой памятью, поэтому с ним будет работать обычная сборка мусора, без необходимости его включения в удаление.
2. Полезно иметь возможность получать байты потока памяти даже после того, как поток был закрыт (что могло произойти автоматически после того, как пар был передан методу, который что-то записывает в поток, а затем закрывает указанный поток). И чтобы это работало, объект должен хранить буфер вместе с записью о том, сколько в него было записано.

Что касается второго пункта, то на самом деле во многих случаях имеет смысл вызывать ToArray() (что, как было сказано, требует, чтобы хранилище в памяти, которое возвращает GetBuffer(), оставалось живым) после закрытия потока, потому что закрытие потока гарантирует, что любая дальнейшая попытка записи в поток завершится ошибкой. Следовательно, если у вас есть ошибка, из-за которой вы получаете массив слишком рано, он вызовет исключение, а не просто даст вам неверные данные. (Очевидно, если вы явно хотите получить текущий массив частично через потоковые операции, это другое дело). Это также гарантирует, что все потоки полностью очищены, а не часть их данных находится во временном буфере (MemoryStream не буферизуется, потому что MemoryStream по существу является буфером, но вы могли использовать его со связанными потоками). или писатели, у которых был свой отдельный буфер).

Технически в MemoryStream нечего утилизировать. Буквально ничего, у него нет дескрипторов операционной системы, неуправляемых ресурсов, ничего. это просто оболочка вокруг byte[]. Все, что вы можете сделать, это установить buffer (внутренний массив) в null, чего команда BCL по какой-то причине не сделала.

Как отметил @mike в комментариях, команда BCL хотела, чтобы GetBuffer и ToArray работали даже после утилизации, хотя мы не уверены, почему? Источник ссылок.

Вот как реализован Dispose.

protected override void Dispose(bool disposing)
{
    try {
        if (disposing) {
            _isOpen = false;
            _writable = false;
            _expandable = false;
            // Don't set buffer to null - allow GetBuffer & ToArray to work.
    #if FEATURE_ASYNC_IO
                        _lastReadTask = null;
    #endif
        }
    }
    finally {
        // Call base.Close() to cleanup async IO resources
        base.Dispose(disposing);
    }
}

и GetBuffer ниже

public virtual byte[] GetBuffer()
{
    if (!this._exposable)
    {
        throw new UnauthorizedAccessException(Environment.GetResourceString("UnauthorizedAccess_MemStreamBuffer"));
    }
    return this._buffer;
}

Как видите, в Dispose _buffer нетронутые, а в GetBuffer нет выброшенных чеков.

Поскольку GC не является детерминированным, вы не можете заставить его немедленно удалить MemoryStream, поэтому экземпляр не будет помечен как удаленный немедленно, вместо этого он будет просто помечен для удаления. Это означает, что в течение некоторого времени, пока он действительно не будет утилизирован, вы можете использовать некоторые его функции. Поскольку он хранит сильную ссылку на свой буфер, вы можете получить его, вот как выглядит метод GetBuffer:

public virtual byte[] GetBuffer()
{
    if (!this._exposable)
    {
        throw new UnauthorizedAccessException(Environment.GetResourceString("UnauthorizedAccess_MemStreamBuffer"));
    }
    return this._buffer;
}

В отличие от большинства интерфейсных методов, IDisposable.Dispose ничего не обещает. Вместо этого он предоставляет стандартные средства, с помощью которых владелец объекта может сообщить этому объекту, что его службы больше не требуются, на случай, если объекту может понадобиться использовать эту информацию. Если объект попросил внешние объекты сделать что-то от его имени и пообещал этим внешним объектам, что сообщит им, когда их услуги больше не понадобятся, его Dispose метод может передать уведомление этим объектам.

Если у объекта есть метод, который может быть выполнен только тогда, когда у объекта есть внешние сущности, действующие от его имени, попытка вызвать этот метод после того, как эти сущности были отклонены, должна вызывать ObjectDisposedException а не сбой каким-либо другим образом. Кроме того, если есть метод, который не может быть полезен после закрытия объекта, он часто должен выдавать ObjectDisposedException, даже если конкретному объекту на самом деле не нужно использовать объект. С другой стороны, если конкретный вызов будет иметь разумное значение после того, как объект отклонил все сущности, которые действовали от его имени, нет особых причин, по которым такой вызов не должен быть допущен к успеху.