JVM故障分析及性能优化系列之七：使用MAT的Histogram和Dominator Tree定位溢出源

灰太狼 2021-08-19 18:10 531阅读 0赞

上一篇文章概括的介绍了JVM Heap Dump文件生成的方式以及内存分析工具MAT的概要功能，今天讲解如何使用MAT的Histogram和Dominator Tree两个视图，定位到内存溢出源。

**目录**

基础概念

Shallow Heap 和 Retained Heap

对象引用（Reference）

GC Roots和Reference Chain

Histogram（直方图）视图

Dominator Tree视图

定位溢出源

后续观察

--------------------

## 基础概念 ##

先列出几个基础的概念：

### Shallow Heap 和 Retained Heap ###

Shallow Heap表示对象本身占用内存的大小，不包含对其他对象的引用，也就是对象头加成员变量（不是成员变量的值）的总和。

Retained Heap是该对象自己的Shallow Heap，并加上从该对象能直接或间接访问到对象的Shallow Heap之和。换句话说，Retained Heap是该对象GC之后所能回收到内存的总和。

把内存中的对象看成下图中的节点，并且对象和对象之间互相引用。这里有一个特殊的节点GC Roots，这就是reference chain的起点。  
![format_png][]

从obj1入手，上图中蓝色节点代表仅仅只有通过obj1才能直接或间接访问的对象。因为可以通过GC Roots访问，所以左图的obj3不是蓝色节点；而在右图却是蓝色，因为它已经被包含在retained集合内。所以对于左图，obj1的retained size是obj1、obj2、obj4的shallow size总和；右图的retained size是obj1、obj2、obj3、obj4的shallow size总和。obj2的retained size可以通过相同的方式计算。

### 对象引用（Reference） ###

对象引用按从最强到最弱有如下级别，不同的引用（可到达性）级别反映了对象的生命周期：

*  **强引用（Strong Ref）**：通常我们编写的代码都是强引用，于此相对应的是强可达性，只有去掉强可达性，对象才能被回收。
 *  **软引用（Soft Ref）**：对应软可达性，只要有足够的内存就一直保持对象，直到发现内存不足且没有强引用的时候才回收对象。
 *  **弱引用（Weak Ref）**：比软引用更弱，当发现不存在强引用的时候会立即回收此类型的对象，而不需要等到内存不足。通过java.lang.ref.WeakReference和java.util.WeakHashMap类实现。
 *  **虚引用（Phantom Ref）**：根本不会在内存中保持该类型的对象，只能使用虚引用本身，一般用于在进入finalize()方法后进行特殊的清理过程，通过java.lang.ref.PhantomReference实现。

### GC Roots和Reference Chain ###

JVM在进行GC的时候是通过使用可达性来判断对象是否存活，通过GC Roots（GC根节点）的对象作为起始点，从这些节点开始进行向下搜索，搜索所走过的路径成为Reference Chain（引用链），当一个对象到GC Roots没有任何引用链相连（用图论的话来说就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。

如下图所示，对象object 5、object 6、object 7虽然互相有关联，它们的引用并不为0，但是它们到GC Roots是不可达的，因此它们将会被判定为是可回收的对象。  
![format_png 1][]

## Histogram（直方图）视图 ##

点击工具栏上的 ![Histogram][] 图标可以打开Histogram（直方图）视图，可以列出每个类产生的实例数量，以及所占用的内存大小和百分比。主界面如下图所示：

![format_png 2][]

图中Shallow Heap 和 Retained Heap分别表示对象自身不包含引用的大小和对象自身并包含引用的大小，具体请参考下面 [Shallow Heap 和 Retained Heap][Shallow Heap _ Retained Heap] 部分的内容。默认的大小单位是 Bytes，可以在 Window - Preferences 菜单中设置单位，图中设置的是KB。

通过直方图视图可以很容易找到占用内存最多的几个类（通过Retained Heap排序），还可以通过其他方式进行分组（见下图）。  
![format_png 3][]

如果存在内存溢出，时间久了溢出类的实例数量或者内存占比会越来越多，排名也越来越靠前。可以点击工具类上的 ![format_png 4][] 图标进行对比，通过多次对比不同时间点下的直方图对比就很容易把溢出的类找出来。  
![format_png 5][]

还有一种对比直方图的方式，首先通过 Window 菜单打开 Navigation History 视图，选中直方图右键并选中 Add to Compare Basket项目，将直方图添加到 Compare Basket 中。  
![format_png 6][]  
然后在 Compare Basket 中点击右上角的 ![format_png 7][] 按钮，可以分别列出对比的所有结果，见下图：  
![format_png 8][]  
并且在上面的可以设置不同的对比方式。  
![format_png 9][]

## Dominator Tree视图 ##

点击工具栏上的 ![format_png 10][] 图标可以打开Dominator Tree（支配树）视图，在此视图中列出了每个对象（Object Instance）与其引用关系的树状结构，同时包含了占用内存的大小和百分比。

![format_png 11][]

通过Dominator Tree视图可以很容易的找出占用内存最多的几个对象（根据Retained Heap或Percentage排序），和Histogram类似，可以通过不同的方式进行分组显示：  
![format_png 12][]

## 定位溢出源 ##

Histogram视图和Dominator Tree视图的角度不同，前者是基于类的角度，后者是基于对象实例的角度，并且可以更方便的看出其引用关系。

首先，在两个视图中找出疑似溢出的对象或者类（可以通过Retained Heap排序，并且可以在Class Name中输入正则表达式的关键词只显示指定的类名），然后右键选择Path To GC Roots（Histogram中没有此项）或Merge Shortest Paths to GC Roots，然后选择 *exclude all phantom/weak/soft etc. reference*：  
![format_png 13][]  
GC Roots意为GC根节点，其含义见上面的 [GC Roots和Reference Chain][GC Roots_Reference Chain] 部分，后面的 *exclude all phantom/weak/soft etc. reference* 意思是排除[虚引用、弱引用和软引用][Link 1]，即只剩下[强引用][Link 1]，因为除了强引用之外，其他的引用都可以被JVM GC掉，如果一个对象始终无法被GC，就说明有强引用存在，从而导致在GC的过程中一直得不到回收，最终就内存溢出了。

通过结果就可以很方便的定位到具体的代码，然后分析是什么原因无法释放该对象，比如被缓存了或者没有使用单例模式等等。

下面是执行的结果：  
![format_png 14][]  
上图中保留了大量的VelocitySqlBulder的外部引用，后来查看了代码，原来每次调用的时候都实例化一个新的对象，由于VelocitySqlBulder类是无状态的工具类，因此修改为单例方式就可以解决这个问题。

## 后续观察 ##

根据上面分析的结果对问题进行处理之后，再对照之前的操作，看看对象是否还再持续增长，如果没有就说明这个地方的问题已经解决了。

最后再[用 jstat 持续跟踪][jstat]一段时间，看看[Old和Perm区的内存][Old_Perm]是否最终稳定在一个范围之内，如果长时间稳定在一个范围说明溢出问题得到了解决，否则还要继续进行分析和处理，一直到稳定为止。

参考资料：  
[Memory Analyzer Tool 使用手记][Memory Analyzer Tool]  
[使用Eclipse Memory Analyzer分析内存][Eclipse Memory Analyzer]  
[使用Memory Analyzer tool(MAT)分析内存泄漏（一）][Memory Analyzer tool_MAT]  
[Shallow and retained sizes][]  
[JVM内存回收理论与实现][JVM]  
[GC roots][]  
[一次使用Eclipse Memory Analyzer分析Tomcat内存溢出][Eclipse Memory Analyzer_Tomcat]

[format_png]: /images/20210527/2f6cf8b5501a4960981803415f97687e.png
[format_png 1]: /images/20210527/32fd36322b9e4ce5946bfeb752c140d5.png
[Histogram]: /images/20210527/c692cfdac6004b0a8e003afa715426d6.png
[format_png 2]: /images/20210527/22b1087b7a30438b824c7ed38eb190ad.png
[Shallow Heap _ Retained Heap]: https://www.javatang.com/archives/2017/11/08/11582145.html#Shallow_Heap_Retained_Heap
[format_png 3]: /images/20210527/1ed14a8a5d4046258ddea58d75eaa404.png
[format_png 4]: /images/20210527/a770eab7e53d4dbea988eb0f907e9f23.png
[format_png 5]: /images/20210527/6b0b9004717f47b8affa203c4870ce06.png
[format_png 6]: /images/20210527/75edebc693454a01bbb26639ee46a4c2.png
[format_png 7]: /images/20210527/32a35bc848c54356bf86f8c69f729bac.png
[format_png 8]: /images/20210527/07a6b01a4da84968acbf866d85ca800b.png
[format_png 9]: /images/20210527/ac198078fdde45efa12bd3c0e766bd94.png
[format_png 10]: /images/20210527/382629bb41024348adadc6a0fa9fbe84.png
[format_png 11]: /images/20210527/b01ddf51c12d4dbea347303bb0a6c192.png
[format_png 12]: /images/20210527/6f1ccc54187b4c3d8cdb6d6505615e35.png
[format_png 13]: /images/20210527/6f9f4f2971d34755a99b66566c543a22.png
[GC Roots_Reference Chain]: https://www.javatang.com/archives/2017/11/08/11582145.html#GC_RootsReference_Chain
[Link 1]: https://www.javatang.com/archives/2017/11/08/11582145.html#Reference
[format_png 14]: /images/20210527/4e4b1b325a9d47c2b6b069870163a699.png
[jstat]: http://www.javatang.com/archives/2017/10/20/12131956.html#jstat
[Old_Perm]: http://www.javatang.com/archives/2017/10/20/12131956.html#JVM
[Memory Analyzer Tool]: http://wensong.iteye.com/blog/1986449
[Eclipse Memory Analyzer]: http://blog.csdn.net/jackesy/article/details/47039865
[Memory Analyzer tool_MAT]: http://www.blogjava.net/rosen/archive/2010/05/21/321575.html
[Shallow and retained sizes]: https://www.yourkit.com/docs/java/help/sizes.jsp
[JVM]: http://www.infoq.com/cn/articles/jvm-memory-collection
[GC roots]: https://www.yourkit.com/docs/java/help/gc_roots.jsp
[Eclipse Memory Analyzer_Tomcat]: http://tivan.iteye.com/blog/1487855