『クラウドネイティブJavaの最適化 第2版』

第4章 ガベージ・コレクションを理解する

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

この章では、JVMのガベージコレクション サブシステムを紹介する。基本的な理論 のマークとスイープ（トレース・ガベージコレクションとしても知られている）の概要から始めてアプローチする。 その後、HotSpotランタイムの低レベルの機能と、実行時にJavaオブジェクトをどのように表現するかを見ていく。

章の後半では、HotSpotがアロケーションに使用する2つの重要なテクニックを説明する前に、アロケーションとライフタイムの重要な概念について説明します。 その後、これまで説明したトピックをすべてまとめ、HotSpotのプロダクションコレクタの中で最もシンプルな 、パラレルコレクタを紹介し、多くのプロダクションワークロードに役立つ詳細について説明します。

注

ガベージコレクションは膨大なテーマなので、この章では入門的な内容しかカバーできない。第5章では、より高度なトピックの一部を取り上げる。

まず、Java環境にはいくつかの象徴的あるいは定義的な特徴があり、ガベージ・コレクションは最もすぐに認識できる特徴の一つであることに注目しよう。

Javaのガベージ・コレクションの本質は、プログラマがシステム内のすべてのオブジェクトの寿命（ ）を正確に理解することを要求するのではなく、ランタイムがプログラマに代わってオブジェクトを追跡し、不要になったオブジェクトを自動的に取り除くことである。 自動的に取り戻されたメモリは、消去して再利用することができる。

しかし、プラットフォームがリリースされた当初は、GCに対してかなりの敵意があった。 これは、Javaがコレクターの振る舞いを制御する言語レベルの方法を意図的に提供しなかった（そして、最新のバージョンでも、それは続いている）という事実によって煽られた。

注

System.gc() メソッドは存在するが、基本的に実用的な目的には使えない。¹

このため、初期の頃は、JavaのGCのパフォーマンスがあまり良くないことに加えて、Javaの機能に対する不満がある程度あった。 これはプラットフォーム全体に対する認識にも影響し、今日でも、JavaのGCが問題だと、間違った思い込みをしている人に出会うことがある。 実際のところ、最近のJavaのGCは信じられないほど高速（クラス最高）で、大半の実運用ワークロードに完全に適している。

実際、強制的でユーザが制御できないGCという初期の構想は、十分すぎるほど正当化されており、最近では、メモリを手作業で管理すべきだという意見を守ろうとするアプリケーション開発者はほとんどいない。 最新のシステムプログラミング言語（例えば、RustやGo）でさえ、メモリ管理はプログラマではなく、それぞれコンパイラとランタイムの適切な領域とみなしている。²

ガベージコレクションには2つの基本規則があり、すべての実装がこれを守るよう努力している：

• 生きているオブジェクトは決して回収してはならない。

• アルゴリズムはすべてのゴミを回収しなければならない。

この2つの規則のうち、前者が圧倒的に重要である。生きているオブジェクトを収集すると、セグメンテーション・フォールトや、（さらに悪いことに）プログラム・データの無言の破損につながる可能性がある。JavaのGCアルゴリズムは、プログラムがまだ使用しているオブジェクトを決して収集しないことを確認する必要がある。 ...