java内存溢出问题分析过程

再强化记忆一下，X对象要直接支配Y，必须满足这两点：

• 指向Y的对象路径都要经过X。

• X对象是离Y最近的支配对象。

左边是对象的引用图，右边是支配树。

C节点的子树就是所有被C支配的节点的集合，也称为C的Retained Set。

由图可以看出，C是E的直接支配节点，所以C的上级支配节点B也可以支配E。

dump分析初步

---

首先用MemoryAnalyzer工具打开dump文件。

从整体情况可以看出，1.6 gb的堆内存，有大对象占了1.1g。

怀疑是有内存泄漏，我们通过Leak Suspect Report报告查看

内存泄漏分析报告显示有两项问题：

• 一是WebappClassLoader 类加载器装载的A.A[][] 对象占了约1.2g（70.40%）。

• 二是一个名为TP-Processor9的线程持有本地变量多达337M（占了19.58%）。

通过分析报告，我们初步可以推断出OOM的问题应该出在这两个地方，我们逐个击破。

内存泄漏点一

---

先来看类装载器加载的AA对象。我们点开内存泄漏报告的Detail，查看其详情。

Shortest Paths To the Accumulation Point视图可以看出正是和org.apache.catalina.loader.WebappClassLoader这个GC root相连导致当前Retained Heap占用相当大的对象无法被回收，而对象数量居然达到了170288个。

Accumulated Objects in Dominator Tree视图，可以看出AA对象中，到底是什么内嵌对象占用heap高。

可以看出，170288个AA对象数组内部，主要是AH对象 和 AM对象。

我们继续向下看，通过按class类分组，来看看具体占用比例情况。

按class分组后，冒出了一个Af对象，反倒AH占用不是那么多了。

小结：AH/AM/Af三个对象占用堆内存很高，并且它们的gc root是WebappClassLoader。

内存泄漏点二

---

TP-Processor9 线程本身就是GC root，故只有一条数据。

以这个线程为GC ROOT来看看，它的支配树是什么样的？

可以看到19.58%的Retained Heap就是来源于TP-Processor9 线程本身。这意味着，如果这个线程能被gc回收掉，则至少能释放19.58%的堆内存。

以TP-Processor9 线程为gc root的支配树，按class分类，可以发现Am对象本身占用163m左右。

Detail明细的最后由于当前怀疑泄露点为TP-Processor9 线程对象，故展示了线程明细信息，调用栈信息。

小结：TP-Processor9 线程内部可能导致内存泄漏。

整合两个泄漏点结论

---

从两个泄漏点，得出的结论，我们可以将问题定位到如下元素上：TP-Processor9 线程、170288个AA对象数组、AM、AH对象。

我们来看看AA对象数组的（Outgoing Reference）引用其他外部对象的情况

可以看到com.fr.report.core.A.A[170288][] @ 0xcfdb62a0 这个对象引用外部对象的情况，一共是170289个 com.fr.report.core.A.A[25] 对象。

并且其Shallow Heap 和Retained Heap大小一样。170289 * 120 = 20434680。约占20M内存。

最后

各位读者，由于本篇幅度过长，为了避免影响阅读体验，下面我就大概概括了整理了

度过长，为了避免影响阅读体验，下面我就大概概括了整理了

[外链图片转存中…(img-THbduZy0-1714343165896)]

[外链图片转存中…(img-r7mHwStG-1714343165897)]

[外链图片转存中…(img-67oCd1QJ-1714343165897)]

[外链图片转存中…(img-Hau8bZV0-1714343165897)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录