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

简介MemoryAnalyzer 1.6.12016年11月25日发布Windows x86_64 压缩包是一款面向Java开发、测试与运维人员的堆内存分析工具主要用于排查内存泄漏、OOM异常、对象占用过高及垃圾回收效率下降等问题。它基于Eclipse MAT可读取heap dump并通过支配树、泄漏嫌疑报告、直方图、引用链与线程概览等视图定位大对象、异常增长的类以及无法回收的引用路径适合开发联调、测试压测和生产故障复盘等场景。压缩包共463个文件约57.99MB以174个jar为核心运行库辅以html帮助文档、xml与properties配置、png/gif界面资源、exe与bat启动文件等目录结构完整解压后即可独立运行。已有303人学习。借助内置帮助文档和完整运行时文件读者可快速搭建本地分析环境结合堆转储完成泄漏点筛查、内存分布核查与引用关系追踪并据此优化对象生命周期和缓存策略为代码调优与稳定性排查提供可复用的诊断依据。1. 一个 40MB 的 zip 包为什么排查内存问题的人都留着一份线上服务每隔两天被 OOM Killer 干掉一次重启就好第二天照旧dump 躺在磁盘上 8 个 Gjmap -histo排第一的永远是[B和java.lang.String看不出是谁在背后捂着不放。这时候缺的不是再猜一轮而是能把堆快照拆开、指出这 8 个 G 被哪条引用链拴住的工具。Memory Analyzer下称 MAT就干这件事读 hprof、建索引、出支配树和 Leak Suspects 报告、支持 OQL 查询。手上这个MemoryAnalyzer-1.6.1.20161125-win32.win32.x86_64.zip是 Windows 64 位免安装包解压即用包名里的 20161125 是构建日期属于 JDK 8 时代的版本。适合手上有老 dump、机器是 Windows、不想为一次分析装整套 IDE 插件的人。2. 打开 dump 之前先理解 MAT 的解析模型很多人拿到 MAT 的第一反应是双击 exe 然后把 8G 的 hprof 拖进去进度条走到 92% 卡住风扇狂转十分钟最后弹一个红叉。这不是工具坏了是它内部的工作方式和你以为的不一样。MAT 不是流式读取 dump 然后边读边显示它要做的是把一份扁平的二进制记录流重组成一张可以双向遍历的对象图再在这张图上算出支配关系和保留大小。搞清这套模型你才知道该给多少内存、该等多久、哪些结论不能信。2.1 一次解析、多次秒开索引文件到底存了什么hprof 文件本质上是一串顺序记录一条记录描述一个类一条记录描述一个实例记录里的字段值是对象 ID 而不是真正的引用指针。想回答这个 char[] 被谁引用这种反向问题只靠顺序扫描是做不到的必须建立从对象 ID 到文件偏移、再到引用者集合的映射。MAT 第一次打开 dump 时做的就是这件事——全量扫一遍把结果写回 dump 同目录的一组索引文件。以heap.hprof为例解析完成后目录里会多出这些文件文件名作用heap.hprof.index对象 ID 到文件偏移的主映射定位任意实例的入口heap.hprof.o2hprof.index对象 ID 到 hprof 原始记录的偏移读字段值时用heap.hprof.a2s.index数组对象到其元素内容的映射heap.hprof.dominator_tree预计算的支配树retained heap 依赖它heap.hprof.inbound反向引用索引Path to GC Roots 靠它heap.hprof.threads线程栈快照的解析结果这几个文件加起来往往和 dump 本身差不多大所以准备磁盘空间时别只按 hprof 的大小算。好处是只付一次代价第二次打开同一个 dumpMAT 直接读索引8G 的文件也能在一两分钟内出首页报告。反过来如果你每次都把索引删掉重来那每次都要等全量解析时间全耗在重复劳动上。解析阶段还有一个容易被忽略的开关默认情况下 MAT 会丢弃不可达对象以缩小索引体积。这在排查已经泄漏但还没被回收的场景下没问题因为泄漏对象一定是可达的但如果你要验证这批对象是不是本来就该死就得让解析器把它们留下来命令行下对应的是保留不可达对象的参数。我的习惯是第一次解析走默认索引小、速度快只有当结论指向这个对象应该被回收了却还在时才删掉索引重新解析一遍带完整对象的版本。2.2 浅堆、深堆与支配树三把尺子的分工shallow heap 是对象自身占的字节数一个String大约 24 字节一个HashMap的空壳也就 48 字节左右。retained heap 是把这个对象干掉之后能连带释放多少内存它包含对象自己以及只有它能到达的所有下游对象。支配树的定义更拗口一点如果从 GC Roots 到对象 B 的所有路径都必须经过 A那么 A 支配 BB 的 retained heap 就记在 A 头上。这个定义带来的直接后果是两个对象共享的下游只算给它们最近的共同支配者不重复计数。所以支配树给出的数字是可以直接相加的——你按 retained 排前几名的对象加起来基本就是这堆内存的大头不会出现重复统计。举个实际会遇到的例子。一个HashMap里塞了 100 万个 Entry每个 Entry 的 shallow 是 32 字节HashMap自己的 shallow 只有 48 字节。在直方图里按 shallow 排序这个HashMap排到几千名开外你根本看不见它按 retained 排序它可能是 3 个 G稳居第一。同样的道理直方图里byte[]永远排前面但它只是账面数字真正把内存攥住的是持有这些数组的业务对象。新手最常干的事就是盯着byte[]一路点下去点到最后发现是几百个不同的类然后得出没有明显泄漏点的结论。支配树之外还有一把尺子叫 inbound 引用也就是谁引用了我。它不关心层级只列直接的引用者用来回答这个对象为什么还没被回收。三者的分工可以这么记直方图看类型分布支配树找内存大户inbound 查引用来源Path to GC Roots 则把 inbound 一路串到根给你一条完整的证据链。2.3 索引与 dump 的绑定关系改名、搬目录、换版本索引文件是按 dump 的文件路径和大小绑定的。把heap.hprof改名成heap-2024.hprof或者把整个目录从 D 盘挪到 E 盘MAT 下一次打开时会发现索引对不上要么重新解析要么直接报错。这不是 bug是它没法确认你给的文件还是不是当初那个文件。所以正确的操作顺序是先把 dump 放到最终位置、改成最终名字再开始解析。中间要换机器分析就把整个目录连同索引一起拷走别只拷 hprof。用 PowerShell 确认索引是不是已经生成过比在资源管理器里数文件快$dump D:\dumps\heap.hprof $dir Split-Path $dump $name Split-Path $dump -Leaf Get-ChildItem $dir -Filter $name.* | Select-Object Name, {nSizeMB;e{[math]::Round($_.Length/1MB,1)}}, LastWriteTime | Sort-Object Name这段只是列目录但能一眼看出索引齐不齐dominator_tree和inbound缺失说明上次解析没跑完直接重新解析比硬开更省时间。输出的LastWriteTime也有用如果索引时间比 hprof 早那基本可以确定它对不上当前这份 dump。还有一个版本维度的绑定索引是 MAT 自己的序列化格式不同大版本的 MAT 之间不保证能互相读。用 1.6.1 解析出来的索引交给另一个版本的 MAT 打开可能提示索引无效然后重来一遍。分析团队里多人协作时把 MAT 版本统一了能省掉很多我这边打不开的来回。3. 解压即用的启动流程从 hprof 到 Leak Suspects 报告免安装包的好处是没有安装程序、不写注册表坏处是所有配置都得自己动手而配置写错的表现往往是一个没有任何信息量的弹窗。这一章按顺序走一遍先确认 Java 环境对得上再改启动参数最后用命令行批量出报告。每一步都给出可以照抄的命令跑完你应该拿到一个不依赖 GUI 的 zip 报告。3.1 先核对 JRE64 位包配 32 位 JDK 是最常见的翻车点文件名里的win32.win32.x86_64说明这是 64 位构建。它会去找 64 位的 JVM如果系统 PATH 里第一个 java 是 32 位的双击MemoryAnalyzer.exe的结果通常是闪退或者弹一句 Failed to create the Java Virtual Machine然后什么都没发生。先确认当前 java 到底是什么java -version (Get-Command java).Sourcejava -version的输出里如果带64-Bit Server VM说明是 64 位没有这行就是 32 位。第二行告诉你这个 java 从哪来很多时候会发现是某个旧软件自带的 JRE被写进 PATH 排在了前面。这种情况下不必去动全局 PATH直接在 MAT 的配置文件里指定 JVM 更干净。MemoryAnalyzer.ini是纯文本用记事本就能改。指定 JVM 的写法是加-vm和路径位置很关键-vm C:\Program Files\Java\jdk1.8.0_202\bin\javaw.exe -vmargs -Xmx1024m-vm必须写在-vmargs之前。写到后面去Eclipse 启动器会把它当成 JVM 参数而不是启动器参数结果就是要么被忽略要么直接报参数非法。这个顺序问题我在不同机器上踩过不止一次血泪经验是改完 ini 先别急着双击用命令行启动一次报错能直接打在控制台里比看弹窗快得多。注意路径里有空格时不要加引号-vm的参数是逐行解析的加了引号反而会把引号当成路径的一部分。3.2 改 MemoryAnalyzer.ini 的 -Xmx按 dump 大小倒推-Xmx是这个工具里唯一真正重要的参数。解析和打开 dump 的过程中对象图、索引、各种中间结构都堆在 JVM 堆里-Xmx给小了表现就是进度条走到一大半然后OutOfMemoryError: Java heap space前面等的时间全白费。倒推公式不复杂取 dump 文件大小的 1.2 到 1.5 倍同时不超过物理内存的 60% 到 70%。8G 的 dump 配 10G 到 12G机器得有 16G 以上内存。低于这个比例不是一定失败但失败概率随 dump 里对象数量上升而上升赌这个没必要。手动改一行就够但如果你经常换不同大小的 dump写个小脚本自动算更省事# 按 dump 实际大小重算 -Xmx写回 MemoryAnalyzer.ini $ini D:\mat\MemoryAnalyzer.ini $dump D:\dumps\heap.hprof $sizeGB (Get-Item $dump).Length / 1GB $heapGB [math]::Max(2, [math]::Ceiling($sizeGB * 1.3)) $content Get-Content $ini if ($content -match ^-Xmx) { $content $content -replace ^-Xmx.*$, -Xmx${heapGB}g } else { # 没有 -Xmx 行就补在 -vmargs 后面 $idx [array]::IndexOf($content, -vmargs) $content $content[0..$idx] -Xmx${heapGB}g $content[($idx1)..($content.Length-1)] } Set-Content -Path $ini -Value $content -Encoding ASCII dump${sizeGB}GB - Xmx${heapGB}g逻辑很直白读文件大小、乘 1.3、向上取整、替换或插入-Xmx行。[math]::Max(2, ...)是兜底避免小 dump 算出 1G 以下导致 MAT 自己起不来。-Encoding ASCII是为了不让 PowerShell 写出带 BOM 的文件启动器读带 BOM 的 ini 有时会解析失败。改完一定要验证别假设脚本写对了Select-String -Path D:\mat\MemoryAnalyzer.ini -Pattern ^-Xmx|^-vm看到-vm在-vmargs上方、-Xmx在-vmargs下方顺序就对了。3.3 用 ParseHeapDump.bat 出报告不开 GUI 也能交付GUI 适合自己看但很多时候你需要把结论发给别人或者在一台没有图形界面的分析机上批量跑。MAT 自带命令行入口ParseHeapDump.bat跑完直接产出几个 zip 报告。先切到 MAT 根目录这个 bat 内部用的是相对路径找MemoryAnalyzer.exe在别处调用会找不到cd /d D:\mat ParseHeapDump.bat D:\dumps\heap.hprof ^ org.eclipse.mat.api:suspects ^ org.eclipse.mat.api:overview ^ org.eclipse.mat.api:top_components三个参数对应三份报告suspects是泄漏嫌疑分析overview是总体概览含 Top Consumerstop_components是按组件聚合的内存占用。后面还可以接org.eclipse.mat.api:system之类但常用的就这三个。跑完在 dump 同目录下会看到Leak_Suspects.zip、System_Overview.zip、Top_Components.zip每个 zip 里是 HTML双击就能在浏览器里看不需要装 MAT。如果只是想先把索引建好省掉出报告的时间把后面三个参数全部去掉即可cd /d D:\mat ParseHeapDump.bat D:\dumps\heap.hprof这条命令在批处理脚本里特别有用白天抓 dump晚上批量建索引第二天上班直接开 GUI 看省掉等待。注意命令行和 GUI 用的是同一个 ini-Xmx的配置对两者都生效别以为改的是 GUI 就不会影响批处理。配套的抓取命令也一并记下避免现场手忙脚乱jmap -dump:formatb,fileD:\dumps\heap.hprof 1234512345换成目标进程 PID-dump:formatb表示二进制 hprof。加:live会先触发一次 Full GC 再 dump文件更小、更接近存活对象真实占用代价是那一次 Full GC 对线上是实打实的停顿业务高峰期不要用。4. 直方图与 OQL把谁在占内存变成可复现的查询GUI 点几下能出结论但结论很难复现也很难交给别人验证。真正让分析过程站得住脚的做法是把判断写成查询同样的 OQL 在同样的 dump 上跑谁跑都是同一个结果。这一章讲三件事——直方图怎么过滤才有意义、OQL 怎么写才不白写、Path to GC Roots 为什么要排除弱引用。4.1 直方图的三个开关正则、retained、class loader直方图默认按类名排序几千行里混着大量 JDK 内部类直接看等于没看。第一个开关是正则过滤在表头上方的输入框里填java\.lang\..*之类先把不关心的包排除掉。常见做法是先看业务包前缀比如com\.example\..*把范围缩到自己的代码里再逐步放开。第二个开关是切换排序维度。直方图默认列的是 shallow heap这个数字对定位问题几乎没有价值。切到 retained heap 之后排序结果会完全不一样前面说的HashMap例子就是这个差别。切换按钮在表格右上角两个来回点一下就能感受到差距。第三个开关是 group by class loader。一个容器里跑多个应用时同名类可能被不同 class loader 各加载一份静态字段也就各有一份。不按 class loader 分组你会看到两个FooService的实例数加在一起误以为是泄漏实际上是两个隔离的上下文。这个坑在插件化、热部署场景里特别常见。4.2 OQL把怀疑写成可执行的查询OQL 的语法接近 SQL但查询对象是堆里的实例。选中一个 dump 之后在菜单里打开 OQL 视图输入框里敲语句回车执行。下面几条是我常用的起手式。查大字符串先看有没有明显的文本堆积SELECT s.toString(), s.value.length AS len FROM java.lang.String s WHERE s.value.length 5000s.value是String内部的字符数组length是 OQL 访问数组长度的写法。这条语句会把长度超过 5000 的字符串连内容一起列出来很多时候一眼就能看到重复拼接的 SQL 或者没截断的响应报文。查大数组本身SELECT * FROM char[] c WHERE c.length 100000SELECT * FROM byte[] b WHERE b.length 1048576第一条找超过 10 万字符的字符数组第二条找超过 1MB 的字节数组。后者在排查缓冲区、序列化结果、文件读取残留时很有效。查集合膨胀SELECT * FROM java.util.ArrayList a WHERE a.size 5000SELECT * FROM java.util.HashMap h WHERE h.size 10000size是私有字段OQL 可以直接读不用管访问修饰符。这两条能快速捞出那些本以为是缓存实际上是只进不出的容器。按线程名过滤定位到具体业务线程持有的对象SELECT * FROM java.lang.Thread t WHERE t.name.toString() LIKE .*order-sync.*LIKE后面是正则.*不能省。拿到线程对象之后可以在 GUI 里对它做 Path to GC Roots把整条链子拉出来。写 OQL 有两个容易白写的点。一是结果集太大直接把界面拖死加WHERE限制条数是必须的别上来就SELECT * FROM java.lang.Object。二是 OQL 不支持任意方法调用能读字段、能调toString()这类少数方法业务方法基本调不了所以查询要围绕字段展开。4.3 Path to GC Roots为什么必须排除弱引用拿到可疑对象之后右键 → Path to GC Roots → 选带exclude weak/soft references的那一项。这个选项不是可选的礼貌是必须。原因在于弱引用和软引用不阻止对象被回收。一个对象如果只被WeakHashMap的 key 或者某个缓存框架的SoftReference引用着它其实随时可以被回收不构成泄漏。但如果查询时把弱引用也算进路径你会得到几十条通往各种缓存管理器的链子看起来每条都像元凶实际全是噪音。排除之后剩下的路径才是强引用链也就是真正让对象活下来的原因。常见的收敛结果有三类静态集合字段static final Map只 put 不 remove、线程池里的ThreadLocal没清理、监听器注册了没反注册。这三类占了实际排查里的大头看到路径终点是static字段基本就可以往下查代码了。还有一个小技巧路径太长的时候在路径视图里对中间节点再右键一次 Path to GC Roots能一段一段往前推比盯着一条几十层的链子找重点快得多。5. 避坑与排查五个把 MAT 用废的常见操作这套工具本身不复杂但配置和输入数据的边界很硬踩中一个就是几小时的无效等待。下面五条都是我或者身边人真实翻过的车按现象 → 原因 → 解决写对照着排查能省不少时间。5.1 双击闪退没有任何报错现象解压后双击MemoryAnalyzer.exe窗口一闪就没了任务管理器里也看不到进程。或者弹一句 Failed to create the Java Virtual Machine 就结束。原因64 位构建找不到 64 位 JVM。系统里可能装了多个 JavaPATH 里排第一的是某个旧软件自带的 32 位 JRE也可能是-Xmx被设成了 8g而实际用上的是 32 位 JVM地址空间根本给不出来。解决先跑java -version确认位数再在MemoryAnalyzer.ini里用-vm显式指向 64 位的javaw.exe并且保证-vm写在-vmargs之前。改完别双击用命令行启动一次错误信息会打在控制台里比看弹窗有效得多。5.2 解析到 90% 报 Java heap space现象进度条走到一大半弹窗 An internal error occurred during: Loading heap dump详情里是java.lang.OutOfMemoryError: Java heap space。原因-Xmx小于 dump 大小。解析阶段要把对象图和索引结构都放进堆里8G 的 dump 配 4G 的-Xmx中途必然撑爆。解决按 dump 大小的 1.2 到 1.5 倍重设-Xmx同时确认物理内存够。物理内存确实不够时别在原机器上硬扛把 dump 拷到内存更大的分析机上做离线分析或者先在命令行只建索引不出报告减少同时驻留的中间结构。删掉半成品索引再重来别指望它断点续传。5.3 dump 文件本身是残的现象打开时报 Invalid HPROF file header或者解析到一半抛 EOF 异常进度条直接归零。原因抓取时进程被 kill、磁盘写满、或者文件在传输过程中被当成文本模式处理过换行符被改写二进制就废了。也有可能是jmap执行到一半被中断留下一个长度不对的文件。解决先验文件头。hprof 的前十几个字节是可读的 ASCII$fs [System.IO.File]::OpenRead(D:\dumps\heap.hprof) $buf New-Object byte[] 32 $fs.Read($buf, 0, 32) | Out-Null $fs.Close() [System.Text.Encoding]::ASCII.GetString($buf)正常应该看到JAVA PROFILE 1.0.2开头。看不到就是文件坏了重抓。重抓之前先看磁盘余量再挑业务低峰期别在高峰期用:live触发 Full GC 把问题放大。5.4 把 shallow heap 当成泄漏判据现象直方图里byte[]、char[]、String排前三点进去发现来源分散在几十个类里于是得出没有集中泄漏点的结论问题搁置。原因byte[]和char[]是承载数据的容器不是持有者。它们的 shallow 大是因为数据本身大但让它们活着的强引用在上层业务对象那里。按 shallow 排序永远只能看到容器。解决切到 Dominator Tree 按 retained heap 排序找真正的大户或者对可疑的byte[]做 Path to GC Roots 并排除弱引用看能不能收敛到同一个业务类。收敛不到就说明确实分散这时候该看的是对象增长速率用两个时间点的 dump 做对比而不是在单个快照里死磕。5.5 改名、换版本导致索引错位现象明明解析过了再打开却提示重新解析或者打开后类名乱码、实例数和之前对不上。原因两种情况。一是 hprof 被改名或移动过旧索引还留在原目录MAT 按路径找不到对应关系二是用不同版本的 MAT 打开同一份索引序列化格式不兼容。解决改变 dump 位置时把同名的.index、.dominator_tree、.inbound等一组文件一起处理——要么一起移动要么全部删掉重新解析。团队协作时统一 MAT 版本别一个人用 1.6.1、另一个人用更新版本然后互相说对方给的报告有问题。这个版本的构建年份比较早遇到新 JDK 生成的 dump 打不开时优先考虑换更新的解析器不要在旧包上反复折腾。6. 大堆 dump 的进阶打法20 分钟内从 8G 收敛到三个类拿到一份 8G 的 dump最耗时间的不是分析是漫无目的地浏览。我现在固定走一条路径把过程压到 20 分钟以内你可以直接抄。第一步看 Overview 里的 Top Consumers它按 retained 给出前若干个组件通常是几个业务模块加几个 JDK 内部结构。这一步只花两分钟目的是建立全局印象内存是被一个东西吃掉的还是被几千个中等对象摊掉的。第二步看 Leak Suspects 的 Problem Suspect 1。它给出的是某个类的实例占了 X%被某条引用链持有。这一条能命中就基本结束了命不中就往下走别在 Suspect 2、3 上耗太久那些多半是同一个问题的碎片。第三步用直方图正则过滤把java\.、sun\.、org\.springframework\.这些框架包先排掉只看自己的业务包前缀。这一步经常能直接看到某个 DTO 的实例数是几十万而正常量级应该是几千。第四步对可疑类做 retained 排序的支配树查询确认它是不是真的持有那么多下游。有时候实例数多但每个都很小retained 加起来不值一提那就不是它。第五步如果单个 dump 看不出趋势用两个时间点的 dump 做对比。MAT 里叫 Compare Basket把两份直方图放进去做差增长最快的那几行就是嫌疑。这个功能比人眼对比两份表格可靠得多。下面是我自己用的时间预算供参考步骤目标时间Top Consumers判断是集中还是分散2 分钟Leak Suspects抓现成的引用链结论3 分钟直方图过滤缩到业务包范围3 分钟支配树 retained 排序确认真实占用5 分钟Path to GC Roots拿到强引用链证据5 分钟两快照对比可选看增长趋势10 分钟有两个习惯是踩坑之后才养成的。一是每次分析前先把-Xmx按 dump 大小重算一遍绝不沿用上次的配置——曾经有一次直接拿 4G 的配置去开 12G 的 dump等了四十分钟换来一个 OOM那四十分钟本来可以用来做别的事。二是所有结论都要落到一条可复现的 OQL 或者一条完整的 Path to GC Roots 路径上截图不算口头描述更不算因为下次别人复现不出来你就得从头再查一遍。从那以后我每次抓完 dump都强制走一遍验文件头、算 Xmx、建索引、出 suspects 报告这四步哪怕当时觉得没必要。希望帮到你。本文还有配套的精品资源点击获取