JVM チューニングの概要: 基本的なガベージコレクションアルゴリズム

ガベージコレクションアルゴリズムは、さまざまな観点から分類できます。

基本的なリサイクル戦略によれば

参照カウント:

古いリサイクルアルゴリズム。原則として、このオブジェクトには参照があり、それによってカウントが増加し、参照を削除するとカウントが減少します。ガベージコレクション中は、カウントが 0 のオブジェクトのみが収集されます。このアルゴリズムの最も致命的な問題は、循環参照の問題を処理できないことです。

マークスイープ:

このアルゴリズムは 2 段階で実行されます。最初のステージでは、参照ルートノードから始まるすべての参照オブジェクトをマークし、2 番目のステージではヒープ全体を走査してマークされていないオブジェクトをクリアします。このアルゴリズムではアプリケーション全体を一時停止する必要があり、メモリの断片化が発生します。

コピー:

このアルゴリズムは、メモリ空間を 2 つの等しい領域に分割し、一度に 1 つの領域のみを使用します。ガベージコレクション中、現在使用されている領域が走査され、使用中のオブジェクトが別の領域にコピーされます。このアルゴリズムは、使用中のオブジェクトのみを毎回処理するため、コピーコストは比較的小さくなります。同時に、コピー後にメモリを適切にソートできるため、「断片化」の問題は発生しません。もちろん、このアルゴリズムの欠点も明らかです。つまり、メモリスペースが 2 倍必要になるということです。

マークコンパクト:

このアルゴリズムは、「マークアンドスイープ」アルゴリズムと「コピー」アルゴリズムの両方の利点を組み合わせたものです。これも 2 つのステージに分かれています。最初のステージでは、ルートノードから始まる参照されているすべてのオブジェクトをマークします。2 番目のステージでは、ヒープ全体を走査し、マークされていないオブジェクトをクリアし、生き残ったオブジェクトをヒープの 1 つの部分に「圧縮」して、順序どおりに配置します。このアルゴリズムは、「マークアンドスイープ」アルゴリズムの断片化の問題を回避し、「コピー」アルゴリズムのスペースの問題も回避します。

治療方法によって分けられる

増分収集:アプリケーションの実行中にガベージコレクションを実行するリアルタイムガベージコレクションアルゴリズム。何らかの理由で、JDK5.0 のコレクターはこのアルゴリズムを使用しません。

世代別収集:オブジェクトのライフサイクルの分析に基づくガベージコレクションアルゴリズム。オブジェクトは若い世代、古い世代、永久世代に分けられ、異なるライフサイクルでオブジェクトをリサイクルするために異なるアルゴリズム (上記の方法のいずれか) が使用されます。現在のガベージコレクター (J2SE1.2 以降) はすべてこのアルゴリズムを使用します。

システムスレッド別

シリアルコレクション:シリアルコレクションでは、単一のスレッドを使用してすべてのガベージコレクション作業を処理します。マルチスレッドのやり取りが必要ないため、実装が簡単で、比較的効率的です。ただし、複数のプロセッサを活用できないという制限も明らかであるため、このコレクションはシングルプロセッサマシンに適しています。もちろん、このコレクターは、データ量が少ない (約 100 MB) マルチプロセッサマシンでも使用できます。

並列コレクション:並列コレクションでは、複数のスレッドを使用してガベージコレクション作業を処理するため、処理が高速かつ効率的になります。理論的には、CPU の数が多いほど、並列コレクターが発揮できる利点は多くなります。

同時実行コレクション:シリアルコレクションや並列コレクションと比較すると、前 2 つはガベージコレクションを実行するときにオペレーティング環境全体を一時停止する必要があり、ガベージコレクションプログラムのみが実行されます。そのため、ガベージコレクション中にシステムは明らかな一時停止状態になり、ヒープが大きくなるにつれて一時停止時間が長くなります。

オリジナルリンク: http://pengjiaheng.iteye.com/blog/520228

【編集者のおすすめ】