.NETのMemoryStreamが閉じていない場合、メモリリークは発生しますか？

私は次のコードを持っています：

MemoryStream foo(){
    MemoryStream ms = new MemoryStream();
    // write stuff to ms
    return ms;
}

void bar(){
    MemoryStream ms2 = foo();
    // do stuff with ms2
    return;
}

私が割り当てたMemoryStreamが何らかの理由で後で破棄​​されない可能性はありますか？

私はこれを手動で閉じると主張するピアレビューを持っています、そして彼が有効なポイントを持っているかどうかを知るための情報を見つけることができません。

何かが使い捨ての場合は、常にそれを処分する必要があります。メソッドでusingステートメントを使用して、bar()確実ms2にDisposed にする必要があります。

最終的にはガベージコレクターによってクリーンアップされますが、常にDisposeを呼び出すことをお勧めします。コードでFxCopを実行すると、警告としてフラグが立てられます。

あなたは何もリークしません-少なくとも現在の実装では。

Disposeを呼び出しても、MemoryStreamによって使用されているメモリはこれ以上速くクリーンアップされません。呼び出し後にストリームが読み取り/書き込み呼び出しで実行可能になるのを停止します。

MemoryStreamから別の種類のストリームに移動したくないと確信している場合は、Disposeを呼び出さなくても害はありません。ただし、別のストリームを使用するように変更したとしても、早い段階で簡単な方法を選択したので、見つけにくいバグに噛まれたくないので、これは一般的に良い習慣です。（その一方で、YAGNIの議論があります...）

とにかくそれを行うもう1つの理由は、新しい実装が Disposeで解放されるリソースを導入する可能性があるためです。

はい、リークの定義方法と後でどの程度意味するかに応じて、リークがあります...

リークによって「メモリは割り当てられたままで、使用できなくても使用できます」という意味であり、後者の場合は、disposeを呼び出した後であればいつでも意味します。そうすると、永続的ではありませんが、リークが発生する可能性があります（つまり、アプリケーションランタイムの寿命）。

MemoryStreamによって使用されているマネージメモリを解放するには、その参照を無効にすることにより、その参照を解除する必要があります。これにより、ガベージコレクションの対象となります。これに失敗すると、それを使用し終えた時点から、参照がスコープ外になるまで一時的なリークが発生します。その間、メモリは割り当てに使用できなくなります。

usingステートメントの利点（単にdisposeを呼び出すよりも）は、usingステートメントで参照を宣言できることです。usingステートメントが終了すると、disposeが呼び出されるだけでなく、参照がスコープ外になり、参照を事実上無効にし、オブジェクトをガベージコレクションの対象にすぐにできるようにします。

すぐに参照を解除できないことは、古典的な「永続的な」メモリリークではありませんが、同じ効果があります。たとえば、（disposeを呼び出した後でも）MemoryStreamへの参照を保持し、メソッドの少し下でさらにメモリを割り当てようとすると、まだ参照されているメモリストリームによって使用されているメモリは利用できません。破棄を呼び出してそれを使用し終わったとしても、参照を無効にするか、または範囲外になるまで、あなたに。

呼び出す.Dispose()（またはでラップするUsing）必要はありません。

呼び出す理由.Dispose()は、リソースをできるだけ早く解放するためです。

たとえば、スタックオーバーフローサーバーについて考えてみましょう。このサーバーでは、メモリのセットが制限されており、何千ものリクエストが受信されます。スケジュールされたガベージコレクションを待たずに、できるだけ早くメモリを解放して利用できるようにします。新しい着信要求の場合。

これはすでに回答されていますが、情報を隠すという古き良き時代の原則は、将来的にリファクタリングしたいことを意味します。

MemoryStream foo()
{    
    MemoryStream ms = new MemoryStream();    
    // write stuff to ms    
    return ms;
}

に：

Stream foo()
{    
   ...
}

これは、呼び出し側がどのような種類のStreamが返されるかを気にする必要がないことを強調し、内部実装を変更できるようにします（たとえば、ユニットテスト用にモックする場合）。

バーの実装でDisposeを使用していない場合は、問題が発生する可能性があります。

void bar()
{    
    using (Stream s = foo())
    {
        // do stuff with s
        return;
    }
}

すべてのストリームはIDisposableを実装します。メモリストリームをusingステートメントで囲みます。usingブロックは、ストリームが確実に閉じられ、どのような場合でも破棄されるようにします。

Fooを呼び出す場所はどこでも（MemoryStream ms = foo（））を使用して行うことができます。

メモリをリークすることはありませんが、コードレビュー担当者はストリームを閉じる必要があることを示しています。そうするのは礼儀正しい。

メモリをリークする可能性がある唯一の状況は、誤ってストリームへの参照を残し、決して閉じない場合です。あなたはまだ本当にメモリリークされていませんが、あなたはしている不あなたがそれを使用すると主張する時間を延長します。

私は中のMemoryStreamを包む推薦bar()でusing主に一貫性を保つための文：

• 現在、MemoryStreamはメモリを解放しません .Dispose()が、将来のある時点でれる可能性があります。または、あなた（またはあなたの会社の他の誰か）がそれを独自のカスタムMemoryStreamで置き換える可能性もあります。
• プロジェクトにパターンを確立してすべてのストリームを確実に破棄するのに役立ちます。「一部のストリームを破棄する必要がありますが、特定のストリームは破棄する必要はありません」ではなく、「すべてのストリームを破棄する必要がある」と言うことで、より明確に線が引かれます。 ...
• 他のタイプのストリームを返すことができるようにコードを変更した場合は、とにかく破棄するようにコードを変更する必要があります。

私が通常次のような場合に行う別のこと foo()IDisposableを作成して返す、は、オブジェクトの構築との間の障害がreturn例外によってキャッチされ、オブジェクトが破棄され、例外が再度スローされるようにすることです。

MemoryStream x = new MemoryStream();
try
{
    // ... other code goes here ...
    return x;
}
catch
{
    // "other code" failed, dispose the stream before throwing out the Exception
    x.Dispose();
    throw;
}

オブジェクトがIDisposableを実装している場合は、完了時に.Disposeメソッドを呼び出す必要があります。

一部のオブジェクトでは、DisposeはCloseと同じことを意味し、その逆も同様です。その場合、どちらかが適切です。

さて、あなたの特定の質問については、いいえ、あなたはメモリをリークしません。

私は.netの専門家ではありませんが、おそらくここでの問題はリソースではなく、ファイルハンドルであり、メモリではありません。ガベージコレクターは最終的にストリームを解放し、ハンドルを閉じると思いますが、コンテンツをディスクにフラッシュすることを確認するために、明示的に閉じることが常にベストプラクティスになると思います。

アンマネージリソースの破棄は、ガベージコレクションされた言語では非決定的です。Disposeを明示的に呼び出しても、バッキングメモリが実際に解放されるタイミングを完全に制御することはできません。オブジェクトがスコープ外になると、Disposeは暗黙的に呼び出されます。これは、usingステートメントを終了した場合でも、従属メソッドから呼び出しスタックをポップアップした場合でも同様です。これはすべて言われていますが、オブジェクトは実際には管理対象リソース（ファイルなど）のラッパーである場合があります。このため、finallyステートメントを明示的に閉じるか、usingステートメントを使用することをお勧めします。乾杯

MemorySteramは、管理オブジェクトであるバイトの配列にすぎません。これを破棄するか閉じることを忘れても、ファイナライズの頭上以外に副作用はありません。
リフレクター内のMemoryStreamのconstuctorまたはflushメソッドを確認するだけで、優れたプラクティスに従うだけでなく、閉じるまたは破棄する必要がない理由が明らかになります。