java heap space 内存溢出_java内存溢出问题分析过程二

淡淡的烟草味﹌ 2023-01-01 10:49 278阅读 0赞

(给ImportNew加星标，提高Java技能)

> 来源：侠梦的开发日记/黄云权 (本文来自作者投稿)

###  ###

### **前言** ###

java程序的性能问题定位，一直都是开发者需要面对的一个“拦路虎”， 在前面的两篇文章中，已经介绍了Heap dump的概念和生成方式，以及Shallow heap和Retained heap以及GC ROOT的概念，本篇文章，我们继续来介绍一些新的概念和基于一个dump案例，详尽的介绍，在程序OOM后，改如何去定位具体原因。

### **再次提及dominator tree(支配树)** ###

如果你玩过竞技类游戏，肯定会很熟悉Dominating -主宰比赛这个单词。 ![6b1a76bc1fc719ae899c302b8e828b38.png][] 在Memory Analyzer工具中提供了对象图的支配树。将对象引用图转换为dominator tree可以让轻松地确定Retained heap最大内存块和对象之间保持活动的依赖关系，相当于主宰了整个JVM的感觉。 我们把java对象之间的引用关系看做一张有向图，如果所有指向Y的对象路径都要经过X，则我们说X支配Y。如果X是离对象Y最近的支配对象，则我们说对象X是Y的直接支配者( immediate dominator)。 再强化记忆一下，X对象要直接支配Y，必须满足这两点：

*  指向Y的对象路径都要经过X。
 *  X对象是离Y最近的支配对象。

![841a668756c4fc6e4305d251a30c6e21.png][] 左边是对象的引用图，右边是支配树。 C节点的子树就是所有被C支配的节点的集合，也称为C的Retained Set。 由图可以看出，C是E的直接支配节点，所以C的上级支配节点B也可以支配E。

### **dump分析初步** ###

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

![7080c0128ef93f73a4c99b138558b36b.png][]

从整体情况可以看出，1.6 gb的堆内存，有大对象占了1.1g。 怀疑是有内存泄漏，我们通过Leak Suspect Report报告查看 ![a97533b577a346d2f85e5a9dac2d53c6.png][] 内存泄漏分析报告显示有两项问题：

*  一是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个。

![d7d529700a7da16d6d560e860030681f.png][]

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

![41345ab40568076b5745672142778b0b.png][]

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

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

![267170978dde97c8f4daff8394424e7d.png][]

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

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

### **内存泄漏点二** ###

![5e06002a6c92dd0aa816be79c62f03b7.png][]

TP-Processor9 线程本身就是GC root，故只有一条数据。 以这个线程为GC ROOT来看看，它的支配树是什么样的？

![417fe74b3f11ba4655d635154389ecc3.png][]

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

![e05541c474884f5f68040309d6d567dd.png][]

以TP-Processor9 线程为gc root的支配树，按class分类，可以发现Am对象本身占用163m左右。 ![40215fe5bd04066b2a8b05e7e5392b11.png][] Detail明细的最后由于当前怀疑泄露点为TP-Processor9 线程对象，故展示了线程明细信息，调用栈信息。 小结：TP-Processor9 线程内部可能导致内存泄漏。

### **整合两个泄漏点结论** ###

从两个泄漏点，得出的结论，我们可以将问题定位到如下元素上：TP-Processor9 线程、170288个AA对象数组、AM、AH对象。 我们来看看AA对象数组的(Outgoing Reference)引用其他外部对象的情况

![5abb8cfdc80a7a7a9feeefb5e117c432.png][]

可以看到com.fr.report.core.A.A\[170288\]\[\] @ 0xcfdb62a0 这个对象引用外部对象的情况，一共是170289个 com.fr.report.core.A.A\[25\] 对象。 并且其Shallow Heap 和Retained Heap大小一样。170289 \* 120 = 20434680。约占20M内存。 所以这个对象应用的外部对象，不是根因。 接下来，再分析Incomming Reference(被其他外部对象引用的情况)。

![5d0a4cedecf60755939369807b20e710.png][]

可以看到com.fr.report.core.A.A\[170288\]\[\] @ 0xcfdb62a0 这个包含170288个元素的对象，主要被 com.fr.report.worksheet.PageRWorkSheet @ 0xcfd02188 对象持有。 出现了一系列的ReportPage和ClippedECPage对象。

![8e59348ccea43d137216efaf745df948.png][]

从依赖树和对象地址可以知道，ClippedECPage引用ReportPage对象。 所以只需要重点关注ClippedECPage对象。继续分析ClippedECPage对象的依赖树如下： 其他的 Shallow Heap占用都不高，唯独一个对象数组，占用较大，并且它的Retained Heap很大。 问题应该就出在ClippedECPage类上，进一步分析它存储的 com.fr.page.ReportPage。这个对象是：用于展示及打印的页面 执行完一个多Sheet的Report后, 会生成多个ReportPage。 分析它的属性：

![d3310c147f890f881be576471557d3ec.png][]

连续查看了两个对象，发现其中的属性，currentPageNumber为591和592。

![eef4a8891ee17c35c1079ef0e5e1d3e1.png][]

总页数为599. 可以推断出，是在做分页操作。

![6e6a33112b819fe1aeab54a73c2f2a03.png][] 可以看到当时浏览器的信息

![d683fbe206f5897b919782b022ef316d.png][]

操作的文件：xxx/customized/xxx表.xxx

### **结论** ###

结合ReportPage类的作用：用于展示及打印的页面 执行完一个多Sheet的Report后, 会生成多个ReportPage。 最后结论为： 在执行查询时间段为：2018/6/8 15:57:15 - 2018/6/8 16:0:53 一次性打印599页数据，导致OOM，程序宕机崩溃。 推荐阅读   点击标题可跳转

Java 14 新功能介绍！

这 35 个 Java 代码优化细节，你用了吗？

用好Java中的枚举，真的没有那么简单！

看完本文有收获？请转发分享给更多人

**关注「ImportNew」，提升Java技能**

![2c79389f34c9fcb8ce2b54ab551580ee.png][]

好文章，我在看❤️

[6b1a76bc1fc719ae899c302b8e828b38.png]: /images/20221120/61fe31d95e054e56b36cc6a141b86902.png
[841a668756c4fc6e4305d251a30c6e21.png]: /images/20221120/8fd5ceec3e5841f08340bb74adc9db11.png
[7080c0128ef93f73a4c99b138558b36b.png]: /images/20221120/741f219e99ef4ef999cb2f7ca9b72ae8.png
[a97533b577a346d2f85e5a9dac2d53c6.png]: /images/20221120/af199c7d52f049df8a1da04523e8a6c1.png
[d7d529700a7da16d6d560e860030681f.png]: /images/20221120/46da9f2ba9fe488da872c42d62a2e0ef.png
[41345ab40568076b5745672142778b0b.png]: /images/20221120/3d7f7407af7b4de4bb49eab4b809e42f.png
[267170978dde97c8f4daff8394424e7d.png]: /images/20221120/3dade20a66ae401fb2c9ac1cb2507af8.png
[5e06002a6c92dd0aa816be79c62f03b7.png]: /images/20221120/00652de0ddf848938c186a1bf40372ab.png
[417fe74b3f11ba4655d635154389ecc3.png]: /images/20221120/3726ddbacb3946c0adfef89ae19a42df.png
[e05541c474884f5f68040309d6d567dd.png]: /images/20221120/4851673ea0544d6d9bdee9b4b7b27a09.png
[40215fe5bd04066b2a8b05e7e5392b11.png]: /images/20221120/4bb91bca4ea74018bcf12b7a5538ce9e.png
[5abb8cfdc80a7a7a9feeefb5e117c432.png]: /images/20221120/1c8a4e4df871409ca82273d63f5ceb31.png
[5d0a4cedecf60755939369807b20e710.png]: /images/20221120/1dc346e4de224b578234d409480dde6a.png
[8e59348ccea43d137216efaf745df948.png]: /images/20221120/4f08f116d0f84c41831b1a40fac72f54.png
[d3310c147f890f881be576471557d3ec.png]: /images/20221120/0231819342db4c5ba1b8aa00abbd05aa.png
[eef4a8891ee17c35c1079ef0e5e1d3e1.png]: /images/20221120/9a2c367e50804905b857b29d367028fc.png
[6e6a33112b819fe1aeab54a73c2f2a03.png]: /images/20221120/211f89530c5f4fbb9f3f43e5b495a3f7.png
[d683fbe206f5897b919782b022ef316d.png]: /images/20221120/64ce96c8a3dd44a9907f6923fce9f7d3.png
[2c79389f34c9fcb8ce2b54ab551580ee.png]: /images/20221120/c6a032b534a743d192a7a9467bdbd5e4.png