.NETのメモリリーク(意図しない保持)

業務上は不要になったオブジェクトが、staticフィールド・キャッシュ・イベント・Timer・DIのライフタイムなどから参照され続け、GCが回収できずに増え続ける状態。

概念URI: https://comcomponent.com/knowledge/dotnet-memory-leak/
別名・表記: 意図しない保持 / Unintended Object Retention
最終確認日: 2026-08-01
機械可読データ: JSON-LD

この概念が関わる関係

.NETのメモリリーク(意図しない保持)はdotnet-gcdumpで確認できます。負荷前後で型ごとのCount/Sizeが増えているかはdotnet-gcdumpの比較で確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
.NETのメモリリーク(意図しない保持)はdotnet-dumpで確認できます。増えている型が見えたあと、なぜ回収されないのかはdotnet-dumpのヒープ解析で確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
.NETのメモリリーク(意図しない保持)はgcrootコマンドで確認できます。そのオブジェクトがなぜ生きているのかという参照経路は、gcrootコマンドで確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
.NETのメモリリーク(意図しない保持)はdotnet-traceで確認できます。いつ、どこで大量に割り当てているかは、ダンプではなくdotnet-traceのイベント収集で確認できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
.NETのメモリリーク(意図しない保持)はGen 2(第2世代ヒープ)で確認できます。GC後もGen 2ヒープのサイズが増え続けているかは、メモリリークを疑う手がかりとして確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Total Allocated(累積割り当て量)を.NETのメモリリーク(意図しない保持)に用いることは推奨されません。Total Allocatedは起動後の累積値でGCで回収されても減らないため、単独でメモリリークの判定材料に使うべきではない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Working Set / RSSを.NETのメモリリーク(意図しない保持)に用いることは推奨されません。Working Set/RSSの増加はOS視点のメモリでありGCヒープの生存オブジェクト量と一致しないため、単独でマネージドリークの判定に使うべきではない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
強制GC(Induced Collection)を.NETのメモリリーク(意図しない保持)に用いることは推奨されません。強制GCで一時的にメモリが下がっても根本原因は消えておらず、本当のリークなら参照が残っているオブジェクトは強制GCでも回収されない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
staticコレクションによる保持は.NETのメモリリーク(意図しない保持)の原因になることがあります。staticフィールドのコレクションへ追加しっぱなしにすると、プロセスが生きている限りオブジェクトを保持し続けてしまうことがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
上限・期限のないキャッシュは.NETのメモリリーク(意図しない保持)の原因になることがあります。上限や有効期限のないキャッシュは、キーが増え続ける設計だと実質的なメモリリークになることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
イベント購読解除漏れは.NETのメモリリーク(意図しない保持)の原因になることがあります。寿命の長いpublisherへのイベント購読を解除しないと、寿命の短いsubscriberが残り続けることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Timerの破棄漏れは.NETのメモリリーク(意図しない保持)の原因になることがあります。Timerを破棄しないまま残すと、コールバックのdelegate経由でオブジェクトが保持され続けることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
IDisposableの解放漏れは.NETのメモリリーク(意図しない保持)の原因になることがあります。所有権が曖昧なコードでDispose漏れが起きると、ハンドルやネイティブメモリなどが解放されないまま増え続けることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
DIライフタイムの取り違えは.NETのメモリリーク(意図しない保持)の原因になることがあります。singletonがリクエスト単位のデータを保持する設計だと、リクエストが終わってもデータが増え続けることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
LOH(Large Object Heap)は.NETのメモリリーク(意図しない保持)の原因になることがあります。大きな配列やバッファを長く保持したり断片化したりすると、LOHが増え続けてリークに近い状態になることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

この概念を扱う記事

.NETでGC待ちとメモリリークを見分ける ── 増えるメモリを観測・比較・証明する実務手順(主要トピック)

一次資料

https://learn.microsoft.com/en-us/dotnet/core/diagnostics/debug-memory-leak

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。