最近生产遇到内存泄漏的问题,说一下排查过程及内心历程。
生产报错:java.lang.OutOfMemoryError: Java heap space
堆内存泄漏一般有以下情况:
1, 堆内存本身没有设置或者配置参数设置不合适,若按默认启动,默认是256m?512m?,而服务本身复杂,不够用
2, 堆中对象死了,但是GC无法回收空间,内存泄漏
3, 服务有大对象,当有过大对象时,而此时堆空间不足,内存溢出、
还有其他情况,上面三种情况都会导致java.lang.OutOfMemoryError错误。
所以针对上述情况排查过程如下:刚开始只是通过简单的jmap,jstat,jstack等命令分别查看了当时服务的堆内存状况,YGC,FGC次数及耗时时间,当时堆栈的情况等,看完之后,没有任何头绪,所以转换思路重新生成dump文件,执行如下命令:
jmap -dump:format=b,file=jconsole.dump pid
生产的dump文件用专门的工具memory analyzer分析。
分析思路如下:
导入文件后,界面如下:
1,Actions------>Histogram
先查看当前 Actions 下Histogram 查看当前每个类有多少实例如下:
图一
通过正则匹配,查看xxx服务类所占空间。
图略,分析原因不在这。
2,Reports----> LeakSuspects
Leak Suspects: includes leak suspects and asystem overview 内存泄漏和系统概况
点开 Leak Suspects 如图:
看到已经自动分析好的2个最可能的内存泄漏的问题,
问题1:
点开Details
找到
再找到
找到并打开所占数值大的对象
里面加载的是mybatis映射文件,正常,再找占用大内存的
一个是sql语句,一个是结果集
再分析sql语句,找出其中几个
body 是SQL语句
body是见截屏
是各种组装的sql语句及查询条件;
继续往下看,找到
看一下用堆内存比较大的对象,进去查看
其中一个,是数据库的某个字段
此问题的原因就是操作数据库,根据sql找到相关的代码,分析一下原因。
问题2:
类加载器加载对象占14.78%,分析如下:
找最大的对象 class,打开如下:
只列出25个,还有9797个,这大概可以说明1,服务依赖的类包多,但是微服务不应该有如此大的jar包依赖;
2,依赖的其他服务所依赖的包也加载进来,这就是多余的包,应该去掉多余的类包,减轻类加载器加载的jar包
分析建议:
分析服务所依赖的jar包,去掉多余的jar包,减少不必要的类加载。
至此,两个最可能内存泄漏的点已经找到。继续验证刚才的问题。
3, Reports-----> Top Components
Top Components: list reports for componentsbigger than 1 percent of the total heap.
列出报告中总内存占用大于1%的部分。
打开第一个:
打开:Possible Memory Waste 可能的内存垃圾
打开Details
由于String类型底层存储的就是字符数组,主要排查对象就是字符串,如下:
找到批量插入组装的sql语句,
略
验证了问题一的分析。
再看空间垃圾回收率很低,如下:翻译一下就是垃圾回收率低于20%的内存块
发现这些是存储类的反射及基本信息存储的
发现ibatis的sessionfactory占用了将近50%的堆空间,还是说明sql有问题,见上面分析出来的sql原因,再查代码。
再看软引用,这也会导致内存泄漏,如下:
打开Details,简单举例一个如下:
再结合代码分析,推测此类该方法发生了多个方法同时调用的问题,请避免此类问题,减少软引用,缩短垃圾回收时间。
再看Histogram of Softly Referenced:
看到有3300个软引用:
经过GC,仍然有581个存活:
查看原因:
前10个如下:
都是一些常量引用,如果这些常量没有必要,就别再加载了。
问题分析总结:
综上分析,建议如下:
1, sql问题,分析dump文件发现有大量查询语句,大量批量插入数据库,如xxxxx查询,需要结合代码查看是否有限制条件,或者是否一次性查出数据太多等;
如xxxxxx
等批量插入,是否涉及到插入数据量很大等等,结合代码分析,是否有继续优化的空间。
2, 类包问题,仔细分析一下xxx服务,到底都有哪些jar包需要依赖,把不需要依赖的排除掉,这样可以减少多余类对堆的占用,提供堆的利用空间和减少GC。