JVM チューニング: ガベージの場所、ガベージコレクションアルゴリズム、ガベージプロセッサの比較

ガベージコレクターについて説明する前に、まずガベージコレクションアルゴリズムと JVM のガベージ識別戦略について説明する必要があります。JVM ガベージコレクターは、ガベージコレクションアルゴリズムの具体的な実装です。これまでの前提知識を理解することで、ガベージコレクターを理解するのに役立ちます。

ゴミとは何ですか？

ガベージは主にヒープ上のオブジェクトを指しますが、これらのオブジェクトがリサイクル可能かどうかをどのように判断するのでしょうか?

一般的な考え方としては、オブジェクトにアクセスできない場合は、そのオブジェクトはゴミであり、リサイクルできるということです。そのオブジェクトが決して使用されないことをどうやって確認できるでしょうか?

参照カウント

オブジェクトに参照カウンターを追加します。どこかから参照されるたびに、カウンターの値が 1 増加します。参照が無効になると、カウンターの値が 1 減少します。カウンターが 0 のオブジェクトは、使用できなくなります。しかし、Java 分野では、少なくとも主流の Java 仮想マシンは、メモリを管理するために参照カウントアルゴリズムを使用していません。主な理由は、この一見単純なアルゴリズムには考慮すべき例外が多く、正しい動作を保証するために多くの追加処理と組み合わせる必要があるためです。たとえば、単純な参照カウントでは、オブジェクト間の循環参照の問題をほとんど解決できません。

図に示すように、各オブジェクトの参照は 1 であり、循環参照を構成していますが、他のオブジェクトからアクセスすることはできません。これらの 2 つのオブジェクトには参照がなくなり、参照カウントアルゴリズムはそれらをリサイクルできません。

コード検証:

パッケージcom.courage;
公共 クラスReferenceCountingGC {
パブリックオブジェクトインスタンス = null ;
プライベート 静的 ファイナル 整数_1MB = 1024 * 1024 ;
 /**
     * このメンバープロパティの唯一の目的は、メモリを占有して、リサイクルされたかどうかをGCログで明確に確認できるようにすることです。
     */  
プライベート バイト[] bigSize =新しい バイト[ 5 * _1MB];
公共 静的  void testGC() {
 //5 万 
        ReferenceCountingGC objA =新しいReferenceCountingGC();
 //5 万 
        ReferenceCountingGC objB =新しいReferenceCountingGC();
        objA インスタンス = objB;
        objB インスタンス = objA;
        objA = null ;
        objB = null ;
 // この行で GC が発生すると仮定すると、objA と objB はリサイクルできますか?  
        システム.gc();
    }
公共 静的  void main(String[] args) {
        テストGC();
    }
 }

実行結果:

 [ 0 .004s][警告][gc] -XX:+PrintGCDetails は非推奨です。代わりに -Xlog:gc* を使用します。
 [ 0 .012s][info ][gc,heap] ヒープ領域サイズ: 1M
 [ 0 .015s][info][gc ] G1の使用
[ 0 .015s][info ][gc,heap,coops] ヒープ アドレス: 0x0000000701000000 、サイズ: 4080 MB、圧縮 Oops モード: ゼロ ベース、Oop シフト量: 3  
 ......
 [ 0 .119s][info][gc,metaspace ] GC( 0 ) メタスペース: 805K->805K(1056768K)
 [ 0 .119s][info][gc ] GC( 0 ) 一時停止フル (System.gc()) 14M->0M(8M) 2 .886ms
 [ 0 .119s][info ][gc,cpu ] GC( 0 ) ユーザー= 0 .03s システム= 0 .00s 実数= 0 .00s
 [ 0 .120s][info][gc,heap,exit ] ヒープ
......

長さの関係で、出力内容の一部を省略しました。System.gc() 後、メモリ使用量が 14M から 0M に削減され、10M のオブジェクトが解放されていることがわかります。つまり、JVM はガベージをマークするために参照カウントを使用しません。

ルート到達可能性アルゴリズム

このアルゴリズムの基本的な考え方は、「GC ルート」と呼ばれる一連のルートオブジェクトを開始ノードセットとして使用し、これらのノードから開始して、参照関係に従って下方向に検索することです。検索プロセス中に横断されるパスは、「参照チェーン」と呼ばれます。オブジェクトを GC ルートに接続する参照チェーンがない場合、またはグラフ理論の用語で言えば、オブジェクトが GC ルートから到達できない場合、オブジェクトは使用できなくなったことが証明されます。

Java テクノロジーシステムでは、次のオブジェクトを GC ルートとして使用できます。

各スレッドが呼び出すメソッドスタック内で使用されるパラメータ、ローカル変数、一時変数などの仮想マシンスタック（スタックフレーム内のローカル変数テーブル）内で参照されるオブジェクト、Java クラスの参照型静的変数などのメソッド領域内のクラス静的属性によって参照されるオブジェクト。
文字列定数プール (文字列テーブル) 内の参照など、メソッド領域内の定数によって参照されるオブジェクト。
ネイティブメソッドスタック内の JNI (一般にネイティブメソッドと呼ばれる) によって参照されるオブジェクト。
Java仮想マシン内の参照、例えば基本データ型に対応するクラスオブジェクト、一部の常駐例外オブジェクト（
システムクラスローダーだけでなく、NullPointExcepiton、OutOfMemoryError などにも適用されます。
同期ロック (synchronized キーワード) によって保持されるすべてのオブジェクト。
Java 仮想マシンの内部状況、JVMTI に登録されたコールバック、ローカルコードキャッシュなどを反映する JMXBean。

ガベージコレクションアルゴリズム

この記事では、Java 仮想マシンのさまざまなガベージコレクターのアルゴリズムの基礎となる、3 つの一般的なガベージコレクションアルゴリズム (mark-sweep、mark-compact、mark-copy) について説明します。

ガベージコレクションアルゴリズムのアイデア

現在市販されている仮想マシン用のガベージコレクターのほとんどは、「世代別コレクション」の理論に基づいて設計されています。世代別コレクションは理論と呼ばれていますが、実際にはほとんどのプログラムの実際の実行条件に適合する一連の経験的ルールです。これは、次の 2 つの世代仮説に基づいています。

1) 弱い世代仮説: 物体の大部分は一夜にして生まれ、そして死んでいきます。

2) 強力な世代仮説: オブジェクトがガベージコレクションを生き残る回数が増えるほど、消滅しにくくなります。

これら 2 つの世代仮説は、一般的に使用されている多くのガベージコレクターの一貫した設計原則の基礎となっています。つまり、コレクターは Java ヒープを複数の領域に分割し、回収されたオブジェクトをその年齢 (年齢とは、オブジェクトがガベージコレクションプロセスを生き延びた回数) に応じて異なる領域に割り当てて保存する必要があります。明らかに、ある領域内のほとんどのオブジェクトが一夜にして生まれて死んでしまい、ガベージコレクションプロセスを生き延びるのが難しい場合は、それらをまとめて、リサイクルされる多数のオブジェクトをマークするのではなく、毎回少数の生き残ったオブジェクトを保持する方法に焦点を当てることで、低コストで大量のスペースを回収できます。

残りのオブジェクトを破棄するのが難しい場合は、それらをまとめると、仮想マシンは、ガベージコレクションの時間オーバーヘッドとメモリ領域の有効利用の両方を考慮した上で、より低い頻度でこの領域を再利用できるようになります。

マークスイープ

アルゴリズムは、「マーキング」と「クリア」の 2 つの段階に分かれています。まず、リサイクルが必要なすべてのオブジェクトをマークします。マーキング後、マークされたすべてのオブジェクトをリサイクルします。逆に、生き残ったオブジェクトをマークし、マークされていないすべてのオブジェクトをリサイクルします。

主な欠点は 2 つあります。

1 つ目は、実行効率が不安定であることです。Java ヒープに多数のオブジェクトが含まれており、そのほとんどをリサイクルする必要がある場合、多数のマーキングとクリア操作を実行する必要があり、オブジェクトの数が増えるにつれて、マーキングとクリアの両方のプロセスの実行効率が低下します。

2 つ目は、メモリ空間の断片化の問題です。マーキングとクリアの後、不連続なメモリ断片が大量に生成されます。空間の断片化が多すぎると、プログラム実行中に大きなオブジェクトを割り当てる必要があるときに連続メモリが不足し、事前に別のガベージコレクションアクションをトリガーする必要があります。

マークコピー

マークコピーアルゴリズムは、コピーアルゴリズムとも呼ばれます。使用可能なメモリを容量に応じて 2 つの同じサイズのブロックに分割し、一度にそのうちの 1 つだけを使用します。このメモリブロックが使い果たされると、残っているオブジェクトが別のブロックにコピーされ、使用済みのメモリ領域がすぐにクリーンアップされます。

メモリ内のほとんどのオブジェクトが生きている場合、このアルゴリズムは大量のメモリコピーオーバーヘッドを生成します。ただし、ほとんどのオブジェクトがリサイクル可能な場合、アルゴリズムは生き残った少数のオブジェクトをコピーするだけでよく、そのたびにメモリは半分の領域全体で再利用されます。メモリを割り当てるときは、スペースの断片化の複雑な状況を考慮する必要はありません。ヒープの先頭のポインタを移動して、順番に割り当てるだけです。これは実装が簡単で、実行も効率的ですが、欠点も明らかです。このコピーリサイクルアルゴリズムのコストは、使用可能なメモリを元のサイズの半分に減らすことであり、これによりスペースが無駄になりすぎます。

マークコンパクト

マークコピーアルゴリズムは、オブジェクトの生存率が高い場合、より多くのコピー操作を実行し、効率が低下します。さらに重要なのは、スペースの 50% を無駄にしたくない場合は、使用済みメモリ内のすべてのオブジェクトが 100% 有効であるという極端な状況に対処するために、割り当て保証のための追加のスペースが必要になるため、このアルゴリズムは古い世代では直接選択できないことです。

マーク圧縮アルゴリズムのマーキングプロセスは、マークスイープアルゴリズムと同じですが、後続のステップでは、リサイクル可能なオブジェクトを直接クリーンアップするのではなく、残っているすべてのオブジェクトをメモリ空間の一方の端に移動し、境界外のメモリを直接クリーンアップします。

マークスイープアルゴリズムとマークコンパクトアルゴリズムの本質的な違いは、前者が非モバイルリサイクルアルゴリズムであるのに対し、後者はモバイルリサイクルアルゴリズムである点です。コレクション後に残存オブジェクトを移動するかどうかは、利点と欠点の両方があるリスクのある決定です。残存オブジェクトを移動すると、特に各コレクションに多数の残存オブジェクトがある古い世代では、残存オブジェクトの移動とこれらのオブジェクトを参照するすべての場所の更新が非常に重い操作になり、このオブジェクト移動操作は、実行されるプロセス全体にわたってユーザーアプリケーションを一時停止する必要があります (STW 問題)。

ゴミ処理機

上記の 3 つのガベージコレクションアルゴリズムに基づいて、次の 7 つのガベージコレクターが派生します。

シリアルコレクター

このコレクターはシングルスレッドコレクターですが、その「シングルスレッド」の意味は、ガベージコレクション作業を完了するために 1 つのプロセッサまたは 1 つのコレクションスレッドのみを使用することを意味するだけではなく、より重要なことは、ガベージを収集しているときは、収集が完了するまで他のすべての作業スレッドを一時停止する必要があることを強調していることです。

現在でも、クライアントモードで実行されている HotSpot 仮想マシンのデフォルトの新世代コレクターです。他のコレクターに比べてシンプルで効率的であるという利点があります (他のコレクターのシングルスレッドコレクターと比較して)。メモリリソースが限られている環境では、すべてのコレクターの中で追加のメモリ消費量 (メモリフットプリント) [1] が最も小さくなります。シングルコアプロセッサまたはプロセッサコアの数が少ない環境では、Serial コレクターにはスレッド相互作用のオーバーヘッドがなく、ガベージコレクションに重点を置くことで、自然に最高のシングルスレッドコレクション効率を実現できます。シリアルコレクターは、クライアントモードで実行されている仮想マシンに適しています。

パーニューコレクター

ParNew コレクターは、本質的には Serial コレクターのマルチスレッド並列バージョンですが、複数のスレッドを使用して同時にガベージを収集する点が異なります。

さらに、残りの動作には、シリアルコレクターで使用可能なすべての制御パラメータが含まれます（例：-XX:SurvivorRatio、-XX:

PretenureSizeThreshold、-XX:HandlePromotionFailure など)、コレクションアルゴリズム、Stop The World、オブジェクト割り当てルール

ルールとリサイクル戦略は Serial コレクターとまったく同じであり、2 つのコレクターは実装でも多くのコードを共有しています。

ParNew コレクターは、マルチスレッド並列コレクションをサポートしていることを除けば、Serial コレクターと比べてそれほど革新的な点はありません。

ただし、これは、サーバーモードで実行されている多くの HotSpot 仮想マシン、特に JDK 7 より前のレガシーシステムでは、推奨される新世代のコレクションです。

機能やパフォーマンスとはまったく関係のない、非常に重要な理由があります。

シリアルコレクターに加えて、現在CMSで使用できる唯一のコレクターです。

コレクターは仕事に協力し、CMSの出現はParNewの地位を強化します

スレッドが存在する場合でも、シングルコアプロセッサ環境では、ParNew コレクターのパフォーマンスが Serial コレクターよりも優れていることはありません。

相互作用のオーバーヘッドのため、このコレクターは、ハイパースレッディングテクノロジによって実装された疑似デュアルコアプロセッサ環境において、シリアルコレクターを上回ることを 100% 保証することはできません。もちろん、使用できるプロセッサコアの数が増えるにつれて、ガベージコレクションにとって ParNew の重要性は高まります。

システムリソースを効率的に使用することは、依然として非常に有益です。

パラレルスカベンジコレクター

Parallel Scavenge コレクターも新世代のコレクターです。これは、マークコピーアルゴリズムに基づくコレクターであり、並列コレクションが可能なマルチスレッドコレクターでもあります... 表面的には、Parallel Scavenge の多くの機能は ParNew と非常に似ていますが、何が特別なのでしょうか。

Parallel Scavenge コレクターの特徴は、その焦点が他のコレクターと異なることです。CMS などのコレクターの焦点は、ガベージコレクション中のユーザースレッドの一時停止時間を可能な限り短縮することですが、Parallel Scavenge コレクターの目標は、制御可能なスループットを実現することです。いわゆるスループットは、プロセッサがユーザーコードを実行するために使用する時間とプロセッサが消費する合計時間の比率です。

仮想マシンがタスクを完了し、ユーザーコードとガベージコレクションの合計が 100 分かかり、そのうちガベージコレクションに 1 分かかる場合、スループットは 99% になります。一時停止時間が短いほど、ユーザーと対話する必要があるプログラムや、サービス応答の品質を保証する必要があるプログラムに適しています。応答速度が速いと、ユーザーエクスペリエンスが向上します。スループットが高いと、プロセッサリソースを最も効率的に使用し、プログラムのコンピューティングタスクをできるだけ早く完了できます。これは主に、バックグラウンドで実行され、多くの対話を必要としない分析タスクに適しています。

スループットと密接な関係があるため、Parallel Scavenge コレクターは「スループット優先コレクター」と呼ばれることがよくあります。

シリアルオールドコレクター

Serial Old は Serial コレクターの古いバージョンです。これも、マークスイープアルゴリズムを使用するシングルスレッドコレクターです。このコレクターの主な目的は、クライアントモードの HotSpot 仮想マシンによって使用されることです。サーバーモードの場合、2 つの用途があります。1 つは、JDK 5 以前のバージョンの Parallel Scavenge コレクターで使用することであり、もう 1 つは、CMS コレクターが失敗した場合のバックアッププランとして使用し、同時収集で同時モード障害が発生した場合に使用することです。

パラレルオールドコレクター

Parallel Old は、マルチスレッドの同時コレクションをサポートし、マークスイープアルゴリズムに基づいて実装された Parallel Scavenge コレクターの旧世代バージョンです。このコレクターは、JDK 6 までは提供されていませんでした。それ以前は、新世代の Parallel Scavenge コレクターはかなり扱いにくい状態でした。その理由は、新世代に Parallel Scavenge コレクターを選択した場合、旧世代には Serial Old (PSMarkSweep) コレクターしか選択の余地がなかったためです。CMS など、パフォーマンスの優れた他の旧世代コレクターは、これと連携できませんでした。

Serial Old コレクターはサーバー側アプリケーションのパフォーマンスに「悪影響を及ぼす」ため、Parallel Scavenge コレクターを使用しても、必ずしも全体のスループットを最大化する効果が得られない場合があります。

同様に、シングルスレッドの旧世代コレクションでは、サーバーの複数のプロセッサの並列処理機能を十分に活用できないため、旧世代のメモリ空間が大きく、ハードウェア仕様が比較的高度な動作環境では、この組み合わせの合計スループットは、ParNew と CMS の組み合わせよりも優れない可能性があります。 Parallel Old コレクターが登場して初めて、「スループット優先」コレクターはより現実的な組み合わせを持つようになりました。スループットが重要であるか、プロセッサリソースが不足している状況では、Parallel Scavenge コレクターと Parallel Old コレクターの組み合わせを優先できます。

CMS コレクター

CMS (Concurrent Mark Sweep) コレクターは、コレクションの一時停止時間を最小限に抑えることを目的としたコレクターです。現在、多数の Java アプリケーションが、インターネット Web サイトやブラウザベースの B/S システムのサーバー側に集中しています。このようなアプリケーションは通常、サービスの応答速度を重視し、システムのダウンタイムをできるだけ短くして、ユーザーに優れたインタラクティブエクスペリエンスを提供することを望んでいます。 CMS コレクターは、このタイプのアプリケーションに非常に適しています。

名前（「マークスイープ」を含む）が示すように、CMS コレクターはマークスイープアルゴリズムに基づいています。その操作プロセスは以前のコレクターよりも複雑です。全体のプロセスは、次の 4 つのステップに分かれています。

1) 初期マーク（CMS初期マーク）

2) コンカレントマーク（CMSコンカレントマーク）

3) CMSコメント

4) 同時スイープ（CMS同時スイープ）

初期マーキングと再マーキングの 2 つのステップでは、依然として「Stop The World」が必要です。初期マーキングでは、GCRoots が直接関連付けることができるオブジェクトのみがマーキングされ、速度が非常に高速です。並行マーキングフェーズは、GC ルートに直接関連付けられているオブジェクトから始めて、オブジェクトグラフ全体をトラバースするプロセスです。このプロセスは時間がかかりますが、ユーザースレッドを一時停止する必要がなく、ガベージコレクションスレッドと同時に実行できます。再マーキングフェーズは、並行マーキング中にユーザープログラムが継続的に動作したためにマーキングが変更されたオブジェクトのマーキングレコードを修正することです。このフェーズの一時停止時間は通常、初期マーキングフェーズよりもわずかに長くなりますが、並行マーキングフェーズよりもはるかに短くなります。最後は並行クリアフェーズで、マーキングフェーズで判定されたデッドオブジェクトをクリーンアップして削除します。生き残ったオブジェクトを移動する必要がないため、このフェーズもユーザースレッドと同時に実行できます。ガベージコレクタースレッドは、プロセス全体で最も長い同時マーキングフェーズと同時クリアフェーズ中にユーザースレッドと連携できるため、CMS コレクターのメモリ回復プロセスは通常、ユーザースレッドと同時に実行されます。

利点: 同時収集、低停止

デメリット: 1. プロセッサリソースに非常に敏感

2. 「浮遊ゴミ」を処理できない

3. 宇宙ゴミ

ガベージファーストコレクター

ガベージファースト (G1) コレクターは、ガベージコレクターテクノロジの開発における画期的な出来事です。コレクターのローカルコレクションの設計概念と、リージョンベースのメモリレイアウトの先駆けとなりました。 G1 は主にサーバー側アプリケーション用のガベージコレクターです。

CMS を含む、G1 コレクターより前の他のすべてのコレクターは、新しい世代全体 (マイナー GC)、古い世代全体 (メジャー GC)、または Java ヒープ全体 (フル GC) のいずれかのガベージコレクションをターゲットにします。 G1 はこの檻から脱出しました。ヒープメモリのどの部分でも、リサイクル用のコレクションセット (CSet) を形成できます。測定基準は、どの世代に属するかではなく、どのメモリのガベージ量が最も多く、リサイクルのメリットが最も大きいかです。これが、G1 コレクターの Mixed GC モードです。 G1 が先駆けて開発したリージョンベースのヒープメモリレイアウトが、この目標を達成するための鍵となります。 G1 は依然として世代別コレクション理論に従って設計されていますが、そのヒープメモリレイアウトは他のコレクターとは大きく異なります。G1 は固定サイズと固定数の世代領域分割を要求せず、連続した Java ヒープを同じサイズの複数の独立した領域に分割します。各領域は、必要に応じて、新しい世代の Eden 領域、Survivor 領域、または古い世代の領域の役割を果たすことができます。コレクターは、異なる戦略を使用して、異なる役割を果たす領域を処理できるため、新しく作成されたオブジェクトと、一定期間存続し、複数のコレクションを生き延びた古いオブジェクトの両方で、良好なコレクション結果を得ることができます。

また、リージョンには、特に大きなオブジェクトを保管するために使用される特別なタイプの Humongous 領域もあります。 G1 では、リージョンの容量の半分を超えるサイズのオブジェクトを大きなオブジェクトと見なします。各リージョンのサイズは、パラメータ -XX:G1HeapRegionSize で設定できます。値の範囲は 1MB ～ 32MB で、2 の累乗にする必要があります。領域全体の容量を超える超大型オブジェクトは、N 個の連続する Humongous Region に格納されます。G1 のほとんどのアクションでは、図 3-12 に示すように、Humongous Region は古い世代の一部とみなされます。

G1 では、新世代と旧世代の概念は保持されていますが、新世代と旧世代は固定されたものではなく、一連の領域 (必ずしも連続的ではない) の動的な集合体です。 G1 コレクターが予測可能な一時停止時間モデルを確立できる理由は、Region を単一のリカバリの最小単位として使用すること、つまり、毎回収集されるメモリ空間が Region サイズの整数倍であるため、Java ヒープ全体の領域全体のガベージコレクションを計画的に回避できるためです。より具体的な処理のアイデアは、G1 コレクターに各リージョンのガベージ蓄積の「価値」を追跡させることです。その価値とは、リサイクルによって得られるスペースのサイズと、リサイクルに必要な時間の経験値です。次に、優先順位リストがバックグラウンドで維持されます。そのたびに、ユーザーが許可したコレクション一時停止時間 (パラメーター -XX:MaxGCPauseMillis を使用して指定、デフォルト値は 200 ミリ秒) に応じて、リサイクル価値のメリットが最も大きいリージョンが優先されます。これが「Garbage First」という名前の由来です。領域を使用してメモリ空間を分割し、優先度に従って領域を再利用するこの方法により、G1 コレクターは限られた時間内に可能な限り最高のコレクション効率を達成できます。