现象

调整前

visualGc工具 在线分析

jprofile工具 在线分析

调整后

解决

排查思路

1.发现eden区一直在增长,cpu负载抖动较大 30s左右触发一次youngGc 而本地的jvm参数没有设置过,即使用默认的参数 s0和s1和老年代没有明显增长,没有触发过oom 初步怀疑是内存泄漏 怀疑是创建了大量的线程,占满了eden,导致触发gc

2.观察gc情况 jstat -gcutil 9448

using thread-local object allocation. S0 S1 E O M CCS YGC YGCT FGC FGCT GCT

0.00 10.42 14.28 25.31 94.60 91.66 87 3.682 6 3.067 6.750

发现gc过于频繁

3.经观察线程情况 (windows,使用jprofile) 存在大量死亡的 RedisListeningContainer-X线程 ??? 哪里有创建,怎么这么快死掉了

根据线程名称,找到相关的代码 org.springframework.data.redis.listener.RedisMessageListenerContainer

4.最终定位 org.springframework.core.task.SimpleAsyncTaskExecutor 问问万能的GPT

5.根据以上,先把这个简单线程池换掉,看看效果

实际加了springSessionRedisTaskExecutor之后,问题就解决了

6.找找问题产生的根源

先阅读这两篇文章 springsession的监听创建大量线程导致异常的参考: www.cnblogs.com/aoeiuv/p/95…

了解一下: RedisSession监听机制 DispatchMessageListener blog.csdn.net/weixin_3952…

我们发现这个包下的这个类:

这玩意可以简单理解就是Mq