前言
生产环境OOM并不可怕,可怕的是你不知道问题所在,一直在扩大运行内存。楼主的生产环境OOM异常如图:
分析手段
首先需要做的是为运行环境加上gc日志&在内存溢出的时候让他产生一个内存快照。
我是tomcat运行的服务所以去改tomcat启动参数:
找到对应运行服务的tomcat/bin目录修改启动参数如下图
参数 | 作用 |
---|---|
-XX:MaxPermSize=4096M | 永久代大小调整 |
-XX:+PrintGCDetails | 开启了GC日志输出 |
-XX:+PrintGCDateStamps | 输出格式 |
-XX:+PrintGCTimeStamps | 输出格式 |
-Xloggc:/home/apache-tomcat-web/logs/gc.$$.log | 指定GC log的位置,以文件输出 |
-XX:+HeapDumpOnOutOfMemoryError | 快照保存 |
-XX:HeapDumpPath=/home/apache-tomcat-web/logs/ | 快照保存地址 |
PS:jvm性能调优是一个很复杂的东西,涉及到了很多东西,一般情况下大多数都是代码的问题引起的OOM异常,我们这里先附上一篇楼主认为写的比较好的博客,方便理解学习。
深入理解JVM原理:https://blog.csdn.net/know9163/article/details/80574488
冷静对待你遇到的所有Java内存异常:https://zazalu.space/2019/09/17/java-memory-error-solution-Theoretically/
言归正传,我们在启动了上面的参数后,在程序再一次产生OOM异常的时候,我们可以去/home/apache-tomcat-web/logs/目录下获取当时产生的内存快照如下图:
PS:gc日志是留着JVM调优用的
把这个快照文件从服务器上拿到本地电脑,然后用java自带的jvisualvm.exe分析
导入快照文件:
查看结果:
PS如果你跟我的问题不一样,可以去看看类找到占用最多的进行分析。
看类信息:
楼主这里基本已经定位问题了,
再结合jstack找出最耗cpu的线程:
https://blog.csdn.net/shasiqq/article/details/109801683
基本可以看出是Spring session(redis存储方式)监听导致创建大量redisMessageListenerContailner-X线程
解决办法
为spring session添加springSessionRedisTaskExecutor线程池。
Spring boot方式
/**
* 用于spring session,防止每次创建一个线程
* @return
*/
@Bean
public ThreadPoolTaskExecutor threadPoolTaskExecutor(){
ThreadPoolTaskExecutor threadPoolTaskExecutor= new ThreadPoolTaskExecutor();
threadPoolTaskExecutor.setCorePoolSize(8);
threadPoolTaskExecutor.setMaxPoolSize(