知識マップ: .NETでGC待ちとメモリリークを見分ける ── 増えるメモリを観測・比較・証明する実務手順

記事「.NETでGC待ちとメモリリークを見分ける ── 増えるメモリを観測・比較・証明する実務手順」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

.NETアプリのメモリ増加は、ガベージコレクションがまだ回収していないだけの場合と、staticコレクションや上限のないキャッシュ、イベント購読解除漏れ、Timerの破棄漏れ、IDisposableの解放漏れ、DIライフタイムの取り違えなどにより本当に参照が残り続けている場合とに分かれる。見分けにはまずdotnet-countersでGCヒープやGen 2、LOHの傾向を確認し、累積値であるTotal AllocatedやOS視点のWorking Setの増加だけでは判断しないことが重要になる。次にdotnet-gcdumpで負荷前後の型ごとのCountとSizeを比較して増えている型を特定し、dotnet-dumpのdumpheapとgcrootコマンドで誰がそのオブジェクトを参照し続けているのかまで追う。強制GCでメモリが下がっても根本原因は消えておらず、本番へ入れる対策にはならない。

flowchart LR
    accTitle: .NETのGC待ちとメモリリークの見分け方の知識マップ
    accDescr: .NETでメモリ増加がGC待ちか本当のメモリリークかを、dotnet-counters・dotnet-gcdump・dotnet-dumpとgcrootで切り分ける関係を示す図
    dotnet_garbage_collection[".NETのガベージコレクション(GC)"]
    dotnet_memory_leak[".NETのメモリリーク(意図しない保持)"]
    dotnet_counters["dotnet-counters"]
    dotnet_gcdump["dotnet-gcdump"]
    dotnet_dump["dotnet-dump"]
    gcroot_command["gcrootコマンド"]
    gc_heap["GCヒープ(マネージドヒープ)"]
    dumpheap_command["dumpheap -statコマンド"]
    dotnet_trace["dotnet-trace"]
    gen2_heap["Gen 2(第2世代ヒープ)"]
    total_allocated_memory["Total Allocated(累積割り当て量)"]
    working_set_rss["Working Set / RSS"]
    induced_gc["強制GC(Induced Collection)"]
    static_collection_leak["staticコレクションによる保持"]
    unbounded_cache["上限・期限のないキャッシュ"]
    event_subscription_leak["イベント購読解除漏れ"]
    timer_disposal_leak["Timerの破棄漏れ"]
    idisposable_leak["IDisposableの解放漏れ"]
    di_lifetime_mismatch["DIライフタイムの取り違え"]
    large_object_heap["LOH(Large Object Heap)"]
    dotnet_framework[".NET Framework"]
    dotnet[".NET(Core以降)"]
    dotnet_garbage_collection -->|"で確認できる"| dotnet_counters
    dotnet_memory_leak -->|"で確認できる"| dotnet_gcdump
    dotnet_memory_leak -->|"で確認できる"| dotnet_dump
    dotnet_memory_leak -->|"で確認できる"| gcroot_command
    gc_heap -->|"で確認できる"| dumpheap_command
    dotnet_memory_leak -.->|"で確認できる"| dotnet_trace
    dotnet_memory_leak -->|"で確認できる"| gen2_heap
    total_allocated_memory -->|"用いるのは非推奨"| dotnet_memory_leak
    working_set_rss -->|"用いるのは非推奨"| dotnet_memory_leak
    induced_gc -->|"用いるのは非推奨"| dotnet_memory_leak
    static_collection_leak -.->|"原因になり得る"| dotnet_memory_leak
    unbounded_cache -.->|"原因になり得る"| dotnet_memory_leak
    event_subscription_leak -.->|"原因になり得る"| dotnet_memory_leak
    timer_disposal_leak -.->|"原因になり得る"| dotnet_memory_leak
    idisposable_leak -.->|"原因になり得る"| dotnet_memory_leak
    di_lifetime_mismatch -.->|"原因になり得る"| dotnet_memory_leak
    large_object_heap -.->|"原因になり得る"| dotnet_memory_leak
    dotnet_counters -->|"より先に行うべき"| dotnet_gcdump
    dotnet_gcdump -->|"より先に行うべき"| dotnet_dump
    dotnet_counters -->|"両立しない"| dotnet_framework
    dotnet_dump -->|"両立しない"| dotnet_framework
    dotnet_garbage_collection -->|"利用する"| gc_heap
    dotnet_garbage_collection -->|"前提とする"| dotnet

概念間の関係(全23件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• .NETのガベージコレクション(GC)はdotnet-countersで確認できます。GCヒープやWorking Setの傾向はdotnet-countersでリアルタイムに確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• .NETのメモリリーク(意図しない保持)はdotnet-gcdumpで確認できます。負荷前後で型ごとのCount/Sizeが増えているかはdotnet-gcdumpの比較で確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• .NETのメモリリーク(意図しない保持)はdotnet-dumpで確認できます。増えている型が見えたあと、なぜ回収されないのかはdotnet-dumpのヒープ解析で確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• .NETのメモリリーク(意図しない保持)はgcrootコマンドで確認できます。そのオブジェクトがなぜ生きているのかという参照経路は、gcrootコマンドで確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• GCヒープ(マネージドヒープ)はdumpheap -statコマンドで確認できます。ヒープ上の型ごとの件数とサイズの統計は、dumpheap -statコマンドで確認できる / 確度: 確立した関係 / 確認日: 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 出典
• dotnet-countersはdotnet-gcdumpより先に行うべきです。実務ではまずdotnet-countersで傾向を見て、そのうえで型統計の比較にdotnet-gcdumpへ進むのが効率的な順番とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• dotnet-gcdumpはdotnet-dumpより先に行うべきです。軽量なdotnet-gcdumpで増えている型を絞り込んだうえで、参照元を追うdotnet-dumpに進むのが効率的な順番とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• dotnet-countersは.NET Frameworkと両立しません。dotnet-counters/dotnet-dump/dotnet-gcdumpは.NET Core 3.0以降のランタイムが持つ診断機能を使うツールで、.NET Framework 4.xのアプリには使えない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• dotnet-dumpは.NET Frameworkと両立しません。dotnet-dumpは.NET Core 3.0以降の診断機能を前提とするため.NET Framework 4.xでは使えず、代わりにWinDbgでSOSを読み込んで解析する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• .NETのガベージコレクション(GC)はGCヒープ(マネージドヒープ)を利用します。GCはマネージドオブジェクトをGCヒープ(マネージドヒープ)上で管理し、回収の対象にする / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• .NETのガベージコレクション(GC)は.NET(Core以降)を前提とします。ガベージコレクションは.NETランタイムが提供する仕組みである / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

.NETのガベージコレクション(GC)

オブジェクトへ到達できる参照が無くなったときに.NETランタイムがそのメモリを回収する仕組み。割り当て状況やヒープのしきい値、世代を見ながら動く。

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

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

GCヒープ(マネージドヒープ)

GCの回収対象となるマネージドオブジェクトが置かれるヒープ領域。dumpheapで見えるのはこの範囲だけで、ネイティブ側のメモリは含まれない。

Total Allocated(累積割り当て量)

起動後にアプリが割り当てたメモリの累積量を表す指標。GCで回収されても値は減らない。

Working Set / RSS

物理メモリ上に載っているプロセスのページ量を表すOS視点のメモリ指標。GCヒープの生存オブジェクト量とは一致しない。

強制GC(Induced Collection)

アプリケーションコードが明示的に要求するガベージコレクション。未回収だったオブジェクトをその場で回収するだけで、根本原因を消すものではない。

staticコレクションによる保持

staticフィールドのコレクションへ追加し続け、プロセスが生きている限りオブジェクトを保持し続けてしまうリークパターン。

上限・期限のないキャッシュ

最大件数や有効期限を設けていないキャッシュで、実質的にメモリリークとして働く状態。

イベント購読解除漏れ

寿命の長いpublisherが寿命の短いsubscriberをイベントハンドラー経由で参照し続け、購読解除しない限りsubscriberが解放されないリークパターン。

Timerの破棄漏れ

System.Threading.TimerなどのTimerを破棄しないまま残し、コールバックのdelegateを通じてオブジェクトを保持し続けるリークパターン。

IDisposableの解放漏れ

using/await usingなどで所有権を明確にせず、ファイル・ソケット・ハンドルなどのリソースが解放されないまま残る状態。

DIライフタイムの取り違え

寿命の長いsingletonサービスがリクエスト単位のデータを保持してしまい、リクエストが終わってもオブジェクトが残ってしまう設計上の誤り。

LOH(Large Object Heap)

85,000バイト以上の大きなオブジェクトが置かれる特別なヒープ。

dotnet-counters

実行中の.NETプロセスのGCやWorking Setなどの傾向をリアルタイムに監視する診断ツール。

dotnet-gcdump

実行中の.NETプロセスからGC dumpを取得し、型ごとのCount/Sizeの統計を比較するための診断ツール。

dotnet-dump

プロセスのダンプ(ヒープダンプやクラッシュダンプ)を収集・解析する.NETの診断ツール。SOSコマンド(dumpheap・gcroot・clrstackなど)でヒープの参照元やスタックトレースを調べられるが、ネイティブのスタックフレームは扱えない。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

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