记录一次小型的java内存泄露问题排查过程
前不久发现自己的微信小程序突然挂了,查询后台发现tomcat竟然被干掉了,赶忙将服务重新启动,先解决问题再说。
然后就该想想tomcat的进程为什么会被杀掉了。
在排除人为因素后,就只有内存不够的情况下被Linux主动杀掉了。用free -h命令查了一下,发现内存就剩下120多MB了。我的天,我可是买的4G内存啊,mysql+2个java项目+redis就用光了?赶紧用top命令查看了每个程序所占用的内存。
需要在top所展示的界面下,再按一个大写M,这样整个列表就会按照内存使用情况进行排序,如下图(这张图是后来截的)。
可以看到经过一段时间运行后,一个java程序占用了24.6%的内存空间,另一个占用了16.6%的空间,太夸张了!初步怀疑是内存泄露了。
使用 jstat -gc pid 10000命令进行查看,每10秒打印一次GC状态,发现程序每隔190秒左右,就会发生一次FGC,这也太频繁了点。
再调用 jmap -dump:format=b,file=dump.hprof pid 命令将堆栈数据导出,下载到本地进行分析。生成的这个dump.hprof文件有点大,下载前最好用压缩命令压缩一下,不然太浪费时间了。
分析工具就使用大名鼎鼎的MAT工具,点击这里可以下载。
打开工具以后,选择File->Open Heap Dump,选择下好的dump.hprof文件就好。这里强烈建议将这个文件单独放到一个文件夹中,因为MAT在解析文件过程中会产生一堆子文件,我第一次打开的时候,直接铺满了整个桌面,整理起来好麻烦的。
这时会弹出一个对话框,选择第一项Leak Suspects Report就好。加载完毕界面如下:
最中间的饼图,就是将此时最占内存的几个实例列出来。可以看到有一个实例竟然占了一多半的内存了。如果想看到更细的饼图,点击下面的那个Top Consumers,在打开的页面中会看到更详细的内容
常用的分析方式有两种,就是Histogram和Dominator_Tree。
Histogram:以直方图的形式可以列出每个类产生的实例数量,以及所占用的内存大小和百分比;
Dominator_Tree:列出最大和保持其存活的对象,在此视图中列出了每个对象与其引用关系的树状结构,同时包含了占用内存的大小和百分比;
Histogram视图和Dominator_Tree视图的角度不同,前者是基于类的角度,后者是基于对象实例的角度,并且可以更方便的看出其引用关系。相对而言,我更喜欢用Dominator_Tree视图。两个视图中都有相同的字段:
ShallowHeap字段是指定义这个对象本身所占据的大小
RetainedHeap字段是该对象自己的ShallowHeap,再加上从该对象能直接或间接访问到对象的Shallow Heap之和。也就是说RetainedHeap是该对象GC之后所能回收到内存的总和。
我们一般都要按照RetainedHeap字段进行排序,最靠前的,就是疑似内存泄露的类。可以右键点击该类,按照上图所示,打开该类除了虚引用、弱引用和软引用以外的引用(这三个引用都会被JVM自动回收),也就是强引用。打开的界面如下图。
可以看到net.bull.javamelody.CollectorServer这个类存在108.45MB的强引用。
接着我们就可以去代码中分析这个类了,毕竟工具不会告诉你具体哪行出现的问题。我这个情况是因为采用了开源工具javamelody来进行系统分析的,可能是这个工具本身存在bug吧,导致了内存泄露,我也懒得去研究它了,直接删除这个工具就好了。(据说阿里的arthas工具不错,完了研究研究这个工具替代吧)。
最终处理完所有疑似内存泄露问题后,java工程所占的内存情况如下: