解决P2级故障：CMSGC太频繁，你知道这是什么？

原标题：解决P2级故障：CMSGC太频繁，你知道这是什么？

大家好，我是陶朱公Boy。

背景

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

什么是Cm文章来源站点https://www.yii666.com/sGc？CmsGc太频繁又是什么意思？什么情况下会触发CMSGC太频繁这种告警？要怎么样去找到那个被频繁创建的对象？最后又需要怎么规避？

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

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

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

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

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

 

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

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

• 长期存活的对象文章来源地址1.html将进入老年代

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

• 动态对象年龄判断

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

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

• 老年代可用的连续空间小于年轻代历次YGC后升入老年代的对象总和的平均大小，说文章来源地址1.html明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动作加快，可以考虑临时增加服务器实例，分摊流量。不过很多问题可www.yii666.com能都是程序员代码书写不正确才导致的，这个时候你应该首先找出问题对象，然后找出频繁创建对象的代码块。

本文完！

写到最后

作为996的程序员，写这篇文章基本都是利用工作日下班时间和周六周日双休的时间才最终成稿，比较不易。

如果你看了文章之后但凡对你有所帮助或启发，真诚恳请帮忙关注一下作者，点赞、在看此文。你的肯定与赞美是我未来创作最强大的动力，我也将继续前行，创作出更加优秀好的作品回馈给大家，在此先谢谢大家了！

关注我

如果这篇文章你看了对你有帮助或启发，麻烦点赞、关注一下作者。你的肯定是作者创作源源不断的动力。

公众号

里面不仅汇集了硬核的干货技术、还汇集了像左耳朵耗子、张朝阳总结的高效学习方法论、职场升迁窍门、软技能。希望能辅助你达到你想梦想之地！

公众号内回复关键字“电子书”下载pdf格式的电子书籍(JAVAEE、Spring、JVM、并发编程、Mysql、Linuwww.yii666.comx、kafka、分布式等)、“开发手册”获取阿里开发手册2本、"面试"获取面试PDF资料。

来源于：解决P2级故障：CMSGC太频繁，你知道这是什么？