CacheRefresh使用不当导致FullGC

收到报警

image.png

查看ARMS

image.png

根据老年代内存回收点情况可以看出老年代是可以回收干净的，排除内存泄漏。老年代的大小是通过几天的时间积攒下来的，怀疑可能是有大对象或者生命周期过长的对象。

对象何时进入老年代

1. 内存担保机制

2. 大对象直接进入老年代

3. 长期存活的对象进入老年代

4. 动态年龄判断进入老年代

进入机器继续排除

1. 直接查看jvm参数

   jps -v 或者 jinfo -flags

-Xmx4G -Xms4G -XX:NewRatio=2 -XX:ParallelGCThreads=10 -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:logs/gc.log

2. jstat查看gc情况

   jstat -gcutil <6> 1000 30

image.png

经过多次观察，发现的问题是，每次进行YGC的时候都会有对象晋升到old区，但是交换区并未达到100。

所以大致定位问题是，有些对象的生命周期过长，导致晋升老年代。

3. 下掉节点流量，执行jmap查看堆中对象信息

   jmap -histo[:live] |head -n 20

   
   
   image.png

图中一共执行2次jmap命令，第一次为堆中对象信息，包括死亡对象，第二个为堆中存活对象的信息。

StudentDTO的实例明显过高，并且死亡实例高于存活对象很多，怀疑有一部分在老年代。

这时有些过于心急，以为大获全胜了，直接代码扫描了一下StudentDTO，然而并未发现有异常情况，都是简单的查库然后返回。

回过头来继续看堆中对象信息，发现ScheduledThreadPoolExecutor也有些不正常，同时看到了jetcache的数量也紧随其后。

一下就猜到了jetcache的@CacheRefresh，根据设定的key创建一个任务放到ScheduledThreadPoolExecutor中。

image.png

后台刷新任务是针对单个的key每个key都创建一个Runnable，对系统的线程池是一个考验，不能过度依赖自动刷新，要保证key是热点数据并且数量是有限的。

继续查看代码，使用到@CacheRefresh的地方，发现在获取学生基本信息的接口用到了StudentDTO，正好吻合。

去除@CacheRefresh后效果

1. 6小时堆内存对比

   
   
   image.png

image.png

2. GC情况对比

   
   
   image.png
   
   
   image.png