“喜提”一个P2级故障—CMSGC太频繁，你知道这是什么鬼？

大家好，我是陶朱公Boy。

背景

不知道大家看到这条告警内容后，是什么感触？我当时是一脸懵逼的，一万个为什么萦绕心头。

什么是CmsGc？CmsGc太频繁又是什么意思？什么情况下会触发CMSGC太频繁这种告警？要怎么样去找到那个被频繁创建的对象？最后又需要怎么规避？

接下来这篇文章我会来回答一下：什么是CMSGC太频繁；整个排查过程与你分享；最后我们一起探讨一下一些规避手段。

首先我觉得还是有必要解释清楚什么是CMSGC太频繁这个术语，相信不少小伙伴也是比较关心的。

如果你听过垃圾搜集器中有一款名为CMS垃圾搜集器，那就好理解了，所谓的CMSGC太频繁意思是说CMS垃圾搜集器在当下时间窗口垃圾收集的动作频次太快（平时老半天才回收一次或几次垃圾对象，现在可能一分钟就需要回收多次），大致就是这个意思。

所以说CMS垃圾收集器是一款作用于老年代区域的垃圾收集器。

关于CMS+ParNew垃圾搜集器的配置说明：大家如果在VM启动配置参数中做如下配置:-XX:+UseConcMarkSweepGC.该配置项首先是激活CMS收集器(作用于老年代)。之后-XX：UseParNewGC会自动开启，意味着年轻代将使用多线程并行垃圾收集器parNew进行回收。

• 新生代因为垃圾回收之后，因为存活对象太多，导致Survivor空间放不下，部分对象会进入老年代
• 大对象直接进入老年代

这里的大对象是指那些需要大量连续空间的JAVA对象,比如那种很长的字符串或数组对象。

• 长期存活的对象将进入老年代

对象在Eden出生，并经过第一次YGC后任然存活，并且能被Survivor空间容纳，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor空间每熬过一次YGC，年龄就增加一岁，如果达到15(默认)岁，对象就会进入老年代。

• 动态对象年龄判断

这点是对长期存活的对象进入老年代的补充。

其实不一定要必须满足所谓的存活对象年龄达到15岁才能进入老年代。如果一次YGC后，尽管Survivor区域有空间能容纳存活对象，但这批存活对象恰好存活的年龄相同，且加起来的大小总和大于Survivor空间的一半，这些对象照样会进入老年代。

• 老年代可用的连续空间小于年轻代历次YGC后升入老年代的对象总和的平均大小，说明YGC后升入老年代的对象大小很可能超过了老年底当期可用的内存空间；触发cmsgc后再进行ygc

• ygc之后有一批对象需要放入老年代，但老年代没有足够的空间存放了，需要触发一次cmsgc

• 老年代的内存使用率超过92%，也要触发OLD 过程(通过参数控制-xx:+CMSInitiatingOccupancyFraction)

1. 配置VM参数
   -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${LOGDIR}/ 虚拟机在OOM异常之后会自动生成一份dump文件在本地。
2. 执行jmap(Java内存映像工具)命令

   jdk提供的命令行工具jmap能生成堆存储快照，jmap -dump:format=b,file=heapdump.hprof {进程ID}

   

3. 阿里开源性能诊断工具:Arthas

接下来作者用本次告警dump下来的堆文件，用MAT工具给大家演示一下具体查找问题对象的全过程。

MAT是Memory Analyzer tool的缩写，是一种快速，功能丰富的Java堆分析工具，能帮助你查找内存泄漏和减少内存消耗。

很多情况下，我们需要处理测试提供的hprof文件，分析内存相关问题，那么MAT也绝对是不二之选。Eclipse可以下载插件结合使用，也可以作为一个独立分析工具使用。

下载地址:eclipse.org/mat/downloa。如果安装过程中可能会碰到版本过低的问题，需要安装一下高版本JDK 比如11，最后设置一下安装路径即可。

打开堆文件

如果你已经成功安装完MAT。进入首页后就可以打开本地hprof文件了。

打开文件后，进入分析页

• Actions：

  Histogram列出每个类所对应的对象个数，以及所占用的内存大小；Dominator Tree 以占用总内存的百分比的方式来列举出所有的实例对象，注意这个地方是直接列举出的对应的对象而不是类，这个视图是用来发现大内存对象的Top Consumers：按照类和包分组的方式展示出占用内存最大的一个对象Duplicate Classes：检测由多个类加载器所加载的类信息（用来查找重复的类）

• Reports：

  Leak Suspects：通过MAT自动分析当前内存泄露的主要原因
  Top Components：Top组件，列出大于总堆1%的组件的报告

• Step By Step：
  Component Report：组件报告,分析属于公共根包或类加载器的对象

关注上述两个选项基本就能找到问题对象了。

1. 如果你的程序代码书写正常，纯粹是真的应用流量太大，你部署的机器没办法抗住这波流量，这种情况发生CMSGC太频繁概率就很大了，甚至最终会导致OOM异常。对这种情况也只能横向扩充机器了，以均衡流量。
2. 如果你的机器足够，线上流量也正常，但也发生了cmsgc太频繁，甚至OOM异常。那大概率是你的程序代码有问题，导致老年代区域聚集了大量垃圾对象，垃圾回收线程频繁回收那些无用的垃圾对象，最终可能还达不到回收的理想效果，那么这个时候你不得不分析堆里面被大量占据的对象，看看是不是程序代码问题导致老年代被堆满。
   像作者文章开始出的这个案例，作者经过上述步骤分析后，发现是程序代码问题导致有大量对象进入老年代。(作者在应用中引入了一个java8的Nashorn组件，该组件的构建过程极其复杂，内部会创建很多个对象实例，因为作者的业务流量还是比较大的，每秒2000+QPS)，机器也是够的大概10台(每台4C8G)，分析发现内存中大量充斥着Nashorn相关代码，经过深入分析，其实这个Nashorn实例全局单例就可以了，不需要每次方法执行都构建一个实例，因为构建过程复杂且多对象，流量一高势必最终导致应用发生内存溢出等异常。

最后我也总结了应该如何避免发生GC太频繁甚至OOM这类异常。如果程序代码一切正常，纯粹是瞬时流量太高才导致的GC动作加快，可以考虑临时增加服务器实例，分摊流量。不过很多问题可能都是程序员代码书写不正确才导致的，这个时候你应该首先找出问题对象，然后找出频繁创建对象的代码块。

本文完！