Java GC の基礎

メモリを手で管理する言語では、確保したものを自分で返す必要がある。 これを人間がやると、三種類の失敗が必ず起きる。 返し忘れ（メモリリーク）、二度返し（double free）、 そして返した後にまだ使う（ダングリングポインタ）。

最後のひとつがとりわけ厄介で、壊れるのは「使った瞬間」ではなく、 その領域が別の用途に再利用された後の、まったく無関係に見える場所になる。 再現しないバグの温床であり、セキュリティ上の穴にもなる。

ガベージコレクタはこの三つをまとめて消す。 「もう誰からも使われていないオブジェクトを、処理系が見つけて回収する」—— やっていることはそれだけで、以降の話はすべて「どうやって見つけるか」と 「いつ、どれだけアプリを止めて片付けるか」のバリエーションでしかない。

直感的には「もう使わないオブジェクト」がゴミだが、処理系に未来は分からない。 そこで実際に使われる定義はこうなる—— GC Roots から参照をたどって到達できないものは、二度と使われない。 プログラムがオブジェクトに触る手段は参照しかないので、辿り着けないなら触れようがない。

GC Roots は「確実に生きている」と断言できる出発点の集合で、実行中のスレッドの スタックフレームにあるローカル変数、クラスの static フィールド、JNI の参照、 同期に使われているモニタなどが入る。

逆に言えば、ルートから辿れてしまうものは、使う気がなくても回収されない。 Java のメモリリークはほぼこの形で、static なコレクションやキャッシュ、 解除し忘れたリスナー、閉じ忘れた ThreadLocal が典型になる。 GC のバグではなく、参照が残っているという事実がすべて。

生きているものが分かった後、実際に領域を再利用可能にする操作は、 突き詰めると次の 3 つの組み合わせになる。どのコレクタも、 世代や領域ごとにこれらを選んで貼り合わせているだけと言ってよい。

実際のプログラムのオブジェクトの寿命を測ると、極端に偏った分布になる。 ループの中間結果、文字列連結の一時オブジェクト、イテレータ、ボクシングされた数値—— 大半は生まれてすぐ誰からも参照されなくなる。一方で、一度長生きしたものは その後も長生きしやすい（設定オブジェクト、キャッシュ、コネクションプール）。

これを弱世代仮説（weak generational hypothesis）と呼び、 Java の GC は 20 年以上この観測に賭けて設計されてきた。

この形が分かっているなら、ヒープ全体を毎回調べるのは無駄が多い。 そこでヒープを若い世代（Young）と古い世代（Old）に分け、 若い世代だけを高い頻度で、コピー方式で回収する。ほとんどがゴミなので、 コピーすべき生存者はごくわずかで済む。

若い世代はさらに Eden（新規割り当て先）と 2 つの Survivor に分かれる。 Eden が埋まると Minor GC が走り、生存者は Survivor へコピーされて年齢が 1 増える。 規定の年齢（-XX:MaxTenuringThreshold、既定 15）を超えたものは Old 世代へ昇格する。

-Xlog:gc（JDK 9 以降）を付けると、この 1 行が GC のたびに出る。 222M 減って 8.4ms——これが実際に読みたい数字で、 推測より先に、まずこのログを出すのが定石になる。

若い世代だけを回収したい。しかし「Old 世代のオブジェクトが Young のオブジェクトを指している」 場合、Young だけを見ると生存者を見落としてしまう。 かといって、それを探すために Old 世代を全部走査したら、世代を分けた意味がない。

そこで、参照を書き換える瞬間に記録しておく。 フィールドへの代入に短いコードを差し込む仕組みを書き込みバリア（write barrier）と呼び、 「Old → Young の参照が作られた」という事実を、カードテーブル（ヒープを一定サイズの カードに区切ったビットマップ）や Remembered Set に残す。 Minor GC はルートに加えて、この記録だけを追加で見ればよくなる。

同じ発想は世代以外にも効く。G1 はリージョンごとに Remembered Set（自分を指しているのは誰か）を持つので、ヒープの一部だけを独立して回収できる。 ZGC と Shenandoah は読み込み側にバリアを置き、 参照を読んだ瞬間に「このオブジェクトは移動済みか」を判定して、必要なら参照をその場で直す。 コピー中でもアプリを動かし続けられるのは、この読み込みバリアのおかげ。

オブジェクトグラフを辿っている最中に、アプリケーションが参照を書き換えたらどうなるか。 すでに「ゴミ」と判定した先に新しい参照が生まれると、生きているオブジェクトを回収してしまう—— これは即座にクラッシュを意味する。

いちばん単純な解決は、全部止めてから作業すること。これが Stop-the-World（STW）で、すべてのアプリケーションスレッドを 安全点（safepoint）——スタックの状態を正確に読み取れる決まった場所——まで走らせてから停止させる。

コレクタを選ぶときに見る軸は 3 つある。 スループット（総実行時間のうちアプリの仕事に使えた割合）、 レイテンシ（最悪の停止時間）、 フットプリント（GC のために余分に必要なメモリと CPU）。 どれかを上げると、ほぼ必ず他のどれかが下がる。

実際の選択は、多くの場合そう複雑ではない。 既定の G1 のままで要件を満たすならそれでよく、 バッチ処理でスループットが欲しいなら Parallel、 応答時間の裾（p99）が問題になっていて、かつヒープが大きいなら ZGC。 コンテナに小さなヒープを詰め込むなら Serial が妥当なこともある。

そして、その前にまず -Xlog:gc を出すこと。 止まっているのが本当に GC なのか、それとも別の何かなのかは、測らないと分からない。

ここまでの戦略は Java に固有のものではない。どの処理系も同じ問題を解いていて、 違うのは「どの軸を諦めたか」だけ。Java のコレクタを地図の目印にすると、 他の言語の GC も同じ平面の上に置ける。

表に収まらないのが、Java が最初から採らなかった道を選んだ処理系たち。 トレース方式そのものを使わない、あるいはヒープの持ち方から変えてしまう設計になる。