Javaパフォーマンス第2版

第5章. ガベージ・コレクション入門

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この章では、JVM内のガベージ・コレクションの基本について説明する。コードを書き換えることを除けば、ガベージ・コレクタのチューニングは、Javaアプリケーションのパフォーマンスを向上させるためにできる最も重要なことである。

Javaアプリケーションの性能はガベージ・コレクション技術に大きく依存するため、かなりの数のコレクターが利用可能であることは驚くべきことではない。OpenJDKには、実運用に適したコレクターが3つ、JDK 11では非推奨だがJDK 8ではまだかなり人気のあるコレクターが1つ、そして（理想的には）将来のリリースで実運用に対応する実験的なコレクターがいくつかある。Open J9やAzul JVMのような他のJava実装には、独自のコレクターがある。

これらすべてのコレクターの性能特性はかなり異なるので、ここではOpenJDKに付属しているものだけに焦点を当てる。 それぞれについては次の章で詳しく説明するが、基本的な概念は共通しているので、この章ではコレクターがどのように動作するかの基本的な概要を説明する。

ガベージコレクションの概要

Javaでのプログラミングの最も魅力的な特徴のひとつは、開発者がオブジェクトのライフサイクルを明示的に管理する必要がないことだ。 必要なときにオブジェクトが作成され、オブジェクトが使用されなくなると、JVMが自動的にオブジェクトを解放する。 私のように、Javaプログラムのメモリ使用を最適化することに多くの時間を費やしている場合、この仕組み全体が特徴ではなく弱点のように思えるかもしれない（GCの説明に多くの時間を費やすと、その立場に信憑性があるように思えるかもしれない）。確かに、この仕組みは天の恵みとも言えるが、他の言語ではヌル・ポインタやダングリング・ポインタを追跡するのが難しかったことを思い出す。ガベージ・コレクタのチューニングは、ポインタのバグを追跡するよりもはるかに簡単だ（そして時間もかからない）と私は強く主張したい。

基本的なレベルでは、GCは使用中のオブジェクトを発見し、残りのオブジェクト（使用されていないオブジェクト）に関連するメモリを解放することからなる。 これは、もはや参照を持たないオブジェクトを発見すると表現されることもある（参照がカウントによって追跡されることを意味する）。 しかし、そのような参照カウントは不十分である。オブジェクトのリンクリストがある場合、リスト内の各オブジェクト（先頭を除く）は、リスト内の別のオブジェクトから指されていることになる。また、リストが循環している場合（例えば、リストの末尾が先頭を指している場合）、リスト内のすべてのオブジェクトがそのオブジェクトへの参照を持っている。

そのため、カウントによって動的に参照を追跡することはできない。その代わりに、JVMは定期的にヒープを検索して未使用のオブジェクトを探す必要がある。これは、ヒープの外からアクセス可能なオブジェクトであるGCルートであるオブジェクトから始めることによって行われる。これには主にスレッド・スタックとシステム・クラスが含まれる。これらのオブジェクトは常に到達可能なので、GCアルゴリズムはルート・オブジェクトのいずれかを経由して到達可能なすべてのオブジェクトをスキャンする。GCルートを経由して到達可能なオブジェクトはライブ・オブジェクトであり、残りの到達不可能なオブジェクトは（たとえそれがライブ・オブジェクトへの参照や相互参照を保持していたとしても）ガベージである。 ...