JVMガベージコレクションを理解する-クラシックガベージコレクター(10)

ガベージコレクターの概要

古典的なガベージコレクタとの間の関係は、次の
ガベージコレクターの図
図に示すが、異なる世代におけるコレクタの7種類の効果を、2つのコレクタの間に接続がある場合、図コレクタが配置とそれらが使用され得ることを示唆していますこの領域は、それが新世代コレクターまたは旧世代コレクターに属していることを示しています。

シリアルコレクター

Seriaコレクターは、最も基本的で最も古いコレクターです。コレクターはシングルスレッドコレクターですが、その「シングルスレッド」の意味は、ガベージコレクションの作業を完了するために1つのプロセッサまたはコレクションスレッドのみを使用することを意味するだけではありません。ガベージを収集するときは、収集が終了するまで、すべてのワーカースレッド(Stop the World)を一時停止する必要があります。シリアル旧コレクターの操作プロセスは次のとおりです。
シリアルコレクター実行プロセス
シリアルコレクターは、クライアントモードのデフォルトの新世代コレクターです。他のコレクターよりも優れています。シンプルで効率的です(他のコレクターの単一スレッドと比較して)。メモリ用リソースに制約のある環境では、すべてのコレクター間で追加のメモリ消費が最小になります。シングルコアプロセッサまたはプロセッサコアの数が少ない環境の場合、シリアルコレクターにはスレッドの相互作用によるオーバーヘッドがないため、ガベージコレクションに集中することで、当然のことながら最高のシングルスレッドコレクション効率を得ることができます。ユーザーデスクトップのアプリケーションシナリオで仮想マシンに割り当てられるメモリは、通常、それほど大きくはなく、数十メガバイトまたは100メガバイトまたは200メガバイトの新世代を収集します(新世代が使用するメモリのみを参照し、デスクトップアプリケーションがこの容量を超えることはめったにありません)。デバイスの一時停止時間は、携帯電話が頻繁に発生しない限り、数十または数十ミリ秒から最大100ミリ秒まで完全に制御できます。この一時停止時間は、多くのユーザーにとって完全に許容できます。したがって、シリアルコレクターは、クライアントモードで実行されている仮想マシンに適しています。

ParNewコレクター

ParNewコレクターは、本質的にシリアルコレクターのマルチスレッドパラレルバージョンです。ガベージコレクションに複数のスレッドを使用することに加えて、残りの動作には、シリアルコレクターで使用可能なすべての制御パラメーターが含まれます(-XX:SurvivorRatio、-XX:PretenureSizeThreSholdなど)。 、-XX:HandlePromotionFailureなど)、コレクションアルゴリズム、Stop the World、オブジェクト割り当てルール、リサイクル戦略などはすべてシリアルコレクターと一貫性があります。
ParNewコレクター
ParNewコレクターの作業プロセスは、次のとおりです。ParNewコレクター、マルチスレッド並列コレクターをサポートすることに加えて、シリアルコレクターとの多くの革新はありませんが、サーバーモードで実行される多くのHotSpot仮想マシンです。具体的には、関係なく、パフォーマンスが、非常に重要な理由の機能を持つ新世代のJDK7コレクタの選択に先立って、従来のシステムでは、次のとおりです除了Serial收集器外,目前只有ParNew收集器能与CMS收集器配合工作

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

Parallel Scavengeコレクターは、高性能の新世代コレクターでもあり、マークコピーアルゴリズムに基づくコレクターであり、並列収集が可能なマルチスレッドコレクターでもあります。Parallel Scavengeの多くの機能はParNewコレクターと非常によく似ているようですが、それらの違いは何ですか?
Parallel Scavengeコレクターの特徴は、その焦点が他のコレクターとは異なることです。CMSなどのコレクターの焦点は、ガベージコレクション中のユーザースレッドの一時停止時間を可能な限り短縮することです。ParallelScavengeコレクターの目標は、制御されたスループット(スループット)。いわゆるスループットとは、プロセッサがユーザーコードを実行するために使用する時間と、プロセッサが消費する合計時間の比率です。すなわち:吞吐量=运行用户代码时间/运行用户代码时间+运行垃圾收集时间並列スキャベンジコレクターは次のように実行されます。
並列スカベンジコレクター実行プロセス
仮想マシンが特定のタスクを完了した場合、ユーザーコードとガベージコレクションに100分かかり、ガベージコレクションには1分かかり、スループットは99%になります。一時停止時間が短いほど、ユーザーとの対話が必要なプログラムや、サービス品質の応答を保証する必要があるプログラムに適しています。応答速度が速いと、ユーザーエクスペリエンスが向上します。高スループットでは、プロセッサリソースを最も効率的に使用して、プログラムの計算タスクをできるだけ早く完了することができます。インタラクティブな分析タスクが多すぎないバックグラウンド計算に適しています。
Parallel Scavengeコレクターは、スループットを正確に制御するための2つのパラメーターを提供します。これらは、最大のガベージコレクションの休止時間を制御する-XX:MaxGCPauseMillisパラメーターと、スループットサイズを直接設定するパラメーターです-XX:GCTineRatio

  • -XX:MaxGCPauseMillis許容値は、0より大きいミリ秒数に設定されます。コレクターは、メモリーのリサイクルに費やされる時間がユーザーの設定値を超えないようにします。ただし、値が小さいほど、システムのガベージコレクション速度が速くなるとは考えないでください。ガベージコレクションの休止時間を短くすると、スループットと若い世代のスペースが犠牲になります。システムは若い世代を減らし、300Mの若い世代のメモリを収集します。 500Mより高速である必要がありますが、ガベージコレクションが直接発生する頻度も高くなります。これは、一時停止時間100ミリ秒で10秒に1回収集されていましたが、現在は5ミリ秒に1回、一時停止が70ミリ秒です。一時停止時間は減少していますが、スループットも減少しています。
  • -XX:GCTineRatioパラメータは0〜100の整数に設定されます。これは、総時間に対するガベージコレクション時間の比率です。これは、スループットの逆数に相当します。たとえば、このパラメータが19に設定されている場合、許可される最大のガベージコレクション時間は、総時間の5を占めます。 %Is 1 /(1 + 19)、デフォルト値は99、つまり、最大1%(つまり1 /(1 + 99))ガベージコレクション時間が許可されます。

パラレルスカベンジコレクターはスループット優先度コレクターと呼ばれます。上記のパラメーター設定に加えて、パラメーターもあります-XX:+UseAdaptiveSizePolicy。これはスイッチパラメーターです。このパラメーターをアクティブにすると、新しい世代のサイズであるEdenとSurvivorを手動で指定する必要がなくなります。サイズ比(-XX:SurvivorRatio)、古い時代の昇格のオブジェクトサイズ(-XX:PretenureSizeThreShold)などのパラメーター、および仮想マシンは、現在のシステム操作に基づいてパフォーマンス監視情報を自動的に収集し、これらのパラメーターを動的に調整して、最適な一時停止時間または最大スループット。この調整方法は、ガベージコレクションの適応調整戦略(GC Ergonomics)になります。コレクターの操作についてよく知らず、手動での最適化が困難な場合は、並列スキャベンジコレクターと適応調整戦略を使用してメモリ管理を仮想マシンに引き渡すことも適切です。基本的なメモリデータを設定するだけで済みます。 (たとえば、-Xmxは最大ヒープを設定します)、次に-XX:MaxPauseMillisパラメーター(最大休止時間に注意を向けます)または-XX:GCTimeRatio(スループットに注意を向けます)パラメーターを使用して非仮想マシンの最適化目標を設定し、特定の詳細パラメーターの調整は仮想マシンによって行われます。適応調整戦略は、ParNewコレクターとは異なるParallel Scavengeコレクターの重要な機能でもあります。

シリアル古いコレクター

Serial Oldコレクターは、マークソートアルゴリズムを使用するシングルスレッドの古い世代のコレクターです。このコレクターの意味は、主にクライアントモードでHotSpot仮想マシンを提供することです。サーバー側で使用する場合は、次の2つの用途があります。

  • 1つは、JDK1.5以前のバージョンがParallel Scavengeコレクターと組み合わせて使用​​されることです。
  • もう1つは、CMSコレクターに障害が発生した場合のバックアップ計画として使用され、並行収集で並行モード障害が発生した場合に使用されます。

Serial Oldコレクターの作業プロセスは次のとおりです。
シリアルオールドコレクターの作業工程

並列古いコレクター

Parallel Oldコレクターは、Parallel Scavengeコレクターの古い世代のバージョンです。マルチスレッドの同時収集をサポートし、マークソートアルゴリズムに基づいています。このコレクターが登場する前(JDK1.6より前)、Parallel ScavengeコレクターはSerial Oldコレクターでのみ使用できます。一緒に使用すると、Parallel Oldコレクターが出現するまで、「スループット優先度」コレクターの方がより確実な組み合わせになります。スループットまたはプロセッサーリソースが不足しているシナリオでは、Parallel ScavengeコレクターとParallel Oldコレクターを優先できます。コレクター。Parallel Oldコレクターの操作プロセスは次のとおりです。
並列古いコレクター実行プロセス

CMSコレクター

CMS(Concurrent Mark Sweep)コレクターは、最短のリカバリー休止時間を得ることを目的としたコレクターです。現在、Javaアプリケーションの大部分は、インターネットサイトまたはブラウザベースのB / Sシステムのサービスに集中しています。このようなアプリケーションは、通常、サービスの応答速度により多くの注意を払っており、システムのダウンタイムができるだけ短いことをユーザーに提供します。インタラクティブな体験。
CMSコレクターは、マークアンドスイープアルゴリズムに基づいて実装されています。主な操作プロセスには、主に次の4つのステップが含まれます。

  • 初期マーク(CMS初期マーク):GCルートが直接関連付けることができるオブジェクトにマークを付けるだけで、非常に高速
  • 並行マーク(CMS並行マーク):GC Rootsの直接関連付けられたオブジェクトからオブジェクトグラフ全体をトラバースするプロセス。このプロセスには時間がかかり、ユーザースレッドを一時停止する必要はありません。ユーザースレッドは、ガベージコレクションスレッドと同時に実行できます。
  • 再マーキング(CMS remark):再マーキングフェーズでは、主に同時マーキングを変更しますユーザースレッドの継続的な操作によってマークが変更されたオブジェクトの部分のマークレコード(増分更新)。このステージの一時停止時間は通常、最初のマーキングステージよりも少し長くなりますが、同時マーキングステージの時間よりははるかに短くなります。
  • 同時スイープ(CMS同時スイープ):マークフェーズでデッドと判断されたオブジェクトをクリーンアップして削除します。このフェーズは、ユーザースレッドと同時に実行することもできます。

初始标记阶段和重新标记阶段这两个步骤任然需要Stop The Worldプロセス全体で最も時間がかかる並行マーキングと並行クリーニングのフェーズはガベージコレクションスレッドとユーザースレッドが連携して動作するため、通常、CMSコレクターのメモリリサイクルプロセスはユーザースレッドと同時に実行されます。CMSコレクターの操作プロセスは次のとおりです
CMSコレクター操作プロセス
。CMSは優れたコレクターであり、その主な利点は名前に反映されています:**同時収集、低休止。**公式ウェブサイト上のいくつかの公開ドキュメントは、「同時ローポーズコレクター」とも呼ばれます。ただし、CMSコレクターには明らかな欠点もあります。

  • CMSコレクターはプロセッサーリソースに非常に敏感であり、実際、同時実行用に設計されたプログラムはすべてプロセッサーリソースに敏感です。同時実行フェーズでは、ユーザースレッドが一時停止することはありませんが、スレッドの一部(またはプロセッサの計算能力)が占有され、アプリケーションの速度が低下し、全体的なスループットが低下します。CMSでデフォルトで開始されるリサイクルスレッドの数は(プロセッサコアの数+ 3)/ 4です。つまり、プロセッサコアの数が4以上の場合、ガベージコレクションスレッドは、同時リサイクル時にプロセッサ操作の25%以下しか占有しませんリソース、およびプロセッサコアの数が増えるにつれて減少します。ただし、プロセッサコアの数が4未満の場合、ユーザープログラムに対するCMSの影響が大きくなる可能性があります。アプリケーションの元のプロセッサ負荷が高い場合、コレクタスレッドを実行するためにコンピューティング能力の半分を割り当てる必要があります。これにより、ユーザースレッドの実行速度が大幅に低下する可能性があります。この状況を緩和するために、仮想マシンには“增量式并发收集器(Incrementak Concurrent Mark Sweep/i-CMS)”CMSコレクターのバリアントが用意されています何が行われるかは、ステルスマルチタスクによってマルチコアパラレルマルチタスクをシミュレートする、以前のシングルコアプロセッサ時代のPCオペレーティングシステムのアイデアと同じです。これにより、並行マーキングおよびクリーニング中にコレクタスレッドとユーザースレッドを交互に実行して、最小化することができます。ガベージコレクションスレッドがリソースを独占する時間。これにより、ガベージコレクションプロセス全体は長くなりますが、ユーザープログラムへの影響は少なくなります。直感的には速度が遅くなりますが、速度の低下はそれほど明白ではありません。インクリメンタルCMSコレクターの効果は非常に一般的であることが実務で証明されたため、i-CMSモードはJDK9のリリース後に放棄されました。
  • CMSコレクターはそれを処理できません“浮动垃圾(Floating Garbage)”。「Con-currentMode Failure」の障害が発生している可能性があり、完全な「Stop The Word」を含む完全なGCが生成される可能性があります。CMSの同時マーキングおよび同時クリーニングフェーズでは、ユーザースレッドはまだ実行中であり、プログラムには当然新しいガベージオブジェクトの生成が伴いますが、ガベージオブジェクトのこの部分はマーキングプロセスの終了後に表示されます。これらをこのコレクションで破棄し、次のガベージコレクションのためにクリーンアップします。この部分は「浮遊ゴミ」と呼ばれています。また、ユーザースレッドはガベージコレクションフェーズでも実行を継続する必要があるため、ユーザースレッドが使用するために十分なスペースを確保する必要もあります。そのため、CMSコレクターは、他のガベージコレクターのように古い世代がほぼ完全に満たされるまで待機できません。収集の場合、同時収集中のプログラムの操作のためにスペースの一部を予約する必要があります。JDK5のデフォルト設定では、CMSコレクターは、古い世代がスペースの68%を使用するとアクティブになります。これは控えめな設定です。実際のアプリケーションで古い世代があまり速く成長しない場合は、パラメーターを適切に調整できます-XX:CMSInitiationOccu-pancyFractionCMSのトリガーの割合を増やし、メモリ再利用の頻度を減らし、より良いパフォーマンスを得る値。JDK6では、CMSコレクターの起動しきい値がデフォルトで92%に引き上げられています。ただし、これは別のリスクに直面する可能性が高くなります。CMSの操作中に予約されたメモリが新しいオブジェクトを割り当てるプログラムのニーズを満たすことができない場合、「並行モード障害」が発生し、仮想マシンはバックアップ計画を開始します。実行スレッドをフリーズし、Serial Oldコレクターを一時的に有効にして古いガベージコレクションを再開しますが、これはより長く一時停止します。したがって、パラメータの設定-XX:CMSInitiationOccupancyFractionが高すぎると、多数の同時障害が発生しやすくなりますが、パフォーマンスは低下します。ユーザーは、本番環境での実際のアプリケーションシナリオに従って、設定を比較検討します。
  • CMSは明確にマークされたアルゴリズムを使用します。つまり、コレクションの最後に大量のメモリスペースフラグメントが存在する可能性があります。スペースデブリが多すぎると、大きなオブジェクトの割り当てに多くの問題が発生します。多くの場合、古い世代にはまだ多くのスペースが残っていますが、現在のオブジェクトを割り当てるのに十分な連続スペースを見つけることができず、事前にフルGC状況をトリガーする必要がありました。この問題を解決するために、CMSはパラメーター-XX:UseCMS-CompacttAtFullCollectionスイッチパラメーター(デフォルトで開かれ、JDK1.9以降は破棄されます)を提供します。ユーザーのCMSコレクターは、フルGCのときにメモリフラグメントのマージおよびソートプロセスを開始する必要があります。 (シェナンドアとZGCが登場する前)は同時にはできません。このようにして、断片化の問題は解決されますが、一時停止時間が長くなります。したがって、仮想マシンの設計者は別のパラメーターも提供します-XX:CMSFullGCBefore-Compaction(このパラメーターはJDK9から破棄されます)このパラメーターの主な機能は、CMSコレクターが数回実行することを要求することです(数はパラメーター値によって決定されます)。最適化は、フルGCに入る前に実行されます(デフォルトは0です。つまり、フルGCに入るたびにデフラグが実行されます)。
G1コレクター

G1はサービス指向のガベージコレクターです。G1コレクターは、ヒープの任意の部分に面して、リサイクル用のコレクションセット(コレクションセット、CSet)を形成できます。測定基準は、どの世代に属しているかではなく、どのメモリブロックに最大量のごみと最大のリサイクル収入が含まれているかです。これは、G1コレクターの混合GCモードです。G1はリージョンのヒープメモリレイアウトに基づいています。G1は引き続き世代別コレクション理論に従いますが、ヒープメモリのレイアウトは他のコレクターとは大きく異なります。G1は固定サイズおよび固定数の世代別領域分割を要求しなくなりました。代わりに、継続的なJavaヒープメモリは、同じサイズの複数の対向するリージョン(リージョン)に分割され、各リージョンは、必要に応じて新世代のエデン、サバイバースペース、または旧世代のスペースとして機能できます。コレクターは、さまざまな戦略を使用してさまざまな役割を果たしているリージョンを処理できるため、新しく作成されたオブジェクトでも、一定期間存続して何度も収集されたオブジェクトでも、オブジェクトは優れた携帯電話の効果を得ることができます。
地域には特別なカテゴリもありますHumongous区域,专门用来存储大对象G1人工物は領域の半分の大きさを超えていれば大きな物体と判断でき、各領域の大きさを-XX:G1GeapRegionSize設定でき、値の範囲は1〜32M、2のN乗です。リージョン全体の容量を超える超大型オブジェクトの場合、それらはN個の連続する巨大なリージョンに配置されます。ほとんどのG1の職位はHumongous Region老後の一部と見なされます。G1分割リージョンの概略図は次のとおりです。
G1ヒープ空間分割領域の模式図
G1はまだ新世代と旧世代の概念を保持していますが、新世代と次世代はもはや修正されていません。これらはすべて一連のリージョンの動的なコレクションです(連続である必要はありません)。G1コレクターが予測可能な一時停止時間モデルを確立できる理由は、単一の回復の最小単位としてリージョンを使用するためです。つまり、毎回収集されるメモリ空間はリージョンのサイズの整数倍であり、体系的に回避できます。 Javaヒープの領域全体がガベージコレクションされます。より具体的な処理の考え方は、G1コレクターに各リージョンに蓄積されたごみの「値」サイズを追跡させることです。値は、リサイクルによって得られたスペースのサイズとリサイクルに必要な時間の経験値であり、優先順位リストをバックグラウンドで維持します。許可された収集休止時間のユーザー設定(パラメーター-XX:MAxGCPauseMillisで指定、デフォルト値は200ms)に従って、最大のリサイクル値(Garbage First-> G1)を持つリージョンが優先されますこのように、Regionを使用してメモリ空間を分割し、優先領域を回復する方法により、G1コレクターは限られた時間内で最高の収集効率を得ることができます。
G1実装のいくつかの主要なノードが導入されています。

  • G1はヒープ領域を複数の独立した領域に分割します。領域内のクロス領域参照オブジェクトを解決するにはどうすればよいですか?メモリセットを使用して、GCルートとしてのフルヒープスキャンを回避记忆集しますが、G1コレクター上のアプリケーションはるかに複雑です。各リージョンは、独自のメモリセットを維持する必要があります。これらのメモリセットは、独自のリージョンポインターを記録し、これらをマークしますポインターは、どのカードページの範囲内にあります。G1のメモリセットは実際にはストレージ構造内のハッシュテーブルであり、Keyは別の領域の実際のアドレスであり、valueはセットであり、それに格納されている要素はカードテーブルのインデックス番号です。この「双方向」カードテーブルインターフェース(私が指差した人、私が指差した人)は、元のカードテーブルの実装よりも複雑です。リージョンの数が従来のコレクターの世代数よりも大幅に多いため、G1コレクター他の従来のガベージコレクターよりもメモリ占有の負荷が高くなります(経験値はJavaヒープ領域の約10%〜20%です)。
  • 並行マーキングフェーズでは、収集スレッドとユーザースレッドが干渉なしで実行されることをどのように保証しますか?まず、ユーザースレッドがオブジェクト参照関係を変更する場合、元のオブジェクトグラフ構造を壊さないようにして、マーキング結果にエラーが発生しないようにする必要があります。この問題の解決策G1は、主に元のスナップショット(SATB)アルゴリズムを使用します。さらに、ユーザースレッドに対するガベージコレクションの影響は、リサイクルプロセス中に作成されたオブジェクトのメモリ割り当てにも反映されます。プログラムが引き続き実行されると、新しいオブジェクトが引き続き作成されます。G1は2つの名前付きTAMS(Top Mark Start)で、領域内のスペースの一部は、同時リサイクルプロセスでの新しいオブジェクトの割り当てに割り当てられ、同時リサイクル中の新しく割り当てられたオブジェクトのアドレスは、これらの2つのポインター位置より上である必要があります。G1コレクターは、このアドレスより上のオブジェクトが暗黙的にマークされることをデフォルトに設定します。つまり、それらはデフォルトで有効であり、コレクションのスコープ内にありません。メモリ再利用の速度がメモリ割り当ての速度に追いつけない場合、G1はフル旧GCにSerial Oldを使用してStop the Worldを生成するように強制されます。
  • 信頼性の高い一時停止予測モデルを構築するにはどうすればよいですか?ユーザーが-XX: MaxGcPauseMillisパラメーターで一時停止時間指定するのは、ガベージコレクションが発生する前の期待値のみを意味ます。G1コレクターの一時停止予測モデルは、減衰平均の理論値に基づいて実装されます。ガベージコレクションプロセス中に、G1コレクターはそれぞれを記録します領域の回復には時間がかかり、各領域メモリセット内のダーティカードの数などの測定可能な各ステップのコストがかかり、平均、標準偏差、信頼度などの統計情報を分析して取得します。ここで強調されている「減衰平均」とは、通常の平均よりも新しいデータの影響を受けやすいことを意味します。平均は全体的な平均状態を表しますが、平均減衰は「最近の」平均状態をより正確に表します。つまり、リージョンの統計状態が新しいほど、回復の価値を判断できます。次に、この情報を使用して、予想される短時間を超えないという制約のもとで最高の利益を得る前に、どの地域が回収されて回収されるかを予測します。

G1コレクターの操作プロセスは、次の4つのステップに分けることができます。

  • 初始标记:GCルートに直接関連付けることができるオブジェクトのみをマークし、TAMSポインターの値を変更して、ユーザースレッドの次のステージが、同時に実行されているときに利用可能な領域に新しいオブジェクトを正しく割り当てることができるようにします。このステージには一時停止スレッドが必要ですが、少し時間がかかり、マイナーGCを借用するときに同期的に完了するため、G1コレクターのこのステージで追加の一時停止はありません。
  • 并发标记:GCルートから開始して、ヒープ内のオブジェクトの到達可能性を分析し、ヒープ全体のオブジェクトグラフを再帰的にスキャンして、再利用するオブジェクトを見つけます。この段階には長い時間がかかりますが、ユーザースレッドと同時に実行できます。オブジェクトグラフのスキャンが完了したら、SATBに記録された参照の変更を含むオブジェクトを再処理する必要があります。
  • 最终标记:ユーザースレッドの別の短い一時停止。ユーザーは、同時実行フェーズの終了後に残った最後のいくつかのSATAレコードをスローします。
  • 筛选回收:地域の統計データの更新、各地域のリサイクル値とコストのソート、ユーザーが予想する一時停止時間に応じたリサイクル計画の策定を担当し、任意の数の地域を自由に選択してコレクションを形成し、地域のどの部分をリサイクルするかを決定できます。残っているオブジェクトは空のリージョンにコピーされ、古いリージョンスペース全体がクリアされます。ここでの操作にはライブオブジェクトの移動が含まれ、ユーザースレッドは一時停止する必要があります。これは、複数のコレクタスレッドによって並行して完了されます。

G1運用プロセスの概略図:
G1運用プロセスの模式図
CMSとG1の比較:

  • CMSはマーククリーニングアルゴリズムを使用して多数のメモリの断片化の問題を生成します。G1はマークコピーアルゴリズムを使用します。ガベージコレクションが定期的に利用可能なメモリを提供できるようになった後、この機能はプログラムの長期実行に役立ち、プログラムは大きなオブジェクトにメモリを割り当てます連続したメモリ空間が見つからないため、次のコレクションを開始するのは簡単ではありません。
  • G1は各領域がカードテーブルを維持する必要があるため(領域間の参照関係を記録)、これによりG1メモリセットはヒープ容量全体のより大きなメモリ空間を占有する可能性があります(CMSカードテーブルと比較して1つのコピーのみ)古い世代から新しい世代への引用を記録する必要があります。
  • G1とCMSの詳細な実装により、ユーザープログラムの負荷が異なります。CMSは書き込みバリアを使用してカードテーブルを維持します。書き込み後バリアを使用してカードテーブル操作を維持することに加えて、G1は元のスナップショット検索(SATB)アルゴリズムを実装するために、同時実行中にポインターの変更を追跡するための事前書き込みバリアも必要です。増分更新アルゴリズムと比較すると、元のスナップショット検索では、マーキングと再マーキングの同時実行の消費を削減でき、最終的なマーキングフェーズでのCMSのストールが長すぎるという欠点を回避できますが、実際には、ユーザープログラム操作中に参照の変更を追跡することによって引き起こされます。余分な負担。
    ここに画像の説明を挿入
公開された41元の記事 ウォン称賛14 ビュー10000 +

おすすめ

転載: blog.csdn.net/Yunwei_Zheng/article/details/105381015