如何记录一次对dump文件的详细分析过程？

本文共计1941个文字，预计阅读时间需要8分钟。

一、背景+今天下午，正邪淡漠的聚集，突然运维同事在群里通知，核心服务某个节点内存异常，服务假死。神一紧张，立刻冲到运维那边，目睹了现场。

+观察结果：服务内异常

一、背景

今天下午，正酣畅淋漓的搬砖，突然运维同事在群里通知，核心服务某个节点内存异常，服务假死。神经一下子紧张起来，赶紧跑到运维那边观察现象。

观察的结果是服务内存溢出，该服务是核心服务，分配了5G内存。运维在转存快照后，立刻重启服务后正常。在接下来的一段时间里，另一台服务节点也发生了同样的情况。

二、分析过程

这个服务是另外一个同事负责开发的，本着学习的态度，在拿到运维转存的dump文件后，就准备尝试着分析下问题，由于之前没有类似的经历，于是先在网上查了下一般怎么分析类似的问题。

首先尝试使用MAT(Memory Analyzer)工具进行分析，下载后就准备载入dump文件，很不幸由于dump文件过大，载入失败了，于是调大了内存大小，尝试再次载入，但此时这个文件不再尝试重新载入，直接提示载入失败。

先不纠结工具的问题，然后网上说JDK自带的jvisualvm也可以用来分析dump文件, 但也遇到了同样内存不足的问题，再尝试修改jvisualvm的内存限制后, 成功载入了。

看到的界面是这样的，很明显看到char[]占用了近70%的内存，接近4G，这太不正常了，点进去看对应的实例(加载的非常慢，需要耐心)。

在实例数界面中看到实例数达到了千万级，大部分都是一些文件的路径字符串信息。在业务中，我们会生成很多临时文件，然后这些临时文件会删除，这里面大部分保存的是这些临时文件路径。

到这里导致内存泄露的原因似乎找到了，但好像又还不够，是什么原因导致这些临时变量没有被回收呢。

回到家后，还是想着这个事情，于是又开始研究起来，这个时候想起来可以再用MAT试着分析下，毕竟据说工具很强大。重启了电脑之后，经过漫长的等待，载入成功了(果然重启能解决一切问题)。