UseCMSCompactAtFullCollection 与 CMSFullGCsBeforeCompaction

CMS并发GC不是 full GC
HotSpot VM里对concurrent collection和full collection有明确的区分


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") 
        
        
*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 是否在full GC时做压缩  

UseCMSCompactAtFullCollection 开启 （默认开启）  并满足 CMSFullGCsBeforeCompaction 条件 
调用了System.gc()，且DisableExplicitGC没有开启
young gen 报告接下来如果做增量收集会失败 ，young gen预计old gen没有足够空间来容纳下次young GC晋升的对象


CMSFullGCsBeforeCompaction  执行多少次full GC才做压缩 ，默认0 

不是每N次CMS并发GC就做一次压缩

不压缩  可能导致 碎片化

CMS回退到full GC时用的是 mark-sweep-compact


-XX:CMSInitiatingOccupancyFraction=70   -XX:+UseCMSInitiatingOccupancyOnly

内存占用率达到70%的时候开始GC， 因为CMS会有浮动垃圾,所以一般较早启动GC

-XX:+CMSScavengeBeforeRemark

CMS GC前启动一次ygc，目的在于减少old gen对ygc gen的引用，降低remark时的开销 ，一般CMS的GC耗时 80%都在remark阶段


配置了CMS却触发Full GC 的几种可能原因

大对象分配时，年轻代不够，直接晋升到老年代，老年代空间也不够，触发 Full GC 
内存碎片导致
CMS GC失败导致（ concurrent mode failure ）
jmap -histo（人肉执行该命令）
手动调用 System.gc()



正常的 CMS GC 日志 片段


[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.661/0.661 secs] [Times: user=3.17 sys=0.56, real=0.66 secs]
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.069/0.089 secs] [Times: user=0.14 sys=0.04, real=0.09 secs]
[CMS-concurrent-abortable-preclean-start]

FULL gc 日志片段

[Full GC ...