“喜提”一个P2级故障—CMSGC太频繁,你知道这是什么鬼?
大家好,我是陶朱公Boy。
背景
不知道大家看到这条告警内容后,是什么感触?我当时是一脸懵逼的,一万个为什么萦绕心头。
什么是CmsGc?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)
排查过程
-
配置VM参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${LOGDIR}/ 虚拟机在OOM异常之后会自动生成一份dump文件在本地 。 -
执行jmap(Java内存映像工具)命令 jdk提供的命令行工具jmap能生成堆存储快照,jmap -dump:format=b,file=heapdump.hprof {进程ID}
-
阿里开源性能诊断工具: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:组件报告,分析属于公共根包或类加载器的对象
关注上述两个选项基本就能找到问题对象了。
解决方案
-
如果你的程序代码书写正常,纯粹是真的应用流量太大,你部署的机器没办法抗住这波流量,这种情况发生CMSGC太频繁概率就很大了,甚至最终会导致OOM异常。对这种情况也只能横向扩充机器了,以均衡流量。 -
如果你的机器足够,线上流量也正常,但也发生了cmsgc太频繁,甚至OOM异常。那大概率是你的程序代码有问题,导致老年代区域聚集了大量垃圾对象,垃圾回收线程频繁回收那些无用的垃圾对象,最终可能还达不到回收的理想效果,那么这个时候你不得不分析堆里面被大量占据的对象,看看是不是程序代码问题导致老年代被堆满。 像作者文章开始出的这个案例,作者经过上述步骤分析后,发现是程序代码问题导致有大量对象进入老年代。(作者在应用中引入了一个java8的Nashorn组件,该组件的构建过程极其复杂,内部会创建很多个对象实例,因为作者的业务流量还是比较大的,每秒2000+QPS),机器也是够的大概10台(每台4C8G),分析发现内存中大量充斥着Nashorn相关代码,经过深入分析,其实这个Nashorn实例全局单例就可以了,不需要每次方法执行都构建一个实例,因为构建过程复杂且多对象,流量一高势必最终导致应用发生内存溢出等异常。
总结
最后我也总结了应该如何避免发生GC太频繁甚至OOM这类异常。如果程序代码一切正常,纯粹是瞬时流量太高才导致的GC动作加快,可以考虑临时增加服务器实例,分摊流量。不过很多问题可能都是程序员代码书写不正确才导致的,这个时候你应该首先找出问题对象,然后找出频繁创建对象的代码块。
本文完!
写到最后
关注我
如果这篇文章你看了对你有帮助或启发,麻烦点赞、关注一下作者。你的肯定是作者创作源源不断的动力。
公众号
里面不仅汇集了硬核的干货技术、还汇集了像左耳朵耗子、张朝阳总结的高效学习方法论、职场升迁窍门、软技能。希望能辅助你达到你想梦想之地!
公众号内回复关键字“电子书”下载pdf格式的电子书籍(JAVAEE、Spring、JVM、并发编程、Mysql、Linux、kafka、分布式等)、“开发手册”获取阿里开发手册2本、"面试"获取面试PDF资料。