Javaのガベージコレクションメカニズムの複数のレビューをすでに読んでいることは間違いありません。XmxやXmsなどのオプションを設定することは、あなたにとってルーチンになっています。 しかし、メモリ内の不要なオブジェクトを削除するときが来て、理想的に最適化されたメソッドが必要以上に数倍実行され始めたときに、仮想マシンの内部で何が起こっているのかを本当に詳しく理解していますか？ また、最新のJavaバージョンが、アプリケーションのパフォーマンスに大きな影響を与える責任のあるガベージコレクションの作業を最適化するために提供する機能を知っていますか？



いくつかの記事では、すべてのガベージコレクターの根底にある基本的なアイデアの説明から、さまざまなJava HotSpot VMコレクターの作業アルゴリズムと微調整機能の分析に進みます（このようなコレクターが4つあることをご存知ですか？）。 そして最も重要なのは、この知識を実際にどのように使用できるかを検討することです。



以下に記載されているすべてがHotSpot仮想マシンに適用されることに注意してください。 したがって、本文でJVMについて言及している場合は、これがまさにこの実装です。 ただし、基本原則は他のベンダーの仮想マシンに適用されますが、詳細は多少異なる場合があります。

必要ですか？

合理的な質問。 すべてのプログラムが、トラブルのない操作のためにガベージコレクタを微調整する必要があるわけではありません。 多くの場合、必要な量のメモリを割り当てるだけで十分です。 最終的に、まれなユーザーは、プログラムの応答が通常よりも100〜2ミリ秒長くかかることに気付くでしょう。



ただし、プログラムで使用されるメモリ量は、クリーニングに数秒、場合によっては数十秒かかることもあります。 または、サービスは厳格なSLAによって接続されており、数十ミリ秒を左右に分散させる余裕はありません。 または、好奇心があなたのプログラムが腸で何かをしているという事実に目をつぶることを許可しません、そしてあなたは何を知りません。 これらの場合、理解しましょう。

分割して征服する

Augeanのstable舎の清掃に直接取り組む前に、それらの一般的な構造を見て、具体的に何に焦点を当てたいかを決めましょう。



JVMは、使用するメモリを2つの領域に分割します。アプリケーションデータが格納されるヒープと、プログラムコードおよびその他の補助データが格納される非ヒープです。



アプリケーションが動作中に新しいクラスを生成せず、常にクラスをロード/アンロードしない場合、非ヒープ状態は静的に近く、長期的には最適化されません。 この点で、ここでは非ヒープ領域の機能のメカニズムを考慮せず、私たちの努力が最大の利益をもたらす領域に焦点を当てます。



Javaアプリケーションによって明示的または暗黙的に作成されたすべてのオブジェクトは、ヒープに配置されます。 オブジェクトとその処理アルゴリズムの配置の最適化に関して、自動ガベージコレクションを使用する言語開発者は、作成の初日から苦労しています。 そして、少なくとも近い将来、処理されたデータの量が増え、さまざまなアプリケーションでのガベージコレクションの要件が非常に異なるため、この戦いは続くでしょう。 私たちのビジネスは、状況の発展を監視し、既存のツールから可能な限り多くの利益を引き出すことです。

世代から世代へ

目標（さまざまな場合があり、以下で明確に検討します）を追求するために、異なるガベージコレクターはメモリの整理とクリーニングに異なるアプローチを使用しますが、共通点が1つあります。それらはすべて、 弱い世代の仮説に依存しています。 一般的に言えば、世代仮説は、年齢の関数としての死の確率は非常に急速に減少すると言います。 特にガベージコレクションへの応用は、大多数のオブジェクトがあまり長く生きていないことを意味します。 人間の基準では、ほとんどが幼稚園にさえ行かないでしょう。 また、オブジェクトが長生きするほど、オブジェクトが存続する可能性が高くなることも意味します。



ほとんどのアプリケーションには、オブジェクトの寿命の分布があり、次のような曲線で概略的に説明されます。







大部分のオブジェクトは非常に短時間で作成され、最初に使用した直後には不要になります。 反復子、ローカルメソッド変数、ボクシング結果、および暗黙的に作成されることが多いその他の一時オブジェクトは、このカテゴリに分類され、グラフの最初にピークを形成します。



次に、作成されるオブジェクトは、多少長い計算を実行するために作成されます。 彼らの生活はもう少し多様です-彼らは通常、さまざまな方法で歩み、プロセスで自分自身を変えて豊かにしますが、その後は不要になり、ゴミになります。 そのようなオブジェクトのおかげで、一時的なオブジェクトのピーク後に小さな結節がグラフに表示されます。



そして最後に、ほとんどすべての人を生き抜く昔の人は永久的なプログラムデータであり、多くの場合、最初からダウンロードされ、アプリケーションが停止するまで長く幸せな生活を送っています。



もちろん、各アプリケーションは独自の方法で一意であるため、いずれの場合も、このグラフは変化し、比率を変更し、異常が表示されますが、ほとんどの場合、フォームはそれだけです。 このグラフを忘れないでください。最適化を実行する際に役立ちます。



これにより、開発者は、まず最初に、最近作成されたオブジェクトのクリーニングに集中する必要があるという考えに至りました。 その中には、多くの場合、すでに自分自身よりも長生きしている人がより多くおり、最小限の労力で最大の効果を得ることができます。







ここで、オブジェクトを若い世代（若い世代）と古い世代（古い世代）に分割するというアイデアが生まれます。 この分離に従って、ガベージコレクションプロセスは、若い世代のみに影響する小さなアセンブリ（マイナーGC）と 、両方の世代に影響を与える可能性のあるフルアセンブリ（フルGC）に分けられます。 小さなアセンブリは十分な頻度で実行され、ほとんどの死んだオブジェクトが削除されます。 完全なアセンブリは、プログラムに割り当てられている現在のメモリ量が使い果たされ、小さなアセンブリを省くことができない場合に実行されます。



さらに、世代ごとのオブジェクトの分離は条件付きではなく、メモリの異なる領域に物理的に配置されます。 若い世代のオブジェクトは、ガベージコレクションで生き残り、古い世代に渡されます。 古い世代では、オブジェクトはアプリケーションが終了するまで存続するか、完全なガベージコレクションのいずれかで削除されます。

あなたは速い、安い、または高品質ですか？

直観的には、不要なオブジェクトをできるだけ早く取り除き、若い人たちの道を開き、長い肝臓の静かで平和な存在を確保するガベージコレクターが必要です。 しかし、ガベージコレクターの作業は無料ではなく、コンピューターリソースとプログラムの実行の遅延によって支払われます。 したがって、次に進む前に、コレクターの評価に使用される基準を見てみましょう。



従来、ガベージコレクタのパフォーマンスを決定する際には、次の要素が考慮されます。

• 最大遅延-コレクターが1つのアセンブリーを実行するためにプログラムを一時停止する最大時間。 そのような停車地は、世界停止 （またはSTW ）と呼ばれます。
• スループットとは、長期間にわたるガベージコレクションによって引き起こされる総ダウンタイムに対する総プログラムランタイムの比率です。
• 消費リソース-コレクターによって消費されるプロセッサリソースや追加メモリの量。

3つのパラメーターすべてを同時に改善することはほとんど不可能であることは明らかです。 最大遅延時間を短縮すると、ガベージコレクションが増加し、スループットが低下します。 または、帯域幅を節約するために、より洗練されたアルゴリズムを使用する必要があり、多くの場合、リソース消費が増加します。 などなど。



したがって、ガベージコレクターを設定するとき、開発者は通常、1つまたは2つのパラメーターの最適化に焦点を当て、他のパラメーターをあまり悪化させず、必要に応じてそれらを犠牲にします。

メメントモリ

主よ、まだ必要なものに対応する場所をください

役に立たなくなったものを削除する勇気をください

そして、あるものを他のものと区別するための知恵をください。

-ガベージコレクターの祈り

先に進む前に分析したい別の重要な問題は、ごみの概念そのもの、つまり死んだオブジェクトの定義です。



すでに上で説明したように、ほとんどのオブジェクトは、その作成と使命の達成からゴミに変わる瞬間までの道のりは非常に短いです。 しかし、彼が私たちが望むより少し長く生きている世界で彼を遅らせることができる要因があります。



他のオブジェクトからのリンクが存在するという事実だけで、オブジェクトを生きていると見なすことは不可能であることは誰もが知っています。 それ以外の場合、JVMでの不滅のレシピはとてつもなく単純で、少なくとも2つのオブジェクトの相互参照が存在し、一般的な場合-接続されたオブジェクトのグラフにサイクルが存在することになります。 このアプローチと限られたメモリ量では、多かれ少なかれ深刻なプログラムは長時間動作しません。したがって、JVMはオブジェクトグラフのループを追跡するのに適しています。



しかし、オブジェクトを世代に分割すると調整が行われるため、オブジェクトが死んでおり、プログラムでまだ（直接または間接的に）使用されているオブジェクトがまだ使用されていないことに基づいてのみオブジェクトを削除できると言うことも不可能です。



この状況を考えてみましょう。若いオブジェクトAとそれを参照しているオブジェクトBがあり、それらはすでに古い世代で場所を獲得しています。 ある時点で、これらのオブジェクトの両方が必要なくなり、それらへの参照をすべてリセットしました。 明らかに、オブジェクトAは最も近い小さなガベージコレクションに削除できますが、この知識を得るためには、コレクターは古い世代全体を調べて、Aを参照するオブジェクトBもガベージであることを理解する必要があるため、両方とも破棄できます。 しかし、古い世代の分析は、比較的高価な手順であるため、小さなアセンブリの計画には含まれません。したがって、小さなアセンブリ中のオブジェクトAは生きていると見なされます。







したがって、ほとんどの場合、小さなガベージコレクションの目的では、オブジェクトは死んでいると見なされ、古い世代のオブジェクトまたはストリームスタック、静的クラスメンバからのリンクを含むいわゆるrootsからのリンクで到達できない場合、廃棄する必要がありますなど。完全なガベージコレクションを使用すると、両方の世代を分析できるため、ここでコレクターはルートからしか踊ることができません。



ちなみに、オブジェクトが不要になった瞬間から実際にメモリから削除されるまでの時間は、 プロンプトネスと呼ばれ、コレクターの効率を評価する際の追加要因と見なされる場合があります。

顕微鏡下で

そのため、ガベージコレクターが何をするのか、どのような基準で評価できるのかについての基本的なアイデアを既に得ています。 ここで、仮想マシンの内部をどのように見ることができるかを理解したいので、隠されたメカニズムの動作を観察する機会があります。



メモリおよびガベージコレクションプロセスを監視するためのツールは、2つのグループに分ける必要があります。

• 内部、私たちが監視しているプログラムの一部であり、
• 外部から、研究されたプログラムのプロセスに外部から接続されています。

メモリ監視ツールの問題は、量子力学または心理学の両方でメモリとガベージコレクションを観察するという事実によって、被験者の行動に影響を与えることです。 以下では、このような動作の変更の例を示しますが、今のところは、使用するツールに関係なく、少なくとも簡単な例でキャリブレーションを確認する必要があることを覚えておく必要があります：何もしないプログラムを実行して監視する必要があります

内部ツール

内部監視ツールに関しては、ここでJVMにさまざまな詳細レベル（stdoutまたはログファイル）でアセンブリに関する情報を表示するか、メモリの状態とガベージコレクションに関する情報を返すMXBeansに個別に連絡することができます。 、私たちが好きなように扱います。



JVM HotSpotでは、ガベージコレクションに関する情報の出力を制御する次のオプションを使用できます（これらはすべてのコレクターで機能する主なオプションです）。

-詳細：gc	stdoutのガベージコレクションのロギングを有効にします。
-Xloggc：ファイル名	ガベージコレクション情報を記録するファイルの名前を指定します。 -verbose：gcよりも優先されます 。
-XX：+ PrintGCTimeStamps	アセンブリ情報にタイムスタンプを追加します（プログラムの開始から経過した秒数として）。
-XX：+ PrintGCDetails	ガベージコレクション情報の拡張出力を有効にします。
-XX：+ PrintFlagsFinal	アプリケーションが起動すると、明示的に指定されたオプションまたはJVM自体によって設定されたすべてのオプションの値が標準出力に表示されます。 これには、ガベージコレクションに関連するオプションも含まれます。 多くの場合、割り当てられた値を確認すると便利です。

アプリケーションから自分でデータを収集する場合は、これに対応するMXBeanを使用できます。 以下は、さまざまなメモリ領域の現在の状態とガベージコレクションに関する情報を表示できる単純なクラスの例です。独自の監視を開発する場合は、それを基礎として使用できます。

外部ツール

自然界には、Javaプロセスに接続して、メモリおよびガベージコレクションプロセスの状態に関する情報を簡単に取得できるツールが数多くあります。 これらは、VisualGCプラグイン（VisualGCプラグインを含む）とJava Mission Control、IDEのさまざまなツール/プラグイン、JVM HotSpotパッケージに付属するJProfilerやYourKitなどの個別のプログラムです。



より使いやすいものを選択できますが、上記のように、実験アプリケーションでツールとその設定がどのような影響を与えるかを確認してください。 VisualVMが実行可能コード全体がメインスレッドの実行の一時停止で構成されるプログラムの動作にどのように影響するかの例を次に示します。











この成長しているチャートを上部に表示しますか？ これは、監視によってもたらされる1分あたり約8 MBのジャンクデータです。 コレクタがどのように機能するかについての一般的なアイデアが必要な場合、またはプログラムの1分あたり数十メガバイトのデータが許容測定誤差よりも小さい場合、ツールのこの動作は許容できます。 ただし、微調整を行い、アカウントにすべてのメガバイトがある場合は、食いしん坊のようなものを選択しないほうがよいでしょう。



理想的には、ツールは次のようなprogram睡状態のプログラムでメモリ使用量のグラフを表示する必要があります。











オプションとして、上記の内部監視ツールに注意してください。これらは最初は軽量であり、高度な機能を追加する必要がある場合は、自分で大食いに影響を与えることができます。

みんな見えますか？

さて、あなたはこの場所に着き、前のパラグラフの明らかなものの長いリストによってさえ止められなかったので、あなたは本当に興味があるはずです。 次に、HotSpotがすぐに提供するものを見てみましょう。



既に述べたように、上記のガベージコレクションの原則はすべてのコレクターに共通です。 しかし、同時に、コレクターの間には顕著な違いがあり、次の質問への回答に現れています。

1. 使用されるヒープ領域の数、その目的とサイズは？ これらのサイズは動的にどのように変化しますか？
2. 若い世代から古い世代へのオブジェクトの転送はどうですか？
3. メインプログラムの作業と並行して実行されるガーベッジコレクションの作業と、それを停止させるガーベッジコレクションの作業はどれですか？
4. ガベージコレクタは、必要なパフォーマンスパラメータにどのように自動的に調整しますか？ どちらが優先されますか？
5. コレクターを構成するためのオプションは何ですか？

Java HotSpot VMは、開発者に4つの異なるガベージコレクターの選択肢を提供します。



シリアルは、少量のデータと低遅延の要件を持つアプリケーションにとって最も簡単なオプションです。 まれに使用されますが、弱いコンピューターでは、仮想マシンがデフォルトコレクターとして選択できます。



並列（並列） -シリアルコレクターからアセンブリアプローチを継承しますが、一部の操作に並列性を追加し、必要なパフォーマンスパラメーターに自動的に調整する機能を追加します。



同時マークスイープ（CMS） -メインアプリケーションスレッドと並行してガベージコレクション作業の一部を実行することにより、最大遅延を削減することを目的としています。 メモリ内の比較的大量のデータを扱うのに適しています。



Garbage-First（G1） -特にマルチプロセッササーバーで実行され、大量のデータで動作するサーバーアプリケーションで、CMSを徐々に置き換えるために作成されます。



次の記事では、これらの各コレクターを詳細に検討し、一般的な計画を順守しようとします：簡単な説明、仕事の原則、STWの状況（これを忘れてしまった場合、これは世界を止めます）、構成方法、長所と短所。 この知識を受け取った後、私たちは実際の生活でそれらをどうするかを見ます。



パート2-シリアルGCおよびパラレルGCコレクター→

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