最近在学习使用CMS这个GC,这里记录下经常使用的参数。算法
1. UseCMSCompactAtFullCollection 与 CMSFullGCsBeforeCompaction并发
有一点须要注意的是:CMS并发GC不是“full GC”。HotSpot VM里对concurrent collection和full collection有明确的区分。全部带有“FullCollection”字样的VM参数都是跟真正的full GC相关,而跟CMS并发GC无关的。
CMSFullGCsBeforeCompaction这个参数在HotSpot VM里是这样声明的: 学习
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") \
而后这样使用的:ui
*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 是搭配使用的;前者目前默认就是true了,也就是关键在后者上。
第二种条件是用户调用了System.gc(),并且DisableExplicitGC没有开启。
第三种条件是young gen报告接下来若是作增量收集会失败;简单来讲也就是young gen预计old gen没有足够空间来容纳下次young GC晋升的对象。
上述三种条件的任意一种成立都会让CMS决定此次作full GC时要作压缩。
CMSFullGCsBeforeCompaction 说的是,在上一次CMS并发GC执行事后,到底还要再执行多少次full GC才会作压缩。默认是0,也就是在默认配置下每次CMS GC顶不住了而要转入full GC的时候都会作压缩。 把CMSFullGCsBeforeCompaction配置为10,就会让上面说的第一个条件变成每隔10次真正的full GC才作一次压缩(而不是每10次CMS并发GC就作一次压缩,目前VM里没有这样的参数)。这会使full GC更少作压缩,也就更容易使CMS的old gen受碎片化问题的困扰。 原本这个参数就是用来配置下降full GC压缩的频率,以期减小某些full GC的暂停时间。CMS回退到full GC时用的算法是mark-sweep-compact,但compaction是可选的,不作的话碎片化会严重些但此次full GC的暂停时间会短些;这是个取舍。spa
2. -XX:CMSInitiatingOccupancyFraction=70 和-XX:+UseCMSInitiatingOccupancyOnlycode
这两个设置通常配合使用,通常用于『下降CMS GC频率或者增长频率、减小GC时长』的需求对象
-XX:CMSInitiatingOccupancyFraction=70 是指设定CMS在对内存占用率达到70%的时候开始GC(由于CMS会有浮动垃圾,因此通常都较早启动GC);blog
-XX:+UseCMSInitiatingOccupancyOnly 只是用设定的回收阈值(上面指定的70%),若是不指定,JVM仅在第一次使用设定值,后续则自动调整.内存
3. -XX:+CMSScavengeBeforeRemarkci
在CMS GC前启动一次ygc,目的在于减小old gen对ygc gen的引用,下降remark时的开销-----通常CMS的GC耗时 80%都在remark阶段