一次MAT工具的使用过程

背景

前阵子放假回来组内其他同事发现线上出现了机器频繁重启问题,协助进行问题排查。主要表现为cpu资源占用80%以上,同时jvm gc次数频繁。经过初步排查出是excel文件导入导致的,但并未找到关键代码,遂导出堆文件进行本地分析。

MAT (Memory Analyzer tool) 内存分析工具

MAT 能够对堆内存文件进行较详细分析的工具,主流的格式都支持,目前试过hprof,bin格式。以下为个人使用步骤

1.内存文件转储

首先需要将线上堆内存文件拉下来,由于堆文件较大,可能会搞崩内部系统,所以尽量先压缩再拉到本地

转储堆内存文件命令

ini 复制代码
jmap -dump:format=b,file=存储目录/文件名称.hprof <pid>

例如之前是转储在/logs目录下的

jmap -dump:format=b,file=/logs/dump.hprof java进程号

生成后可以进行压缩,再拉到本地,能压缩5-10倍左右

复制代码
tar -zxvf 文件路径 

2.内存文件分析

内存分析工具自己平时用的是Eclipse MemoryAnalyzer

相关页面:

excel问题一开始是从线上dump了一次内存文件,但因为相应的对象已经给回收完毕了,所以内存文件看不到存在异常的地方。之后组内推断出是某个excel引起的,在线上使用该excel发现内存跟cpu的确会同步飙升。

遂尝试本地调用该文件,拿到回收前的内存情况,看能能否找出具体的问题代码。

缩略图

通过缩略图可以看到,未被回收的内存有3.1G,其中3G的内存都跟一个名字叫 asyncBatchExecutor 的线程池有关系,这个线程池的确跟导入有关系

Histogram

用于查看对象类的内存占用情况。

Thread对象实际占用了超过3G的内存空间,猜测是上面说到的asyncBatchExecutor线程池。

点击类对象,右键选择List objects -》 outgoing references 查看引用该类的对象

可以看到的确是 asyncBatchExecutor 这个线程池引用的一个线程对象

可以看到,一个与xml相关的类,占用了超过1G以上的内存空间

一个与dom相关的类,占用了超过1G的内存空间

所以判断:

asyncBatchExecutor线程池中的一个thread对象,执行excel导入任务时,会创建大量的xml,dom相关的类对象,从而导致服务频繁gc

Leak Suspects

能够对内存中存在的问题做一些检测及推断

定位出了一个问题,跟asyncBatchExecutor有关,看下detail详细内容

内存空间大部分被dom,xml这两个类的对象占用了

通过thread Stack 找出这两种类对象生成的源头代码。 为poi包,WorkbookFactory类的create方法

解决方案

百度了下poi WorkbookFactory.create 的确会出现大量对象创建的问题。推测该方法除了解析excel文字外,还会解析一些excel格式,跟xml,dom有关系,相关代码存在bug导致创建大量对象。临时解决方案,先临时将poi版本进行升级,先避免问题再次发生。目前已经已经将该excel导入接口替换为用easyExcel进行导入了。

MAT工具使用参考网址

相关推荐
咕白m6252 天前
Java 开发:用 Spire.PDF 高效压缩 PDF 文件
java·编程语言
藤椒鱼不爱编程2 天前
核心类库_常用类
java·编程语言
NekoCNN7 天前
流式处理-与迭代相对的现代编程范式
编程语言
莲动渔舟9 天前
第4.3节:awk正则表达式详解-特殊字符
正则表达式·编程语言·awk
你的人类朋友9 天前
【Node&Vue】JS是编译型语言还是解释型语言?
javascript·node.js·编程语言
Mirageef10 天前
aardio简单爬取网站图片链接和名称
编程语言
Moonbit10 天前
MoonBit Perals Vol.06: MoonBit 与 LLVM 共舞 (上):编译前端实现
后端·算法·编程语言
Moonbit10 天前
MoonBit Pearls Vol.05: 函数式里的依赖注入:Reader Monad
后端·rust·编程语言
ansurfen11 天前
Hulo 编程语言开发 —— 解释器
开源·编程语言
楽码13 天前
自动修复GoVet:语言实现对比
后端·算法·编程语言