Recently, I am learning to use CMS, the GC, and record the commonly used parameters here.
1. UseCMSCompactAtFullCollection and CMSFullGCsBeforeCompaction
One thing to note: CMS concurrent GC is not "full GC". There is a clear distinction between concurrent collection and full collection in HotSpot VM. All VM parameters with the word "FullCollection" are related to real full GC, not related to CMS concurrent GC.
The parameter CMSFullGCsBeforeCompaction is declared in the HotSpot VM as follows:
product(bool, UseCMSCompactAtFullCollection, true, \ "Use mark sweep compact at full collections") \ \ product(uintx, CMSFullGCsBeforeCompaction, 0, \ "Number of CMS full collection done before compaction if > 0") \
Then use like this:
*should_compact = UseCMSCompactAtFullCollection && ((_full_gcs_since_conc_gc >= CMSFullGCsBeforeCompaction) || GCCause::is_user_requested_gc(gch->gc_cause()) || gch->incremental_collection_will_fail(true /* consult_young */));
CMS GC depends on several conditions to decide whether to compress at full GC. Among them,
the first condition, UseCMSCompactAtFullCollection and CMSFullGCsBeforeCompaction are used together; the former is currently true by default, that is, the latter is the key.
The second condition is that the user calls System.gc(), and DisableExplicitGC is not enabled.
The third condition is that the young gen reports that the next incremental collection will fail; in short, the young gen expects that the old gen does not have enough space to accommodate the objects promoted by the next young GC.
Any one of the above three conditions will make CMS decide to do compression when doing full GC this time.
CMSFullGCsBeforeCompaction means that after the last CMS concurrent GC is executed, how many more full GCs will be executed before the compression is performed. The default is 0, that is, under the default configuration, compression will be done every time the CMS GC can't stand up and is transferred to the full GC. Configuring CMSFullGCsBeforeCompaction to 10 will make the first condition mentioned above to be compressed every 10 real full GCs ( instead of every 10 CMS concurrent GCs, which is not currently in the VM). parameter ). This will make the full GC less compact, which makes it easier for the old gen of the CMS to suffer from fragmentation problems. Originally, this parameter is used to configure the frequency of reducing the full GC compression, in order to reduce the pause time of some full GC. The algorithm used by CMS to fall back to full GC is mark-sweep-compact , but compaction is optional. If it is not done, the fragmentation will be more serious, but the pause time of this full GC will be shorter; this is a trade-off.
2. -XX:CMSInitiatingOccupancyFraction=70 和-XX:+UseCMSInitiatingOccupancyOnly
这两个设置一般配合使用,一般用于『降低CMS GC频率或者增加频率、减少GC时长』的需求
-XX:CMSInitiatingOccupancyFraction=70 是指设定CMS在对内存占用率达到70%的时候开始GC(因为CMS会有浮动垃圾,所以一般都较早启动GC);
-XX:+UseCMSInitiatingOccupancyOnly 只是用设定的回收阈值(上面指定的70%),如果不指定,JVM仅在第一次使用设定值,后续则自动调整.
3. -XX:+CMSScavengeBeforeRemark
在CMS GC前启动一次ygc，目的在于减少old gen对ygc gen的引用，降低remark时的开销-----一般CMS的GC耗时 80%都在remark阶段
https://www.cnblogs.com/onmyway20xx/p/6605324.html