记录一次小型的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工程所占的内存情况如下：