実行時に、アプリケーションによるメモリ使用量が非常に大きいことがわかりました。
しかし、私は3〜4 MemoryStreamsしか使用していないようですが、そのうちの1つは81Mbでいっぱいになることがあります。
その他は主に20mb、3 mb、1mbのコンテナです...
しかし、それでもアプリケーションによる525.xxMBのメモリ使用量があります...
私もステートメントを使ってみusing(...)ましたが、運がありませんでした。
そこで、メモリリークを削減するための最も効率的な方法をここで求めています。
マネージド.NETアプリでは、アンマネージドリソースハンドルを割り当てて正しく破棄しない限り、通常、本来の意味でのメモリ「リーク」は発生しません。しかし、それはあなたがしていることのようには聞こえません。
おそらく、不要になったオブジェクトへの参照を保持している可能性があります。これにより、メモリが予想よりも長く「生きている」状態に保たれます。
たとえば、5MBのデータをメモリストリームに入れ、そのメモリストリームを静的フィールドに割り当てると、アプリケーションの存続期間中、5MBがなくなることはありません。ガベージコレクタがその5MBのメモリを解放して再利用できるように、メモリストリームが指すものが不要になったときに、メモリストリームを参照する静的フィールドにnullを割り当てる必要があります。
同様に、ローカル変数は関数が終了するまで解放されません。大量のメモリを割り当ててローカル変数に割り当ててから、何時間も実行される別の関数を呼び出すと、ローカル変数は常に存続します。そのメモリが不要になった場合は、ローカル変数にnullを割り当てます。
アプリにメモリリークがあるとどのように判断していますか？タスクマネージャによって表示されるプロセス仮想メモリの割り当てを見ている場合、それはあまり正確ではありません。アプリケーションのメモリマネージャは、OSから大量のメモリを割り当て、OSに解放せずに、アプリケーション内の他の用途のために内部的に解放する場合があります。
常識的な慣行を使用します。必要に応じてdisposeまたはcloseを呼び出し、変数の内容が不要になったらすぐにnullを変数に割り当てます。
ガベージコレクション環境で怠惰になるからといって、コード内のメモリ割り当てと割り当て解除のパターンに注意を払うべきではないという意味ではありません。
メモリリークの定義は珍しいようです...次のコードは、観察している効果を正確に生成しますが、メモリリークと呼ばれることはめったにありません。
var data = new byte[512*1024*1024];
data = null;
しかし、実際には正当なリークがある可能性があります。メモリプロファイラーはそれらを簡単に表示しますが、巨大なものはコードレビューによって追跡できます。メモリストリームの数が少ないことがすでにわかっている場合は、リストまたは単にメンバー変数に格納して、それらを存続させないかどうかを確認してください。また、同様の理由で大規模なアレイが稼働していないかどうかも確認してください。