1. 前言

2. 内存分布详解及实战

2.1 全局信息概览

• 方法区溢出时（Java 8后不使用方法区，对应堆溢出），查看 class 数量异常多，可以考虑是否为动态代理类异常载入过多或类被反复重复加载。

• 方法区溢出时，查看 class loader 数量过多，可以考虑是否为自定义 class loader 被异常循环使用。

• GC Root 过多，可以查看 GC Root 分布，理论上这种情况极少会遇到，笔者只在 JNI 使用一个存在 BUG 的库时遇到过。

• 线程数过多，一般是频繁创建线程但无法执行结束，从概览可以了解异常表象，具体原因可以参考本文线程分析部分内容，此处不展开。

2.2 Dominator tree

• 展现对象的支配关系图，并给出对象支配内存的大小（支配内存等同于 Retained Heap，即其被 GC 回收可释放的内存大小）

• 支持排序、支持按 package、class loader、super class、class 聚类统计

• 开始 Dump 分析时，首先应使用 Dominator tree 了解各支配树起点对象所支配内存的大小，进而了解哪几个起点对象是 GC 无法释放大内存的原因。

• 当个别对象支配树的 Retained Heap 很大存在明显倾斜时，可以重点分析占比高的对象支配关系，展开子树进一步定位到问题根因，如下图中可看出最终是 SameContentWrapperContainer 对象持有的 ArrayList 过大。

• 在 Dominator tree 中展开树状图，可以查看支配关系路径（与 outgoing reference 的区别是：如果 X 支配 Y，则 X 释放后 Y必然可释放；如果仅仅是 X 引用 Y，可能仍有其他对象引用 Y，X 释放后 Y 仍不能释放，所以 Dominator tree 去除了 incoming reference 中大量的冗余信息）。

• 有些情况下可能并没有支配起点对象的 Retained Heap 占用很大内存（比如 class X 有100个对象，每个对象的 Retained Heap 是10M，则 class X 所有对象实际支配的内存是 1G，但可能 Dominator tree 的前20个都是其他class 的对象），这时可以按 class、package、class loader 做聚合，进而定位目标。
• 下图中各 GC Roots 所支配的内存均不大，这时需要聚合定位爆发点。
• 在 Dominator tree 展现后按 class 聚合，如下图：
• 可以定位到是 SomeEntry 对象支配内存较多，然后结合代码进一步分析具体原因。

• 在一些操作后定位到异常持有 Retained Heap 对象后（如从代码看对象应该被回收），可以获取对象的直接支配者，操作方式如下。

2.3 Histogram 直方图

• 罗列每个类实例的数量、类实例累计内存占比，包括自身内存占用量（Shallow Heap）及支配对象的内存占用量（Retain Heap）。

• 支持按对象数量、Retained Heap、Shallow Heap（默认排序）等指标排序；支持按正则过滤；支持按 package、class loader、super class、class 聚类统计，

• 有些情况 Dominator tree 无法展现出热点对象（上文提到 Dominator tree 支配内存排名前20的占比均不高，或者按 class 聚合也无明显热点对象，此时 Dominator tree 很难做关联分析判断哪类对象占比高），这时可以使用 Histogram 查看所有对象所属类的分布，快速定位占据 Retained Heap 大头的类。

• 使用技巧
• Integer，String 和 Object[] 一般不直接导致内存问题。为更好的组织视图，可以通过 class loader 或 package 分组进一步聚焦，如下图。
• Histogram 支持使用正则表达式来过滤。例如，我们可以只展示那些匹配com.q.*的类。
• 可以在 Histogram 的某个类继续使用 outgoing reference 查看对象分布，进而定位哪些对象是大头

2.4 Leak Suspects

• 下图中 Leak Suspects 视图展现了两个线程支配了绝大部分内存。

• 下图是点击上图中 Keywords 中 "Details" ,获取实例到 GC Root 的最短路径、dominator 路径的细信息。

2.5 Top Consumers

2.6 综合案例一

1. 首先进入 Dominator tree，可以看出是 SameContentWrapperContainerProxy 对象与 main 线程两者持有99%内存不能释放导致 OOM。

2. 先来看方向一，在 Heap Dump Overview 中可以快速定位到 Number of class loaders 数达50万以上，这种基本属于异常情况，如下图所示。

3. 使用 Class Loader Explorer 分析工具，此时会展现类加载详情，可以看到有524061个 class loader。我们的案例中仅有ClassLoaderOOMOps 这样的自定义类加载器，所以很快可以定位到问题。

4. 如果类加载器较多，不能确定是哪个引发问题，则可以将所有的 class loader对象按类做聚类，如下图所示。

5. Histogram 会根据 class 聚合，并展现对象数量级其 Shallow Heap 及 Retained Heap（如Retained Heap项目为空，可以点击下图中计算机的图标并计算 Retained Heap），可以看到 ClassLoaderOOMOps 有524044个对象，其 Retain Heap 占据了370M以上（上述代码是100M左右）。

6. 使用 incoming references，可以找到创建的代码位置。

7. 再来看方向二，同样在占据319M内存的 Obejct 数组采用 incoming references 查看引用路径，也很容易定位到具体代码位置。并且从下图中我们看出，Dominator tree 的起点并不一定是 GC根，且通过 Dominator tree 可能无法获取到最开始的创建路径，但 incoming references 是可以的。

3. 对象间依赖详解及实战

3.1 References

• outgoing reference：查看对象所引用的对象，并支持链式传递操作。如查看一个大对象持有哪些内容，当一个复杂对象的 Retained Heap 较大时，通过 outgoing reference 可以查看由哪个属性引发。下图中 A 支配 F，且 F 占据大量内存，但优化时 F 的直接支配对象 A 无法修改。可通过 outgoing reference 看关系链上 D、B、E、C，并结合业务逻辑优化中间环节，这依托 dominator tree 是做不到的。

• incoming reference：查看对象被哪些对象引用，并支持链式传递操作。如查看一个大对象都被哪些对象引用，下图中 K 占内存大，所以 J 的 Retained Heap 较大，目标是从 GC Roots 摘除 J 引用，但在 Dominator tree 上 J 是树根，无法获取其被引用路径，可通过 incoming reference 查看关系链上的 H、X、Y ，并结合业务逻辑将 J 从 GC Root 链摘除。

3.2 Thread overview

• 查看不同线程持有的内存占比，定位高内存消耗线程（开发技巧：不要直接使用 Thread 或 Executor 默认线程名避免全部混合在一起，使用线程尽量自命名方便识别，如下图中 ThreadAndListHolder-thread 是自定义线程名，可以很容易定位到具体代码）

• 查看线程的执行栈及变量，结合业务代码了解线程阻塞在什么地方，以及无法继续运行释放内存，如下图中 ThreadAndListHolder-thread 阻塞在 sleep 方法。

3.3 Path To GC Roots

3.4 class loader 分析

• 查看堆中所有 class loader 的使用情况（入口：MAT 主页菜单蓝色桶图标 → Java Basics → Class Loader Explorer）。

• 查看堆中被不同class loader 重复加载的类（入口：MAT 主页菜单蓝色桶图标 → Java Basics → Duplicated Classes）。

• 当从 Heap dump overview 了解到系统中 class loader 过多，导致占用内存异常时进入更细致的分析定位根因时使用。

• 解决 NoClassDefFoundError 问题或检测 jar 包是否被重复加载

3.5 综合案例二

1. 进入 MAT 已加载的重复类检测功能，方式如下图。

2. 可以看到所有重复的类，以及相关的类加载器，如下图。

3. 根据类名，在<Regex>框中输入类名可以过滤无效信息。

4. 选中目标类，通过Inspector视图，可以看到被加载的类具体是在哪个jar包里。（本例中重复的类是被 URLClassloader 加载的，右键点击 “_context” 属性，最后点击 “Go Into”，在弹出的窗口中的属性 “_war” 值是被加载类的具体包位置）

4. 对象状态详解及实战

4.1 inspector

• 当内存使用量与业务逻辑有较强关联的场景，通过 inspector 可以通过查看对象具体属性值。比如：社交场景中某个用户对象的好友列表异常，其 List 长度达到几亿，通过 inspector 面板获取到异常用户 ID，进而从业务视角继续排查属于哪个用户，本例可能有系统账号，与所有用户是好友。

• 集合等类型的使用会较多，如查看 ArrayList 的 size 属性也就了解其大小。

4.2 集合状态

• 通过对 ArrayList 或数组等集合类对象按填充率聚类，定位稀疏或空集合类对象造成的内存浪费。

• 通过 HashMap 冲突率判定 hash 策略是否合理。

4.3 综合案例三

1. 使用 Dominator tree 查看并无高占比起点。

2. 使用 Histogram 定位到 ListHolder 及 ArrayList 占比过高，经过业务分析很多 List 填充率很低浪费内存。

3. 查看 ArrayList 的填充率，MAT 首页 → Java Collections → Collection Fill Ratio。

4. 查看类型填写 java.util.ArrayList。

5. 从结果可以看出绝大部分 ArrayList 初始申请长度过大。

5. 按条件检索详解及实战

5.1 OQL

• Select 子句可以使用“*”，查看结果对象的引用实例（相当于 outgoing references）；可以指定具体的内容，如 Select OBJECTS v.elementData from xx 是返回的结果是完整的对象，而不是简单的对象描述信息)；可以使用 Distinct 关键词去重。

• From 指定查询范围，一般指定类名、正则表达式、对象地址。

• Where 用来指定筛选条件。

• 全部语法详见：OQL 语法

• 未支持的核心功能：group by value，如果有需求可以先导出结果到 csv 中，再使用 awk 等脚本工具分析即可。

• 例子：查找 size＝0 且未使用过的 ArrayList：select * from java.util.ArrayList where size=0 and modCount=0。

• 一般比较复杂的问题会使用 OQL，而且这类问题往往与业务逻辑有较大关系。比如大量的小对象整体占用内存高，但预期小对象应该不会过多（比如达到百万个），一个一个看又不现实，可以采用 OQL 查询导出数据排查。

• 例子：微服务的分布式链路追踪系统，采集各服务所有接口名，共计200个服务却采集到了200万个接口名（一个服务不会有1万个接口），这时直接在 List 中一个个查看很难定位，可以直接用 OQL 导出，定位哪个服务接口名收集异常（如把 URL 中 ID 也统计到接口中了）

5.2 检索及筛选

5.3 按地址寻址

5.4 综合案例四

1. 内存中有50万个 capacity = 10 的空 ArrayList 实例。我们分析下这些对象的占用内存总大小及对象创建位置，以便分析延迟初始化（即直到使用这些对象的时候才将之实例化，否则一直为null）是否有必要。

2. 使用 OQL 查询出初始化后未被使用的 ArrayList（size=0 且 modCount=0），语句如下图。可以看出公有 150 万个空 ArrayList，这些对象属于浪费内存。我们接下来计算下总计占用多少内存，并根据结果看是否需要优化。

3. 计算 150万 ArrayList占内存总量，直接点击右上方带黄色箭头的 Histogram 图标，这个图标是在选定的结果再用直方图展示，总计支配了120M 左右内存（所以这里点击结果，不包含 modCount 或 size 大于0的 ArrayList 对象）。这类在选定结果继续分析很多功能都支持，如正则检索、Histogram、Dominator tree等等。

4. 查看下空 ArrayList 的具体来源，可用 incoming references，下图中显示了清晰的对象创建路径。

总结展望

参考