JVMのメモリとガベージコレクションはどのように機能しますか?

Question

Accepted Answer

JVMは**メモリを自動的に管理**します — オブジェクトを割り当て、**ガベージコレクション（GC）**を通じて到達不可能なものを解放します — つまり、メモリを手動で解放する必要がありません。メモリ領域とGCの動作を理解することは、パフォーマンスをチューニングしメモリの問題を診断するために重要です。 ## JVMのメモリ領域 ```text HEAP — where all OBJECTS live (shared across threads), GC operates here ├── Young Generation — new objects (most die young) │ ├── Eden — new allocations go here │ └── Survivor — objects that survived a young GC └── Old (Tenured) Gen — long-lived objects (promoted from young) STACK — per-thread; method frames, local variables, primitive locals, references Metaspace — class metadata (replaced PermGen in Java 8+) ``` オブジェクトは**ヒープ**上に存在し、ローカル変数と参照はスレッドごとの**スタック**上に存在します。GCはヒープに焦点を合わせます。 ## 世代仮説 ```text Observation: MOST objects die young (short-lived). → GC splits the heap into generations and collects the young gen FREQUENTLY (cheap, fast) and the old gen RARELY (expensive). ``` ## GCの仕組み：マークアンドスイープ ```text 1. MARK — starting from GC roots (stack refs, static fields), mark all REACHABLE objects 2. SWEEP — reclaim memory of unmarked (unreachable) objects 3. COMPACT— (often) move survivors together to reduce fragmentation ``` オブジェクトがガベージになるのは、GCルートから**到達可能**でなくなった場合です。あなたがそれを解放することはありません — GCがそれを見つけて回収します。 ## Minor GC vs Major GC ```text Minor GC — collects the Young Generation; frequent, fast, short pause Major/Full GC — collects the Old Generation (and more); rarer, longer pause → long Full GC pauses ("stop-the-world") are a common performance concern ``` ## GCアルゴリズム（ワークロードに応じて選択） ```text G1 GC (default, Java 9+) — balanced, predictable pause times, good general choice Parallel GC — max throughput (batch jobs), longer pauses acceptable ZGC / Shenandoah — very low pause times for large heaps (latency-sensitive apps) ``` ## メモリリークは依然として発生します（GCがあっても） ```java // ❌ a leak: a static collection that only grows keeps objects REACHABLE forever static List

JVMのメモリ領域

世代仮説

GCの仕組み：マークアンドスイープ

Minor GC vs Major GC

GCアルゴリズム（ワークロードに応じて選択）

メモリリークは依然として発生します（GCがあっても）

なぜ重要なのか