玩转MAT—dump与动态分析

前言

我们使用jmap-histo这种命令去分析哪些对象占据着我们的堆空间。但是那是比较容易分析的问题。如果遇到的是内存情况比较复杂的情况，基础命令是不容易分析问题的。这时，我们需要借助工具。今天介绍的工具MAT，既可以使用dump日志分析内存问题，也可以在程序运行期间，获取程序当时运行的快照进行分析。

内存分析工具

JDK自带工具VisualVM

案例

分析代码

本程序可以大概看一下，首先先启动一个线程池。这个线程池的其实容量与最大容量设置死，也就是说最多可同时容纳开启50个线程执行任务。并且队列使用的无界队列。

仔细分析代码可以知道，我们每0.1s给线程池丢100个任务，而线程池没3s才搞定一个任务。因此这些未执行的任务的对象无法回而导致OOM。

-XX:+HeapDumpOnOutOfMemoryError//此参数添加后，可以在程序OOM后自动生成dump日志。

使用VisualVM

VisualVM目录在我们的jdk/bin下。

VisualVm 属于比较寒酸的工具，基本上跟 jmap 之类的命令没多少区别，它只是可以事后看，通过 dump 信息来看，里面没有多少可以做分析的功能。

MAT简介

MAT 工具是基于 Eclipse 平台开发的，本身是一个 Java 程序，是一款很好的内存分析工具，所以如果你的堆快照比较大的话，则需要一台内存比较大的分析机器，并给 MAT 本身加大初始内存，这个可以修改安装目录中的 MemoryAnalyzer.ini 文件

概要

柱状图

MAT中的Incoming/Outgoing References

在柱状图中，我们看到，其实它显示的东西跟 jmap –histo 非常相似的，也就是类、实例数量、空间大小。

但是 MAT 有一个专业的概念，这个可以显示对象的引入和对象的引出。

在 Eclipse MAT 中，当右键单击任何对象时，将看到下拉菜单。如果选择“ListObjects”菜单项，则会注意到两个选项：

Ø with incoming references 对象的引入
Ø with outgoing references 对象的引出

案例

我们说两个类直接的关系除了继承之外，还可以是组合。

我们根据上述代码可以画出各类的组合关系图:

代码中对象和引用关系如下：

对象 A 和对象 B 持有对象 C 的引用

对象 C 持有对象 D 和对象 E 的引用

运行程序

MAT 连接上（MAT 不单单只打开 dump 日志，也可以打开正在运行的 JVM 进程，跟 arthas 有点类似，效果是一样的，只是一个是动态的，一个是日志导出那个时刻的）

可以从上面的图中分析，看到incoming references代表该类对象被哪些类所持有。相反的，outgoing reference代表本类所持有哪些类的对象。

这个 outgoing references 和 incoming references 非常有用，因为我们做 MAT 分析一般时对代码不了解，排查内存泄漏也好，排查问题也好，垃圾回收中有一个很重要的概念，可达性分析算法，那么根据这个引入和引出，我就可以知道这些对象的引用关系，在 MAT 中我们就可以知道比如 A,B,C,D,E,F 之间的引用关系图，便于做具体问题的分析。

MAT中的浅堆和深堆

浅堆（shallow heap）

代表了对象本身的内存占用，包括对象自身的内存占用，以及“为了引用”其他对象所占用的内存。

深堆（Retained heap）

是一个统计结果，会循环计算引用的具体对象所占用的内存。但是深堆和“对象大小”有一点不同，深堆指的是一个对象被垃圾回收后，能够释放的内存大小，这些被释放的对象集合，叫做保留集（Retained Set）

Java对象内存大小

JAVA 对象大小=对象头+实例数据+对齐填充

非数组类型

浅堆（shallow_size）=对象头+各成员变量大小之和+对齐填充

其中，各成员变量大小之和就是实例数据，如果存在继承的情况，需要包括父类成员变量

数组类型

深堆（Retained _size）=对象头+类型变量大小*数组长度+对齐填充，如果是引用类型，则是四字节或者八字节（64 位系统），如果是 boolean 类型，则是一个字节。

注意：这里类型变量大小*数组长度就是实例数据，强调是变量不是对象本身。

案例分析

对象 A 持有对象 B 和 C 的引用。

对象 B 持有对象 D 和 E 的引用。

对象 C 持有对象 F 和 G 的引用。

一句话，浅堆就是自身对象大小，那么深堆就是根可达分析自己后面的引用链对象总大小+自己的大小呢？我们接着看。往往深堆更能体现出一个对象的回收价值。

引用变动的影响

在下面的示例中，让对象 H 开始持有对 B 的引用。注意对象 B 已经被对象 A 引用了。

在这种情况下，对象 A 的 Retained heap 大小将从之前的 70 减小到 40 个字节

如果对象 A 被垃圾回收了，则将仅会影响 C、F 和 G 对象的引用。因此，仅对象 C、F 和 G 将被垃圾回收。另一方面，由于 H 持有对 B 的活动引用，因此对象 B、D 和 E 将继续存在于内存中。因此，即使 A 被垃圾回收，B、D 和 E 也不会从内存中删除。因此，A 的 Retained heap 大小为：= A的 shallow heap 大小 + C 的 shallow heap 大小 + F 的 shallow heap 大小 + G 的 shallow heap 大小 = 10 bytes + 10 bytes + 10 bytes + 10 bytes = 40

bytes.

总结：因此我们说深堆大小并不能直接从引用链的角度来分析，而是要站在垃圾回收的根可达分析算法的角度，看这个对象会收的后真正可以释放的内存大小。我们分析问题时，往往去那些深堆很大，尤其那些浅堆比较小，但深堆比较大的对象。它们极有可能是有问题的对象。

使用 MAT 进行内存泄漏检测

案例

仔细分析代码，我们可以发现A引出B引出C。king-thread线程中，包含一个map，map又引出了A（包含了A的实例a）。同时Demo1与Demo2互相引用。总结为下图关系：

运行程序并使用MAT调试

当我们产生问题时，MAT会帮助我们进行问题猜测。这个程序的泄漏很明显，就是线程无法结束，导致map无法销毁，导致深堆过大的内存泄漏。

这里一个名称叫做 king-thread 的线程，持有了超过 99% 的对象，数据被一个 HashMap 所持有。

这个就是内存泄漏的点，因为我代码中对线程进行了标识，所以像阿里等公司的编码规范中为什么一定要给线程取名字，这个是有依据的，如果不取名字的话，这种问题的排查将非常困难。

所以，如果是对于特别明显的内存泄漏，在这里能够帮助我们迅速定位，但通常内存泄漏问题会比较隐蔽，我们需要做更加复杂的分析。

支配树视图

支配树列出了堆中最大的对象，第二层级的节点表示当被第一层级的节点所引用到的对象，当第一层级对象被回收时，这些对象也将被回收。这个工具可以帮助我们定位对象间的引用情况，以及垃圾回收时的引用依赖关系。支配树视图对数据进行了归类，体现了对象之间的依赖关系。我们通常会根据“深堆”进行倒序排序，可以很容易的看到占用内存比较高的几个对象，点击前面的箭头，即可一层层展开支配关系（依次找深堆明显比浅堆大的对象）。

从上图层层分解，我们也知道，原来是 king-thread 的深堆和浅堆比例很多（深堆比浅堆多很多、一般经验都是找那些浅堆比较小，同时深堆比较大的对

象）

1、一个浅堆非常小的 king-thread 持有了一个非常大的深堆

2、这个关系来源于一个 HashMap

3、这个 map 中有对象 A，同时 A 中引用了 B，B 中引用了 C

4、最后找到 C 中里面有一个 ArrayList 引用了一个大数据的数组。经过分析，内存的泄漏点就在此。线程中的map长期持有100个超大的ArrayList ,有可能导致内存泄漏。

MAT 中内存对比

我们对于堆的快照，其实是一个“瞬时态”，有时候仅仅分析这个瞬时状态，并不一定能确定问题，这就需要对两个或者多个快照进行对比，来确定一个增长趋势。我们导出两份 dump 日志，分别是上个例子中循环次数分别是 10 和 100 的两份日志。

线程视图

想要看具体的引用关系，可以通过线程视图。线程在运行中是可以作为 GC Roots 的。我们可以通过线程视图展示了线程内对象的引用关系，以及方法调用关系，相对比 jstack 获取的栈 dump，我们能够更加清晰地看到内存中具体的数据。我们找到了 king-thread，依次展开找到 holder 对象，可以看到内存的泄漏点