收到报警
查看ARMS
根据老年代内存回收点情况可以看出老年代是可以回收干净的，排除内存泄漏。老年代的大小是通过几天的时间积攒下来的，怀疑可能是有大对象或者生命周期过长的对象。
对象何时进入老年代
内存担保机制
大对象直接进入老年代
长期存活的对象进入老年代
动态年龄判断进入老年代
进入机器继续排除
-
直接查看jvm参数
jps -v 或者 jinfo -flags <pid>
-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
-
jstat查看gc情况jstat -gcutil <6> 1000 30
经过多次观察，发现的问题是，每次进行YGC的时候都会有对象晋升到old区，但是交换区并未达到100。
所以大致定位问题是，有些对象的生命周期过长，导致晋升老年代。
-
下掉节点流量，执行jmap查看堆中对象信息
jmap -histo[:live] <pid>|head -n 20
image.png
图中一共执行2次jmap命令，第一次为堆中对象信息，包括死亡对象，第二个为堆中存活对象的信息。
StudentDTO的实例明显过高，并且死亡实例高于存活对象很多，怀疑有一部分在老年代。
这时有些过于心急，以为大获全胜了，直接代码扫描了一下StudentDTO，然而并未发现有异常情况，都是简单的查库然后返回。
回过头来继续看堆中对象信息，发现ScheduledThreadPoolExecutor也有些不正常，同时看到了jetcache的数量也紧随其后。
一下就猜到了jetcache的@CacheRefresh，根据设定的key创建一个任务放到ScheduledThreadPoolExecutor中。
后台刷新任务是针对单个的key每个key都创建一个Runnable，对系统的线程池是一个考验，不能过度依赖自动刷新，要保证key是热点数据并且数量是有限的。
继续查看代码，使用到@CacheRefresh的地方，发现在获取学生基本信息的接口用到了StudentDTO，正好吻合。
去除@CacheRefresh后效果
-
6小时堆内存对比
image.png
-
GC情况对比
image.png
image.png
