【Java进阶营】「终」虚拟机研究系列面向CMS垃圾回收器的性能优化实战

• 关于CMS GC介绍和调优的文章比较多&＃xff0c;但大多没有经过验证。因为CMS目前在Java9之前还是相对用的较多&＃xff08;G1也需要持续去调研&＃xff09;&＃xff0c;所以这里把CMS的一些重要知识和调优经验总结一下。

• 相关jvm源代码版本为/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/src/share/vm&＃xff0c;个人建议还是选择openjdk7比较好&＃xff0c;因为是行业标准&＃xff01;

除了OpenJDK的源代码和R大以外&＃xff0c;什么都不要轻易相信。

CMS的一些重要知识点

使用CMS GC必备的三个参数

-XX:&＃43;UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction&＃61;n
-XX:&＃43;UseCMSInitiatingOccupancyOnly

• -XX:CMSInitiatingOccupancyFraction&＃61;n&＃xff1a;CMS回收器机制触发回收垃圾的百分比比重 jdk8的时候为92%。

• -XX:&＃43;UseCMSInitiatingOccupancyOnly&＃xff1a;是否每次都采用固化参数进行分配触发MajorGC

NewRatio参数参考

• 默认的NewRatio为2&＃xff0c;表示新生代和老年代比例是1:2&＃xff0c;即占堆的1/3

但是实际设置了-Xmx和-Xms后&＃xff0c;新生代的大小不符合预期

原因:runtime.arguments.cpp

else if (UseConcMarkSweepGC) {set_cms_and_parnew_gc_flags();
}
const size_t preferred_max_new_size_unaligned &＃61;MIN2(max_heap/(NewRatio&＃43;1), ScaleForWordSize(young_gen_per_worker * parallel_gc_threads));

cms新生代的大小是计算出来的

所以通常使用cms的时候&＃xff0c;建议手动指定新生代大小参数

(-XX:NewRatio或者-Xmn或者-XX:NewSize/-XX:MaxNewSize)

另外JDK-6862534 : -XX:NewRatio completely ignored when combined with -XX:&＃43;UseConcMarkSweepGC&＃xff0c;之前是即使手动指定 -XX:NewRatio&＃xff0c;也无效&＃xff0c;现早已修复

使用jstat -gccause pid 观察cms fgc的时候&＃xff0c;发现每次到阈值回收的时候&＃xff0c;fgc每次会跳2次

• 因为cms的一个并发周期内有两个阶段initial mark与final re-mark&＃xff0c;这两个阶段都是"stop the world"‘&＃xff0c;不过暂停时间较短

• 而jstat的这个fgc的计数器是说的应用暂停的次数&＃xff0c;注意这里所指的是’cms gc’引起的stw&＃xff0c;详细可参考jstat显示的full GC次数与CMS周期的关系

• 如果观察cms fgc&＃xff0c;突然发现stw的时间很长&＃xff0c;多达几秒甚至更多&＃xff0c;一定是出现了异常情况&＃xff0c;而这些情况的代价都十分昂贵&＃xff0c;在做cms调优的时候要尽可能的避免

concurrent mode failure

1. cms并发周期执行期间&＃xff0c;用户的线程依然在运行&＃xff0c;如果这时候如果应用线程向老年代请求分配的空间超过预留的空间&＃xff0c;就会抛出该错误 - 后台线程的收集没有赶上应用线程的分配速度

2. 有时候“空间不足”是CMS GC时当前的浮动垃圾过多&＃xff08;内存碎片&＃xff09;导致暂时性的空间不足&＃xff0c;而浮动垃圾就是cms执行期间用户线程申请的内存空间&＃xff0c;这个错误可能触发两种情况在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫&＃xff1a;1253431195&＃xff08;里面有大量的面试题及答案&＃xff09;里面会分享一些资深架构师录制的视频录像&＃xff1a;有Spring&＃xff0c;MyBatis&＃xff0c;Netty源码分析&＃xff0c;高并发、高性能、分布式、微服务架构的原理&＃xff0c;JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源&＃xff0c;目前受益良多

   • cms的foreground模式&＃xff08;默认的cms gc属于background模式&＃xff09;&＃xff0c;这个模式是CMS自己的mark-sweep不实现做并发的&＃xff08;串行的&＃xff09;old generation GC&＃xff0c;不过会将一些阶段省略掉。
   • CMS的foreground collector的算法就是普通的mark-sweep。它收集的范围只是CMS的old generation&＃xff0c;而不包括其它generation&＃xff08;有争议哦&＃xff0c;标记会涉及到young区以及同时也可以scavenge机制预先触发minorgc&＃xff09;。因而它在HotSpot VM里不叫做full GC

Serial Old GC

• mark-sweep-compact算法
• 它收集的范围是整个GC堆&＃xff0c;包括Java heap的young generation和old generation&＃xff0c;以及non-Java heap的permanent generation。因而其名 Full GC

前者的出现原因

A STW foreground collection can pick up where a concurrent background collection left off to try to avoid a full GC. This is nice but normally it has worse performance than a full GC。

即是为了避免fgc&＃xff0c;但是往往性能甚至比fgc更差。

对于第一种foreground模式&＃xff0c;必须要 -XX:-UseCMSCompactAtFullCollection 和 -XX:CMSFullGCsBeforeCompaction 设置大于0

• 但是UseCMSCompactAtFullCollection默认为true&＃xff0c;CMSFullGCsBeforeCompaction默认是0&＃xff08;每次fullgc都会进行压缩&＃xff01;&＃xff09;&＃xff0c;所以一定会触发第二种Serial Old GC

参考:

• https://bugs.openjdk.java.net/browse/JDK-8010202
• https://bugs.openjdk.java.net/browse/JDK-8064702
• https://bugs.openjdk.java.net/browse/JDK-8027132

均建议foreground collector在Java8废弃&＃xff0c;在Java9移除&＃xff0c;包括UseCMSCompactAtFullCollection和CMSFullGCsBeforeCompaction这两个参数

4. 所以通常来说不建议设置上面两个参数&＃xff0c;否则可能在Java8中会触发foreground collector&＃xff0c;可能会更慢(单线程)。所以通常当出现concurrent mode failure时触发的都是Serial Old GC

5. 关于UseCMSCompactAtFullCollection和CMSFullGCsBeforeCompaction的警告源代码

runtime\arguments.cpp

if (FLAG_IS_CMDLINE(UseCMSCompactAtFullCollection)) {warning("UseCMSCompactAtFullCollection is deprecated and will likely be removed in a future release.");}if (FLAG_IS_CMDLINE(CMSFullGCsBeforeCompaction)) {warning("CMSFullGCsBeforeCompaction is deprecated and will likely be removed in a future release.");}

2. 关于用哪种处理方式的源代码 gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

void CMSCollector::acquire_control_and_collect{
...
bool should_compact &＃61; false;
decide_foreground_collection_type(clear_all_soft_refs,&should_compact, &should_start_over);
...if (should_compact) {
...
// 这个就是mark-sweep-compact 的 Full GC
do_compaction_work(clear_all_soft_refs);
...}else {// mark-sweepdo_mark_sweep_work(clear_all_soft_refs, first_state,should_start_over);
}*should_compact &＃61;UseCMSCompactAtFullCollection &&((_full_gcs_since_conc_gc >&＃61; CMSFullGCsBeforeCompaction) ||GCCause::is_user_requested_gc(gch->gc_cause()) ||gch->incremental_collection_will_fail(true /* consult_young */));

而should_compact主要的一个判断逻辑就是判断UseCMSCompactAtFullCollection和CMSFullGCsBeforeCompaction这两个参数

concurrent promotion failed

Java Performance,The Definitive Guide的原文是这样描述的&＃xff1a;

原文:

Here, CMS started a young collection and assumed that there was enough free space to hold all the promoted objects (otherwise, it would have declared a concurrent mode failure). That assumption proved incorrect: CMS couldn’t promote the objects because the old generation was fragmented (or, much less likely, because the amount of memory to be promoted was bigger than CMS expected).

翻译&＃xff1a;

新生代垃圾收集&＃xff0c;判断老年代似乎有足够的空闲空间可以容纳所有的晋升对象&＃xff08;否则&＃xff0c;CMS收集器会报concurrent mode failure&＃xff09;。这个假设最终被证明是错误的&＃xff0c;由于老年代空间的碎片化&＃xff08;或者&＃xff0c;不太贴切的说&＃xff0c;由于晋升实际要占用的内存超过了CMS收集器的判断&＃xff09;&＃xff0c;CMS收集器无法晋升这些对象。

原文:

Sometimes we see these promotion failures even when thelogs show that there is enough free space in tenured generation. The reason is’fragmentation’ - the free space available in tenured generation is notcontiguous, and promotions from young generation require a contiguous freeblock to be available in tenured generation. CMS collector is a non-compactingcollector, so can cause fragmentation of space for some type of applications.

翻译:

• CMS收集器对老年代收集的时候&＃xff0c;不再进行任何压缩和整理的工作&＃xff0c;意味着老年代随着应用的运行会变得碎片化&＃xff1b;碎片过多会影响大对象的分配&＃xff0c;虽然老年代还有很大的剩余空间&＃xff0c;但是没有连续的空间来分配大对象

• 如果在ParNew准备收集时CMS说晋升没问题&＃xff0c;但ParNew已经开始收集之后确实遇到了晋升失败的情况。

• promotion failed是说&＃xff0c;担保机制确定老年代是否有足够的空间容纳新来的对象&＃xff0c;如果担保机制说有&＃xff0c;但是真正分配的时候发现由于碎片导致找不到连续的空间而失败&＃xff1b;而concurrent mode failure是指并发周期还没执行完&＃xff0c;用户线程就来请求比预留空间更大的空间了&＃xff0c;即后台线程的收集没有赶上应用线程的分配速度。

• promotion failed触发fgc&＃xff0c;触发模式同上&＃xff0c;通常也是Serial Old GC

permgen (or the metaspace) fills up

1. 对于Java8来说&＃xff0c;这个主要是在metaspace扩容时触发的
2. 如果老年代设置了CMS&＃xff0c;则 Metasapce 扩容引起的FGC会转变成一次 CMS
3. Java8中收集器默认就会收集元空间中不再载入的类

在刚启动应用后&＃xff0c;通过jstat -gccause pid后看到出现了fgc&＃xff0c;此时ou也没有占用

• 通常这种情况是上面提到的metaspace扩容引起的&＃xff0c;从LGCC也可以看到Metadata GC Threshold&＃xff0c;触发的原因是因为Metaspace大小达到了GC阈值

• MetaspaceSize主要是控制metaspaceGC发生的初始阈值&＃xff0c;也是最小阈值&＃xff0c;但是触发metaspaceGC的阈值是不断变化的在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫&＃xff1a;1253431195&＃xff08;里面有大量的面试题及答案&＃xff09;里面会分享一些资深架构师录制的视频录像&＃xff1a;有Spring&＃xff0c;MyBatis&＃xff0c;Netty源码分析&＃xff0c;高并发、高性能、分布式、微服务架构的原理&＃xff0c;JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源&＃xff0c;目前受益良多

jstat -gccause 23270 1000S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC 0.00 25.87 82.46 0.00 97.47 94.80 1 0.124 2 0.096 0.220 Metadata GC Threshold No GC

通过观察gc日志&＃xff0c;出现cms异常的几种情况

[ParNew (promotion failed): ... (concurrent mode failure):...

这种情况是先出现了promotion failed&＃xff0c;然后准备触发fgc。

而此时cms这在执行并发收集&＃xff0c;此时则执行打断逻辑&＃xff0c;输出concurrent mode failure

具体源代码也是concurrentMarkSweepGeneration.cpp

if (first_state > Idling) {report_concurrent_mode_interruption();
}
[ParNew (promotion failed): ...

这种情况就是单纯出现了promotion failed&＃xff0c;此时cms未执行并发收集
(concurrent mode failure): …

这种情况是单纯的cms正在执行并发收集&＃xff0c;然后用户线程申请内存空间不足jvm有一个内存担保机制&＃xff0c;是类似于判断’老年代最大的可用连续空间是否大于新生代所有对象的总和’。但通常描述promotion failed的时候是指担保机制够了&＃xff0c; 才会发生。那么既然有最大可用连续空间&＃xff0c;为什么还会failed with 5.0 because a single contiguous chunk of space is not required
for promotions&＃xff0c;即在jdk5后&＃xff0c;晋升不需要连续空间了
所以这里的担保是指’老年代是否有足够的空间容纳要晋升的对象’&＃xff0c;而不是连续空间。那么出现fail&＃xff0c;则是碎片问题

CMS优化方向

原则

cms的的优势就是低延迟&＃xff0c;但是如果出现了长时间的stw&＃xff0c;则对应用程序有很大的影响
如果出现了concurrent mode failure和promotion failed&＃xff0c;代价都非常昂贵&＃xff0c;我们调优应该尽量避免这些情况

针对concurrent mode failure的优化

发生该失败的主要原因是由于CMS不能以足够快的速度清理老年代空间

当老年代空间的占用达到某个阈值时&＃xff0c;并发回收就开始了。一个CMS后台线程开始扫描老年代空间&＃xff0c;寻找无用的垃圾对象时&＃xff0c;竞争就开始了。CMS收集器必须在老年代剩余的空间用尽之前&＃xff0c;完成老年代空间的扫描及回收工作。否则如果在正常速度的比赛中失效&＃xff0c;就会发生该错误

在并发清理阶段&＃xff0c;用户线程仍然在运行&＃xff0c;必须预留出空间给用户线程使用&＃xff0c;会产生’浮动垃圾‘

常规优化途径如下

• 以更高的频率执行后台的回收线程&＃xff0c;即提高CMS并发周期发生的频率

• 主要是调低CMSInitiatingOccupancyFraction的值

• 但是不能太低&＃xff0c;太低会导致过于频繁的gc&＃xff0c;会消耗更多的的cpu和停顿

需要先计算老年代常驻内存大小&＃xff0c;如占用60%&＃xff0c;那么这个阈值则可以设置为约70%&＃xff0c;否则会比较频繁gc

可以考虑担保机制&＃xff0c;只要老年代预留剩余空间大于年轻代大小&＃xff0c;比如新生代和老年代的比例是1 : 4&＃xff0c;即新生代占用老年代的25%&＃xff0c;那么这个阈值可以设置为70&＃xff0c;即老年代还预留出来30%的空间

注意如果浮动垃圾很多的话&＃xff0c;也无法解决该问题&＃xff0c;即cms并发回收期间&＃xff0c;浮动垃圾越来越多&＃xff0c;占用预留空间&＃xff0c;多次的ygc的话&＃xff0c;会有填满预留空间的可能&＃xff0c;虽然概率较低

两个条件综合考虑&＃xff0c;如果设置了阈值70&＃xff0c;但是老年代常驻内存很大&＃xff0c;甚至超过70&＃xff0c;那么此时的建议要提高堆内存&＃xff0c;增加老年代的大小或者减少新生代的大小

针对promotion failed的优化

这个是cms最为严重的’碎片问题‘&＃xff0c;我们要尽量避免这个发生后引起的fgc

所以优化这个问题&＃xff0c;也可以描述为’如何解决碎片问题’

常规优化途径如下

增大堆内存&＃xff0c;增加老年代大小&＃xff0c;但要注意不要超过32g(the HotSpot JVM uses a trick to compress object pointers when heaps are less than around 32 GB)

尽早执行cms gc&＃xff0c;合理设置CMSInitiatingOccupancyFraction&＃xff0c;会合并老生代中相邻的free空间&＃xff0c;可分配给较大的对象

和上面一样&＃xff0c;也可以做一个老年代预留空间大于年轻代

到了阈值后&＃xff0c;就会触发cms gc&＃xff0c;但还是和上面说的&＃xff0c;会产生浮动垃圾 &＃43; 碎片&＃xff0c;还是会出现

另外一个比较“挫”的办法&＃xff0c;是在每天凌晨访问量低的时候&＃xff0c;主动执行一下fgc&＃xff0c;执行一下’碎片压缩’

如System.gc&＃xff0c;但是要注意是否开启了 -XX:&＃43;ExplicitGCInvokesConcurrent,-XX:DisableExplictGC

所以建议办法是用**jmap -histo:live**

另外晋升还包括to space空间小&＃xff0c;可以根据情况尝试提高Survivor

CMS实战参数

日志&＃xff0c;主要是用来排查cms相关问题

基础参数&＃xff1a;

-Xloggc:gc_%t.log -XX:&＃43;PrintGCDetails -XX:&＃43;PrintGCDateStamps

可选调试参数:

-XX:&＃43;PrintGCApplicationStoppedTime # 打印停顿日志-XX:&＃43;PrintTenuringDistribution&＃xff1a;打印升迁日志-XX:&＃43;PrintPromotionFailure # 打印分派失败-XX:&＃43;PrintHeapAtGC gc 进行打印-XX:PrintFLSStatistics&＃61;1 较少使用 主要用于统计计算

cms相关

1. 物理机内存&＃xff1a;16G
2. 预估老年代常驻对象如Player 3000&＃xff0c;一个Player平均2M&＃xff0c;大约6G&＃xff0c;所以老年代比如建议10G
3. -Xms12G -Xmx12G
4. 设置新生代2G&＃xff0c;老年代10G
5. 设置CMSInitiatingOccupancyFraction为70&＃xff0c;则老年代剩余空间为3G&＃xff0c;大于新生代大小
6. 可选&＃xff1a;-XX:&＃43;CMSScavengeBeforeRemark

简单算法&＃xff1a;

-XX:NewRatio&＃61;4&＃xff0c;即新生代和老年代1:4

然后设置CMSInitiatingOccupancyFraction为70&＃xff0c;即老年代剩余空间稍大新生代
但要保证这个70基本上要大于老年代常驻内存&＃xff0c;否则可能会频繁cms gc

另外建议增加脚本&＃xff0c;尝试手动执行fgc&＃xff0c;整理碎片

如每天凌晨3点

jstat -gccause pid >> cms.log
jmap -histo pid >> cms.logjstat -gccause pid >> cms.log
jmap -histo:live pid >> cms.log

metaspace

设置 -XX:MetaspaceSize&＃61;512m -XX:MaxMetaspaceSize&＃61;512m&＃xff0c;注意如果设置的过小&＃xff0c;则会引起fgc甚至metaspace oom