转载自某位资深开发者在内部技术社区的总结我在实际排查线上 Java 内存问题时反复用过这套思路整理成一篇完整的实战笔记希望对正在和堆内存搏斗的你有帮助。Java 应用跑着跑着内存就涨直到某天早上收到告警“堆内存使用率 99%”再一看 GC 日志Full GC 频繁得像地铁早高峰。这种场景做过线上运维的基本都懂。定位这类问题的标准姿势就是用堆转储快照配合分析工具查对象引用链而 Eclipse MATMemory Analyzer Tool是我用过最顺手的一个。这篇文章围绕 MAT 展开讲清楚它的核心概念、实际操作流程、典型案例的排查思路以及那些只有踩过坑才会注意到的细节。适合正在学习 JVM 调优的开发者也适合需要快速上手内存分析的运维和后端工程师内容按“原理—操作—实战—避坑”的顺序组织越往后越偏经验。1. MAT 是什么以及它凭什么定位内存问题先说背景。Java 应用的内存问题大致分两类一类是内存泄漏对象用完没释放堆被慢慢填满另一类是内存溢出某个瞬间堆直接被撑爆比如加载了一个超大的数据集。不管是哪一种最终都会表现为高频率的 Full GC、响应变慢、甚至进程直接 OOM 崩溃。问题是光看监控曲线只能知道“内存涨了”不知道“是什么涨了”。监控图形只能画出结果画不出原因。要找到“谁占了大头”“谁一直在增长”“谁把对象引用住了”唯一的出路就是把堆内存拍个快照也就是 Heap Dump然后离线分析。MAT 就是做这个事的专业工具。它读入 HPROF 格式的堆转储文件把其中上千万个对象重新组织成一张张可统计、可钻取的表让你从“对象总数”看到“对象级别字符串”的内容再沿着 GC Roots 一步步找到那个不该存在的引用链。它几个核心功能我列一下后面会逐个展开Histogram按类统计堆中的对象数量、占用空间快速框定大对象。Dominator Tree算支配关系直接找出“如果我干掉这个对象能释放多少内存”。Leak Suspects 报告自动跑一圈检测逻辑把最像泄漏点的候选列表拿给你。Thread Details看每个线程的栈帧、局部变量、锁和对象引用排查线程内存占用。OQL类 SQL 的查询语言针对堆内对象做筛选、统计适合精细化探索。工具本身是开源的基于 Eclipse RCP 平台开发的桌面应用虽然界面风格有点老派但计算引擎很扎实几 GB 的堆转储也能处理。官方全称是 Eclipse Memory Analyzer Tool所以平时搜资料直接搜“MAT Eclipse”就能找到。从定位上讲MAT 不是唯一的堆分析工具但它在“查内存泄漏”这个细分场景上做得最全能。像 jmap 只能导出堆jhat 只能看最表面的直方图VisualVM 也能装插件看但复杂场景下都不如 MAT 的 Dominator Tree 和 Leak Suspects 来得直接。2. 分析前的关键准备堆转储的获取与工具调校2.1 堆转储的几种获取方式怎么选MAT 分析的对象是堆转储文件所以第一步是先把这个文件搞到手。常用的方式有三种按实际场景选择第一种用jmap手动导出。这是最通用的办法适合线上进程还活着、内存还没崩的情况jmap -dump:formatb,file/data/dump/heap.hprof pidformatb表示以二进制 HPROF 格式输出MAT 主要支持这种格式。如果不传参数直接jmap -dump:file...某些 JDK 版本默认也能用但建议明确写formatb防止踩到格式坑。我一般还会加live参数像这样jmap -dump:live,formatb,file/data/dump/heap.hprof pid加live会先触发一次 Full GC 再 dump只保留存活对象。这样 dump 出来的文件会小很多分析速度会快不少但它代表的是“清理完垃圾之后”的内存状态会掩盖一部分本来可以清除只是还没来得及清除的对象。如果是排查“GC 之后内存还很高”的问题用live合适如果想看真实的内存分布、包括那些准备回收的对象就别加live。第二种通过 JVM 参数自动导出。这是我最推荐的生产环境配置提前在启动参数里加两句-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/这样一旦发生 OOMJVM 会自动把当时的堆快照写到指定目录文件名类似java_pidpid.hprof。好处是不用手工干预出事现场就是第一手材料。很多事故之所以难复盘就是因为进程一 OOM 就被运维重启了堆没了什么证据都没留下。配了这个参数至少事后能打开现场看看。第三种从容器和云平台捞文件。如果进程跑在容器里或者用了某些运维平台通常有统一的 dump 导出入口原理还是 jmap只是包装成了界面操作。这里不展开大家按各自平台的文档操作就行。2.2 MAT 安装和启动内存调校MAT 是 Eclipse 基金会出的独立桌面程序下载完成解压就能用不依赖安装包。不过有个非常关键的坑MAT 本身是个 Java 程序它要加载几 GB 的堆转储文件自己也要消耗大量内存。默认配置下主程序 JVM 可能只分配了 1GB 左右内存打开大 dump 会直接报错An error has occurred. See the log file Could not reserve enough space for object heap解决办法是改安装目录下的MemoryAnalyzer.ini文件把-Xmx调大比如-vmargs -Xmx4096m我自己的经验是-Xmx设成堆转储文件大小的 1.5 到 2 倍比较稳。一个 4GB 的 hprof 文件Xmx 开到 6GB 到 8GB 才能顺畅操作如果机器内存只有 16GB开 12GB 给 MAT 也没问题只要别把系统内存吃光就行。注意不要设到超过物理内存否则 MAT 自己开始疯狂 GC分析过程慢到怀疑人生。还有一个隐藏参数-XX:UseConcMarkSweepGC老版本里加上可以改善大内存下的响应速度新 JDK 下不一定需要我一般保持默认。重点就一个打开 dump 之前先确认 MAT 能分配到的最大内存别在分析中途才发现 OOM。2.3 打开 dump 的第一眼怎么看用 MAT 打开 dump 后会先出现一张Overview页面展示堆大小、类数量、对象数量、ClassLoader 数量等概要。右上角有一排快捷入口包括Histogram、Dominator Tree、Leak Suspects、Thread Overview、Run Expert Test。新手最容易犯的错是直接点 Leak Suspects 等结果没有先看 Overview 上的基础数据。其实概要信息能告诉你很多比如类加载器数量异常多可能存在大量动态代理或热部署导致的类泄漏对象总数和类总数能大致反映 dump 的规模和健康度。花 30 秒扫一眼 Overview再进下一步比一头扎进细节高效得多。3. 核心功能逐个拆解从 Histogram 到 OQL3.1 Histogram 直方图先看全局再谈细节Histogram 是 MAT 所有功能里最“直觉”的一个入口。它按类汇总了堆中的对象数量、Shallow Heap 和 Retained Heap 三个关键列列名含义Objects该类在堆中的实例个数Shallow Heap对象自身占用的内存总量不含它引用的其他对象Retained Heap如果这个类的所有对象被回收连带可以释放的总内存为了更直观地理解这两个概念可以打一个比方你想判断一个家庭“占用的资源总量”Shallow Heap 就是这一家人身上的衣服、包、手机Retained Heap 则是把这一家人送走后他们名下所有房产、车、家具加一起会被腾出来的总数。显然对于定位内存问题Retained Heap 更有参考价值——因为它衡量的是“释放能力”。实际操作中我一般会先按 Retained Heap 排序把总量最大的前 20 个类拉出来看一遍。大量业务熟悉的情况下很快就能看出哪些类是“正常大”哪些是“异常大”。比如正常情况下某个缓存 Map 也就几万条数据现在看到几十万个节点基本就能确定问题方向在这个区域。但 Histogram 有个明显的局限它只按类聚合看不到实例之间的引用关系。就算看到某个类占了几百 MB没法直接知道是谁在引用它。更关键的是一个类占用大不代表类本身有问题有可能只是某几个实例异常膨胀这时候需要进一步下探到对象级别。这也是为什么紧接着要看 Dominator Tree。3.2 Dominator Tree 支配树谁才是真正的内存大户Dominator Tree 比 Histogram 更进一步它按对象实例的支配关系组织起一棵树。所谓“支配”可以通俗理解为如果对象 A 被 GC Roots 引用链经过而对象 B 只有通过 A 才能被访问到那么 A 支配 B。一旦 A 被回收B 也会被连带回收。在这个视图下树的顶层节点就是堆内存的“总入口”子节点一层层展开每节点都标注了 Retained Heap。我通常第一步只展开前几层找到 Retained Heap 最大的几个顶层节点这些节点往往就是内存泄漏的“根头目”。如果顶层就是一个业务对象、一个线程、或者一个静态集合顺着它往下看基本上就能圈出问题链路。举一个真实的场景某系统有个定时任务每小时把一批用户行为数据聚合后存入一个静态 List后续有消费者从这个 List 取数处理。由于业务上忘记清理消费完的数据List 只增不减。从直方图里看某个业务对象的数量直线增长但从支配树里看会明确看到这个 List 对象挂在一棵巨大的子树上这棵树的 Retained Heap 几乎占了一半堆。从树根往下引用链一目了然静态字段 - Map - List - 业务对象。这个就是在找“谁支配了谁”的意义。同时在 Dominator Tree 里选中任意对象鼠标右键菜单里有个Path to GC Roots功能可以显示从 GC Roots 到这个对象的所有引用路径。对于排查“这个对象为什么没被回收”这个功能是杀手锏后面实战部分再细说。3.3 Leak Suspects 报告让工具先猜一轮Leak Suspects 是 MAT 自动执行的一组启发式分析。它会扫描整个堆找出那些 Retained Heap 明显偏高、且引用链不寻常的对象集合然后把结果整理成一份带排名的报告每一项都展示问题描述例如“一个或多个实例被某类加载器持有”Shortest Paths To the Accumulation Point到该聚合点的最短引用链Acculated Object 列表聚合点下挂的对象很多博客会把 Leak Suspects 说得很神仿佛点一下就能告诉你泄漏源。实际用下来的体会是它适合当“向导”不适合当“判决书”。因为启发式规则可能会漏掉业务里那种隐性的、需要结合上下文才能看出来的泄漏。比如一个自定义线程池里的任务队列积压Leak Suspects 可能根本不会把它列为高危但它的确是生产事故的元凶。所以我用 Leak Suspects 的方式是先看它的报告能指到可疑对象最好如果指向的结果跟业务直觉不符就直接跳过它改用 Histogram 和 Dominator Tree 手排。工具是辅助分析框架在脑子里这两者结合才能覆盖全。3.4 Thread Overview 线程视角内存与线程的交集内存问题不只是对象问题有时候问题的根子在线程上。Thread Overview 视图列出 dump 瞬间所有线程的栈帧以及每个栈帧局部变量指向的对象和对应的 Retained Heap。这个功能的典型用途有两个一是查某个线程是否持有了大量对象比如一个耗时的请求处理线程在堆里堆积了大量中间结果二是查线程池场景下任务堆积在什么地方比如线程池队列里的对象由谁持有。展开线程的栈帧双击某一帧还能跳到对应的对象详情从线程栈出发找到对象的创建和持有者这条路径在特定场景下效率极高。我线上遇到过一类很隐蔽的问题服务用了异步事件机制某个事件处理器内部持有了请求上下文对象但因为编码失误这个持有动作没有在事件处理完成后释放导致每次请求都留下一个“事件订阅者”对象挂在某个单线程线程池上。从 Histogram 看对象分布很零散只有切到 Thread Overview把那个线程的局部变量逐个展开才发现线程栈上挂着一整串历史请求对象。这个角度是对象树视图看不到的。3.5 OQL 查询在堆里写 SQL如果说前面几个功能像 Excel 的透视表和筛选OQL 就像直接在堆里跑 SQL。MAT 内置了一套对象查询语言语法上接近 SQL但查询对象是堆内的实例和引用。常用写法-- 查询所有长度超过 500 的字符串 SELECT s, s.value.length AS len FROM java.lang.String s WHERE s.value.length 500-- 统计各个 char[] 长度区间分布 SELECT t.c AS length, count(*) AS cnt FROM (SELECT s.value.length AS c FROM java.lang.String s) t GROUP BY t.c-- 查询某个 List 实例的所有元素后面可精确带引用 SELECT l.elementData FROM com.example.MyList l WHERE l.id 123OQL 在两类场景特别好用。一类是精确搜索比如你知道某条数据值或者某个 ID 对应的对象直接在堆里查出来然后看它的引用链能快速定位一条“从哪来、被谁持有”的完整路径。另一类是横向统计比如按日期分组统计某个业务对象的数量几天没清理的缓存可能一目了然。OQL 也支持自定义函数和正则匹配不过日常场景用基础语法就够。菜鸟阶段可以先学这 3 个模板查大字符串、按某字段统计、按某属性查找基本覆盖大多数诉求。4. 实战一次从内存告警到泄漏根因的完整排查4.1 事故现场还原某天凌晨监控系统发出告警某 Java 服务堆内存使用率连续 30 分钟超过 85%Full GC 次数从每天个位数暴增到每小时几百次。服务响应开始变慢部分调用方报超时。值班同学先保留了现场日志、GC 记录、线程栈都打包了但由于启动参数里已经提前配好了HeapDumpOnOutOfMemoryError进程倒是一直没 OOM所以我们决定手动导一份 dump 来分析。导入之前先确认了几件事一是导出必然有性能影响jmap -dump对线上进程来说会有短暂的停顿和 CPU 开销所以选在流量低峰期执行二是磁盘剩余空间要足够因为堆已经涨到将近 6GB导出文件也很大落在独立磁盘分区比较稳妥。综合判断后执行了jmap -dump:live,formatb,file/data/dump/order-core-2024.hprof 28564这里用live是因为我们关心的就是“Full GC 之后仍然占用大头的对象”这更贴近真实泄漏。导出过程持续了约 20 秒文件大小 3.2GB。4.2 用 MAT 打开按三层递进定位本地启动 MAT确认MemoryAnalyzer.ini里的-Xmx已调到 6GB 后打开 dump 文件。先看 Overview堆大小为 3.2GB对象数量 2.1 亿类数量 5 万个。然后看 Histogram按 Retained Heap 排序排第一的是一个业务对象OrderContextRetained Heap 占了整个堆的 65%。到这里方向基本锁定大部分内存被这个业务对象占着但为什么会这么多实例还不知道。顺着 Histogram 右键选择List objects - with outbound references展开OrderContext的实例列表发现里面存在大量重复的订单快照数据——同一个订单 ID 出现了几千次。这就很奇怪了正常业务里一个订单上下文只会存在很短时间。于是选中一个实例右键Path to GC Roots - exclude weak references把弱引用排除掉只看强引用路径。返回的路径非常清晰Thread-异步处理线程的当前栈帧持有TaskQueue对象TaskQueue指向了一长串EventTask每个EventTask内部又引用着各自的OrderContext。到这里根因已经浮出水面某异步任务在内部向任务队列重复投递了自己还没消费完成的事件每次投递都携带完整的 OrderContext队列又设置了很大的容量导致对象持续堆积。再结合业务代码发现是重试逻辑中的死循环式重新入队。4.3 确认引用关系后修复和验证在 MAT 里找到的证据直接拿到代码里验证定位到那个异步处理器的入队逻辑确实存在一个在异常分支中重复offer自身而不退出的 bug。修复方案很简单在重新入队前设置最大重试次数超过上限直接丢弃并记录告警。改完后回归验证观察一周内存曲线平稳Full GC 次数回落到正常水平。同时顺手把这个“重复事件堆积”的场景加了监控指标再出现能第一时间看到队列深度上涨。这个案例反映了一个通用排查套路值得抽象成流程拿到堆转储先看 Overview 和 Histogram确认大头方向和异常类。对可疑对象做引用链分析用Path to GC Roots确定持有者。结合线程视图或 OQL 确认业务持有链判断是“正常缓存”还是“异常堆积”。回代码定位逻辑根因修复后从监控和 GC 日志双向验证。排查过程中最关键的一点是不要只看对象大小要看引用路径。很多泄漏对象单个体积不大但数量极大且引用链完整只有顺着引用链才能解释“为什么这些对象没有被回收”。5. 高频踩坑记录帮你省几小时起步的学习成本5.1 dump 文件太大打不开这是被问得最多的一个问题。现象是 MAT 打开 hprof 时内存报错或卡死解决办法前面提过调大MemoryAnalyzer.ini的Xmx。还有一个补充思路如果堆文件已经几十个 GB建议先考虑用 MAT 的mat命令行批处理模式导出关键结果比如用命令行跑org.eclipse.mat.api:topComponents这类的查询任务只输出摘要不打开图形界面。虽然命令行的姿势不够直观但处理超大文件时这是最稳妥的方案。5.2 别忽略 live 参数的影响jmap -dump:live和jmap -dump导出来的堆内容完全不同。加live会触发 Full GC等于你看到的堆是“打扫过房间之后的样子”。如果问题是“GC 之后内存还是下不去”加 live 是对的但如果想查“GC 之前到底什么临时对象撑爆了堆”必须不带 live 导出。还有jmap -dump:live会触发一次 STW线上低峰期也要评估影响别在核心交易时段贸然执行。5.3 只信 Histogram 不看 Retained Heap 会跑偏新手经常只看 Shallow Heap 排序结果看到一堆byte[]和char[]。比如一个byte[]占 1MB它可能是某个大图片的缓存但也可能是无数个小对象的共享底层数据。Shallow Heap 大不代表它真的可释放如果这个数组被很多对象引用干掉这个数组会导致大半个程序崩溃。而 Retained Heap 才代表“释放价值”。一定要结合 Dominator Tree 看否则会被几个大数组带偏方向。5.4 分析时必须排除弱引用再看强引用路径Path to GC Roots的菜单勾选里我建议默认选exclude weak references。为什么呢因为很多设计合理的框架会故意用弱引用做缓存比如WeakHashMap、某些池里的弱引用条目这些对象即使存在也不构成泄漏。如果不排除弱引用引用链可能被弱引用索引先截获误导到“缓存没清”的结论上真正的强引用持有链反而被淹没了。当然如果你就是想确认某个弱引用到底引用了什么再选择包含弱引用的路径也不迟。5.5 别忽略 OOM 自动 dump 文件的下一步动作有些团队配置了HeapDumpOnOutOfMemoryError但 OOM 后实际发生的 dump 会卡住进程一段时间因为 dump 本身也要分配临时空间和写磁盘。如果堆已经是崩溃边缘open 空间不够dump 大概率失败。所以生产环境我同时会配合-XX:HeapDumpPath指定目录并确认该目录磁盘空闲超过堆上限。另外最好再加一个脚本OOM 后自动压缩 dump 文件并转移到分析服务器避免现场被后续运维操作覆盖。6. 写在最后的个人体会用 MAT 做了这几年线上内存分析我最深的感受是工具本身并不难学难的是建立起“引用推导”的分析思路。你看一台机器内存满了第一反应如果是“哪个进程占得最多”那只是在处理表象MAT 教会我们把问题细化为“哪个对象、被谁持有、沿着哪条引用链无法释放”。一旦掌握了这种分析方法无论是排 OOM、查线程堆积还是分析慢 GC都能很快找到入口。还是那句话内存泄漏不会自己消失早一点把堆转储导出、早一点用 MAT 打开后面的修复和验证就能少走一半弯路。真遇到 dump 打不开或分析结果对不上业务直觉的时候回来看看这篇的经验大概率能帮你节省几个晚上的加班时间。
