MAT 分析 hprof 堆转储：OOM 与内存泄漏排查实战

简介MemoryAnalyzerMAT1.6.1 的 Windows 发行包兼容 32 位与 64 位环境面向需要排查 Java 内存问题的开发者与性能调优人员。它以堆转储文件为输入通过支配树、直方图、泄漏嫌疑报告与引用链追踪等视图定位内存泄漏和高占用对象适合具备一定 JVM 基础的中级读者上手。压缩包共 463 个文件、约 57.99MB以 174 个 jar 插件、31 个 xml 与 26 个 properties 配置、44 个 html 与 25 个 css 帮助页面为主另有图标资源和 exe、dll、bat 启动组件构成完整的 Eclipse RCP 插件体系解压即可离线运行。已有 303 人学习下载。读者可借助内置帮助文档与批处理脚本完成堆转储解析与报告导出结合说明文件熟悉界面布局与分析路径形成从快照采集、对象统计到泄漏根因定位的排查思路。1. 从一次堆溢出说起60 多 MB 的 zip 里装的是事后复盘工具线上服务在凌晨两点抛了OutOfMemoryError重启后一切正常日志里只留下一行堆栈——这种场景我遇到过不止一次。重启能救命但它把现场一并抹掉了真正能回答“谁把内存吃光的”只有那份堆转储。Memory Analyzer 就是拆这份现场的工具输入一个 hprof 文件输出支配树、泄漏嫌疑、对象引用链。这次要拆的是MemoryAnalyzer-1.6.1.20161125-win32.win32.x86_64.zip2016 年 11 月下旬构建的 Windows 64 位版本解压即用、不写注册表、不依赖安装器。适合两类人一是手上已经有 dump 但只会用jmap和jstat看个热闹的后端二是想把这套分析固化成流程、交给别人也能复现的团队里那个“背锅位”。它的价值不在界面好看而在于把几百 MB 的二进制现场压缩成几条可验证的结论。2. 拆包前先对齐概念hprof、索引与 1.6.1 的时间坐标很多人拿到这个包第一反应是双击 exe然后对着空界面发呆——因为 MAT 不是监控工具它不连进程只吃文件。所以在动手解压之前得先弄清楚三件事输入是什么格式、打开为什么慢、这个 2016 年的版本在今天还能覆盖哪些 JVM。这三件事想不清楚后面所有的视图都只是看图说话。2.1 堆转储不是日志hprof 里到底存了什么hprof 是一份对象图的快照不是文本日志。它记录的是某一时刻堆里所有对象的类、字段值、数组内容以及对象之间的引用关系再加上 GC Roots 的标记。MAT 读它本质是在重建一张有向图然后在这张图上做可达性计算。这解释了一个常见误解很多人以为 dump 越大信息越全其实关键看的是“有没有在 OOM 之后立刻抓”——延迟几分钟再抓短命对象早被回收现场就失真了。抓取方式决定了文件质量。生产上我一般用两种# 方式一进程还在主动抓一份live 会先触发一次 Full GC只留存活对象 jmap -dump:live,formatb,file/data/dump/heap-$(date %s).hprof 12345 # 方式二进程已经挂了靠启动参数兜底 # 在 JVM 启动参数里加 # -XX:HeapDumpOnOutOfMemoryError # -XX:HeapDumpPath/data/dump/第一行里的live是个双刃剑它能过滤掉垃圾对象、显著缩小文件但会强制一次 Full GC对正在服务的进程是实打实的停顿。第二行的两个参数是“后悔药”平时不占成本出事时自动落盘我建议所有长期运行的服务都加上尤其是那些复现困难的偶发 OOM。需要注意格式差异标准 JVM 产出的是二进制 hprof手机端抓到的通常是 dalvik 格式字段布局不同直接丢进 MAT 会解析失败或信息缺失得先转成标准 hprof 再分析。另外非标准 JVM 的 dump 需要额外插件支持离线压缩包里默认没有别指望开箱即用。2.2 为什么打开一个 2 GB 的 dump 要等几分钟第一次打开 dump 时MAT 会在同一目录下生成一个.index目录把对象偏移、类索引、引用关系预计算好写进磁盘。这个过程是单线程为主的2 GB 的文件跑三五分钟很正常。之后再次打开同一份 dump只要索引目录还在通常是秒开。索引的代价是磁盘占用我一般按 dump 体积的三分之一到一半去预留空间。这也是为什么分析机不能只给一点点盘——一份 4 GB 的 dump 配一个 2 GB 的索引再加上导出报告很容易把临时目录撑爆。索引本质上是空间换时间它让“点一下某个类立刻列出所有实例”这种交互成为可能否则每次都要重新扫一遍几百 MB 的二进制。索引和 dump 是绑定的。你把 dump 拷到另一台机器而没带索引目录那边就得从头再解析一遍反过来如果 dump 被覆盖或截断索引不会自动失效打开时会报错或者干脆卡住。我的习惯是dump 文件名带上时间戳和实例标识索引跟着同目录一起归档绝不复用文件名。还有一点常被忽略MAT 解析时会用内存映射的方式读 dump它并不把整个文件加载进堆但重建中间结构仍然吃内存。默认配置下打开几个 G 的 dump 极容易在解析阶段就 OOM这个坑留到第 5 章细说。2.3 1.6.1 这个版本的 JDK 边界与格式兼容面文件名里的1.6.1.20161125拆开看1.6.1 是版本号20161125 是构建日期。这个版本线要求 Java 8 运行环境用 Java 7 或更早的 JRE 起不来用太新的 JRE 也可能因为模块化改动导致启动失败。所以“能不能用”这件事第一道门槛不是 dump 格式而是你机器上有没有一个合适的 8 版本 JRE。兼容面上它能读标准 hprof、能读部分 PHD 格式、能读核心转储需要对应插件但读不了比它更新的 JVM 引入的新特性所产生的一些元数据。反过来说一个 2016 年的工具去分析 2024 年的 JVM dump大多数情况下是能跑的因为 hprof 的二进制格式这些年变化不大真正失配的地方在于新版本 JVM 的一些内部结构名字变了某些高级视图会显示不全但基础的支配树、直方图、引用链这三板斧仍然有效。所以正确的预期是它是一个稳定的“老工具”适合做结构性的内存分析不要指望它理解最新的 GC 实现细节。它也不需要联网、不需要激活、不写系统目录解压到任意路径就能跑这一点对隔离环境里的排障特别友好。3. Windows 上把它跑起来解压、-vm 绑定与命令行报表概念对齐之后剩下的就是让它在机器上稳定启动。这一章的做法都是可以照抄的解压到哪、ini 改哪几行、命令行怎么出报告、输入文件怎么准备。每一步我都会说明为什么这么做以及改错参数时会看到什么现象。3.1 目录结构与启动入口的选择解压之后根目录下会看到MemoryAnalyzer.exe、MemoryAnalyzer.ini、ParseHeapDump.bat、plugins/、features/这几样。MemoryAnalyzer.exe是带界面的启动器.ini是它的配置文件ParseHeapDump.bat是命令行入口plugins里放的是具体功能模块。整个目录可以随便挪没有硬编码路径。这里有一点必须说清楚文件名里的win32.win32.x86_64是 RCP 平台的构建标签三段分别是“操作系统.窗口系统.架构”。x86_64意味着这个包只能跑在 64 位 Windows 上配套的本地库也是 64 位的。把它放到 32 位系统上或者在同目录混入 32 位的插件启动时会报“无法加载 SWT 库”之类的错误。我一般的做法是把它解压到一个短路径下比如D:\tools\mat\避开中文和空格。倒不是它一定不支持而是长路径加空格的组合在批处理调用、日志输出、报告导出这几个环节都会制造麻烦属于典型的“不致命但烦人”。启动前先确认 JRE# 看一眼系统里能用的是哪个 where java java -version # 如果系统默认是 17 或 21建议单独准备一个 8不要改全局 JAVA_HOME # 然后用 ini 里的 -vm 指向它见下一节这里不要偷懒直接改系统环境变量。分析机上很可能还跑着别的工具全局换 JDK 会把别的东西一起带崩。用-vm做局部绑定干净且可回滚。3.2 MemoryAnalyzer.ini 里改哪几个参数打开MemoryAnalyzer.ini会看到类似下面这段内容重点是两处JVM 路径和堆上限。-startup plugins/org.eclipse.equinox.launcher_1.3.201.v20161025-1711.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.500.v20160811-0900 -vm C:/Java/jdk8/bin/javaw.exe -vmargs -Xmx4096m -XX:-UseGCOverheadLimit逐行说。-vm必须单独占一行值写在下一行且路径里的反斜杠要写成正斜杠或者用双反斜杠转义。这是启动器解析参数的老规矩写错了不会报“找不到 JVM”而是静默回退到系统默认 JDK然后因为版本不对而崩溃非常迷惑。-Xmx4096m是给 MAT 自身进程的堆上限默认值通常只有 1024m分析 500 MB 以上的 dump 就吃紧。经验公式是dump 体积的 1 到 1.5 倍且不要超过物理内存的 60%。给 8 GB 内存的机器开 6 GB 堆系统会开始换页解析速度反而暴跌。-XX:-UseGCOverheadLimit这一行是关掉 GC 时间占比检查。MAT 在解析阶段会产生大量短命对象GC 极其频繁默认的并行回收器可能因为“GC 时间超过 98%”直接抛 OOM 终止进程。关掉这个保护不代表内存够用只是让它在真的耗尽之前别自己先投降。改完 ini 之后先做一次启动验证打开界面什么都不加载看Help里的关于信息确认运行时版本是 8 且位数是 64。这一步花两分钟能省掉后面一堆“为什么解析到一半就挂”的排查。3.3 ParseHeapDump.bat不开界面也能出报告生产排障最怕的是把 dump 拷来拷去。Dump 动辄几个 G从服务器下到本地再打开一晚上就过去了。更合理的路径是在服务器上直接跑命令行把结论拿回来。# 在 MAT 根目录执行参数依次是 dump 路径 要生成的报告类型 ParseHeapDump.bat D:\dump\heap-1730000000.hprof \ org.eclipse.mat.api:suspects \ org.eclipse.mat.api:overview \ org.eclipse.mat.api:top_components三个参数分别产出泄漏嫌疑报告、总体概览、最大组件排行。执行完会在 dump 同级目录下生成几个 zip解压后是静态 HTML用浏览器直接看不需要再装任何东西。整个过程不需要图形界面适合在 Windows 服务器上通过远程会话跑。逻辑上它是先建索引、再按报告模板遍历对象图。参数可以只给一个也可以一次给三个给得越多耗时越长但省去了来回切界面。我通常只跑suspects因为概览和组件排行在嫌疑报告里已经有了摘要真要细看再开界面。要注意两点一是路径里不能有中文批处理对编码的处理很脆弱二是它不会覆盖已有的索引如果你替换了同名 dump 文件必须手动删掉旁边那个.index目录否则会拿旧索引去解析新文件出来的结论完全是错的。3.4 用 jmap 与启动参数拿到合格的输入工具再好输入不对也白搭。合格的输入要满足三个条件时间点对、对象完整、文件没截断。时间点对指的是最好在 OOM 发生的那一刻抓而不是内存已经回落后再抓。如果只能用jmap主动抓加live缩小体积如果想知道“垃圾到底堆了多少”反而不加live保留全部对象。这两种场景得到的结论方向完全不同。# 抓一份包含全部对象的 dump含垃圾用于判断是否分配过快 jmap -dump:formatb,file/data/dump/full.hprof 12345 # 抓完做个大小校验避免拷贝中断导致的半截文件 ls -lh /data/dump/full.hprof对象完整要求 dump 期间进程不能被强杀也不能在拷贝过程中断网。文件没截断的判断方法很简单MAT 打开时如果提示文件长度与头部声明不符基本就是传输中断重新拷一遍即可。另外用HeapDumpOnOutOfMemoryError自动落盘时注意磁盘余量。规范做法是把HeapDumpPath指到一个独立分区并配一个清理脚本。我见过最惨的一次是自动 dump 把根分区写满服务从“内存溢出”直接变成“磁盘写满、所有进程卡死”雪上加霜。4. 四张视图读出结论Leak Suspects、Dominator Tree、Histogram、Path to GC Roots界面打开之后真正会用的其实就四张视图。它们回答的是四个递进的问题有没有泄漏、谁占得最多、是哪一类对象、它为什么没被回收。这一章按这个顺序走每张视图我都会说清楚它的口径和误判边界。4.1 Leak Suspects 的置信度与它的三条假设嫌疑报告是自动生成的它会给出一到几个可疑点每个点带一段描述和一棵小树。很多人把它当结论直接贴到故障报告里这是最容易翻车的地方。它背后的判断逻辑大致是找出支配了大量内存的少数对象然后向上追溯到最近的类加载器或线程边界再判断这块内存是否符合“持续增长且不被释放”的模式。它假设了三件事——支配关系能代表泄漏路径、内存大头集中在少数几个点上、以及分析时刻的对象分布能代表稳态。这三条只要有一条不成立报告就会误导。最典型的情况是缓存。缓存天生就是“大块、长期存活、由少数几个容器持有”在嫌疑报告里看起来和内存泄漏一模一样。区别只在于缓存有淘汰策略泄漏没有。所以看到报告里出现某个 Map 或者池对象先别急着下结论去代码里确认它的过期时间和容量上限再决定是不是真问题。我的用法是把它当“检索入口”而不是“诊断结论”从报告里拿到几个类的名字然后带着这些名字去直方图和小对象树里交叉验证。如果三个视图指向同一个对象基本就实锤了。4.2 Dominator TreeRetained Size 的口径差异支配树是 MAT 里信息密度最高的一张视图因为它给的是Retained Size也就是“把这个对象干掉能连带释放多少内存”。这个数值和监控里的堆占用口径不完全一致混淆是导致结论偏差的主要原因。Shallow Size是对象自身占用一个String大概几十字节Retained Size是它独占支配的所有对象之和一个持有十万条记录的HashMap可能是几十 MB。支配树按后者排序所以排在最上面的往往是容器而不是真正的“罪魁”。看支配树时我会做三件事。第一把分组方式从默认改成按类加载器分组快速看出是不是某个热部署模块在泄漏第二展开到具体的对象实例看它的字段值很多问题在字段里一眼就能看出来比如某个List的size是几百万第三右键Path to GC Roots确认它到底是被谁持有的。有一个口径必须提醒Retained Size是相对于当前对象图算出来的它不区分“这个对象本来就该活着”。一个占 800 MB 的本地缓存retained size 就是 800 MB但它可能完全正常。反过来一个只占 20 MB 但持续增长的集合短期看数值不大长期却是真泄漏。数值大小不等于问题严重性增长趋势才是。4.3 Histogram 正则分组与 Merge 技巧直方图是按类统计实例数和浅堆大小它最大的价值是“全覆盖”不会漏掉任何一类对象。缺点是噪声大一个正常的应用打开就是几千行类名根本看不过来。收敛噪声的办法是正则过滤。直方图上方有个输入框直接写正则就能只显示匹配的类com\.myapp\.(cache|session)\..*这条会筛出所有业务侧的缓存和会话类。实践里我通常分三轮筛第一轮筛业务包名看自己写的代码有没有明显问题第二轮筛java.util.*下的集合类找容器膨胀第三轮筛数组类型byte[]、char[]、Object[]因为很多“看不见的膨胀”最后都落在大数组上。另一个技巧是合并。直方图上的Merge Objects by可以按类、按类加载器、按包名合并把上千行压成几十行。合并之后再看占比能迅速定位到“哪个包占了 70%”。合并不会改变总量只是换了聚合维度所以结论是可以互相对照的。还有一个容易被忽略的细节直方图默认统计的是所有对象包括已经不可达但还没被回收的。如果你抓的是不带live的 dump会看到大量本该消失的对象看起来像是泄漏。这时候要么重新抓一份带live的要么在视图里开启“只统计可达对象”别被数字吓到。4.4 Path to GC Roots 的排除项怎么选走到这一步前面的视图已经告诉你“哪个对象有问题”这一步要回答“它为什么还活着”。做法是选中对象右键找引用链菜单里会给出几个排除选项。默认的“包含所有引用”会一路追到线程栈、类加载器、JNI 引用链条往往长达十几层中间夹杂着大量弱引用和软引用看得很累。我的选择顺序是先排除弱引用和软引用因为这两类引用在内存紧张时本来就会被回收走这条路说明对象“可回收但还没轮到”一般不构成泄漏如果排完还是找不到可疑点再放开软引用单独看因为软引用在某些实现里会长期持有大对象。真正需要警惕的是finalizer和ThreadLocal相关的链条。前者说明对象在等待终结器执行堆积起来会造成“回收不掉”后者说明某个线程的局部变量没清理在线程池复用的场景下特别常见——线程不销毁ThreadLocal里的对象就一直活着。还有一个实操细节如果链条中间出现java.lang.ref.ReferenceQueue或者某个线程池的工作队列先别顺着往下看回头确认这个队列的长度是否合理。队列本身不是问题队列里堆积了几万个未处理任务才是。5. 避坑实录五个让结论翻车的现场这一章都是血泪经验每条按“现象、原因、解决”写。这些问题在第一次用 MAT 时几乎都会撞上撞上之后最怕的是误判——不是工具坏了而是用法不对然后得出一个错误结论去改代码。5.1 现象双击 exe 一闪而过或者提示找不到 JVM原因基本只有两个系统里没有 8 版本的 JRE或者 ini 里的-vm路径写错了导致启动器回退到默认 JDK。回退这个行为非常隐蔽界面上不会提示“版本不对”只会在日志里留一行启动失败。解决分三步先用java -version确认本机版本再把-vm那一行改成绝对路径正斜杠单独成行最后在 MAT 目录下用命令行启动一次看控制台输出。如果还不行临时把系统JAVA_HOME指到 8 再试能起来就说明是 ini 的问题起不来就是安装包或位数不匹配。5.2 现象解析到百分之八十卡死或者直接报内存不足原因是 MAT 自身堆上限太小而解析阶段的中间对象撑爆了它。默认 1024m 在 1 GB 以上的 dump 面前基本不够用。这个 OOM 发生在工具进程里和服务端的 OOM 无关但报错信息长得很像容易被误认为“dump 有问题”。解决办法是改 ini 里的-Xmx按 dump 体积的 1 到 1.5 倍设置同时保留-XX:-UseGCOverheadLimit。如果机器内存本身就不够那就换机——别指望通过调小堆来硬扛解析到一半失败比一开始就失败更浪费时间。5.3 现象支配树里的 Retained Size 加起来远超监控显示的堆上限原因是口径不同。支配树算的是对象图的独占支配量而监控里的堆占用包含垃圾、包含未压缩的元数据、也包含各代空间的预留。两边本来就不是一个数硬对没有意义。正确的对照方式是看趋势不看绝对值同一份 dump 里某个对象的 retained size 在两次采样之间涨了十倍这才是有意义的信号。另外注意live抓的 dump 里不包含垃圾数值会明显低于监控峰值这也是正常的。5.4 现象64 位包在 32 位系统上打不开或者打开后界面元素错乱原因是x86_64这个包里的本地库是 64 位的和 32 位系统不兼容。表现不止是起不来有时是能起来但某些视图一开就崩因为插件加载了不匹配的本地组件。解决很直接确认系统位数换对应架构的包。不要试图混搭插件把 32 位插件塞进 64 位目录报错信息会指向完全无关的模块排查成本极高。5.5 现象dump 换了一台机器打开要重新解析十几分钟原因是索引目录没跟着走。.index是和 dump 绑定的缓存不拷过去就得重建。更麻烦的是同名覆盖新 dump 用了老文件名旁边的旧索引还在MAT 会尝试用它结果要么报错要么给出诡异结果。我的固定流程是dump 文件名带毫秒时间戳索引跟着同目录一起打包归档时两者必须同时存在替换 dump 之前先删索引。这条规则写进团队的操作手册之后因为“索引串味”导致的误判基本没再出现。6. 把 MAT 接进日常OQL 查询、两次 dump 对比与报告沉淀前五章解决的是“单次排障能不能得出结论”这一章解决的是“下次还要不要重来一遍”。工具用久了会发现真正省时间的不是界面点得快而是把重复动作变成可复用的查询和可交接的报告。6.1 OQL 三板斧按条件筛、按字段聚合、按引用定位OQL 是 MAT 内置的查询语言语法接近 SQL跑在对象图上。界面里点开查询面板直接执行下面三条基本能覆盖大部分需求。-- 一、按实例大小筛找出所有超过 10 万字符的字符串 SELECT s FROM java.lang.String s WHERE s.count 100000 -- 二、按字段聚合统计重复度最高的字符串值定位拼接型膨胀 SELECT s.value.toString() AS val, COUNT(*) AS cnt FROM java.lang.String s GROUP BY s.value.toString() -- 三、按类型找实例列出所有集合实现看哪个子类数量异常 SELECT * FROM INSTANCEOF java.util.Collection第一条的s.count是字符串的字符数比length()快因为它直接读字段。第二条的GROUP BY配合COUNT能快速发现“同一个值被复制了几十万份”这种典型问题比如日志里拼接的长字符串、JSON 序列化后的重复片段。第三条的INSTANCEOF会包含所有子类型适合在不清楚具体实现类时做粗筛。查询结果可以直接右键导出成 CSV这一步很关键把查询语句和结果一起贴进故障报告别人不用打开 dump 也能验证你的结论。6.2 两次 dump 的差值对比单份 dump 只能告诉你“现在有什么”两份 dump 才能告诉你“什么在涨”。做法是分别打开两个 dump在直方图上右键加入对比篮子然后打开对比视图它会按类给出实例数和内存的差值。实操里有两点要注意。一是两次抓取的时间间隔要够长至少跨过一个完整的业务周期否则噪声盖过信号二是两次的抓取方式要一致都带live或者都不带否则差值里混进了垃圾回收的影响结论不可信。对比视图里我会重点看“实例数在涨但浅堆没怎么变”的类这类通常是对象数量膨胀而不是单个对象变大往往指向缓存键失控或者连接池泄漏。反过来“实例数不变但浅堆暴涨”的多半是集合里塞进了大对象。6.3 报告导出与自动化交接最后一步是把结论固化。MAT 支持把当前视图导出成 HTML 报告也支持在命令行阶段直接产出这一点在第 3 章已经写过。我现在的做法是故障发生时先跑一遍命令行版本拿到嫌疑报告的 zip等定位到具体代码后再打开界面用 OQL 做二次验证把查询语句、对比截图、结论写进同一份文档。阶段动作产出现场命令行跑 suspects 报告泄漏嫌疑 zip初筛界面看支配树和直方图可疑类清单验证OQL 查询具体字段可复现的查询语句交接导出 HTML 加截图一份能给别人看的分析记录这张表的价值在于把“靠记忆”变成“靠流程”。带过几次新人之后我发现同样一份 dump有清单的人两小时出结论没清单的人两天还在翻直方图。还有一个习惯是留样本把脱敏后的 dump 和索引目录留一份在测试机上下次遇到同类问题时先在样本上验证查询语句确认没问题再上生产数据。这一步看着多余但能避免在生产 dump 上反复试错——毕竟那份文件可能是线上唯一的一份现场了。从那以后我每次抓 dump 都强制走一遍“命令行出报告、界面做验证、OQL 留语句、索引一起归档”的流程宁可多花十分钟也不让同一份现场被解析三次。希望帮到你。本文还有配套的精品资源点击获取