★ FEATURED ARTICLE 简介Eclipse MATMemory Analyzer Tool是一套面向Java开发者、运维及性能调优人员的内存分析工具资源包用于解析JVM生成的heap dump堆转储文件帮助快速定位内存泄漏、大对象持有链与循环引用适用于代码审查、故障排查与容量规划。整个zip压缩包共包含5442个文件压缩后约133.56MB文件构成以3758个HTML离线帮助文档为主同时含插件JAR包、PNG/GIF界面示意图、XML/Properties配置及示例hprof堆转储文件并集成MAT主程序、Eclipse插件模块、Windows可执行组件和命令行启动脚本解压后可直接使用。工具内置Leak Suspects泄漏嫌疑报告、Dominator Tree支配树、Histogram对象直方图、Duplicate Objects重复对象检测、对象引用链反向分析、Shallow/Retained Heap统计及多份快照对比分析能系统排查内存占用过高、循环引用和泄漏源头。包内HTML文档相当于离线参考手册示例hprof文件可练习从生成dump到定位根因的完整流程图形化结果也降低上手门槛。目前已有367人学习/下载对希望掌握JVM堆分析、优化Java应用内存表现的开发者有较高参考价值。1. Eclipse MAT 日志分析工具是什么它并不是看普通日志的Eclipse MAT 全称 Eclipse Memory Analyzer标题里挂着“日志分析工具”但它真正啃的并不是应用打印的 error.log而是 JVM 在内存溢出时导出的堆转储文件——那一坨 .hprof 格式的二进制快照。遇到java.lang.OutOfMemoryError: Java heap space时普通日志只能告诉你“崩在哪个线程、哪一行”回答不了“为什么崩、谁把内存吃光了”。Eclipse MAT 的价值在于它把堆转储变成可以逐类、逐对象、逐引用链追查的内存地图适合排查 OOM、频繁 Full GC、缓慢泄漏等一类靠日志看不出所以然的问题。本文按“机制 → 操作 → 参数 → 避坑 → 进阶”展开目标是让你拿到一次 OOM 转储后能独立走完从定位到验证的整套流程。2. 内存分析如何工作MAT 的直方图、支配树与 GC 根目录2.1 从 heap dump 到直方图浅堆与保留堆的区别是判断泄漏的分水岭MAT 打开堆转储后第一件事是构建对象直方图Histogram也就是把 JVM 堆里所有对象按类分组统计每个类的实例数量和占用空间。这里有两个最容易被新手混为一谈的指标浅堆Shallow Heap和保留堆Retained Heap。浅堆只算对象自身占用的内存不含它引用的其他对象。一个byte[1024]的浅堆就是 1KB一个持有 10 万个子对象的业务对象浅堆可能只有几十字节。保留堆则反过来代表“如果这个对象被回收连带一起释放的总内存”。保留堆才是判断某类对象是否泄漏的可靠口径因为泄漏的本质是某个对象被无意义的引用链拽住导致它连同整棵对象树都回不了收。指标含义适用场景浅堆Shallow Heap对象自身字段占用的内存快速查看哪些类实例数量异常多保留堆Retained Heap该对象被回收时连带释放的总内存定位对象树的根、判断单个对象的重度对象数量Objects当前堆中该类的实例总数结合增长趋势判断是否存在实例泄漏实操里我会先按“Retained Heap”降序扫一眼直方图。正常应用排在前面的往往是byte[]、char[]、java.lang.String这类基础数组因为它们是业务数据的物理载体。如果某个自定义业务类出现在保留堆前排而且实例数量也很可观就要怀疑它是不是被某个容器长期引用了。注意直方图默认不显示保留堆需要右键选中列或使用计算功能这个口径差别就是很多人一开始看 MAT 觉得“数值对不上”的原因。2.2 支配树与 GC 根目录为什么说它是一台引用关系显微镜直方图告诉你“什么对象多”支配树Dominator Tree告诉你“谁拽住它们不放”。JVM 里的对象通过引用链从 GC Roots 出发能到达的对象就存活到不了的就等着回收。支配树把这种引用关系画成树状结构如果一个对象是另一个对象在引用路径上必经的节点那么前者支配后者。举例来说线程池里跑任务的 Worker 线程栈帧里持有一个业务请求对象这个请求对象又引用了 2MB 的缓存数据。从 GC Roots 出发请求对象是被线程栈引用的所以只要线程还活着缓存数据就不可能回收。在支配树上你会看到 Worker 线程分支下挂着这个请求对象而请求对象又挂着一整棵缓存树。MAT 的 Leak Suspects Report泄漏疑点报告本质上就是自动遍历支配树找出那些保留堆特别大、且引用路径不合理的可疑子树。理解支配树还有一个实际作用区分“真泄漏”和“合理缓存”。很多全局缓存、连接池、线程池本身保留堆很大但它们是业务正常需要不能叫泄漏。看支配树时重点看可疑对象的引用链是否经过业务代码里的字段是否被一个生命周期异常长的容器持有而不是只盯着保留堆数字。2.3 为什么堆转储日志分析必须用 MAT而不是 grep普通日志是线性的文字流grep 能查出“某个时间点发生了什么”但对象之间的引用关系是图结构文字流表达不了。即使你在日志里打了map.size()之类的业务指标也只能看到表象看不到具体是哪个 key 占住了内存。堆转储记录的是某一瞬间的整个对象图需要专门的内存分析工具来解析。与同类工具对比MAT 是多数团队的默认选择。常见的替代方案里JDK 自带的 jhat 早已被标记为过时功能停留在基础查询层面VisualVM 的堆查看器适合轻量观察但对大转储的解析速度和对象图分析能力有限商业 JProfiler 等工具功能全但收费且不常驻服务器。MAT 免费、跨平台、支持从几百 MB 到数 GB 的转储解析还提供 OQL 对象查询语言和自动化脚本接口所以本文后续的操作全部以 MAT 为主线。3. 完整流程从 OOM 日志到用 MAT 找出泄漏疑点的最短路径3.1 先改 JVM 启动参数让崩溃日志带上完整的现场很多人排查 OOM 时才发现没有堆转储只有一行java.lang.OutOfMemoryError日志这时再想复现成本极高。正确做法是从一开始就在 JVM 启动参数里打开自动转储开关崩溃时留下现场文件。# 生产环境 JVM 参数示例重点是前两行 java -Xmx2g \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/logs/heapdump/ \ -XX:PrintGCDetails \ -XX:PrintGCDateStamps \ -Xloggc:/data/logs/gc.log \ -jar app.jar-XX:HeapDumpOnOutOfMemoryError表示 JVM 在抛出 OOM 的同时把当前堆状态写成 .hprof 文件-XX:HeapDumpPath指定输出目录不然文件默认落在工作目录下位置不确定。-XX:PrintGCDetails和-Xloggc用来记录 GC 历史用于判断 OOM 之前是否已有连续 Full GC 的征兆。这里有一个容易踩的细节HeapDumpPath如果只写目录文件名为java_pidpid.hprof如果写了完整文件路径则固定用该文件名多次崩溃会覆盖。为了保留多次现场我习惯只写目录。另外自动转储发生在内存已经耗尽的时刻文件体积可能比当前-Xmx还大要提前确认磁盘剩余空间否则转储中途失败看到的只是半截文件。3.2 手动抓取现场jmap 与 jcmd 的正确用法线上问题有时候不会立刻 OOM而是表现为内存缓慢上涨。这种情况下不能傻等自动转储需要在服务运行过程中手动抓取。常见做法是先用jps确认进程号再用 jmap 或 jcmd 导出堆。# 查看当前 Java 进程找到目标应用的 PID jps -l # 手动抓取堆转储formatb 表示二进制格式 jmap -dump:formatb,file/data/logs/heapdump/app_$(date %Y%m%d_%H%M%S).hprof pid # 新版 JDK 更推荐用 jcmd避免 jmap 在某些场景下的额外停顿 jcmd pid GC.heap_dump /data/logs/heapdump/app.hprof我把jmap括号里的参数拆开讲formatb指定二进制格式MAT 只能解析这种格式如果漏了会得到文本格式的堆视图file指定输出路径live参数我没有加因为它只导出存活对象会过滤掉一部分本来可以暴露问题的无用对象链。初次尝试可以用jmap -dump:formatb,file/tmp/app.hprof pid很容易成功先保证能拿到文件再考虑参数优化。需要提醒的是手动抓取会触发完整的堆遍历导致应用短暂停顿停顿时间与堆大小相关几百 MB 的堆通常百毫秒级几个 GB 的堆可能到秒级。生产环境抓取前要评估影响最稳妥的做法是在压测或低峰期进行让服务至少保留一定冗余内存。3.3 导入 MAT分析模块选哪个、阅读顺序是什么拿到 .hprof 文件后打开 MAT通过File Open Heap Dump选择文件。MAT 支持直接打开.hprof.gz压缩格式导入前先压缩转储文件能显著减少磁盘和加载时间。首次打开会弹出分析模块选择界面常见的几个模块作用如下。分析模块输出内容适用场景Leak Suspects Report自动生成可疑泄漏点及引用链第一次看转储、快速找方向Overview堆大小、类加载器、GC 根概览了解整体内存结构Histogram按类分组的直方图手工排查实例数量异常Dominator Tree支配树视图追踪大对象的引用路径OQL类似 SQL 的对象查询验证假设、过滤特定对象我一般按固定顺序阅读先点Leak Suspects Report看 MAT 自动挑出的可疑对象重点看每个嫌疑点的Shortest Paths To the Accumulation Point这条路径直接给出从 GC Roots 到泄漏对象的引用链。然后再打开Histogram按保留堆排序确认嫌疑对象确实占大头。最后回到支配树顺着路径逐个检查每一层的字段是否合理。实际操作中最常见的停滞点不是找不到大对象而是找到了大对象却解释不了它为什么被持有。这时不要急着回代码里瞎猜回到支配树视图选中可疑对象点击右键菜单中的Copy Shortest Paths To GC RootsMAT 会列出所有能到达该对象的存活路径业务线程栈、类加载器、静态集合都会单独分组。哪条路径看起来最不像业务需要哪条就是突破口。4. 大转储文件的配置与批处理几千兆字节的文件榨干内存前先改参数4.1 默认内存配置经常翻车改 MemoryAnalyzer.ini 的三个要点MAT 本身是 Java 桌面程序默认最大堆内存通常在 1GB 左右。如果你分析的堆转储是 2GB 甚至 4GBMAT 在解析索引时大概率直接提示Java heap space崩溃。在骂工具之前先打开 MAT 安装目录里的MemoryAnalyzer.ini把堆内存调到足够大。# MemoryAnalyzer.ini 关键参数示例位于 MAT 安装根目录 -startup ../eclipse/plugins/org.eclipse.equinox.launcher_1.x.x.jar --launcher.library ../eclipse/plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.x.x -vmargs -Xms1g -Xmx4g-Xmx4g表示最大允许 4GB 内存。调整时不要拍脑袋写一个超大值建议按转储文件体积的 1.5 到 2 倍设置比如 2GB 的堆转储给 MAT 4GB通常够用。如果机器本身内存只有 8GB又把-Xmx设为 7GB分析过程中系统会疯狂使用交换分区操作界面卡得像死机反而比写小一点更慢。-Xms设成和-Xmx相等可以避免运行时动态扩容带来的停顿。修改 ini 文件容易踩到两个坑一是参数必须写在-vmargs之后写在前面不会生效二是如果你用桌面快捷方式启动某些启动器可能绕过了 ini需要确认实际启动时读取的是同一份配置。改完后重启 MAT在欢迎页底部的状态栏可以确认当前堆配置。4.2 命令行批处理不打开图形界面也能生成分析报告线上服务器往往没有桌面环境不适合天天开着 MAT 点鼠标。MAT 自带命令行脚本可以在纯文本环境下对堆转储执行固定分析模块并输出 HTML 报告。这对定时分析、批量分析很有用也是我希望你尽早掌握的用法。# 进入 MAT 安装目录后调用 ParseHeapDump 脚本 # 注意脚本名为 ParseHeapDump.shWindows 下为 ParseHeapDump.bat ./ParseHeapDump.sh /data/logs/heapdump/app.hprof \ org.eclipse.mat.api:overview \ org.eclipse.mat.api:suspects \ org.eclipse.mat.api:histogram \ -report /data/logs/heapdump/report参数含义拆开讲第一个位置参数是被分析的堆转储文件路径后面跟多个分析模块键org.eclipse.mat.api:overview生成概览报告org.eclipse.mat.api:suspects生成泄漏疑点报告org.eclipse.mat.api:histogram生成直方图报告-report指定输出目录不写则默认输出到当前目录下的report文件夹。这条命令跑完后你会在输出目录里看到一组 HTML 文件内容和图形界面里点出来的报告基本一致。优点是不会被 GUI 卡住也方便写进定时脚本比如凌晨自动分析前一天抓取的转储白天到公司直接看报告就能定位问题。需要提醒的是命令行解析同样消耗内存使用前一样要按 4.1 节调大 MAT 的堆配置它读的是同一个MemoryAnalyzer.ini。4.3 转储文件过大时的处理策略压缩与分片转储文件经常比想象中大一次线上 Full GC 问题产生的转储可能达数 GB。压缩成.gz后通常能缩到原来的 1/5 到 1/3MAT 打开压缩文件时会自动解压不占额外磁盘。手动抓取时可以先压缩再拷贝# 对堆转储进行 gzip 压缩MAT 可以直接打开 gzip /data/logs/heapdump/app.hprof # 压缩后确认文件大小 ls -lh /data/logs/heapdump/app.hprof.gz如果压缩后仍然超出本机内存承载范围我会换一个思路不做全量转储只在怀疑的业务路径上做内存抽样。比如直接抓取疑似泄漏模块所在 JVM 的直方图或者用jcmd pid GC.class_histogram先看实例数分布再用 MAT 针对性分析小范围转储。这样虽然损失了一部分现场细节但在本地资源有限时比硬撑着解析一个超大文件更实际。5. 常见问题与避坑MAT 分析中的翻车现场与自查清单5.1 分析过程中 MAT 自身堆溢出报错后无法继续现象点击分析模块后进度条走一半弹窗提示OutOfMemoryError或Java heap space有时界面直接无响应。原因几乎都是MemoryAnalyzer.ini里的-Xmx低于转储文件的实际解析需求MAT 构建对象索引时内存不够。解决方法是先关掉 MAT按第 4 章调大-Xmx重启再试。如果已经调到机器内存上限还不够就改用命令行ParseHeapDump配合-vmargs -Xmx参数执行把多余的请求关掉也能降低内存压力。5.2 Leak Suspects 报出的对象像误报每个都指向缓存或线程池现象报告里列出的可疑点全是java.lang.Thread、ConcurrentHashMap、Object[]这种基础对象看不出业务代码的影子。原因在于 MAT 的泄漏疑点是纯自动化判定它找出的是“支配了最大保留堆”的对象而全局缓存和线程池天然就是大块内存并不一定是业务泄漏。解决时不要只看报告结论要顺着Shortest Paths To the Accumulation Point往下追找到路径上第一个业务类对象确认它在代码里被谁赋值、被谁长期持有。如果路径一直不经过业务类基本可以排除泄漏属于正常资源池。5.3 直方图里保留堆合计远大于堆大小数字对不上现象把直方图中所有类的 Retained Heap 加总数值超过文件标注的 total heap甚至多出好几倍。原因是保留堆的计算口径是“该对象若回收能释放多少”而多个对象的保留集合相互重叠不能简单相加。这不是工具 bug而是理解偏差。深度使用中只需要记住单看一个对象的保留堆是可比的跨对象相加没有意义。想看全局分配以 Overview 里的 total heap 为准。5.4 手动抓取用了 live 参数导致泄漏线索消失现象某开发者用jmap -dump:live,formatb,fileheap.hprof pid抓取转储分析时却发现大量本应在堆里的对象不存在。原因是live参数会让 JVM 先做一次 Full GC只导出存活对象那些已经被 GC 标记可回收、但还没来得及清理的对象全部被过滤掉。很多时候内存泄漏恰恰隐藏在这些“看似可回收却因引用链问题回收不掉”的对象里。解决方法是手动抓取时不加live抓完整堆转储如果担心停顿时间长优先采用 3.2 节提到的 jcmd 方式它同样不触发 Full GC。5.5 打开 hprof 时提示文件损坏或版本不支持现象MAT 打开文件时报Invalid file或Unsupported version。原因可能有三类一是转储过程中磁盘空间不足文件被截断二是文件未完全写入就被复制比如 JVM 还在写转储时脚本就开始拉文件三是使用的 JDK 版本较新生成的 hprof 版本超出了当前 MAT 版本的兼容范围。解决时先看转储文件大小是否异常偏小若明显小于堆配置多数是磁盘不足重新抓取并在写完后检查日志行Heap dump file created再拷贝。若怀疑版本问题升级到最新版 MAT或者用 JDK 自带的jhat试开确认是不是 MAT 版本过旧。6. 进阶技巧用 OQL 与双快照差分把泄漏点钉死到这一步工具操作已经不是问题瓶颈在于怎么从成百上千个类里准确锁定真正的业务泄漏。这里分享两个我长期在用的手段。第一个是 OQL。MAT 的 OQL 语法类似 SQL可以直接查询特定类型的对象并过滤。比如想知道堆里哪个字符串最大可以执行SELECT toString(s) AS value, s.retainedHeapSize AS retained FROM INSTANCEOF java.lang.String s ORDER BY retained DESC LIMIT 20retainedHeapSize是 MAT 特有的保留堆求值函数INSTANCEOF会覆盖所有子类。这种查询的价值在于直方图只能看到类级别OQL 可以下探到具体对象。排查泄漏时我通常先用直方图锁定可疑类再用 OQL 找出该类下保留堆最大的几十个实例看它们的字段值是否集中在某个业务维度比如用户 ID、订单号、租户标识。如果这些值清一色来自某个集合的 key那就不是简单的对象泄露而是某个 Map 在无脑增长。第二个是双快照差分法。内存泄漏往往不是一个对象占用巨大而是大量对象缓慢累积。单看一次转储很难区分“正常水位”和“异常水位”比较稳妥的做法是间隔一段时间连抓两次比如在业务低峰期抓第一次四小时后再抓第二次然后把两次转储都导入 MAT在直方图中点右键Add to Comparison Basket用比较篮查看两类实例数量与保留堆的增量。增量最大的类就是泄漏嫌疑最大的一批对象。# 第一次抓取业务稳定期 jcmd pid GC.heap_dump /data/logs/heapdump/app_t1.hprof # 等待 4 小时业务运行后第二次抓取 jcmd pid GC.heap_dump /data/logs/heapdump/app_t2.hprof配合这套流程我排解过很多次看起来毫无规律的 OOM第一次转储里疑似泄漏的类并不显眼但差分后增量在全堆里排名第一顺着增长路径追到源头发现是某个本地缓存缺少淘汰策略key 随时间无限增长。这种问题如果当初只分析单次转储很容易被误判成缓存正常扩容。整个 Eclipse MAT 使用链路的核心其实很简单让 JVM 在崩溃时留下现场用 MAT 把现场翻译成对象关系最后用支配链或差分数据把范围缩到业务代码的某一行。工具本身不玄学难的是养成“先留堆转储、再改代码”的习惯。我见过太多人 OOM 后第一反应是翻日志猜代码等白白改完一轮才发现没有现场数据只能凭感觉加内存参数。现在我的习惯很朴素每次部署都带上转储开关每次疑似泄漏都先抓转储再动手复盘时少了很多折腾。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
