.NETのメモリ・リークのバックアップ(No.1)

Open棟梁Project - マイクロソフト系技術情報 Wiki

目次 †

マネージ・リソースであれば、GCで適切に解放される。
このため、マネージ・オブジェクトでリークするものは、関数スタックに積まれる
ローカル変数以外に保持されたマネージ・オブジェクトである可能性が高い。

.NETアプリを軽快にするためのガベージ・コレクション講座－＠IT
http://www.atmarkit.co.jp/fdotnet/directxworld/directxworld06/directxworld06_01.html

アンマネージ・リソースを使用するマネージコードはリソースを明示的に解放する。
これを怠ると、マネージコード上でGCが動作していてもメモリリークが発生する。

マネージのユーザコードでアンマネージ・リソースをGCで
適切に解放するには、以下の実装を施す必要がある。　　

Marshallクラスを使用してアンマネージ・メモリ確保をする場合は
メモリの使用後に明示的な開放が必要になるので注意する。
アンマネージ・メモリは.NETオブジェクトと異なりGC対象とならないため。
- Marshal クラス
  http://msdn.microsoft.com/ja-jp/library/system.runtime.interopservices.marshal.aspx

メンバにアンマネージ・リソースを持つ.NETオブジェクトには、以下のIDisposableインターフェイスと対応する実装を施す必要がある。
- IDisposable インターフェイス
  http://msdn.microsoft.com/ja-jp/library/system.idisposable.aspx
  IDisposableが適切に実装されていれば、例外時はGC任せ（未DisposeのオブジェクトはFinalizeでDisposeされる）で、正常時にClose呼び出しをするだけで良い（Close内でDisposeを呼び出すのが慣例の実装のため）。例外的にCloseやファイナライザがあってもDisposeを明示的に呼び出す必要があるものもある（旧ODP.NET）が、これは、IDisposableの実装方針に反している。オブジェクトの世代によっては解放タイミングが遅れるためファイナライザの実行タイミングも遅れることになる。これが問題となるような場合は、ファイナライザ任せで処理を実装しないこと（Disposeを明示的に呼び出す）。

CLR 徹底解剖大きなオブジェクトヒープの秘密
http://msdn.microsoft.com/ja-jp/magazine/cc534993.aspx
LOHの問題によってGen2の断片化に起因するメモリリークが発生することもある（.NET3.5までの問題）。