Eclipse MAT堆转储分析：从OOM定位到内存泄漏排查

简介Eclipse MAT堆内存分析工具包面向Java开发者、测试与运维人员用于排查应用内存泄漏、优化对象占用并梳理JVM引用关系。压缩包共5442个文件约133.56MB内容以html帮助文档、png图片、jar插件及class组件为主辅以xml、properties配置和少量日志、hprof示例较完整地保留了独立运行环境和插件目录结构。已有371人学习下载适合不同经验层次的读者按主题查阅文档并对照各分析视图以提升内存问题定位效率。资料围绕泄漏嫌疑报告、支配树、直方图、重复对象检测和引用链分析展开可帮助读者从堆转储中定位高占用对象、追踪引用关系、识别重复对象并比较多次内存快照同时了解批处理启动、命令行与配置文件在内存诊断中的配合方式为实际排错和性能优化提供可复用思路。1. 先纠正一个搜索误会MAT 打开的不是日志是堆快照搜eclipse mat 日志分析工具的人多半是被「日志」两个字带偏的。Eclipse MAT 全称 Memory Analyzer它不读应用输出的文本日志喂给它的是 JVM 的堆转储文件.hprof即一份把某个瞬间所有对象、字段、引用关系全量记录下来的快照。文本日志能告诉你「几点几分抛了 OutOfMemoryError」但答不了「到底是哪个对象、被谁一直持有、为什么回收不掉」MAT 处理的是后半段问题。它把几百 MB 到几十 GB 的二进制快照解析成对象图算出每个对象的 Shallow Heap 与 Retained Heap再借助 Dominator Tree、Leak Suspects、OQL 把「谁占了内存」量化到具体类和具体字段。适用人群很明确Java 后端、安卓客户端以及任何需要给 OOM 和内存泄漏收尾的人。工具本身是免费独立包但要跑得动、读得准几处启动参数和打开顺序有讲究。2. 把工具跑起来三种启动形态与一份可信 dump 的采集参数装完双击图标点不开、或者打开了却提示「文件格式不支持」九成不是软件坏了而是形态选错或者 dump 采错。这一章先把「用哪个包」和「怎么采一份能分析的 dump」这两件事定下来后面所有分析动作都建立在这份快照上。2.1 独立包、IDE 插件、命令行三种形态怎么选MAT 有三种常见分发形态选错了会在很蠢的地方卡住半天。形态典型场景优点限制独立包Standalone生产问题排查、离线分析解压即用不依赖已有 IDE启动参数独立可调需要自己配MemoryAnalyzer.ini里的堆大小插件包dropins日常开发边写边看和 IDE 同一套工作区跳转方便受 IDE 自身堆大小限制大 dump 容易拖垮 IDE命令行ParseHeapDump批处理、发布前自检无人值守可出 HTML 报告归档不能交互下钻只能出预设报告我的习惯是现场排查一律用独立包因为它的内存参数只归它自己管流水线里用命令行插件形态只在看几 MB 的小 dump 时用。独立包解压后目录里有个MemoryAnalyzer.ini决定它能不能解析得动大文件的关键就在这几行# 只改这两处指定 JDK以及给解析器足够的堆 -vm /opt/jdk-17/bin/java -vmargs -Xmx8g-vm指向一个真实存在的 JDK不是 JRE 目录里随便挑一个版本太旧的 MAT 打开高版本 JDK 产出的 dump 会报 class file version 相关的错换成新一点的独立包即可。-Xmx是解析器的堆经验值是 dump 文件大小的 1 到 1.5 倍同时不超过物理内存的 70%给 8G 的机器开-Xmx12g只会换来一句「Could not reserve enough space」。另外解析时会在 dump 同目录下生成.index之类的索引文件磁盘预留 dump 体积两倍的空间比较稳妥。2.2 采一份「干净」的堆转储dump 采错后面分析全废。先确认问题真的是内存再动手采集# 1) 先看类直方图确认是哪个类在涨也能判断值不值得采 dump PID$(jps -l | awk /your-app\.jar/ {print $1}) jcmd $PID GC.class_histogram | head -n 30 # 2) 推荐方式jcmd 生成堆转储默认会先做一次 GC 只导存活对象 jcmd $PID GC.heap_dump /data/dump/app-$(date %Y%m%d-%H%M).hprof # 3) 怀疑对象卡在 finalizer / cleaner 队列里没释放时把不可达对象也带上 jcmd $PID GC.heap_dump -all /data/dump/app-all.hprof # 4) jmap 的对照写法带 live 会触发 Full GC不带 live 会把垃圾对象也拍进去 jmap -dump:formatb,file/data/dump/app-live.hprof $PID jmap -dump:live,formatb,file/data/dump/app-gc.hprof $PID第 1 步的GC.class_histogram是先做体温测量如果实例数排名靠前的都是byte[]、char[]、HashMap$Node这类容器类说明问题在数据层如果某个业务类实例数异常高那就直接锁定它连 dump 都不用采。第 2 步的GC.heap_dump是首选它由 JVM 自己写文件不需要外部 attach 太多东西。第 3 步的-all是关键细节默认只导存活对象如果你怀疑「对象明明该被回收却没回收」恰恰要把不可达对象一起拍下来否则打开 MAT 一看干干净净还以为没有泄漏。第 4 步的live参数最容易翻车它会先触发一次 Full GC软引用、弱引用指向的对象会被清掉原本能暴露的问题现场就这么被清理掉了。线上更常见的做法是让 JVM 自己在崩溃点留证据靠这几个启动参数java -jar your-app.jar \ -Xms4g -Xmx4g \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/dump \ -XX:ExitOnOutOfMemoryErrorHeapDumpOnOutOfMemoryError让 JVM 在抛 OOM 的瞬间写 dump这是唯一能拿到「案发第一现场」的机会HeapDumpPath指向一个目录时文件名自动生成指向文件路径时固定覆盖同名文件生产上建议给目录加时间戳习惯。ExitOnOutOfMemoryError是配套的OOM 之后进程状态已经不可信继续活着只会产生更多脏数据不如立刻退出让编排层拉起新实例。容器环境还要多一步HeapDumpPath必须落在挂载卷上写在容器临时层里进程一退文件就没了。同时给 JVM 留 20% 到 30% 的内存余量用-XX:MaxRAMPercentage控制否则容器先被 OOMKilledJVM 根本没机会写文件。2.3 打开向导里的三个选择第一次打开 dump 会弹一个向导不同版本措辞略有差异但选择项基本一致。第一项是报告类型Leak Suspects Report会顺带跑一遍启发式分析并出结论Histogram和Dominator Tree是纯手工入口。我一般先选 Leak Suspects让它跑完给出一个初始方向再回到 Dominator Tree 自己验证。第二项是Keep unreachable objects。这个勾选框默认不勾表示解析时丢掉不可达对象以省内存。如果你的 dump 是-all采的且目的就是查「该回收没回收」这里必须勾上否则等于白采。它只在解析阶段生效改完要重新打开 dump。第三项是工作区位置。MAT 基于 Eclipse 框架默认工作区被一个进程占用后再开第二个实例会报 workspace 被锁。命令行里加-data /tmp/mat-ws-$(date %s)指定一个临时工作区能省掉删.metadata/.lock的麻烦。3. 读懂占比Shallow、Retained 与 Dominator Tree 的三层下钻工具跑通之后真正的门槛是读数。同一份 dump有人五分钟定位到那个 800MB 的 Map有人翻一小时还在看java.lang.String占了 30%。差别不在工具在于有没有把 Shallow Heap、Retained Heap、支配关系这三层关系理清。3.1 Shallow Heap 与 Retained Heap 差在哪里Shallow Heap 是对象自身占的字节数对象头加字段数组就是对象头加元素个数乘以元素大小。Retained Heap 是把这个对象干掉之后能释放的总量等于它支配的所有对象的 Shallow 之和。这两个数字在容器类上差距极大下面这张表是我给人解释时最常用的例子对象Shallow HeapRetained Heap说明HashMap$Node[]数组本体4MB4MB数组只存引用元素对象不在里面单个HashMap$Node约 32B可能 12MB它是链表/红黑树节点的入口挂着一长串业务对象byte[]/char[]2MB2MB叶子对象两者相等看懂这张表就明白为什么按 Shallow Heap 排序永远找不到泄漏泄漏的源头往往是一个只有几十字节的小对象它本身不占地方但它通过引用攥着几十万个业务对象。反过来byte[]的 Shallow 和 Retained 相等所以看到它排第一只能说明内存在字节数组里不能说明是谁写进来的。判断一个对象是不是「泄漏点」标准是它的 Retained Heap 大并且它到 GC Root 的路径上有一根长生命周期的引用静态字段、线程池的线程、单例、缓存容器。3.2 Dominator Tree 的正确打开方式Dominator Tree 的规则很朴素从 GC Root 出发到某个对象的所有路径都必须经过 X那么 X 支配该对象X 的 Retained Heap 就包含该对象。实操按这个顺序走第一步打开 dump 后进 Dominator Tree 视图默认按 Retained Heap 降序排。不要急着展开先看前 20 行。第二步用工具栏的Group by把同一层的对象按 Class、Class Loader 或 Package 聚合。这一步很关键不聚合时你会看到大量同名的框架类节点聚合后才能看出「哪个包整体在膨胀」。做类加载器泄漏排查时Group by Class Loader几乎是唯一好用的入口一眼能看出被卸载失败的加载器下面挂着多少东西。第三步从根往下逐层展开找那个 Retained Heap 突然降到原来的 1% 以下的层级。下降的那个层级上面一个节点基本就是问题的边界。常见形态是某个ConcurrentHashMap的 Retained 是 1.2G展开后下面全是com.your.pkg.CacheEntry。第四步选中可疑节点右键Path to GC Roots勾上exclude weak/soft/phantom references。排除弱引用和软引用非常重要框架里的缓存、监听器注册表大量使用弱引用这些引用不阻止 GC留着只会把引用链拉得又长又误导人。第五步用Show Retained Set看这块内存里到底有哪些对象再用with outgoing references确认这些对象是不是还能从别的地方访问到——如果业务代码里已经没有任何路径能访问它那它就该被回收此时问题在别处比如被 ThreadLocal 或静态集合攥着。新手最容易犯的错是直接从根节点一层层点下去靠眼睛找大数字。几百 MB 的 dump 里节点成千上万眼睛找不过来正确姿势永远是先聚合再排序。3.3 Leak Suspects 报告怎么读才不被误导Leak Suspects 是一组启发式的集合它主要看几件事谁的支配子树占用最大、被系统类加载器加载的类占了多少、有没有对象卡在 finalizer 队列里。报告开头那个Problem Suspect 1经常指向java.lang.Class或者某个框架类这时候不用急着下结论。报告区块它给出的信息我一般下一步做什么Problem Suspect 1一棵 Retained 最大的支配子树含类名和占堆比例先确认它是不是框架自带的缓存或连接池Accumulated Objects in Dominator Tree该子树里按类聚合的对象分布找业务包名前缀锁定具体类References to the suspect从 GC Root 到该对象的引用路径判断这条链是长生命周期还是泄漏See stacktrace对象分配点一般没有因为默认 dump 不带分配栈See stacktrace这一项经常是灰色的因为 JVM 默认不记录对象分配栈除非专门开启。看到它是空的不用纠结把引用链读明白已经足够定性。更重要的判断标准不是「占得多」而是「会不会随流量线性增长」。一个 500MB 的本地缓存如果是固定容量、有淘汰策略那是设计如此一个 50MB 的 Map 每小时涨 5MB 且 GC 之后不回落那才是泄漏。所以单份 dump 只能给出嫌疑两份 dump 对比才能定性。4. 落到证据OQL 查询与两份 dump 的差值定位到了要写排查结论、或者要让别人相信「问题就在这里」的时候光靠截图指认不够得有可复现的查询和可对比的数据。OQL 和 dump 对比就是干这个的。4.1 OQL 的语法边界与四条能直接抄的查询OQL 是 MAT 内置的类 SQL 查询语言语法看着像 SQL能力边界窄很多不支持 JOIN不支持子查询里的复杂递归方法调用受限能用的主要是属性访问、INSTANCEOF、length这类内置属性。但它足够把「按条件筛对象」这件事做掉。-- 1) 找超长字符串JDK8 的 char[] 与 JDK9 的 byte[] 都能用 length 兼容 SELECT s FROM java.lang.String s WHERE s.value.length 1000 -- 2) 按保留堆筛出占内存较大的 Map 节点注意这个属性计算很慢 SELECT n FROM java.util.HashMap$Node n WHERE n.retainedHeapSize 1048576 -- 3) 统计某个业务类的实例数用来验证「实例数是否随请求增长」 SELECT COUNT(*) FROM INSTANCEOF your.pkg.OrderCache -- 4) 查线程本地变量里的 EntryThreadLocal 泄漏的常用入口 SELECT e FROM java.lang.ThreadLocal$ThreadLocalMap$Entry e WHERE e.value ! null第 1 条用length而不是s.value.length是因为length是 MAT 对数组的内置属性访问能同时兼容 JDK8 的char[]和 JDK9 之后的byte[]两种实现换 JDK 不用改查询。第 2 条的retainedHeapSize需要遍历引用图在几个 G 的 dump 上一条查询跑几分钟很正常务必先用INSTANCEOF或具体类名把范围缩小不要全堆扫。第 3 条的COUNT(*)是最实用的验证手段同一个接口压测前后各查一次数字有没有线性上涨一目了然。第 4 条查的是ThreadLocalMap的 Entry注意它的 key 是弱引用、value 是强引用线程池里的线程不销毁value 就一直挂着这是最常见的「看起来没人引用却回收不掉」的场景。OQL 结果面板里可以直接右键某个对象跳到 Dominator Tree 或 Path to GC Roots这比在树里手工找快得多。我一般在 OQL 里把候选对象筛出来再跳回去看引用链两个视图配合着用。4.2 两份 dump 做差把「疑似」变成「证实」采集两份 dump 有三个前提中间不重启进程重启会清空所有内存状态差值就没意义了、两次都尽量在 Full GC 之后采、两次之间的流量模型要一致。满足之后按下面走第一步打开第一份 dump进 Histogram 视图。第二步右键任意一行选Compare to another Heap Dump选中第二份 dump 文件。MAT 会在后台解析第二份文件大文件等几分钟。第三步结果表格里会出现两列对象的增量。按Objects #的差值列降序排先看哪些类的实例数增长最多再按 Shallow Heap 差值排一遍看内存增长落在哪个类上。第四步找到增量最大的业务类回到第二份 dump 的 Dominator Tree 里定位它的 Retained Heap确认这个数字也在涨。实例数涨但 Retained 不涨通常只是对象变小了或者被别的对象吸收了不是泄漏。第五步把这个类名和增长速率记进排查结论。这一步的价值在于它能证明「每小时涨 5MB」这个事实而不是「我觉得是它」。有个细节要注意两份 dump 的 GC 时点不同同一个类的实例数会有正常波动。差值在几百、几千量级时不要下结论看那些增长了几十万的类。4.3 Path to GC Roots 的排除项与引用链解读引用链读错是另一种常见翻车。默认配置下你会看到一条从java.lang.ref.Reference$ReferenceHandler或者某个线程池线程出发的长链中间穿过七八层框架类。这时候第一件事是排除弱引用、软引用、虚引用重新算一遍路径。排除之后如果路径变短甚至消失说明之前的「引用」是框架的缓存机制不阻止回收问题不在那里。排除之后路径还在就要看这条链的「根」是什么类型根是static字段静态集合没清理或者单例里存了请求级数据。根是线程java.lang.Thread线程池里的线程生命周期和容器一样长挂在它上面的 ThreadLocal、上下文对象都会一直存活。根是 JNI 引用或类加载器类加载器泄漏通常发生在热部署、动态代理、脚本引擎场景。这条链上第一个出现的业务包名类就是你要改的代码位置。5. 避坑与排查采集和分析阶段最容易翻车的五处下面五条都是我在真实排查里踩过的或者见别人踩过的按「现象 → 原因 → 解决」写遇到对应症状可以直接对号入座。5.1 dump 采集阶段坑一dump 打开后内存异常干净怀疑根本没有泄漏。现象线上明明每小时涨 200MB采了 dump 打开一看最大对象只有几十 MBHistogram 里也没有明显异常。原因用了jmap -dump:live或者默认的jcmd GC.heap_dump两者都会先触发一次 Full GC软引用、弱引用指向的对象被清掉部分本该暴露的泄漏现场被清理掉了。解决换成jcmd pid GC.heap_dump -all把不可达对象也带上并勾选打开向导里的Keep unreachable objects同时在 GC 日志里确认采集时刻和 Full GC 的时间关系尽量取两次 Full GC 之间的峰值时刻。坑二容器里 OOM 了但 dump 文件找不到。现象日志里明明打印了java.lang.OutOfMemoryError和Heap dump file created去挂载目录里什么都没有。原因HeapDumpPath写的是容器内路径但没有挂卷或者写的是一个不存在的子目录JVM 不会自动创建多级目录再或者容器内存限制太紧JVM 还没写完就被 OOMKilled 直接杀掉。解决HeapDumpPath指向已挂载的卷并且目录提前创建好JVM 堆上限留出 20% 到 30% 余量给堆外和 dump 过程配ExitOnOutOfMemoryError让进程主动退出而不是被杀能给写文件多争取时间。5.2 解析与阅读阶段坑三解析到 80% 卡住或者直接报 OutOfMemoryError。现象进度条走到一多半不动了控制台抛Java heap space或者界面直接白掉。原因MemoryAnalyzer.ini里的-Xmx还是默认的偏小值解析几个 G 的 dump 时索引和对象图撑爆了 MAT 自己的堆。解决把-Xmx调到 dump 文件大小的 1 到 1.5 倍确认机器物理内存够同时检查 dump 同目录所在磁盘剩余空间索引文件通常要占 dump 体积的一半到一倍。空间不够时先把 dump 挪到大盘上再解析。坑四按 Shallow Heap 排序翻了半小时找不到泄漏点。现象Histogram 里排前面的全是byte[]、char[]、String一个个点进去看不出谁在持有它们。原因泄漏源头往往是只有几十字节的容器节点或业务对象它的 Shallow Heap 很小Retained Heap 却很大按 Shallow 排序永远排在后面。解决切到 Dominator Tree按 Retained Heap 排序用Group by Package聚合后再看或者直接在 Histogram 里右键某个类选Show Retained Set反查它被谁攥着。坑五照着 Leak Suspects 的结论改了代码上线后发现内存还是涨。现象报告说Problem Suspect 1是某个 Map改成有界缓存、加了淘汰策略压测两小时内存曲线照旧。原因Leak Suspects 只回答「谁占得最多」不回答「谁在增长」。占得最多的大概率是常驻缓存那是设计如此真正的泄漏可能排在第三、第四位占比不大但每小时涨一点。解决单份 dump 只用来找嫌疑定性必须靠两份 dump 做差。固定间隔采两份用 Histogram 的对比功能看增量增量最大的那个类才是要动的。这个顺序反了改十次也改不对。6. 收进流水线用 ParseHeapDump 做发布前的内存自检手工点界面适合救火但真正省时间的是把 MAT 变成流水线里的一个检查步骤。MAT 安装目录下有个ParseHeapDump.shWindows 是.bat能不开界面直接出报告#!/usr/bin/env bash # 用法ParseHeapDump.sh dump 文件 [-vmargs 参数] 报告 id... MAT_HOME/opt/mat DUMP/data/dump/app.hprof $MAT_HOME/ParseHeapDump.sh $DUMP \ -vmargs -Xmx8g \ org.eclipse.mat.api:suspects \ org.eclipse.mat.api:overview \ org.eclipse.mat.api:top_components三个报告 id 分别对应泄漏嫌疑、全局概览和 Top 组件按类的 Retained Heap 排名。跑完之后dump 同目录下会多出几个.zip解压是静态 HTML可以直接归档到工单里。-vmargs -Xmx8g的位置不能写到报告 id 后面参数顺序错了会被当成报告名忽略掉而且不报错只是报告不出来。加-consolelog可以把解析日志打到标准输出出问题时能看到卡在哪一步。落到实际用法上我一般这么用预发环境压测跑满 30 分钟后采一份 dump流水线里只跑top_components然后把生成的 HTML 里「按 Retained Heap 排名的前 20 个类」抽出来和上一次基线做人工比对。数量级没变就放行某个业务类的 Retained 涨了三倍以上就拦住。这套做法比接复杂的 APM 便宜得多也比等到线上一片 OOM 报警才动手要从容得多。有两个前提必须守住采 dump 之前先做一次 Full GC不然垃圾对象会把 Top 排名搅乱两次比对的流量模型要接近压测的 QPS 差一倍数字本来就没有可比性。说到这里讲个我自己的教训。早几年我图省事直接拿线上 OOM 时自动生成的那份 dump 当基线跟压测环境的 dump 对比得出「内存增长 40 倍」的结论兴师动众改了两周代码最后一查是压测时长不够、缓存还没热起来。从那以后我每次做 dump 对比都强制走一遍「两次采集都在 Full GC 之后 流量模型对齐 至少两份间隔采样」这三个前置检查宁可多等二十分钟也不拿错基线去改代码。希望帮到你。本文还有配套的精品资源点击获取