はじめに

前回の記事で、new したオブジェクトはヒープに置かれることを学びました。では、使い終わったオブジェクトは誰が片付けてくれるのでしょうか？

その答えが GC（ガベージコレクション） です。C言語のように free() を書かなくていいのはGCのおかげですが、「何となく動いてくれてるんでしょ」で止まっているともったいない。この記事では、GCが何をしているのかをザックリ掴みます。

対象読者: Java実務1〜3年目。GCという言葉は知っているが、中身はよくわからないエンジニア

1. GCがやっていること ― ひとことで言うと

誰からも参照されなくなったオブジェクトを見つけて、ヒープから消す

これだけです。逆に言えば、どこかから参照されている限りオブジェクトは消えません。

コードで確認

public class GcDemo {
    public static void main(String[] args) {
        String a = new String("Hello"); // ① オブジェクト生成、aが参照
        String b = new String("World"); // ② オブジェクト生成、bが参照

        a = null;  // ③ "Hello"への参照がなくなる → GC対象になる
        // この時点で "World" はまだbが参照しているので回収されない
    }
}

2. 世代別GCの考え方

JVMのGCは「ほとんどのオブジェクトはすぐ不要になる」という経験則に基づいて設計されています。これを**世代別GC（Generational GC）**と呼びます。

ヒープの構成

領域	役割	GCの特徴
Eden	`new` したオブジェクトが最初に入る場所	いっぱいになるとMinor GCが走る
Survivor (S0/S1)	Minor GCを生き延びたオブジェクトの一時置き場	S0とS1を交互に使う
Old世代	何度もMinor GCを生き延びた長寿オブジェクト	Full GCで回収（重い処理）

ライフサイクルの流れ

// メソッドが呼ばれるたびに一時オブジェクトが大量に作られるケース
public List<String> processData(List<Integer> numbers) {
    return numbers.stream()
        .map(n -> "Item-" + n)    // ← ここで短命なStringが大量にnewされる
        .collect(Collectors.toList());
}

"Item-" + n で作られるStringは Eden に入る
Edenがいっぱいになると Minor GC が走る
もう参照されていないStringはここで回収される（大半がこれ）
まだ使われているオブジェクトは Survivor へ移動
Survivorで何度も生き残ったオブジェクトは Old世代 へ昇格

つまり、短命なオブジェクトはYoung世代で素早く回収され、長生きするオブジェクトだけがOld世代に行くという効率的な仕組みです。

3. GCが走ると何が起きる？ ― Stop-the-World

GCが動いている間、アプリケーションのスレッドは一時停止します。これを Stop-the-World（STW） と呼びます。

Minor GCの停止時間は通常ミリ秒単位なので、ほとんどのアプリケーションでは気になりません。ただし、Full GC（Old世代の回収） は数百ミリ秒〜数秒かかることがあり、レスポンスタイムに影響します。

実務での影響例

// ありがちなパターン：キャッシュをMapで持ち続ける
private static Map<String, Object> cache = new HashMap<>();

public void addToCache(String key, Object value) {
    cache.put(key, value);  // staticフィールドなのでGCに回収されない
    // → cacheが肥大化 → Old世代が圧迫 → Full GCが頻発
}

このようなコードは、意図せずOld世代を圧迫してFull GCの頻度を上げてしまいます。

4. GCの種類（ざっくり）

Java 11以降で使えるGCの代表的なものを紹介します。深入りはしませんが、名前だけ知っておくと調査時に役立ちます。

GCの種類	特徴	向いている用途
G1GC	Java 9以降のデフォルト。バランス型	一般的なWebアプリ
ZGC	STW時間を極端に短く抑える（1ms以下目標）	低レイテンシが求められるシステム
Shenandoah	ZGCと同様の低停止時間を目指す	同上（OpenJDK系）

現時点では「G1GCがデフォルトで動いている」ということだけ押さえておけばOKです。

5. GCログを見てみよう（おまけ）

GCが実際にどう動いているかは、JVM起動オプションでログを出せます。

# Java 11以降
java -Xlog:gc* -jar myapp.jar

出力例（抜粋）:

[0.015s][info][gc] Using G1
[1.234s][info][gc] GC(0) Pause Young (Normal) 24M->8M(256M) 3.456ms
[3.456s][info][gc] GC(1) Pause Young (Normal) 32M->10M(256M) 4.123ms

読み方:

Pause Young → Minor GC（Young世代の回収）
24M->8M → GC前24MB使用 → GC後8MBに減った
3.456ms → 停止時間

「Full GCが頻繁に出ていたら要注意」と覚えておけば、実務のトラブル調査で最初の手がかりになります。

まとめ

GCは参照されなくなったオブジェクトをヒープから消す仕組み
ヒープは Young世代（Eden + Survivor） と Old世代 に分かれている
ほとんどのオブジェクトはYoung世代で短命に回収される
GC中はアプリが一時停止する（Stop-the-World）
Full GCが頻発するとパフォーマンスに影響するので注意

次回は、GCでも回収しきれずヒープが溢れてしまった場合に起きる OutOfMemoryError の対処法を解説します。

シリーズ記事

第1回: ヒープとスタック
第2回: GC（ガベージコレクション）の基本（この記事）
第3回: OutOfMemoryErrorが出たらどうする？（近日公開）