.NETはガベージコレクタ（GC）を介してメモリを自動的に管理します。オブジェクトはマネージドヒープに割り当てられ、到達不可能なオブジェクトは自動的に回収されるため、手動でメモリを解放する必要がありません。GC（ジェネレーション、スタック/ヒープの分割、IDisposable）を理解することはパフォーマンスと正確性にとって重要です。
Stack → value types (locals), method frames; fast, automatically freed when scope ends.
Heap → reference type objects (class instances); managed by the GC.
A reference variable lives on the stack but points to its object on the heap.
The GC divides the heap into GENERATIONS (based on the "most objects die young" idea):
Gen 0 → newest objects; collected FREQUENTLY (fast, cheap)
Gen 1 → survived one collection
Gen 2 → long-lived objects; collected RARELY (expensive)
(+ Large Object Heap for big objects)
→ Collecting young generations often + old ones rarely makes the GC efficient.
GCは到達可能なオブジェクト（ルート：スタック、静的フィールドから）をマークし、残りを回収します。ジェネレーショナルです。ほとんどのオブジェクトは若いうちに消滅するため、Gen 0は頻繁かつ安価に収集され、Gen 2の長命なオブジェクトはめったに収集されません。
// the GC handles MANAGED memory, but NOT unmanaged resources (files, connections, handles)
// → implement IDisposable and use `using` for deterministic cleanup
using (var file = new StreamReader("data.txt"))
{
// use file
} // file.Dispose() called automatically — releases the file handle NOW
GCはマネージドメモリを解放しますが、アンマネージドリソース（ファイルハンドル、DB接続、ソケット）は**IDisposable/Dispose()**を介した明示的なクリーンアップが必要です。usingステートメントはこれを確定的に保証します（GCを待つ必要がありません）。
The GC frees only UNREACHABLE objects. "Leaks" come from lingering references:
✗ static collections/caches that only grow
✗ un-unsubscribed event handlers (the publisher keeps subscribers alive!)
✗ long-lived objects holding references to short-lived ones
.NETのメモリ管理とガベージコレクションを理解することは、パフォーマンスが高く正確なC#を書くための貴重なシニアレベルの知識です。GCは手動メモリ管理（主要な生産性と安全性の利点で、手動のfreeとダングリングポインタを排除）から解放してくれますが、パフォーマンスが敏感なアプリケーションと細かいバグの回避にはそれがどのように機能するかを理解することが重要です。
ジェネレーショナルGC（Gen 0は頻繁かつ安価に収集、Gen 2はめったに収集されないが高コスト、ほとんどのオブジェクトが若いうちに消滅するという観察に基づく）を知ることで、割り当てパターンとGC圧力（特に短命なオブジェクトの割り当てを削減するとGCオーバーヘッドが低下）を推論するのに役立ちます。
スタック対ヒープの区別（値型はスタック上、参照オブジェクトはヒープ上）は値型/参照型モデルに関連しています。
重要なのは、IDisposable/Dispose()とusingステートメントを理解することは不可欠かつ実用的です。GCはメモリを管理しますがアンマネージドリソース（ファイルハンドル、データベース接続、ソケット）は管理しません。これらはusingを介した確定的なクリーンアップが必要です。これを破棄しないとリソースリーク（一般的な実在するバグ）が発生します。
同様に重要なのは、GCが存在するにもかかわらずメモリリークが依然として発生することを認識することです。残存する参照（成長する静的キャッシュ、購読者を生き続けさせるアンサブスクライブされたイベントハンドラー — 古典的なC#リーク）から発生します。
GCのジェネレーショナルモデル、リソース破棄パターン（IDisposable/using）、リークの原因を理解することは、効率的で漏れのないC#を書くために重要です。特に長時間実行されるアプリケーションでは重要です。これは効率的で正確な.NETアプリケーションを構築できる開発者を区別し、シニアレベルのインタビューで一般的なトピックである貴重な知識です。