開発者が .NET での意図しないリソース リークに巻き込まれる方法はいくつかあります。一か所に集めておくと便利だと思いました。
項目ごとに 1 つの回答を追加してください。最高のものが投票されます :)
開発者が .NET での意図しないリソース リークに巻き込まれる方法はいくつかあります。一か所に集めておくと便利だと思いました。
項目ごとに 1 つの回答を追加してください。最高のものが投票されます :)
イベント ハンドラを削除できませんでした。
イベントへの登録は、登録解除と組み合わせる必要があります。
this.myObject.MyEvent += new EventHandler(myObject_MyEvent);
this.myObject.MyEvent -= new EventHandler(myObject_MyEvent);
これがCodeProjectで発生したシステムの例があります。
使用していませんUsing
。
P/アンマネージ コードを呼び出し、それらをクリーンアップしないか、IDisposable を実装してクリーンアップしない。
データベース接続を開いたままにします。
WCF クライアント オブジェクトは、他の IDisposable オブジェクトのようには機能しません。操作が障害状態にある場合、WCF サービスのクライアントを中止する必要があります。中止しないと、接続を開いたままにします。これは通常、難しい方法で学習されます。
Dispose の実装に失敗したため、子オブジェクトが破棄されません。
Office API を使用する場合のほぼすべて。これらはすべて COM オブジェクトであるため、破棄する必要があります。また、イベント ハンドラーを使用する場合は、それらへのクラス参照を保持する必要があります。そうしないと、参照が失われます。多くの場合、オブジェクトをクリーンアップするために GC を手動で呼び出す必要さえあります
WeakReference を使用すると、WeakReference によって保持されているオブジェクトがクリーンアップされるという微妙なリークにつながる可能性があります。これは、強い参照がないためですが、WeakReference 自体は強い参照を保持しているためクリーンアップされません。
リストや WeakReferences のディクショナリなど、プルーニングしないものがある場合、これに遭遇する可能性があります。ターゲットが収集された後でも、WeakReference オブジェクトをリークすることになります。
簡単なメモリ リーク: List 型のクラスに静的フィールドを作成します。リストに項目を追加します。ガベージ コレクションが行われることはありません。そのため、使い終わったアイテムを手動で削除することを忘れない限り、メモリは永久に拘束されます。
System.Windows.Window オブジェクトで 'Close' メソッドを呼び出せませんでした。
System.Windows.Window オブジェクトのすべてのマネージ リソースが確実にガベージ コレクションされるようにする唯一の方法は、Window オブジェクトで 'Close()' メソッドを呼び出すことです。Dispose を呼び出すか、オブジェクト参照を null に設定しても、オブジェクトは破棄されません。
マネージ メモリを「リソース」と見なす場合、イベント ハンドラのフック解除に失敗すると、メモリ リーク (およびその他のさまざまなより深刻なバグ) の一般的な原因となります。
起動コードの外部に入力される静的リスト、辞書、およびコレクション ベースのリソース。
これは、適切な LRU ベースのキャッシュではなく、グローバル キャッシュとして使用するディクショナリがある場合に発生する可能性があります。
静的なものはすべて、特別な注意が必要です!
.NET Compact Frameworkでの描画関連オブジェクト(グラフィックス、フォント、SolidBrush、ペンなど)の破棄の失敗。これにより、不要なときに深刻なメモリリークが発生する可能性があります(モバイルデバイス=限られたメモリ)。
タイマーで Dispose() を呼び出せませんでした
WPF リソース ディクショナリ リーク。役立つリンク:
偽装トークン ハンドルが開いたままになっています。
シングルトンであるべきものの複数のインスタンスを作成するように Spring.NET を誤って構成する。