【原】利用mat分析hprof文件排查线上oom问题

之前给大家演示jvmsualvm分析oom的时候，我准备了两份hprof文件，其中有一份名为eureka.hprof的文件，是我使用jmap -dump命令手动从服务器上导出来的，当时服务器已经卡死了，所以我没办法利用arthas连接到jvm进程，而且我也无法使用jstack命令来精确定位代码，能定位到的也是GC线程。

没办法，我只好将当时的jvm堆内存导出来一份hprof文件，以期对这份文件能分析出结果，最后也是不出我所料，确实从这份文件中找到了导致oom的原因。

不幸的是，虽然将hprof文件导出来了，但是却无法通过jvisualvm工具来分析它，因为还没有来得及出现oom异常。

如上图，jvisualvm工具装入hprof文件之后，根本看不到导致oom异常的线程是哪一个。

遂，只能祭出mat（memory analyzer tools）来搞定它，这东西跟eclipse长得一模一样，idea用习惯了，这东西看起来还特么颇有一种古老沧桑的感觉。

不得不说，jvm堆内存的dump文件是真的大，线上服务器基本上都是配置的以G为单位的内存，大的一批，导入也要很久，而且使用这个mat更加严苛，运行mat工具的机器内存要两倍于hprof文件的大小，否则会打开出错。

如上图，我当时用笔记本电脑直接没能打开它，这是我用家里的台式机打开的这个hprof文件。

hprof文件加载完毕之后，大家注意上图中的红色框，我特意将入口打上标记，从这个入口点进去就能看到mat帮我们分析的一些结果。

呐，从上图中可以看到，入口名为“Leak Suspects”，中文翻译过来大概就是“内存泄漏的嫌疑对象”，这里为什么是内存泄漏呢，不应该是oom吗？

这个并不是人家用错了称呼，而是因为还没有oom，所以它只能当做内存泄漏来分析，让我们在排查的时候，能够找到一些可疑的对象。

不光是打开hprof文件耗时，mat工具分析也是要花时间的，我们等它一会儿，等它打开之后，会在原来hprof文件所在的目录中生成许多的文件。

如上图，我将hprof文件之外的文件全部框起来了，这些都是点击了“Leak Suspects”入口之后产生的。

大家尤其注意这个zip文件，这是一个很好的东西，mat将分析结果整理成了一个可视化的html文件，可以让我们直接在浏览器中打开，这个功能在做技术分享的时候就十分有用了，可以不用开mat，直接在浏览器中打开这个html就能看到各种分析报告。

大家看上面的截图，我特意给大家解压了那个zip看一眼，因为我都已经打开mat了，所以还是继续用mat查看，就不用html查看了。

如上图，在suspects这个分析报告的界面中，我红色框起来的部分，有一个See stacktrace入口，这是不是很熟悉？stacktracke栈，有了这个栈，我们就可以继续定位到调用的代码。

从图片中看到，它直接帮我们定位到了一个线程，那这个线程就是mat帮我们分析出来可能导致内存泄漏，也就是线上系统oom问题的代码。

如上图，使用了一些框架之后，调用栈就会显得比较长，我们向下滚动一下，就可以看到我们自己业务代码，这就是导致oom异常的方法了！！！

oom内存溢出java

看完文章，有任何疑问，请加入群聊一起交流！！！

很赞哦！ ()