前の記事で 、Java HotSpot VMや他の多くの仮想マシンのガベージコレクターの基礎となる用語と基本的なアイデアを紹介しました。 これでようやくシャベルを手に取り、ヒープをかき集めることができます。 今日、私たちのレビューには2つのシャベルがあります。2つのガベージコレクターは、多くのJavaプログラムで使用されており、多くの場合それを認識していません。 これらは、シリアルGCとパラレルGCです。 それらの人気は簡単に説明されています-これらのコレクターは、ほとんどのハードウェア構成の仮想マシンによってデフォルトで選択されています。



これらのコレクターで使用されるヒープを何らかの形で使用するアプローチは、より高度な実装で使用されるため、この段階では、それらに組み込まれているアイデアと機会に対処することが非常に重要になります。

シリアルGC

シリアルGC（別名シリアルコレクター）は、組み込まれている機能の面では最年少ですが、JVMのガベージコレクターの期間の面では上級です。 私たちの多くがJava言語の存在を疑わない場合でも、彼はゆっくりと、しかし確実にゴミを収集しました。 そして、まだ収集を続けています。 同じくらいゆっくりですが、同じように真実です。



しかし、すべてのプログラムに大きなヒープがあるわけではなく、すべてのプログラムが強力なマルチコアプロセッサを搭載したコンピューターで動作するわけではないため、彼は歴史の端まで行きませんでした。 そのようなスパルタの状況では、彼は非常に役に立ちます。 JVMでガベージコレクションを実装するための基本的なアプローチがここで説明されているので、これがあなたのケースではない場合でも、この章をスキップしないでください。



シリアルGCの使用は、 -XX：+ UseSerialGCオプションで有効になります 。

動作原理

このコレクターを使用する場合、ヒープは4つの領域に分割されます。3つの領域は若い世代（Eden、Survivor 0およびSurvivor 1）に属し、1つ（Tenured）は古い領域に属します。











平均的なオブジェクトは、エデン地域での生活を始めます（エデンとして翻訳されますが、これは非常に論理的です）。 これは、JVMが作成時に配置する場所です。 しかし、時間が経つにつれて、エデンに新しく作成されたオブジェクトのスペースがないことが判明する場合があります。そのような場合、小さなガベージコレクションが開始されます。



まず、このようなアセンブリは、エデンから死んだオブジェクトを見つけて削除します。 残りの生きているオブジェクトは、空のSurvivorリージョンに転送されます。 2つのSurvivorリージョンの1つは常に空です。Edenからオブジェクトを転送するために選択されるのは彼です。











小さなアセンブリの後、エデン地域は完全に空になり、新しい施設を収容するために使用できることがわかります。 しかし、遅かれ早かれ、アプリケーションは再びエデンエリア全体を占有し、JVMは再び小さなアセンブリを作成しようとします。今回はエデンとパートタイムサバイバー0をクリアし、その後、生き残ったオブジェクトをすべて空の領域サバイバー1に移動します。











次回、Survivor 0がデスティネーションリージョンとして再び選択されますが、Survivorリージョンに十分なスペースがある限り、すべてがうまくいきます。











JVMは、オブジェクトがSurvivor 0とSurvivor 1の間を移動する時間を常に監視し、そのような移動の数に適したしきい値を選択します。その後、オブジェクトはTenuredに移動します。つまり、古い世代に移動します。 Survivor領域がいっぱいになると、その領域のオブジェクトもTenuredに送信されます。











記述されている小さなガベージコレクションのプロセスは非常に簡単ですが、Survivorリージョン（正確には2つ）を使用する理由は必ずしも明確ではありません。 この記事の範囲を超えた理由の詳細な説明は残します（ コメントで説明します ）が、ここでは、存続するオブジェクトを操作する主な2つの方法-コンパクションとコピー-を、Sunで小さなガベージコレクターを開発するときに、2番目の方法で行ったため、実装がどのように簡単で、多くの場合、生産性が向上することが証明されています。



すでにTenuredに新しいオブジェクトを入れる十分なスペースがない場合、完全なガベージコレクションが作用し、両方の世代のオブジェクトを操作します。 同時に、古い世代は若い世代と同様にサブリージョンに分割されず、1つの大きなメモリを表します。したがって、Tenuredからデッドオブジェクトを削除した後、データは転送されません（転送する場所はありません）が、圧縮されます。つまり、断片化せずに順番に配置されます。 このようなクリーニングメカニズムは、そのステップの名前からMark-Sweep-Compactと呼ばれます（生存オブジェクトのマーク、死んだオブジェクトのメモリのクリア、生存オブジェクトのコンパクト化）。

加速する

ほとんどの注意深い読者は、おそらく、仕事の原則の説明の冒頭で、 平均的なオブジェクトはエデンセクションで作成されており、エデンセクションでは作成されていないことに気づいたでしょう。 そのような予約は、理由のために行われました。 実際には、サイズが非常に大きい加速オブジェクトがまだ存在するため、Edenでオブジェクトを作成し、Survivorsに沿ってドラッグするとコストがかかりすぎます。 この場合、それらはすぐにTenuredに配置されます。

パイルは小さいですか？

説明されているプロセスの重要な要素は、ヒープの絶対サイズとヒープ内の領域の相対サイズです。



ヒープがデータでいっぱいになると、JVMはメモリをクリーンにするだけでなく、OSに領域を拡張するために追加のメモリを割り当てるように要求できます。 さらに、実際に使用されているメモリが特定のしきい値を下回った場合、JVMはメモリの一部をオペレーティングシステムに返すことができます。 仮想マシンの食欲を制御するために、 XmsおよびXmxオプションがすべて知られています。



また、ヒープの境界値を設定するだけでプログラムが動作し、明らかに遅くならない場合もありますが、必要なパフォーマンスを達成するためのコレクターの微調整は、異なる領域のサイズを調整することで実行されます。 そのような規制の例とプログラムの作業への影響については別の記事で検討しますが、ここではこれを行うためのパラメーターをリストします（以下を参照）。



また、デフォルトでは、若い世代がヒープ全体の3分の1を占有し、古い世代がそれぞれ3分の2を占有することにも注意してください。 さらに、各サバイバー領域は若い世代の10分の1を占有します。つまり、エデンは10分の8を占有します。 その結果、デフォルトでは、領域の実際の割合は次のようになります。











しかし、最大量のメモリを割り当てて完全にクリーニングした後でも、新しいオブジェクトのための場所がない場合はどうなりますか？ この場合、予想されるjava.lang.OutOfMemoryError：Javaヒープスペースとアプリケーションの動作が停止し、分析用のファイル形式のヒープが残ります。 技術的には、コレクタの作業に少なくとも98％の時間がかかり始め、ガベージコレクションがメモリの2％以下しか解放しない場合に発生します。

STWの状況

このコレクターでは、彼の作品はすべて1つの堅実なSTWであるため、すべてが非常に単純です。 各ガベージコレクションの開始時に、メインアプリケーションスレッドの動作は停止し、アセンブリの完了後にのみ再開します。 さらに、Serial GCのクリーニング作業はすべて、1つのスレッドでゆっくりと順番に実行され、そのために彼の名前が授与されました。

カスタマイズ

XmsオプションとXmxオプションを使用して、初期許容ヒープサイズと最大許容ヒープサイズをそれぞれ構成できるという事実については既に触れました。 確かにあなたのほとんどはすでにこれを行っています。 では、さらに深く掘り下げてみましょう。



-XXオプションがあります：MinHeapFreeRatio =？ および-XX：MaxHeapFreeRatio =？ 、各世代の空き領域の最小および最大の割合を指定します。このサイズに達すると、世代サイズがそれぞれ自動的に増減します。 たとえば、 MinHeapFreeRatio = 35の場合、任意の世代の空き領域のシェアが35％を下回ると、この世代には少なくとも35％が空きになるように追加の領域が提供されます。 同様に、 MaxHeapFreeRatio = 65の場合、世代の空き領域のシェアが65％以上になると、この世代に割り当てられたメモリの一部が解放され、目的のしきい値に戻ります。 これらのパラメーターのデフォルト値は、コンピューターのハードウェア特性によって異なります。



-XXオプションを使用して、若い世代の領域の合計サイズに対する古い世代のサイズの望ましい比率を設定できます。NewRatio =？ 。 たとえば、 NewRatio = 3は、若い世代（Eden + S0 + S1）ではヒープの4分の1が割り当てられ、古い世代では4分の3が割り当てられることを意味します。 このオプションの直感に反する名前は、Oracleのドキュメントにも混乱を招きますが、そのように機能します。 オプション名がRatioで終わる場合、実際の値は指定した値の逆数になることを覚えておくのは簡単です。



必要に応じて、 -XXオプションを使用して、若い世代のサイズを上下の絶対値に制限できます。NewSize=？ および-XX：MaxNewSize =？ 。 NewSizeとMaxNewSizeの値を同じ値に設定する場合は、単に-Xmnオプションを使用できます。 たとえば、 -Xmn256mは -XX：NewSize = 256m -XX：MaxNewSize = 256mと同等です。



あなたはまだ若い世代の中に入り、サバイバーのサイズに対するエデンのサイズの比率を調整することができます。 これは、 -XXオプションを使用して行われます：SurvivorRatio =？ 。 たとえば、 SurvivorRatio = 6の場合、各Survivorリージョンは若い世代全体のサイズの8分の1を占有し、Edenは6分の8を占有します （ *比率オプション規則を思い出してください）。



-XX：-UseGCOverheadLimitオプションを使用すると、OutOfMemoryErrorが発生したときに、コレクタアクティビティのしきい値98％を無効にできます。



オブジェクトがSurvivorリージョンでどのようにエージングしているか、およびそのサイズのどのターゲット値が現在設定されているかを追跡することに興味がある場合は、 -XX：+ PrintTenuringDistributionオプションを使用できます 。これは、いくつかのガーベッジコレクションに関する情報の出力にSurvivor統計を追加します 。

長所と短所

このコレクターの主な利点は明らかです-コンピューターリソースの観点からは気取らないです。 彼はすべての作業を1つのスレッドで順番に実行するため、顕著なオーバーヘッドや悪影響はありません。



主な欠点も理解できます-大量のデータを含むガベージコレクションの長い休止です。 さらに、すべてのシリアルGC設定が異なるヒープ領域のサイズを中心に展開していることがわかります。 つまり、微調整を行うには、自分で何かを学び、構成し、実験する必要があります。 これは誰かにアピールしないかもしれません。



アプリケーションが操作のために大きなヒープサイズを必要としない場合（Oracleは100 MBの条件付き制限を示します）、ショートストップの影響をあまり受けず、操作に使用できるプロセッサコアは1つだけです。このオプションを詳しく調べることができます。 それ以外の場合は、より良い方法でオプションを探すことができます。

---

パラレルGC

パラレルGC（パラレルコレクター）は、シリアルコレクターによって作成されたアイデアを開発し、それらに並列性と少しのインテリジェンスを追加します。 コンピューターに複数のプロセッサーコアがあり、プログラムで使用するビルダーを明示的に指定していない場合、JVMはほぼ確実にParallel GCを選択します。 それは十分にシンプルですが、同時にほとんどのアプリケーションのニーズを満たすのに十分機能的です。



並列コレクターは、 -XX：+ UseParallelGCオプションで有効になります 。

動作原理

並列コレクターを接続する場合、ヒープを編成するための同じアプローチがシリアルGCの場合と同じように使用されます-同じ原理で動作するEden、Survivor 0、Survivor 1、Old Gen（私たちにはTenuredという名前で知られています）と同じ領域に分割されます。 ただし、これらの領域での作業には2つの基本的な違いがあります。まず、いくつかのスレッドがガーベジコレクションに並行して関与します。 第二に、このコレクターは必要なパフォーマンスパラメーターに個別に適応できます。 仕組みを見てみましょう。



Nプロセッサコアのコンピューターでガベージコレクションで使用されるスレッドの数を決定するために、JVMはデフォルトで次の式を使用します： N≤8の場合、スレッドの数はNです。それ以外の場合、スレッドの数を取得するために、Nは他の係数に応じて係数が乗算されます通常は5/8のパラメーターですが、一部のプラットフォームでは係数が小さくなる場合があります。



デフォルトでは、スモールビルドとフルビルドの両方にマルチスレッドが含まれます。 Smallは、オブジェクトを古い世代に転送するときに使用し、フル-古い世代のデータを圧縮するときに使用します。



各コレクタースレッドは、Old Gen領域（いわゆる昇格バッファー ）に独自のメモリーを取得します。ここでは、他のスレッドと干渉しないようにデータを転送できるのはそれだけです。 このアプローチはガベージコレクションを高速化しますが、メモリの断片化の可能性という形で小さなマイナスの影響ももたらします。











シリアルコレクターと比較したパラレルコレクターの改善の知的コンポーネントは、必要なガベージコレクションの効率を達成することに焦点を合わせた設定があることです。 最適なパフォーマンスパラメーター（最大ビルド時間および/またはスループット）を指定できます。コレクターは、指定されたしきい値を超えないように最善を尽くします。 これを行うために、彼は過去のガベージコレクションの統計を使用し、それに基づいて、さらなるコレクションのパラメータを計画します。世代のサイズを変更し、リージョンの割合を変更します。



たとえば、小規模なビルドで、JVMが割り当てられた時間に収まらない場合、若い世代のサイズが小さくなる可能性があります。 指定された帯域幅を達成することができず、遅延に問題がない場合、生成サイズは増加します。 などなど。



統計は、手動で開始したガベージコレクションを無視することに注意してください。



もちろん、希望するパラメーターを達成することを100％保証する人はいませんが、試すことができます。多くの場合、必要なオプションを設定するだけで十分です。



コレクターが満たすことができない厳格な要件を設定した場合、コレクターは次の優先順位に従って導かれます（重要度の高い順）。

1. 最大一時停止を減らします。
2. スループットの向上。
3. メモリ使用量を最小限に抑えます。

同時に、Parallel GCでは、シリアルコレクターのように、リージョンのサイズを個別に調整することができます。 ただし、自動チューニングアルゴリズムを混乱させないために、両方を同時に行うことはお勧めしません。 アプリケーションに十分なメモリを割り当て、目的のパフォーマンスパラメーターを指定して外部から観察するか、地域設定に自分自身で登りますが、コレクターが必要なパフォーマンス基準に自動的に調整することを要求する権利を失います。 この規則に違反した場合、彼は私たちを誓うことはありませんが、彼は仕事を効果的に遂行することもできません。

STWの状況

シリアルコレクターの場合のように、アプリケーションのすべてのメインスレッドは、メモリクリーニング操作中に停止されます。 唯一の違いは、作業の一部が並行して実行されるため、一時停止が通常短くなることです。

カスタマイズ

パラレルコレクタの場合、シリアルオプションと同じオプションがすべて適用されます。 メモリ領域のサイズまたはメモリ領域間の比率を手動で設定できます。 パラレルコレクターによって上記で既に説明したものに追加されるオプションを以下にリストします。



ガベージコレクションに割り当てるスレッドの数を手動で指定できます。 これは、 -XXオプションを使用して行われます：ParallelGCThreads =？ 。 たとえば、 -XX：ParallelGCThreads = 9は 、スレッド数を9に制限します。 スレッドの数を増やすと、アセンブリがより強力に並列化されるだけでなく、Tenured領域の断片化が増え、これらのスレッドを同期するオーバーヘッドも追加されることに注意してください。



必要に応じて、 -XX：-UseParallelOldGCオプションを使用して、古い世代のオブジェクトを圧縮する並列作業を完全に無効にすることができます 。



コレクターの目的のパフォーマンスパラメーターの設定は、 -XXオプションを使用して実行されます。MaxGCPauseMillis =？ および-XX：GCTimeRatio =？ 。



MaxGCPauseMillisは、ガベージコレクションプログラムの最大一時停止時間に制限を設定します。 たとえば、 -XX：MaxGCPauseMillis = 400はJVMに、ガベージコレクションの一時停止を400ミリ秒より長く延ばさないことをお勧めします。 デフォルトでは、そのような制限はありません。 このパラメーターを設定する場合、アセンブリ時間の制限により、より頻繁に実行する必要があり、その結果、全体のスループットが低下する可能性があることに注意してください。



GCTimeRatioオプションを使用すると、目的の帯域幅のしきい値（プログラムの実行時間とガベージコレクション時間の比率）を指定できます。 たとえば、 -XX：GCTimeRatio = 49の場合、 JVMはプログラムの時間の2％を超えないようにビルドしようとします（ビルド時間とプログラム時間の比は1 /（1 + 49）になります） 。



オプション-XX：YoungGenerationSizeIncrement =？ および-XX：TenuredGenerationSizeIncrement =？ 必要に応じて、若い世代と古い世代をそれぞれどれだけ増やすかを設定します。 デフォルトでは、これらのオプションは両方とも20です。



ただし、世代のサイズを縮小する速度は、パーセンテージではなく、 -XXオプションのAdaptiveSizeDecrementScaleFactorによる特別な要因によって規制されます。 減少が増加よりも少ない回数を示します。 このオプションは両方の世代に適用されます。 たとえば、 -XX：AdaptiveSizeDecrementScaleFactor = 2の場合 、世代の減少はそれぞれ増加の2倍になります（つまり、 -XX：GenerationSizeIncrement = 20および-XX：TenuredGenerationSizeIncrement = 20の場合、両方の世代が10％減少します ）。

長所と短所

シリアルGCの背景に対するこのコレクターの紛れもない利点は、必要なパフォーマンスパラメーターに自動的に調整する機能と、アセンブリ中の短い休止時間です。 複数のプロセッサコアがある場合、ほとんどすべてのアプリケーションで速度が向上します。



もちろん、メモリの特定の断片化はマイナスですが、コレクターが比較的少数のスレッドを使用するため、ほとんどのアプリケーションにとって重要ではありません。



全体として、Parallel GCは、ほとんどのアプリケーションに適した、シンプルで直感的で効率的なビルダーです。 隠れたオーバーヘッドコストはありません。設定をいつでも変更でき、これらの変更の結果を明確に確認できます。



しかし、それだけでは不十分であり、より洗練されたものを探す必要があります。 次の記事では、コレクターのより高度な実装について説明します。



パート3-CMS GCおよびG1 GCコレクター→



早い

←パート1-はじめに