问题现象回顾

春节放了十来天假，开始上班没过几天，就收到生产环境CPU报警的消息，看了一下zabbix最近30天的CPU监控曲线，发现就最近两天CPU明显飙升，曲线如图：

再看了一下skywalking监控，发现负载确实都很高，看来是真的。仔细看了一下监控的指标，发现了一个异常情况：FGC次数远超过YoungGC次数，监控如下图：

对比分析

首先一个正常的服务中是很少会出现FGC次数远超过YoungGC次数这种现象的，我们又对比了一下其他环境的没报警的服务器，这个服务启动了才两天，发现YoungGC是比FGC多很多，FGC一个都没有，如下图：

原因推测分析

一个服务出现大量FGC肯定会导致服务无响应、CPU飙升，所以我们推测是FGC太频繁导致的，那么就先把堆内存dump出来，打开MAT分析一下看看

这里已经可以看到存活对象最大的占比异常了，最大的一类对象关联内存占用了1.9G，仔细分析Dominator Tree，发现如下

继续展开这个占比最高的，找到最底层对象是谁，发现全都是这个ClassPathList对象

再继续展开ClassPathList对象看到底是哪里生成的

终于找到我们自己的代码了，就是这个LogAspect类生成了大量的ClassPathList对象导致的，找到生成对象的地方，原来是这里生成ClassCLassPath对象后，ClassPool会再生成他引用的ClassPathList对象

那么这里就有一个问题，为什么生成的ClassPathList对象不会被YoungGC，最后进入到老年代导致大量的FGC呢？

要回答这个问题，需要看看ClassPool和ClassPathList的内部实现机制：

首先来看ClassPool，他的实现是一个单例模式，使用ClassPool.getDefault()方法获取，这是系统所有请求入参对象的Class容器池，所以ClassPool是不会被YoungGC回收的

其次ClassPool内部持有一个ClassPoolTail变量的引用，所以只要ClassPool没有被YoungGC回收，那么ClassPoolTail也不会被YoungGC回收

再次看ClassPoolTail对象，内部就持有了ClassPathList对象的引用了，按照前面两步逻辑，那么这个ClassPoolTail内部的这一个ClassPathList对象也不会被YoungGC回收(如下图)。至此是否已经清晰了？还没有，因为ClassPoolTail也只会产生一个对象，所以也只有一个ClassPathList对象的引用，那么为什么还会有那么多的ClassPathList对象呢？答案藏在最后

最后来看这个ClassPathList对象内部实现，可以看到ClassPathList内部是一个自定义的链表实现的，每一个对象都持有下一个ClassPathList对象的引用，所以只要后面还有ClassPathList对象，都会被无穷的引用下去，至此ClassPathList不会被YoungGC回收的真相大白了，超过默认15次YoungGC后被送进了老年代，最后由FGC来回收，但是频繁FGC就会导致CPU报警，这就是问题所在

最后的疑问

那么为什么其他prod环境没有出现这个问题，偏偏是pre环境出现了呢？只是因为过了一个春节？

其实prod一样也会出现，只不过机器的内存配置高一点，服务启动参数加了FGC的执行限制，因此还没有达到触发FGC的条件

-XX:CMSInitiatingOccupancyFraction=70

如果再过一个月，prod肯定也会出现CPU报警的问题