1. CMSコレクターとは
CMS（Concurrent Mark-Sweep）は、スループットを犠牲にして最短のリカバリー休止時間を取得するガベージコレクターです。サーバーの応答速度が必要なアプリケーションには、このガベージコレクターが非常に適しています。**-XX：+ UseConcMarkSweepGC **を起動JVMパラメーターに追加します。このパラメーターは、CMSが旧世代のリサイクルに使用されることを示します。CMSで使用される基本的なアルゴリズムは次のとおりです。mark-clear。
2.CMSの作業手順
- STWイニシャルマーク
- 同時マーキング
- 同時前洗浄
- STW備考
- 同時スイープ
- 同時リセット
初期マーク：この段階で、仮想マシンは実行中のタスクを停止する必要があります。正式名称はSTW（Stop The Word）です。このプロセスは、ガベージコレクションの「ルートオブジェクト」から開始され、「ルートオブジェクト」に直接関連付けることができるオブジェクトのみをスキャンしてマークを付けます。したがって、このプロセスはJVM全体を一時停止しましたが、すぐに完了しました。
同時マーキング：この段階は、最初のマーキング段階に続き、最初のマーキングに基づいてマーキングを下向きにトレースし続けます。同時マーキングフェーズでは、アプリケーションスレッドと同時マーキングスレッドが同時に実行されるため、ユーザーは一時停止を感じることはありません。
同時事前クリーンアップ：同時事前クリーンアップフェーズは引き続き同時です。この段階で、仮想マシンは、同時マーキングフェーズ中に旧世代に入ったオブジェクトを検索します（一部のオブジェクトは若い世代から旧世代に昇格される場合や、一部のオブジェクトは旧世代に割り当てられる場合があります）。再スキャンすることにより、次の段階で「世界を止める」ため、次の段階での「再マーキング」の作業が軽減されます。-XXを使用できます：-CMSPrecleaningEnabledは、前処理なしでオフにできます
備考：このステージでは仮想マシンが一時停止し、コレクタースレッドがCMSヒープ内の残りのオブジェクトをスキャンします。スキャンは、「オブジェクトの追跡」とトレースダウン、およびオブジェクトの関連付けの処理から始まります。（STW）
同時クリーンアップ：ガベージオブジェクトをクリーンアップします。この段階で、コレクタースレッドとアプリケーションスレッドが同時に実行されます。
同時リセット：この段階で、CMSコレクターのデータ構造をリセットし、次のガベージコレクションを待ちます。
3.デモ
環境：JDK1.8
パラメーター設定：
-Xms10M -Xmx10M -Xmn3m -XX：+ PrintGCDetails -XX：+ UseConcMarkSweepGC -XX：MetaspaceSize = 10m -XX：MaxMetaspaceSize = 10m
コード：
public class TestCMSGC {
public static void main(String[] args) {
byte[] a = new byte[6 * 1024 * 1024];
a = null;
byte[] a1 = new byte[5 * 1024 * 1024];
byte[] a2 = new byte[1 * 1024 * 1024];
byte[] a3 = new byte[3 * 1024 * 1024];
}
}
GCログ：
[GC (Allocation Failure) [ParNew: 1545K->256K(2816K), 0.0015253 secs][CMS: 6496K->594K(7168K), 0.0015234 secs] 7689K->594K(9984K), [Metaspace: 3177K->3177K(1056768K)], 0.0031018 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [ParNew: 1103K->168K(2816K), 0.0003180 secs][CMS: 6740K->6734K(7168K), 0.0022887 secs] 6818K->6734K(9984K), [Metaspace: 3192K->3192K(1056768K)], 0.0026347 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) [CMS: 6734K->6716K(7168K), 0.0017369 secs] 6734K->6716K(9984K), [Metaspace: 3192K->3192K(1056768K)], 0.0017498 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (CMS Initial Mark) [1 CMS-initial-mark: 6716K(7168K)] 6745K(9984K), 0.0001022 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (CMS Final Remark) [YG occupancy: 157 K (2816 K)][Rescan (parallel) , 0.0001984 secs][weak refs processing, 0.0000047 secs][class unloading, 0.0001340 secs][scrub symbol table, 0.0002641 secs][scrub string table, 0.0000800 secs][1 CMS-remark: 6716K(7168K)] 6873K(9984K), 0.0007196 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
par new generation total 2816K, used 157K [0x00000000ff600000, 0x00000000ff900000, 0x00000000ff900000)
eden space 2560K, 6% used [0x00000000ff600000, 0x00000000ff6274b0, 0x00000000ff880000)
from space 256K, 0% used [0x00000000ff880000, 0x00000000ff880000, 0x00000000ff8c0000)
to space 256K, 0% used [0x00000000ff8c0000, 0x00000000ff8c0000, 0x00000000ff900000)
concurrent mark-sweep generation total 7168K, used 571K [0x00000000ff900000, 0x0000000100000000, 0x0000000100000000)
Metaspace used 3237K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 350K, capacity 388K, committed 512K, reserved 1048576K
最初にマイナーgcログを分析してみましょう。
割り当ての失敗、割り当ての失敗、マイナーgcがわかります。特定のパラメーターの意味は、次のとおりです。
[GC (Allocation Failure) [ParNew: 1545K->256K(2816K), 0.0015253 secs][CMS: 6496K->594K(7168K), 0.0015234 secs] 7689K->594K(9984K), [Metaspace: 3177K->3177K(1056768K)], 0.0031018 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
次に、CMS GCログがあります。ログ
の黒い部分が上記の7つのステージに対応していることがわかります
[フルGC（割り当ての失敗）[CMS：6734K-> 6716K（7168K）、0.0017369秒] 6734K-> 6716K（ 9984K）、[メタスペース：3192K-> 3192K（1056768K）]、0.0017498秒] [時間：user = 0.00 sys = 0.00、real = 0.00秒]
[GC（CMS初期マーク）[1 CMS-初期マーク：6716K（ 7168K）] 6745K（9984K）、0.0001022秒] [時間：user = 0.00 sys = 0.00、real = 0.00秒]
[CMS-concurrent-mark-start]
[ CMS-concurrent-mark：0.001 /0.001秒] [時間： user = 0.00 sys = 0.00、real = 0.00秒]
[CMS-concurrent-preclean-start]
[ CMS-concurrent-preclean：0.000 /0.000秒] [時間：user = 0.00 sys = 0.00、real = 0.00秒]
[GC（CMS最終コメント）[YG占有率：157 K（2816 K）] [再スキャン（並列）、0.0001984秒] [弱い参照処理、0.0000047秒] [クラスのアンロード、0.0001340秒] [スクラブシンボルテーブル、0.0002641秒] [スクラブ文字列テーブル、0.0000800秒] [ 1CMS-備考：6716K（7168K）] 6873K（9984K）、0.0007196秒] [時間：ユーザー= 0.00sys = 0.00、実数= 0.00秒]
[CMS-concurrent-sweep-start ]
[ CMS-concurrent-sweep：0.000 /0.000秒] [時間：user = 0.00 sys = 0.00、real = 0.00秒]
[CMS-concurrent-reset-start]
[ CMS-concurrent-reset：0.000 /0.000秒] [時間：user = 0.00 sys = 0.00、real = 0.00秒]
4.コンカレントモードの失敗とプロモーションの失敗
上記はCMSGCの通常のプロセスですが、同時モードの失敗はリサイクルプロセス中にも発生する可能性があります
[GC（割り当ての失敗）[ParNew：2110K-> 2110K（2816K）、0.0000069秒] [ CMS（同時モード障害）：6329K-> 5804K（7168K）、0.0031868秒] 8440K-> 5804K（9984K）、[メタスペース：3229K-> 3229K（1056768K）]、0.0032197秒] [時間：ユーザー= 0.00sys = 0.00 、real = 0.00 secs]
これは、ガベージクリーニングとCMSの参照スレッドが並行して実行されるため、クリーニングプロセス中に旧世代のスペースが不十分であることを意味します。旧世代のスペースが十分に収容できない場合並列クリーニングプロセス中に若い世代からプロモートされた新しいオブジェクト、または直接割り当てられた大きなオブジェクトは「同時モード障害」をスローします。
影響：古い時代のガベージコレクターがCMSからSerial Oldに縮退し、すべてのアプリケーションスレッドが一時停止され、一時停止時間が長くなります。
したがって、これがアプリケーションで頻繁に発生する場合は、調整する必要があります
解決策：
1
。旧世代のスペースを増やします。2。-XX：+ UseCMSCompactAtFullCollectionは、CMSが完了後にスペースを最適化することを意味します。CMSはマーククリアアルゴリズムであるため、すべてのスペースフラグメントが生成されます。-XX
：CMSFullGCsBeforeCompaction = nつまり、CMSを何回完了した後、スペース圧縮
3を実行します。-XX：CMSInitiatingOccupancyFraction = N reduce;このパラメーターのデフォルトは68です。これは、旧世代のスペース使用率が68％に達したときにCMSが実行されることを意味します。
失敗したプロモーションはマイナーGC中にそれを置くことができないというサバイバースペースによって引き起こされ、そしてオブジェクトは、古い時代に入れることができ、その際に古い時代には、下に置くことはできません。
5つの.CMS重要パラメーター
上記のソリューションを組み合わせ
ます
。CMS重要パラメーター：-XX：CMSInitiatingOccupancyFraction：CMSコレクターのメモリー比率をトリガーします。たとえば、68％は、メモリが60％に達すると、CMS同時収集が開始されることを意味します。
-XX：+ UseCMSInitiatingOccupancyOnlyは、上記と組み合わせて使用して、リカバリしきい値（上記で指定された68％）を設定します。指定されていない場合、JVMは設定値を初めて使用し、後で自動的に調整します。
-XX：+ UseCMSCompactAtFullCollection：これは前述のとおりであり、CMSコレクターがガベージをクリーンアップするたびにメモリ統合を送信するために使用されます。
-XX：CMSFullGCsBeforeCompaction：複数のCMSガベージコレクションの後にメモリ統合をトリガーするように設定します。デフラグメンテーションは世界を止めます。
参照：
実際のJava仮想マシンのJVM障害診断とパフォーマンスの最適化
https://blog.csdn.net/muzhixi/article/details/105274542
https://blog.csdn.net/xiaocai9999/article/details/88368395
https：// blog.csdn.net/muzhixi/article/details/105274542 www.cnblogs.com/bootdo/p/10482853.htmlhttps://blog.csdn.net/iamzhongyong/article/details/84512298?utm_medium=distribute.pc_relevant_t0
。 none-task-blog-BlogCommendFromMachineLearnPai2-1.control＆depth_1-utm_source = distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.contro