JVM调优之线上内存报警排查（二）

JVM调优

第一章 JVM调优工具
第二章 线上内存报警排查

---

---

一、起因

线上遇到CPU和内存使用率飙升告警，极端情况会触发云平台自动重启。

---

二、排查思路

提示：命令不清楚的请看上一章节或自行查询。

1. 收到报警，查看报警，通过 top 指令发现CPU已经恢复正常。
2. 对比没报警机器， jstat -gcutil 发现FGC次数比其他没触发报警的机器高。
3. 猜测 cpu 飙高是由于GC导致的，为什么FGC之后内存使用率没降下来，反而增加了。一种情况是内存设置小于业务需要，另一种情况是有内存泄漏问题。
   （1）查看jvm参数，堆大小为10G 基本上不会是大小不够用。
   （2）通过jmap-histo:live查看内存存活对象占用情况。发现有500多万个WconfigHelper中的CallBack对象。
   

三、代码排查

1. WconfigHelper类CallBack对象。
   

2. 业务方法调用信息如下：

3. CallBack方法和调用方均在虚拟机栈里，为什么方法执行结束对象没有回收？
   
   
   最终callback对象被增加到了一个cacheSubscribeDatas本地缓存中。
   
   由此可见，业务方每执行一次方法，就会new一个callback增加一个引用放本地缓存，所以导致这个对象越来越大，直到达到一定条件，触发FGC(导致cpu利用率飙升)。内存使用率也会越来越高，直到达到最大值down机 触发云平台重启。

四、改进方案

通过jvm类加载机制 将监听方法放到静态块中。保证对象只会创建一次。
同时保证不被自定义线程池打断监听初始化过程。在服务启动时候调用init()方法，并且在每次业务调用时候检测下监听状态iMClueWatch是否正常。如果不正常，重新执行监听操作。

---

总结

这是我以前整理在有道里面的文章，最近才整理到CSDN，有些截图当时没有存储，有些私密代码做了马赛克，请见谅。