JVMとガベージの関係

[[408351]]

この記事はWeChatの公開アカウント「Code on Java」から転載したもので、著者はCode on Javaです。この記事を転載する場合は、Java Code の公開アカウントにお問い合わせください。

始める前に、ヒープとは何かを確認しましょう。ご存知のとおり、私たちが日々作成するほぼすべての Java オブジェクトはヒープ上に保存されるため、ヒープは管理者が巨大なオブジェクト インスタンスを管理する巨大なオブジェクト プールであると言っても過言ではありません。

オブジェクト プール内のオブジェクトの参照階層は、非常に深くなる場合があります。たとえば、非常に頻繁に呼び出されるインターフェースの場合、オブジェクトの生成速度は非常に優れています。オブジェクト間の関係はネットワークとして記述できます。 Java ではメモリが無限にあるという印象を常に与えますが、オブジェクトは減少せずに増加し続けることはできないため、ガベージ コレクション操作が必要になります。

では、JVM はどのようにしてガベージを見つけるのでしょうか?

この記事では、「ガベージ コレクション」を GC と呼びます。

テレビシリーズ「九族滅亡」を覚えていますか？

例えば、蕭寒皮は皇帝を平手打ちし、皇帝の目は黒くなり、顔は腫れ上がった。皇帝は非常に怒り、憎しみを晴らすために蕭寒皮の9つの氏族を処刑するよう命じようとしました。

ハハハハ～シャオハンの批判は終わりました～

それでは、古代の九族絶滅がどのように行われたのか見てみましょう。まず、共通の祖先（つまり、小漢皮家の長兄）まで遡り、小漢皮と関係のある人物を一人ずつ数える必要があります（小漢皮は本当に詐欺です）。

実は、ヒープ上で行われるガベージコレクションもこの「九族殺し」と同じ考え方なので、JVM がどのように GC を実行するのかを詳しく分析してみましょう。

JVM の GC はプログラムによって制御されず、特定の条件が満たされたときに自動的にトリガーされます。

GC が発生すると、オブジェクトに対して、JVM は常にそれを参照する祖先を見つけることができます。最後のオブジェクトが見つかると、JVM はこのオブジェクトの祖先の一部がすでに終了していることを検出するため、それらは JVM によって強制終了されます。

なぜまだ殺されていない先祖がいるのでしょうか？なぜなら、GC から逃れたこれらの祖先は GC ルーツであり、非常に特別な外見をしているからです (外見については以下で紹介します)。

GC ルートから下方向にトレースして検索すると、参照チェーンが生成されます。オブジェクトに GC ルートが関連付けられていない場合、そのオブジェクトは容赦なく強制終了されます。 （ロープについたバッタ）

何が起こっているのかを確認するために絵を描いてみましょう。次の図に示すように、Object5、Object6、および Object7 は GC ルートに関連付けることができず、GC が発生すると破棄されます。

実際、いわゆるガベージ コレクションは GC ルートを中心に展開されますが、同時に、他の参照兄弟にはまったくこの権限がないため、GC ルートは多くのメモリ リークの原因にもなります。

GC ルートとはどのようなオブジェクトなのか疑問に思うかもしれません。

それがどんな物かは関係なく、それがどこにあるかが鍵です（よく考えてくださいね～）。

GC ルートとは何ですか?

まず、GC ルートはアクティブである必要がある参照のセットである必要があります。簡単に言えば、プログラムが直接または間接的な参照を通じてアクセスできる潜在的なオブジェクトです (まだ少しわかりにくい気がします)。

GC ルートは次のようになります。

1. Java スレッドでは、現在呼び出されているすべてのメソッドの型パラメータ、ローカル変数、一時値などを参照します。つまり、スタック フレームに関連するさまざまな参照です。
2. 現在ロードされているすべての Java クラス。
3. Java クラスの参照型静的変数。
4. ランタイム定数プール内の参照型定数。
5. sun.jvm.hotspot.memory.Univers クラスなどの JVM 内部データ構造への参照。
6. 同期のオブジェクトを監視します。たとえば、オブジェクトの wait() メソッドが呼び出されます。
7. グローバル ハンドルとローカル ハンドルを含む JNI ハンドル。

上記のGCルートは、大きく分けて以下の3つのカテゴリーに分類できます。

1. アクティブ スレッドに関連するさまざまな参照。
2. クラスの静的変数への参照。
3. JNI 参照。

最後に、ここではオブジェクトではなく、アクティブな参照について話していることに注意してください。オブジェクトは GC ルートとして使用できません。

GC プロセス全体は、これらの生きているオブジェクトを見つけて、残りのスペースを「役に立たない」ものとして認識することです。代わりに、すべての死んだオブジェクトを見つけて、それらが占めていたスペースを再利用します。つまり、JVM ヒープが非常に大きい場合でも、トレース GC 方式に基づくと回復速度は依然として高速です。

要約する

GC ルートは到達可能性分析方法です。参照カウントと呼ばれる方法もあります。以下に簡単に紹介させていただきます。

参照カウント方式: Java では、オブジェクトを操作する場合、まずそのオブジェクトへの参照を取得する必要があります。したがって、参照カウント方式を使用して、オブジェクトがリサイクル可能かどうかを判断できます。オブジェクトに参照が追加されると、参照カウンターが 1 増加します。オブジェクトから参照が削除されると、参照カウンタは 1 減少します。オブジェクトの参照カウントが 0 の場合、そのオブジェクトは参照されておらず、リサイクル可能であることを意味します。

利点は、ガベージコレクションがよりタイムリーかつリアルタイムになることです。オブジェクト カウンターが 0 である限り、リサイクル操作を直接実行できます。欠点は、循環参照の問題を解決できないことです。

循環参照の致命的な欠陥のため、主流の JVM では GC を実装するために参照カウントを使用しないため、参照カウントについては完全に忘れてかまいません。