分析和定位线上作业 OOM 问题利器-MAT
点击上方蓝色字体，选择“设为星标”
本文作者：学无止境 原文链接：https://www.cnblogs.com/duanxz/p/6046055.html在工作中可能会遇到内存溢出这种灾难性的问题，那么程序肯定是存在问题，找出问题至关重要，上一篇文章讲了jmap命令的使用方法，当然用jmap导出的文件我们也看不懂啊，那就交给memory analyzer(mat)这个工具，让他帮助我们来观察程序的内存分布情况吧。MAT 不是一个万能工具，它并不能处理所有类型的堆存储文件。但是比较主流的厂家和格式，例如 Sun, HP, SAP 所采用的 HPROF 二进制堆存储文件，以及 IBM 的 PHD 堆存储文件等都能被很好的解析。下面来看看要怎么做呢，也许对你有用。官方文档：http://help.eclipse.org/luna/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html造成OutOfMemoryError原因一般有2种：1、内存泄露，对象已经死了，无法通过垃圾收集器进行自动回收，通过找出泄露的代码位置和原因，才好确定解决方案；2、内存溢出，内存中的对象都还必须存活着，这说明Java堆分配空间不足，检查堆设置大小（-Xmx与-Xms），检查代码是否存在对象生命周期太长、持有状态时间过长的情况。
jmap 命令生成堆信息
jmap -dump:live,format=b,file=E:/jmap/heap.dump pid
这样在E盘的jmap文件夹里会有一个map.bin的堆信息文件这样在E盘的jmap文件夹里会有一个map.bin的堆信息文件将堆信息导入到mat中分析
生成分析报告
mat可以为我们生成多个报告：
从上图可以看到它的大部分功能，在饼图上,你会发现转储的大小和数量的类,对象和类加载器。正确的下面,饼图给出了一个印象最大的对象转储。移动你的鼠标看到对象中的对象的细节检查在左边。下面的Action标签中：Histogram可以列出内存中的对象，对象的个数以及大小。
Dominator Tree可以列出那个线程，以及线程下面的那些对象占用的空间。
Top consumers通过图形列出最大的object。
Leak Suspects通过MA自动分析泄漏的原因。
Histogram
Class Name ：类名称，java类名
Objects ：类的对象的数量，这个对象被创建了多少个
Shallow Heap ：一个对象内存的消耗大小，不包含对其他对象的引用
Retained Heap ：是shallow Heap的总和，也就是该对象被GC之后所能回收到内存的总和
这儿借助工具提供的regex正则搜索一下我们自己的类，排序后看看哪些相对是占用比较大的。
左边可以看到类的详细使用，比如所属包，父类是谁，所属的类加载器，内存地址，占用大小和回收情况等
这儿有个工具可以根据自己的需求分组查找，默认根据class分组，类似我们sql里的group by了~~
这里可以看到上面3个选项，分别生成overview、leak suspects、top components数据，但是这儿生成的不是图表，如果要看图表在（Overview）中的Action标签里点击查看。这个是Overview中的 Heap Dump Overview视图，从工具栏中点开，这是一个全局的内存占用信息
Dominator Tree
我们可以看到ibatis占了较多内存Top consumers
这张图展示的是占用内存比较多的对象的分布，下面是具体的一些类和占用。
按等级分布的类使用情况，其实也就是按使用次数查看，java.lang.Class被排在第一
还有一张图是我们比较关心的，那就是按包名看占用，根据包我们知道哪些公共用的到jar或自己的包占用
这样就可以看到包和包中哪些类的占用比较高。Leak Suspects
从这份报告，看到该图深色区域被怀疑有内存泄漏，可以发现整个heap只有79.7M内存，深色区域就占了62%。所以，MAT通过简单的报告就说明了项目是有可疑代码的，具体点开详情来找到类，
点击鼠标，在List Objects-> with outgoing references下可以查看该类都引用了什么对象，由此查看是否因为其他对象导致的内存问题。下面继续查看pool的gc ROOT如下图所示的上下文菜单中选择 Path To GC Roots -> exclude weak references, 过滤掉弱引用，因为在这里弱引用不是引起问题的关键。进入查看即可，我这儿的代码没有问题，就不用贴了。
The classloader/component "org.apache.catalina.loader.WebappClassLoader @ 0xa34cde8" occupies 19,052,864 (22.80%) bytes. The memory is accumulated in one instance of "java.util.HashMap$Entry[]" loaded by "" .
Keywords
java.util.HashMap$Entry[]
org.apache.catalina.loader.WebappClassLoader @ 0xa34cde8
这段话是在工具中提示的，他告诉我们WebappClassLoader占了19,052,864 字节的容量，这是tomcat的类加载器，JDK自带的系统类加载器中占用比较多的是HashMap。这个其实比较正常，大家经常用map作为存储容器。除了在上一页看到的描述外，还有Shortest Paths To the Accumulation Point和Accumulated Objects部分，这里说明了从GC root到聚集点的最短路径，以及完整的reference chain。观察Accumulated Objects部分，java.util.HashMap的retained heap(size)最大，所以明显类实例都聚集在HashMap中了。
来看看Accumulated Objects by Class区域，这里能找到被聚集的对象实例的类名。java.util.HashMap类上头条了，被实例化了5573次，从这儿看出这个程序不存在什么问题，因为这个数字是比较正常的，但是当出问题的时候我们都会看到比较大的自定义类会在前面，而且占用是相当高。当然，mat这个工具还有很多的用法，这里把我了解的分享给大家，不管如何，最终我们需要得出系统的内存占用，然后对其进行代码或架构，服务器的优化措施！欢迎点赞+收藏+转发朋友圈素质三连文章不错？点个【在看】吧！ ?
评论