JVMは「4つの」7つの一般的なガベージコレクターを指摘

ガベージコレクター

1.シリアル(新世代)

1. 単一スレッド(他のすべてのスレッドは、収集中に中断する必要があります)

2. クライアントモードのデフォルトのコレクターも良い選択です

利点:

1.シンプルで効率的(他のコレクターの単一スレッドと比較して)

2.メモリリソースが限られている場合、追加のメモリ消費は最小限です

3.スレッド相互作用のオーバーヘッドがないため、最高のシングルスレッド効率を得ることができます

ここに画像の説明を挿入

2. ParNew(新世代)

これは、シリアルのマルチスレッドバージョンです。

マルチスレッドの並列コレクション、残りはシリアルと同じです

  1. マルチスレッドの並列コレクション(ユーザープロセスは待機する必要があります)

  2. 現在のところことができる唯一のCMSコレクタと連携作業

    -XX:+UseConcMarkSweepGCパラメーターを使用し、ParNew + CMS + Serial Oldコレクターの組み合わせを使用します。現時点では、ParNewが新世代のデフォルトコレクターです。

  3. デフォルトで有効になっている収集スレッドの数は、プロセッサコアの数と同じです

    -XX:ParallelGCThreadsパラメータを使用してスレッドの数を制限できます

ガベージコレクション中にシステムリソースを効率的に使用することは、非常に有益です。

ここに画像の説明を挿入

JDK9後にキャンセルされた組み合わせ

  1. ParNew + CMS(キャンセルされませんが、サーバーモードのコレクターの組み合わせとしては推奨されません)
  2. ParNew + Serial Old
  3. シリアル+ CMS

したがって、ParNewとCMSのみを組み合わせることができ、ParNewがCMSに組み込まれていることも理解できます。

3. Parallel Scanvenge(新世代)

1.マークベースの複製

2.並列収集

3.スループットに焦点を合わせる 使用する 世帯 世代 ヤード の間 / ( + ) ユーザーコード時間/(ユーザーコード時間+ガベージコレクション時間)

やり取りが多すぎないバックグラウンドでのタスクに適しています

関連パラメーター

  1. -XX:MaxGCPauseMillis

    0より大きいミリ秒数

    ガベージコレクションの最大休止時間(若い世代のサイズを犠牲にして、各休止時間が短いが、GCの頻度が高くなり、スループットが低下する)

  2. -XX:GCTimeRatio

    0-100整数:総時間に対するガベージコレクション時間の比率。元のブックのコンセプトはやや乱雑で理解しにくいものです。

    ただし、パラメーター値Nが1/1 + Nという式で計算される限り、ガベージコレクション時間の合計時間に対する比率が計算され、N自体は比率ではありません。

    パラメータが49の場合:スループット= 1-1 /(1 + 49)= 1-1 / 50 = 98%1/50はガベージコレクション時間の割合

  3. -XX:UseAdaptiveSizePolicy

    このパラメーターをオンにすると、新しい世代サイズ(-Xmn)、-XX:SurvivorRatio、-XX:PretenureSizeThresholdおよびその他のパラメーターを指定する必要はありません。最適化の目標(最大ヒープ-Xmxなど)と、上記のパラメーター1または2を指定するだけで、フォーカスを指定できます。休止時間またはスループット。システムは関連するパラメーターを動的に調整します。これは、ガベージコレクションの適応調整戦略と呼ばれます。

4.パラレルオールド

Parallel Scavengeの旧世代バージョン

  1. マルチスレッド同時収集
  2. マークベースのソート
  3. スループットを重視(Parallel Scanvenge + Parallel Old)

ここに画像の説明を挿入

5.シリアル古い

古い世代のシリアル

1.シングルスレッド

2.マークアップ

3.クライアントモードのシリアルと同じ

4. CMSコレクターが失敗したときのバックアップ計画として

作業工程図リファレンス1、シリアルコレクター

6. CMS(古い時代)

一時停止時間に注意してください—> B / Sなどのサーバーモードでユーザーに優れたインタラクティブエクスペリエンスを提供します

運用プロセス

1.最初のマーク

2.コンカレントマーク

3.備考

4.同時スイープ(同時スイープ)

1.初期マーキング:GCRootsに直接関連付けられたオブジェクトを高速でマーキング

2.同時マーキング:ユーザースレッドを中断することなく、GCRootに直接関連付けられているオブジェクトからオブジェクトグラフ全体のトラバースを開始し、GCスレッドと同時に実行すると、時間がかかります。

3.再マーキング:同時マーキング中にユーザースレッドが原因でマークが変更されるオブジェクトを修正します

4.同時削除:デッドとしてマークされたオブジェクトを削除し、ユーザープログラムと同時に実行できます。

ここに画像の説明を挿入

短所

  1. CPUリソースに敏感

    CMSによってデフォルトで開始されるリサイクルスレッドの数は、**(CPU番号+3)/ 4 **です。したがって、CPUの数が少ないほど、ユーザープログラムの実行速度は遅くなります。

  2. 浮遊ゴミを処理できません

    ユーザープログラムは2つの同時ステージで実行されるため、新しいガベージオブジェクトが生成され、これらのオブジェクトはマークの後に表示されるため、次のGCでのみ収集できます。これらはフローティングガベージです。

    • CMSは、古い世代のオブジェクトがいっぱいになるまで待機できません。

    • パラメータ-XX:CMSInitiatingOccupancyFraction:CMSによってトリガーされるしきい値を設定します。jdk1.6では、CMSのデフォルトのしきい値が92%に引き上げられています。

    • -XX:+ UseCMSInitiatingOccupancyOnly:デフォルトはfalseです。使用しない場合、上記で設定したしきい値は1回だけ使用され、後で自動的に調整されます。使用する場合は、設定したしきい値が常に使用されます。

    これら2つのパラメーターを一緒に使用できます。

    -XX:CMSInitiatingOccupancyFraction=70 -XX:UseCMSInitiatingOccupancyOnly=true

    • CMSの動作中に予約されたメモリがプログラムのニーズを満たせない場合、「Concurrent Mode Failure」が表示され、Serial Oldコレクター古い世代のガベージコレクションに対して一時的に有効なるため、一時停止時間が非常に長くなるため、パラメーター値も設定されます高は、多くの「並行モード障害」を引き起こす可能性があります。

    次のことに注意してください。

    intx CMSInitiatingOccupancyFraction = -1 {product}

    このパラメーターのデフォルト値はjdk1.8では-1で、92%は次のように計算されます。

        void ConcurrentMarkSweepGeneration::init_initiating_occupancy(intx io, uintx tr) {
          assert(io <= 100 && tr <= 100, "Check the arguments");
          if (io >= 0) {
            _initiating_occupancy = (double)io / 100.0;
          } else {
            _initiating_occupancy = ((100 - MinHeapFreeRatio) +
                                     (double)(tr * MinHeapFreeRatio) / 100.0)
                                    / 100.0;
          }
        }
    
    
    1. パラメータ値が0以上の場合、パーセンテージがパラメータとして使用されます

    2. 応じて、0未満の場合MinHeapFreeRatiotr、上記の式に従って計算、MinHeapFreeRatioこの割合を達成するために、ヒープサイズ(無効-Xms = -Xmx)ヒープが減少する、すなわちTR CMSTriggerRatio、デフォルト値は、これら2つのパラメータを表示することが見出されています。

      uintx MinHeapFreeRatio             = 40                           {manageable}
      uintx CMSTriggerRatio               = 80                           {product}
      

      したがって、トリガーされたCMSのパーセンテージは((100-40)+(80 * 40)/ 100)/100=0.92=92%です。

  3. マークアンドスイープアルゴリズムに基づいているため、スペースデブリが存在する

    • -XX:+ UseCMSCompactAtFullCollection:FullGCでのデフラグ、排他的な同時実行はできず、一時停止時間が長くなり、JDK9は破棄され始めました
    • -XX:+ CMSFullGCsBeforeCompactionは、いくつかのFullGC後にデフラグするように設定

まとめ

CMSトリガーのしきい値は大きすぎてはなりません。そうでない場合、同時実行エラーが発生し、小さすぎず、CMSトリガーが頻繁に発生します。また、CMSの最初のマーキングと再マーキング(時間がかかる)により、Stop The Worldが発生します。 70

七、ガベージファースト(G1)

直面1. サーバーを(JDK9は、CMSを廃止した、サーバモードでのデフォルトガベージコレクタとして起動)

2. コレクション(CSet)を形成するためのヒープメモリのどの部分についても、測定の基準は、メモリのどの部分に最も多くのガベージが格納されているか、および最大の回収収益になります。

  • G1は、ヒープを同じサイズ(リージョン)の独立したリージョンに分割します。各リージョンは、エデン、サバイバー、および古い世代を再生できます。コレクターは、異なる役割を持つリージョンに対して異なる戦略的リージョンをとることができます。リージョンは、単一リカバリーの最小単位です、つまり、回復されたメモリ空間は毎回領域の整数倍になります

  • リージョンHumongous(旧世代と見なされる)リージョンは、リージョンの容量の半分以上をラージオブジェクトと呼ぶことができる限り、ラージオブジェクトを格納するために使用されます

    パラメーター-XX:G1HeapRegionSizeパラメーターは、各領域のサイズ、範囲を指定できます:1M~32M2の累乗

    領域全体の特大オブジェクトは、連続する同種に配置されます

  • G1は、各リージョンのゴミの値(つまり、取得したスペースの経験値とリサイクルに必要な時間)に従って優先リストを維持し、ユーザーが設定した一時停止時間に従って、値の大きいリージョンを優先的にリサイクルします。

いくつかの質問

  1. G1はメモリセットを使用して、スタック全体のスキャン回避します

  2. 並行マーキングフェーズでは、収集スレッドとユーザースレッドが互いに干渉しないようにします。

    G1は元のスナップショットメソッドを使用して、ユーザースレッドが参照関係を変更したときに元のオブジェクトグラフ構造が破棄されないようにし、マークの正確さを保証します。上記の4.6を参照してください(元のスナップショット)

    • G1は各リージョンに2つのTAMS(Top At Mark Start)ポインターを設計しました
    • 同時収集中に生成された新しいオブジェクトを割り当てるためのパーティション領域
    • 新しいオブジェクトアドレスは2つのポインタ位置より上にある必要があります
    • このアドレスより上のG1オブジェクトはデフォルトで有効です
    • オブジェクトの割り当て速度が回復速度を超えると、ユーザースレッドが凍結され、フルGCが生成されます

実行中のプロセス

  1. 最初のマーク

    GCRootsに直接関連するオブジェクトをマークし、TAMSポインター値を変更して、ユーザープロセスが次のステージで同時に実行されるときに、新しいオブジェクトを使用可能な領域に割り当てることができるようにします。以前と同様に、STWが必要ですが、短時間で完了し、MinorGCの助けを借りて同期的に完了するため、G1はこの段階で追加の一時停止を必要としません。

  2. 同時マーク

    GCRootsに直接関連するオブジェクトから、オブジェクトグラフのアクセシビリティ分析を実行して、回復するオブジェクトを見つけます。これには長い時間がかかります。

    ユーザープロセスと同時に実行でき、スキャンが完了したら、SATB(元のスナップショット)によって記録された、参照されている変更されたオブジェクトを同時に再処理する必要があります。

  3. 最終マーク

    ユーザースレッドの別の短い一時停止、同時実行フェーズの終了後に残った少数のSATBレコードを処理するために使用されます。

  4. スクリーニングとリサイクル

    • 地域統計を更新する
    • リサイクルの価値とコストですべての地域を分類
    • ユーザーが設定した一時停止時間に応じてリサイクル計画を立てる
    • 複数のリージョンをバックコレクションとして自由に選択し、決定されたリージョンの残存オブジェクトを別の空のリージョンにコピーしてから、古いリージョン全体をクリーンアップします
    • ユーザープロセス一時停止する必要があり、複数のコレクターを並行して実行できます。

    更新->ソート->リサイクル計画の作成->バックコレクションの選択->クリーンアップのコピー(並列、STW)

    同時マーキングに加えて、すべてのユーザープロセスを停止する必要があります。

概略図は次のとおりです。
ここに画像の説明を挿入

機能と利点:

  1. 制御された遅延で最高のスループットを実現します。

  2. ユーザーは、予想される(実際の)休止時間を指定できます。

    デフォルトは200ミリ秒で、低すぎることはありません。低すぎると、選択された各コレクションがヒープのごく一部しか占有しなくなります。

  3. パーティション(領域)管理ヒープメモリ

  4. リサイクル効率に応じて回収に戻る

  5. 全体はマーク編成に基づいており、部分は断片化せずにマークコピーに基づいています

短所(CMSと比較)

  1. メモリ使用量

    世代間参照の問題を解決するには、各領域でカードテーブルを維持する必要があるため、メモリセットがヒープ全体の20%以上を占める場合があります。CMSにはカードフォームが1つだけあります。

  2. 追加の実行負荷が高い

    CMSと同様に、書き込みバリアはカードテーブルを維持するために使用されます。

    CMSのような書き込み後のバリアを使用する(同期を直接使用する)ことに加えて、G1は元のスナップショットアルゴリズムを実装するために書き込み前のバリアも必要とします。(メッセージキューを使用)

小さなメモリアプリケーションCMSは、G1により高い確率で

================================================== ====================

その他の関連メモ:

JVMに関する注意事項(1)Javaメモリ領域とメモリオーバーフロー、オブジェクトの作成、レイアウト、配置

JVMに関する注記(2)オブジェクトの生と死、およびJavaへの4つの主要な参照

JVMノート(3)ガベージコレクションアルゴリズムとHotSpotアルゴリズムの実装(セキュリティポイント、メモリセットとカードテーブル、書き込みバリア、3色マークなど)

JVMのノート(5)クラスロードメカニズム、クラスローダー、親の委任メカニズム

================================================== ==============

参照:
「Java仮想マシンの第3版の詳細な理解」

公開された75元の記事 ウォン称賛13 ビュー8369

おすすめ

転載: blog.csdn.net/weixin_43696529/article/details/104884777