Java 的 OutOfMemoryError 是比较严重的问题，需要分析出根因，所以对生产应用一般都会这样设置 JVM 参数，方便发生 OOM 时进行堆转储：

  1. -XX:+HeapDumpOnOutOfMemoryError 
  2. -XX:HeapDumpPath=.

Eclipse MAT 就是用于分析由 jmap 命令导出的 Java 堆转储快照的工具。当用 MAT 分析 OOM 问题时，一般可按以下思路进行：

  • 通过支配树功能或直方图功能查看消耗内存最大的类型，来分析内存泄露的大概原因；
  • 查看那些消耗内存最大的类型、详细的对象明细列表，以及它们的引用链，来定位内存泄露的具体点；
  • 配合查看对象属性的功能，可以脱离源码看到对象的各种属性的值和依赖关系，帮助我们理清程序逻辑和参数；
  • 辅助使用查看线程栈来看 OOM 问题是否和过多线程有关，甚至可以在线程栈看到 OOM 最后一刻出现异常的线程。

获取堆转储快照

MAT 本身也能够获取堆的二进制快照。该功能将借助 jps 列出当前正在运行的 Java 进程，以供选择并获取堆转储快照。
image.png
MAT 获取二进制快照的方式有三种，一是使用 Attach API，二是新建一个 Java 虚拟机来运行 Attach API，三是使用 jmap 工具。这三种本质上都是在使用 Attach API。不过，当在目标进程启用了 DisableAttachMechanism 参数时，前两者将不在选取列表中显示，后者将在运行时报错。
image.png

分析堆转储快照

首先，用 MAT 打开后先进入的是概览信息界面，概览界面将展示一张饼状图，其中列举占据的 Retained heap 最多的几个对象。这里以一个由于 OOM 导出的 dump 文件为例，可以看到整个堆是 437.6MB
1.png
这里讲一下 MAT 计算对象占据内存的两种方式。第一种是 Shallow heap，指的是对象自身所占据的内存。第二种是 Retained heap，指的是当对象不再被引用时，垃圾回收器所能回收的总内存，包括对象自身所占据的内存，以及仅能够通过该对象引用到的其他对象所占据的内存。上面的饼状图便是基于 Retained heap 的。

MAT 中包括了两个比较重要的视图，分别为直方图（histogram）和支配树（dominator tree）。下面我们就来分析下这 437.6MB 都是些什么对象呢？

1. 直方图

如图所示，工具栏的第二个按钮可以打开直方图。MAT 的直方图和 jmap 的 -histo 子命令一样，都能够展示各个类的实例数目以及这些实例的 Shallow heap 总和。但 MAT 的直方图还能够计算 Retained heap，并支持基于实例数目或 Retained heap 的排序方式（默认为 Shallow heap）。此外，MAT 还可以将直方图中的类按照超类、类加载器或者包名分组。
1.png
在 char[] 上点击右键，选择 List objects->with incoming references，就可以列出所有的 char[] 实例，以及每个 char[] 的整个引用关系链：
1.png
随机展开一个 char[]，如下图所示：
2.png
接下来，我们按照红色框中的引用链来查看，尝试找到这些大 char[] 的来源：

  • 在①处看到，这些 char[] 几乎都是 10000 个字符、占用 20000 字节左右（char 是 UTF-16，每一个字符占用 2 字节）；
  • 在②处看到，char[] 被 String 的 value 字段引用，说明 char[] 来自字符串；
  • 在③处看到，String 被 ArrayList 的 elementData 字段引用，说明这些字符串加入了一个 ArrayList 中；
  • 在④处看到，ArrayList 又被 FooService 的 data 字段引用，这个 ArrayList 整个 RetainedHeap 列的值是 431MB。

Retained Heap（深堆）代表对象本身和对象关联的对象占用的内存，Shallow Heap（浅堆）代表对象本身占用的内存。比如，我们的 FooService 中的 data 这个 ArrayList 对象本身只有 16 字节，但是其所有关联的对象占用了 431MB 内存。这就说明，肯定有哪里在不断向这个 List 中添加 String 数据，导致了 OOM。
CgpOIF5NRsmAEeWTAABDIx8RWa4815.png
左侧的蓝色框可以查看每一个实例的内部属性，图中显示 FooService 有一个 data 属性，类型是 ArrayList。如果我们希望看到字符串完整内容的话，可以右键选择 Copy->Value，把值复制到剪贴板或保存到文件中：
1.png
这里，我们复制出的是 10000 个字符 a（下图红色部分可以看到）。对于真实案例，查看大字符串、大数据的实际内容对于识别数据来源，有很大意义：
2.png
看到这些，我们已经基本可以还原出真实的代码是怎样的了。

2. 支配树

支配树则展示了快照中每个对象所直接支配的对象。我们可以将堆中所有的对象看成一张对象图，每个对象是一个图节点，而 GC Roots 则是对象图的入口，对象之间的引用关系则构成了对象图中的有向边。这样一来，我们便能够构造出该对象图所对应的支配树。MAT 将按照每个对象 Retained heap 的大小排列该支配树。
Cgq2xl5NRsmATfB_AACo8ZKxSls467.png
如上图，左边是引用关系，右边是支配树视图。可以看到 A、B、C 被当作是虚拟的根，支配关系是可传递的，因为 C 支配 E，E 支配 G，所以 C 也支配 G。另外，到对象 C 的路径中，可以经过 A，也可以经过 B，因此对象 C 的直接支配者也是根对象。同理，对象 E 是 H 的支配者。对象 F 与对象 D 相互引用，因为到对象 F 的所有路径必然经过对象 D，因此，对象 D 是对象 F 的直接支配者。

其实，我们之前使用直方图定位 FooService，已经走了些弯路。你可以点击工具栏中第三个按钮（下图左上角的红框所示）进入支配树界面。这个界面会按照对象保留的 Retained Heap 倒序直接列出占用内存最大的对象。

可以看到，第一位就是 FooService，整个路径是 FooSerice->ArrayList->Object[]->String->char[]（蓝色框部分），一共有 21523 个字符串（绿色方框部分）：
1.png
当在支配树视图中选中某一对象时，我们还可以通过 Path To GC Roots 功能，反向列出该对象到 GC Roots 的引用路径。如下图所示：
e04d55d955832bf681aba16dcffc2ee7.png

3. 线程视图

如果我们想知道在 OOM 发生时 FooService 在执行什么逻辑呢？为解决这个问题，我们可以点击工具栏的第五个按钮（下图红色框所示）。打开线程视图，首先看到的就是一个名为 main 的线程（Name 列），展开后果然发现了 FooService：
2.png
先执行的方法先入栈，所以线程栈最上面是线程当前执行的方法，逐一往下看能看到整个调用路径。因为我们希望了解 FooService.oom() 方法，看看是谁在调用它，它的内部又调用了谁，所以选择以 FooService.oom() 方法（蓝色框）为起点来分析这个调用栈。

往下看整个绿色框部分，oom() 方法被 OOMApplication 的 run 方法调用，而这个 run 方法又被 SpringAppliction.callRunner 方法调用。看到参数中的 CommandLineRunner 你应该能想到，OOMApplication 其实是实现了 CommandLineRunner 接口，所以是 SpringBoot 应用程序启动后执行的。

以 FooService 为起点往上看，从紫色框中的 Collectors 和 IntPipeline，你大概也可以猜出，这些字符串是由 Stream 操作产生的。再往上看，可以发现在 StringBuilder 的 append 操作的时候，出现了 OutOfMemoryError 异常（黑色框部分），说明这这个线程抛出了 OOM 异常。

4. OQL

点击工具栏的第四个按钮（如下图红框所示），来到 OQL 界面。在这个界面，我们可以使用类似 SQL 的语法，在 dump 中搜索数据（你可以直接在 MAT 帮助菜单搜索 OQL Syntax，来查看 OQL 的详细语法）。

比如，输入如下语句搜索 FooService 的实例：

  1. SELECT * FROM org.geekbang.time.commonmistakes.troubleshootingtools.oom.FooService

可以看到只有一个实例，然后我们通过 List objects 功能搜索引用 FooService 的对象：
1.png
得到以下结果：
2.png
可以看到，一共两处引用：

  • 第一处是，OOMApplication 使用了 FooService，这个我们已经知道了。
  • 第二处是一个 ConcurrentHashMap。可以看到，这个 HashMap 是 DefaultListableBeanFactory 的 singletonObjects 字段，可以证实 FooService 是 Spring 容器管理的单例的 Bean。

你甚至可以在这个 HashMap 上点击右键，选择 Java Collections->Hash Entries 功能，来查看其内容：
1.png
这样就列出了所有的 Bean，可以在 Value 上的 Regex 进一步过滤。输入 FooService 后可以看到，类型为 FooService 的 Bean 只有一个，其名字是 fooService：
2.png
到现在为止，我们虽然没看程序代码，但是已经大概知道程序出现 OOM 的原因和大概的调用栈了。

OQL 的使用示例：

  1. # 查询 A4MAT 对象：
  2. SELECT * FROM  Objects4MAT$A4MAT
  4. # 正则查询 MAT 结尾的对象：
  5. SELECT * FROM ".*MAT"
  7. # 查询 String 类的 char 数组：
  8. SELECT OBJECTS s.value FROM java.lang.String s 
  9. SELECT OBJECTS mat.b4MAT FROM  Objects4MAT$A4MAT mat
  11. # 根据内存地址查找对象：
  12. select * from 0x55a034c8
  14. # 使用 INSTANCEOF 关键字，查找所有子类：
  15. SELECT * FROM INSTANCEOF java.util.AbstractCollection
  17. # 查询长度大于 1000 的 byte 数组：
  18. SELECT * FROM byte[] s WHERE s.@length>1000
  20. # 查询包含 java 字样的所有字符串：
  21. SELECT * FROM java.lang.String s WHERE toString(s) LIKE ".*java.*"
  23. # 查找所有深堆大小大于 1 万的对象：
  24. SELECT * FROM INSTANCEOF java.lang.Object o WHERE o.@retainedHeapSize>10000