1. 基本的なリサイクル アルゴリズム
1. 参照カウント
古いリサイクル アルゴリズム。原則として、このオブジェクトには参照があるためカウントが増加し、参照を削除するとカウントが減少します。ガベージ コレクション中は、カウントが 0 のオブジェクトのみが収集されます。このアルゴリズムの最も致命的な点は、循環参照の問題を処理できないことです。
2. マークスイープ
このアルゴリズムは 2 段階で実行されます。最初のフェーズでは、参照ルート ノードから始まるすべての参照オブジェクトにマークが付けられ、2 番目のフェーズではヒープ全体がスキャンされ、マークされていないオブジェクトがクリアされます。このアルゴリズムではアプリケーション全体を一時停止する必要があり、同時にメモリの断片化が発生します。
3. コピー
このアルゴリズムはメモリ空間を 2 つの等しい領域に分割し、一度に 1 つの領域のみを使用します。ガベージ コレクション中に、現在使用されている領域が走査され、使用中のオブジェクトが別の領域にコピーされます。このアルゴリズムは、毎回使用中のオブジェクトのみを処理するため、コピーのコストは比較的小さくなります。同時に、コピー後に対応するメモリを整理できますが、「断片化」の問題があります。もちろん、このアルゴリズムの欠点も明らかです。つまり、2 倍のメモリ空間が必要になります。
4. Mark-Compact
このアルゴリズムは、「マーククリア」アルゴリズムと「コピー」アルゴリズムの利点を組み合わせたものです。これは 2 つのフェーズに分かれており、最初のフェーズはルート ノードから開始し、参照されているすべてのオブジェクトをマークし、2 番目のフェーズはヒープ全体を走査し、マークされていないオブジェクトをクリアして、生き残ったオブジェクトをヒープの 1 つに「圧縮」し、それらを順番に排出します。 。このアルゴリズムは、「マーク アンド スイープ」の断片化の問題を回避し、「コピー」アルゴリズムのスペースの問題も回避します。
5. Incremental Collection (増分収集)
ガベージ コレクション アルゴリズムを実装します。つまり、アプリケーションの実行中にガベージ コレクションを実行します。 JDK5.0 のコレクターがこのアルゴリズムを使用しない理由はわかりません。
6. 世代別収集
オブジェクトのライフサイクルの分析に基づくガベージ コレクション アルゴリズム。オブジェクトを若い世代、古い世代、および永続的な世代に分割し、異なるアルゴリズム (上記の方法のいずれか) を使用して、異なるライフ サイクルでオブジェクトをリサイクルします。現在のガベージ コレクター (J2SE1.2 以降) はすべてこのアルゴリズムを使用しています。
1.ヤング（若い世代）
若い世代は3つの領域に分けられます。エデン エリア 1 つとサバイバー エリア 2 つ。ほとんどのオブジェクトはエデンエリアで生成されます。 Eden エリアがいっぱいになると、生き残ったオブジェクトは Survivor エリア (2 つのうち 1 つ) にコピーされ、この Survivor エリアがいっぱいになると、このエリアに残ったオブジェクトは別の Survivor エリアにコピーされます。 , いっぱいになると、最初のSurvivorエリアからコピーされ、その時点ではまだ生きているオブジェクトが「Tenured」エリアにコピーされます。サバイバーの 2 つのエリアは対称であり、連続的な関係がないため、同じエリアにエデンからコピーされたオブジェクトと前のサバイバーからコピーされたオブジェクトが同時に存在する可能性がありますが、最初のサバイバーからコピーされたオブジェクトのみであることに注意してください。エリアは、サバイバーが来たオブジェクトを古いエリアにコピーします。さらに、Survivor エリアの 1 つは常に空いています。
2. Tenured (Old Generation)
Old Generation は、若い世代から生き残ったオブジェクトを保存します。一般に、古い世代には、より長い寿命を持つオブジェクトが保存されます。
3. Perm (永続的な生成)
静的ファイル、現在は Java クラス、メソッドなどを保存するために使用されます。永続的な生成はガベージ コレクションに大きな影響を与えませんが、一部のアプリケーションでは、Hibernate などの一部のクラスを動的に生成または呼び出す場合があります。この場合、これらの新しく追加されたクラスを格納するために、比較的大きな永続的な生成スペースをセットアップする必要があります。手術。永続世代のサイズは、-XX:MaxPermSize=
2. GC の種類
GC には、スカベンジ GC とフル GC の 2 つのタイプがあります。
1. スカベンジ GC
通常、新しいオブジェクトが生成され、エデンのスペースの適用に失敗すると、スカベンジ GC がトリガーされ、エデン領域が GC 用にヒープされ、非生存オブジェクトは消去され、生存オブジェクトは次の場所に移動されます。生存者地区。次にSurvivorの2つのエリアを整理します。
2. フル GC
Young、Tenured、Perm を含むヒープ全体を完了します。フル GC はスカベンジ GC よりも遅いため、フル GC は可能な限り減らす必要があります。以下の理由によりフル GC が発生する可能性があります:
* Tenured がいっぱいである
* Perm ドメインがいっぱいである
* System.gc() が明示的に呼び出される
* 各ドメインのヒープの割り当て戦略が最後の GC 後に動的に変更される
世代別のデモンストレーションガベージ コレクション プロセスの
1.
2.
3.
4.
2. ガベージコレクター
現在、シリアルコレクター、パラレルコレクター、コンカレントコレクターの 3 つの主なコレクターがあります。
1. シリアル コレクター
は、単一のスレッドを使用してすべてのガベージ コレクション作業を処理します。マルチスレッドの対話が必要ないため、より効率的です。ただし、マルチ プロセッサの利点は利用できないため、このコレクタはシングル プロセッサ マシンに適しています。もちろん、このコレクターは、データ量が少ない (約 100M) マルチプロセッサ マシンでも使用できます。 -XX:+UseSerialGC でオンにできます。
2. 並列コレクター
1. 若い世代で並列ガベージ コレクションを実行し、ガベージ コレクション時間を短縮します。通常、マルチスレッドのマルチプロセッサ マシンで使用されます。 -XX:+UseParallelGC を使用して開きます。並列コレクターは、J2SE5.0 の 6 回目の更新で導入され、Java SE6.0 で拡張されました。並列収集用に古い世代をヒープできます。古い世代が同時コレクションを使用しない場合、ガベージ コレクションに単一のスレッドが使用されるため、拡張機能が制限されます。 -XX:+UseParallelOldGC で開きます。
2. -XX:ParallelGCThreads=
3. このコレクターは次のように構成できます:
* ガベージ コレクションの最大一時停止: ガベージ コレクション中の最大一時停止時間を指定します (-XX:MaxGCPauseMillis=
* スループット: スループットは、ガベージ コレクション時間と非ガベージ コレクション時間の比率であり、-XX:GCTimeRatio=
3. 同時コレクター
は、ほとんどの作業が同時に実行されることを保証し (アプリケーションは停止しません)、ガベージ コレクションは短時間のみ停止します。このコレクターは、比較的高い応答を必要とする中規模および大規模なアプリケーションに適しています。時間。 -XX:+UseConcMarkSweatGC でオンにします。
1. コンカレント コレクターは主に、独立したガベージ コレクション スレッドを使用して、アプリケーションを停止せずに到達可能なオブジェクトを追跡します。古い世代の各ガベージ コレクション サイクル中、コンカレント コレクターはコレクションの開始時にアプリケーション全体を一時停止し、コレクション中に再び一時停止します。 2 回目の一時停止は最初の一時停止よりわずかに長くなり、その間、複数のスレッドがガベージ コレクション作業を同時に実行します。
2. 並行コレクターは、短い一時停止時間と引き換えにプロセッサーを使用します。 N 個のプロセッサを備えたシステムでは、同時収集部分は K/N 個の利用可能なプロセッサをリサイクルに使用します。通常、13. プロセッサーが 1 つだけ搭載されたホストで同時コレクターを使用し、それをインクリメンタル モードに設定して、一時停止時間を短縮します。
4. 浮遊ガベージ: アプリケーションの実行中にガベージ コレクションが実行されるため、ガベージ コレクションが完了すると一部のガベージが生成され、このガベージは次のガベージ コレクション サイクルでリサイクルする必要があります。したがって、同時実行コレクタは通常、これらのフローティング ガベージ用に 20% の予約スペースを必要とします。
5. コンカレント モードの失敗: コンカレント コレクターはアプリケーションの実行中に収集を行うため、ガベージ コレクション中にプログラムが使用できる十分な領域をヒープに確保する必要があります。そうしないと、ガベージ コレクションの前にヒープ領域がいっぱいになってしまいます。完成されました。この場合、「同時実行モードの失敗」が発生し、アプリケーション全体がガベージ コレクションのために一時停止されます。
6. 同時実行コレクターを開始します。同時実行収集はアプリケーションの実行中に収集されるため、収集が完了する前にプログラムが使用できる十分なメモリ領域があることを確認する必要があります。そうしないと、「同時実行モードの失敗」が発生します。 -XX:CMSInitiatingOccupancyFraction=
4. 概要
* シリアル プロセッサ:
-- 該当する状況: データ量が比較的少ない (約 100M) ; プロセッサの下で実行され、応答時間の要件がない単一のアプリケーション。
--欠点: 小規模なアプリケーションにのみ使用可能
* 並列プロセッサ:
--該当する状況: 「スループットに対する高い要件」、複数の CPU を備え、アプリケーションの応答時間の要件がない中規模および大規模なアプリケーション。例: バックグラウンド処理、科学計算。
--欠点: アプリケーションの応答時間が長くなる可能性があります
* 同時プロセッサ:
--該当する状況: 「応答時間に対する高い要件」、複数の CPU を備えた中規模および大規模なアプリケーション、およびアプリケーションの応答時間に対する高い要件。例: Web サーバー/アプリケーション サーバー、通信交換機、統合開発環境。
3. GC の基本原理
GC (Garbage Collection) は、JAVA/.NET のガベージ コレクターです。
Java は C++ から開発されました。C++ の面倒でエラーが発生しやすいものを放棄し、カウンターの概念を導入しました。その 1 つは GC メカニズム (C# は JAVA から借用したものです) です。
プログラマはメモリのリサイクルを忘れたり、間違ったりしがちです。 Java が提供する GC 関数は、オブジェクトがスコープを超えているかどうかを自動的に検出して、メモリの自動リサイクルの目的を達成します。Java 言語には、割り当てられたメモリを解放するための明示的な操作方法がありません。メモリ。したがって、Java のメモリ管理は実際には、オブジェクトの割り当てと解放を含むオブジェクトの管理です。
プログラマーの場合は、 new キーワードを使用してオブジェクトを割り当てます。オブジェクトを解放するときは、オブジェクトへのすべての参照を null に割り当てるだけで、プログラムがオブジェクトにアクセスできなくなります。このオブジェクトを「到達不能」オブジェクトと呼びます。すべての「到達不能」オブジェクトのメモリ空間。
GC の場合、プログラマがオブジェクトを作成すると、GC はオブジェクトのアドレス、サイズ、使用状況の監視を開始します。通常、GC は有向グラフを使用して、ヒープ内のすべてのオブジェクトを記録および管理します。このようにして、どのオブジェクトが「到達可能」でどのオブジェクトが「到達不能」であるかが決定され、一部のオブジェクトが「到達不能」であると GC が判断した場合、GC はこれらのメモリ空間を再利用する必要があります。ただし、GC をさまざまなプラットフォームに確実に実装できるようにするために、Java 仕様では GC の多くの動作を厳密に規定していません。たとえば、どのような種類のリサイクルアルゴリズムを使用するか、いつリサイクルを実行するかなどの重要な問題について明確な規制はありません。したがって、JVM 実装者が異なれば、実装アルゴリズムも異なることがよくあります。これは、Java プログラマの開発に多くの不確実性をもたらします。この記事では、GC 作業に関連するいくつかの問題を検討し、この不確実性が Java プログラムに及ぼす悪影響を軽減するよう努めます。
4. GC 世代分割
JVM メモリ モデルのヒープは 2 つの大きなブロックに分割され、1 つはヤング ジェネレーション、もう 1 つはオールド ジェネレーションです
1) ヤング ジェネレーションには、Eden Space と呼ばれる空間があります。 、主に新しいオブジェクトを保存するために使用され、2 つの Survivor Spaces (from、to) があり、それらは各ガベージ コレクションで生き残るオブジェクトを保存するために使用されます。
2) 旧世代では、主にライフサイクルの長いメモリオブジェクトをアプリケーションに保存します。
3) Young Generation ブロックでは、ガベージ コレクションは通常、高速なコピー アルゴリズムを使用します。各 GC 中に、最初に生存オブジェクトが Eden から SurvivorSpace にコピーされ、Survivor Space がいっぱいになると、残りの生存オブジェクトが OldGeneration に直接コピーされます。したがって、各 GC の後、Eden メモリ ブロックはクリアされます。
4) Old Generation ブロックでは、ガベージ コレクションは通常、マーク コンパクト アルゴリズムを使用します。これは速度は遅くなりますが、メモリ要件は軽減されます。
5) ガベージ コレクションは複数のレベルに分かれています。レベル 0 は OLD セグメントのガベージをリサイクルするフル (フル) ガベージ コレクションで、レベル 1 以上はヤング メモリのガベージのみをリサイクルします。オーバーフローは通常、OLD セグメントまたは Perm セグメントがガベージ コレクションされた後でも、新しい Java オブジェクトを収容するメモリ領域がまだないときに発生します。
5. インクリメンタル GC
インクリメンタル GC (インクリメンタル GC) は、通常、JVM 内の 1 つまたは複数のプロセスによって実装される GC であり、それ自体もユーザー プログラムと同様にヒープ領域を占有し、実行時に CPU も占有します。
GC プロセスの実行中、アプリケーションは実行を停止します。したがって、GC が長時間実行されると、ユーザーは Java プログラムの一時停止を感じることができます。一方、GC の実行時間が短すぎると、オブジェクトの再利用率が低すぎる可能性があり、オブジェクトの再利用率がまだ多くなる可能性があります。リサイクルされるべきであるにもかかわらずリサイクルされていないオブジェクトは、依然として大量のメモリを消費します。したがって、GC を設計するときは、一時停止時間と回復速度の間でトレードオフを行う必要があります。優れた GC 実装では、ユーザーは必要な設定を定義できます。たとえば、メモリが限られている一部のデバイスでは、GC がメモリを正確に再利用できることが望まれ、プログラムの速度は考慮されません。他のリアルタイム オンライン ゲームでは、プログラムを長時間中断することはできません。
インクリメンタル GC は、特定のリサイクル アルゴリズムを使用して、長い中断を多数の小さな中断に分割します。これにより、ユーザー プログラムに対する GC の影響が軽減されます。インクリメンタル GC は、全体的なパフォーマンスの点で通常の GC ほど効率的ではない可能性がありますが、プログラムの最大一時停止時間を短縮できます。
Sun JDK が提供する HotSpot JVM は、インクリメンタル GC をサポートできます。 HotSpot JVM のデフォルトの GC モードでは、インクリメンタル GC を使用しません。インクリメンタル GC を開始するには、Java プログラムの実行時に -Xincgc パラメーターを追加する必要があります。
HotSpot JVM インクリメンタル GC は、Train GC アルゴリズムを使用して実装されます。その基本的な考え方は、ヒープ内のすべてのオブジェクトをその作成と使用法に従ってグループ化 (階層化) し、頻繁に使用される関連オブジェクトをチーム内に配置することです。プログラムが実行されるときのチーム。 GC を実行すると、グループ全体がリサイクル可能な場合は、常に最も古い (最近アクセスがほとんどない) オブジェクトが最初にリサイクルされます。このようにして、各 GC 実行では、プログラムのスムーズな実行を保証するために、到達不能なオブジェクトの一定の割合のみが回復されます。
Java の GC ガベージ コレクターの基本概念に関するその他の記事については、PHP 中国語 Web サイトに注目してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
