最后
终极手撕架构师的学习笔记:分布式+微服务+开源框架+性能优化
从整体情况可以看出,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内存。
所以这个对象应用的外部对象,不是根因。
接下来,再分析Incomming Reference(被其他外部对象引用的情况)。
可以看到com.fr.report.core.A.A[170288][] @ 0xcfdb62a0
这个包含170288个元素的对象,主要被 com.fr.report.worksheet.PageRWorkSheet @ 0xcfd02188 对象持有。
出现了一系列的ReportPage和ClippedECPage对象。
从依赖树和对象地址可以知道,ClippedECPage引用ReportPage对象。
所以只需要重点关注ClippedECPage对象。继续分析ClippedECPage对象的依赖树如下:
其他的 Shallow Heap占用都不高,唯独一个对象数组,占用较大,并且它的Retained Heap很大。
问题应该就出在ClippedECPage类上,进一步分析它存储的 com.fr.page.ReportPage。这个对象是:用于展示及打印的页面 执行完一个多Sheet的Report后, 会生成多个ReportPage。分析它的属性:
总结
在这里,由于面试中MySQL问的比较多,因此也就在此以MySQL为例为大家总结分享。但是你要学习的往往不止这一点,还有一些主流框架的使用,Spring源码的学习,Mybatis源码的学习等等都是需要掌握的,我也把这些知识点都整理起来了
外链图片转存中…(img-XXc1gA48-1714842655045)]