简介本资源为Eclipse Memory Analyzer ToolMAT内存分析工具的完整Windows可执行版本面向Java开发者、性能调优工程师及JVM故障排查人员专用于诊断Java应用内存泄漏、分析堆转储heap dump并定位高内存占用对象。资源包含5442个文件主体为3758个HTML帮助文档与界面资源、422个PNG图标、355个JAR插件库、247个GIF动画及109个XML配置文件辅以INI、BAT、EXE等启动与配置文件整体压缩包达133.56MB结构完整开箱即用。目前已有371人学习下载。用户可直接运行MemoryAnalyzer.exe或通过ParseHeapDump.bat加载.hprof快照获得Leak Suspects报告、支配树、直方图、引用链等核心分析能力预览内容显示其内置org.eclipse.mat.ui.rcp模块及多版本框架信息表明该包已集成RCP桌面环境与全功能UI组件无需额外安装Eclipse IDE即可独立运行。1. Eclipse MAT 不是内存快照“看图工具”它是能定位 GC Roots 泄漏链、反向追踪对象引用、精准定位百万级对象归属模块的 Java 堆分析黑匣子你手头有一份 2.3GB 的heap_dump.hprof用 VisualVM 打开卡死、JProfiler 加载超时、IDEA 自带分析器报 OOM——这时候别急着重启机器Eclipse Memory AnalyzerMAT才是专为这种“大而重”的生产级堆转储设计的分析引擎。它不依赖 JVM 运行时纯离线解析二进制 hprof 文件它能把一个HashMap$Node实例沿着ThreadLocalMap → Thread → ThreadGroup → ClassLoader → Class → static field一路向上追溯到泄漏源头的静态持有者它还能用 OQLObject Query Language写类似 SQL 的查询语句比如SELECT * FROM java.util.ArrayList WHERE length 10000快速筛出异常集合。这不是给新手练手的玩具而是某金融系统线上 Full GC 频发后A同学靠 MAT 的Dominator Tree Path to GC Roots组合在 17 分钟内锁定第三方 SDK 中未关闭的ScheduledExecutorService持有大量Runnable导致内存泄漏的真实战场。适合正在处理线上 OOM、GC 日志异常、堆 dump 分析卡顿、或需要从海量对象中逆向定位模块责任边界的 Java 后端、中间件、SRE 工程师。2. 从零加载一份真实堆转储MAT 安装、内存配置与 hprof 文件预检三步闭环2.1 下载与环境适配为什么必须用独立 MAT 而非 Eclipse 插件版MAT 提供两种形态独立桌面应用Standalone和 Eclipse IDE 插件。生产环境强烈推荐使用 Standalone 版本。原因很实际插件版共享 Eclipse JVM 内存当分析 1GB 堆文件时Eclipse 本身极易因-Xmx不足而崩溃而 Standalone 版本可独立配置 JVM 参数且启动轻量、无 IDE 插件冲突风险。截至当前最新稳定版为 MAT 1.14.0基于 Eclipse 2023-09 平台支持 JDK 11–21。注意MAT 本身是 Java 应用但不要用 JDK 21 运行 MAT 来分析 JDK 8 的 hprof——hprof 格式存在版本兼容性MAT 1.14.0 官方明确支持分析 JDK 7–20 生成的堆转储JDK 21 的新格式需等待后续版本。下载地址统一为 Eclipse 官方归档页https://www.eclipse.org/mat/downloads.php选择MemoryAnalyzer-1.14.0-linux.gtk.x86_64.zipLinux、...win32.win32.x86_64.zipWindows或...macosx.cocoa.x86_64.tar.gzmacOS。解压即用无需安装。2.2 关键一步修改 MAT.ini 强制分配足够堆内存MAT 默认启动参数极保守通常-Xmx1024m面对真实生产堆转储必然失败。必须手动编辑解压目录下的MemoryAnalyzer.ini文件Windows 为mat.ini。重点修改两处--launcher.appendVmargs -vmargs -Xms4g -Xmx12g -XX:UseG1GC -XX:MaxMetaspaceSize512m -Dorg.eclipse.mat.parser.index_path/tmp/mat_index说明-Xms4g和-Xmx12g是核心建议设为物理内存的 40%~60%且-Xmx至少为 hprof 文件大小的 3 倍例如 2.3GB hprof-Xmx至少 7g-Dorg.eclipse.mat.parser.index_path指定索引临时目录务必指向空间充足、IO 性能好的磁盘如 SSD 挂载点/data/mat_tmp避免默认/tmp空间不足或为内存盘导致解析失败-XX:UseG1GC显式启用 G1 垃圾回收器对大堆解析更稳定。2.3 hprof 文件预检三招快速判断是否可被 MAT 正常加载不是所有.hprof都能直接打开。在双击启动 MAT 前先执行以下检查文件完整性校验用file heap_dump.hprof查看文件头。正常 hprof 文件应输出类似Java Heap Dump (binary) data。若显示data或cannot open说明文件损坏或传输不完整常见于 FTP 二进制模式未开启、SCP 中断。格式版本确认用head -c 32 heap_dump.hprof | hexdump -C查看前 32 字节。标准 hprof 头部第 21–24 字节为格式版本号如00 00 00 1b表示 JDK 1.6 格式。MAT 1.14.0 支持0x0000001bJDK 6至0x00000024JDK 20。若出现00 00 00 25JDK 21则需降级 JDK 版本重新 dump 或等待 MAT 更新。最小化验证用jhat -J-Xmx2g heap_dump.hprofJDK 自带工具尝试启动。若jhat能成功解析并输出Reading from heap_dump.hprof...及对象统计则 MAT 加载成功率超 95%若jhat报Unrecognized magic numberMAT 必然失败。3. 三大核心视图实战Dominator Tree 定位最大内存持有者、Histogram 筛选异常类实例、Leak Suspects 自动生成报告3.1 Dominator Tree找到“谁占了最多内存”的树形真相Dominator Tree支配树是 MAT 最锋利的刀。它不按类分组而是按对象间的支配关系构建树若从 GC Roots 到对象 A 的每条路径都必须经过对象 B则 B 支配 A。根节点是 GC Roots叶子节点是被支配最深的对象。打开方式File → Open Heap Dump → 选择 hprof → Finish → 等待解析完成 → 右上角下拉菜单选 Dominator Tree。关键操作排序点击Retained Heap列降序顶部即内存“罪魁祸首”。例如某次分析中org.apache.catalina.loader.WebappClassLoader占用Retained Heap 1.2GB远超其他类立刻锁定为 ClassLoader 泄漏。展开支配链双击该 ClassLoader 行右侧自动展开其支配的所有对象。继续双击java.util.HashMap再双击其中某个Entry最终定位到static final MapString, Object中缓存了 50 万条未过期的 session 数据。对比差异若有多份 dump如 GC 前后用File → Compare With → Another Heap DumpDominator Tree 会高亮新增/增长的支配节点比肉眼扫 Histogram 高效十倍。3.2 Histogram用类名、包名、正则快速筛选百万级实例Histogram直方图是“数数”视图列出每个类的实例数量、Shallow Heap自身占用、Retained Heap自身所有被支配对象总和。打开方式Navigation → Histogram。高效筛选技巧按包名过滤在右上角Class Name输入框输入com.xxx.service.*回车立即聚焦业务代码包下的所有类实例。按正则匹配勾选Regex输入java\.util\..*Map可一次性列出HashMap、ConcurrentHashMap、LinkedHashMap所有实例及内存占比。导出可疑类详情右键某行如byte[]选List objects → with incoming references得到所有持有该byte[]的对象列表进而发现是org.springframework.web.multipart.commons.CommonsMultipartFile的bytes字段未清理。参数说明Shallow Heap是对象头字段占用如String对象本身约 24 字节Retained Heap才是真实泄漏代价如String持有的char[]数组。排查泄漏永远以Retained Heap为第一指标。3.3 Leak Suspects自动生成报告但必须人工交叉验证Reports → Leak Suspects是 MAT 的“一键诊断”功能。它基于启发式规则扫描检查是否存在java.lang.Thread持有大量对象检查java.util.concurrent线程池队列是否堆积检查java.lang.ClassLoader是否被意外强引用检查java.util.Map的 value 是否为大对象且 key 未释放。生成的 HTML 报告会标红 Top 3 泄漏嫌疑并给出Path to GC Roots截图。但切记这是线索不是结论。某次报告指出com.xxx.cache.CacheManager是泄漏源但深入Path to GC Roots发现其static cacheMap被org.quartz.core.QuartzSchedulerThread的ThreadLocal持有——真正问题在 Quartz 未正确 shutdown而非 CacheManager 本身。所以Leak Suspects 报告后必须手动进入Path to GC Roots视图逐层点击exclude weak/soft/phantom references确认强引用链真实存在。4. 避坑指南五类高频翻车现场与血泪经验总结4.1 现象MAT 启动后白屏/无响应日志报OutOfMemoryError: Java heap space原因MemoryAnalyzer.ini中-Xmx设置过小或未生效如 Windows 下误改了mat.exe.config而非mat.ini或系统/tmp目录空间不足MAT 默认在此建索引。解决用ps aux | grep mat确认 JVM 参数是否包含设置的-Xmx在MemoryAnalyzer.ini顶部添加-vm参数显式指定 JDK 路径如-vm /usr/lib/jvm/java-11-openjdk-amd64/bin避免 MAT 自动找错 JDK将-Dorg.eclipse.mat.parser.index_path改为绝对路径且确保磁盘剩余空间 hprof 文件大小 × 2。4.2 现象打开 hprof 后提示The heap dump contains errors and may be incomplete但部分视图可打开原因hprof 文件在生成过程中被截断如jmap -dump:formatb,fileheap.hprof pid执行时进程被 kill或使用了-XX:HeapDumpBeforeFullGC但 Full GC 未真正触发。解决用jmap -histo:live pid先确认进程是否存活且能响应重新生成 dump优先用jcmd pid VM.native_memory summary scaleMB辅助判断内存压力再执行jmap -dump:formatb,live,fileheap_full.hprof pid加live参数强制 GC 后 dump若只能用损坏文件尝试 MAT 的File → Import → IBM Heap Dump (.phd)导入PHD 格式容错性略高或用jhat解析后导出 JSON 再人工分析。4.3 现象Dominator Tree 中某对象 Retained Heap 为 0但 Histogram 显示其 Shallow Heap 很大原因该对象被多个 GC Root 强引用MAT 计算 Retained Heap 时只计入“唯一支配者”所持有的部分。若一个byte[]同时被ThreadLocal和static field引用其 Retained Heap 可能为 0因无单一支配者但 Shallow Heap 仍反映真实字节数。解决改用Histogram → 右键 byte[] → List objects → with outgoing references查看哪些对象引用了它或直接用 OQL 查询SELECT s FROM java.lang.String s WHERE s.value.retainedHeap 1000000绕过支配树逻辑。4.4 现象Leak Suspects 报告中Path to GC Roots显示ThreadLocal但点开后全是java.lang.ref.*弱引用原因MAT 默认显示所有引用类型而ThreadLocal的threadLocals字段实际是ThreadLocalMap其Entry继承WeakReferencekey 是弱引用value 是强引用。报告中的“弱引用”是 key真正泄漏的是 value。解决在Path to GC Roots视图右上角取消勾选Weak Reference仅保留Strong Reference和Soft Reference重点观察ThreadLocalMap$Entry.value字段指向的对象这才是泄漏主体。4.5 现象OQL 查询SELECT * FROM java.util.ArrayList返回空但 Histogram 明确显示有 2 万个实例原因OQL 默认只查询“可达对象”reachable而某些 ArrayList 可能处于 finalize 队列或已标记为待回收MAT 解析时将其归类为不可达。解决在 OQL 编辑框左下角勾选Include unreachable objects或改用更鲁棒的查询SELECT * FROM OBJECTS java.util.ArrayListOBJECTS关键字强制包含所有实例无论可达性。5. 进阶技巧用 OQL 写定制化内存审计脚本、批量导出对象到 CSV、与 GC 日志交叉验证5.1 OQL 实战三行代码揪出“缓存雪崩”元凶某次线上事故中GC 日志显示ParNew耗时突增 300%但 Histogram 未见明显异常类。此时需用 OQL 挖掘隐藏模式。目标找出所有ConcurrentHashMap中 size 10000 且loadFactor为默认 0.75 的实例暗示未预估容量导致频繁扩容。SELECT c, c.size AS size, c.loadFactor AS loadFactor, c.table.length AS tableLength FROM java.util.concurrent.ConcurrentHashMap c WHERE c.size 10000 AND c.loadFactor 0.75执行后得到 7 个结果双击任一结果在Properties视图中查看outgoingReferences发现全部被com.xxx.cache.LocalCache的cacheMap静态字段持有。进一步用Path to GC Roots确认该LocalCache类被Spring Context的static ApplicationContext引用——根源是 Spring Bean 作用域配置错误将本该prototype的缓存管理器声明为singleton。OQL 关键语法length获取数组长度retainedHeap获取保留堆大小outgoingReferences查看该对象引用了谁incomingReferences查看谁引用了它。所有字段名均区分大小写且必须存在MAT 不会自动补全不存在字段。5.2 批量导出把可疑对象列表导出为 CSV 供 Excel 分析当 Histogram 筛出 5000 个com.xxx.model.User实例需导出其id、createTime、status字段做分布分析时手工点开每个对象不现实。MAT 支持 OQL 结果导出执行 OQLSELECT u.id, u.createTime, u.status FROM com.xxx.model.User u结果列表右键 →Export Query Result...选择CSV格式勾选Include column headers指定保存路径。生成的 CSV 可直接用 Excel 打开用数据透视表统计status分布或用条件格式标出createTime超过 30 天的“僵尸用户”从而判断是否缓存未及时失效。5.3 GC 日志交叉验证用时间戳锁死泄漏发生窗口单看一份 dump 只能知道“现在谁占得多”但无法确定“什么时候开始涨”。必须结合 GC 日志定位时间点。假设 GC 日志中2024-05-20T14:22:18.1230800发生了一次耗时 8.2 秒的 Full GC且之后老年代使用率未回落用jstat -gc -h10 pid 1000实时监控确认该时间点前后老年代OUOld Used持续上升在此时间点附近如 ±5 分钟用jmap -dump:formatb,fileheap_before.hprof pid和heap_after.hprof各 dump 一次在 MAT 中Compare With → Another Heap Dump切换到Dominator Tree按Retained Heap排序重点关注Delta列为正且数值巨大的类——这些就是泄漏发生期间新增的内存大户。关键细节jmapdump 会触发 Full GC因此heap_before.hprof实际是 GC 后状态。更严谨的做法是用jcmd pid VM.native_memory detail在 GC 前后各执行一次对比Internal和Mapped区域变化再结合 MAT 分析堆内对象。从那以后我每次接到 OOM 报警第一反应不再是jmap而是先jstat -gc pid 1000看 GC 频率再jcmd pid VM.native_memory summary快速摸底最后才决定是否 dump。因为 80% 的“内存泄漏”其实是DirectByteBuffer的MappedByteBuffer未释放或Inflater/Deflater本地内存泄漏这些根本不在堆里MAT 也看不到——MAT 只是堆分析的终点不是内存问题的起点。希望帮到你。本文还有配套的精品资源点击获取
简介本资源为Eclipse Memory Analyzer ToolMAT内存分析工具的完整Windows可执行版本面向Java开发者、性能调优工程师及JVM故障排查人员专用于诊断Java应用内存泄漏、分析堆转储heap dump并定位高内存占用对象。资源包含5442个文件主体为3758个HTML帮助文档与界面资源、422个PNG图标、355个JAR插件库、247个GIF动画及109个XML配置文件辅以INI、BAT、EXE等启动与配置文件整体压缩包达133.56MB结构完整开箱即用。目前已有371人学习下载。用户可直接运行MemoryAnalyzer.exe或通过ParseHeapDump.bat加载.hprof快照获得Leak Suspects报告、支配树、直方图、引用链等核心分析能力预览内容显示其内置org.eclipse.mat.ui.rcp模块及多版本框架信息表明该包已集成RCP桌面环境与全功能UI组件无需额外安装Eclipse IDE即可独立运行。1. Eclipse MAT 不是内存快照“看图工具”它是能定位 GC Roots 泄漏链、反向追踪对象引用、精准定位百万级对象归属模块的 Java 堆分析黑匣子你手头有一份 2.3GB 的heap_dump.hprof用 VisualVM 打开卡死、JProfiler 加载超时、IDEA 自带分析器报 OOM——这时候别急着重启机器Eclipse Memory AnalyzerMAT才是专为这种“大而重”的生产级堆转储设计的分析引擎。它不依赖 JVM 运行时纯离线解析二进制 hprof 文件它能把一个HashMap$Node实例沿着ThreadLocalMap → Thread → ThreadGroup → ClassLoader → Class → static field一路向上追溯到泄漏源头的静态持有者它还能用 OQLObject Query Language写类似 SQL 的查询语句比如SELECT * FROM java.util.ArrayList WHERE length 10000快速筛出异常集合。这不是给新手练手的玩具而是某金融系统线上 Full GC 频发后A同学靠 MAT 的Dominator Tree Path to GC Roots组合在 17 分钟内锁定第三方 SDK 中未关闭的ScheduledExecutorService持有大量Runnable导致内存泄漏的真实战场。适合正在处理线上 OOM、GC 日志异常、堆 dump 分析卡顿、或需要从海量对象中逆向定位模块责任边界的 Java 后端、中间件、SRE 工程师。2. 从零加载一份真实堆转储MAT 安装、内存配置与 hprof 文件预检三步闭环2.1 下载与环境适配为什么必须用独立 MAT 而非 Eclipse 插件版MAT 提供两种形态独立桌面应用Standalone和 Eclipse IDE 插件。生产环境强烈推荐使用 Standalone 版本。原因很实际插件版共享 Eclipse JVM 内存当分析 1GB 堆文件时Eclipse 本身极易因-Xmx不足而崩溃而 Standalone 版本可独立配置 JVM 参数且启动轻量、无 IDE 插件冲突风险。截至当前最新稳定版为 MAT 1.14.0基于 Eclipse 2023-09 平台支持 JDK 11–21。注意MAT 本身是 Java 应用但不要用 JDK 21 运行 MAT 来分析 JDK 8 的 hprof——hprof 格式存在版本兼容性MAT 1.14.0 官方明确支持分析 JDK 7–20 生成的堆转储JDK 21 的新格式需等待后续版本。下载地址统一为 Eclipse 官方归档页https://www.eclipse.org/mat/downloads.php选择MemoryAnalyzer-1.14.0-linux.gtk.x86_64.zipLinux、...win32.win32.x86_64.zipWindows或...macosx.cocoa.x86_64.tar.gzmacOS。解压即用无需安装。2.2 关键一步修改 MAT.ini 强制分配足够堆内存MAT 默认启动参数极保守通常-Xmx1024m面对真实生产堆转储必然失败。必须手动编辑解压目录下的MemoryAnalyzer.ini文件Windows 为mat.ini。重点修改两处--launcher.appendVmargs -vmargs -Xms4g -Xmx12g -XX:UseG1GC -XX:MaxMetaspaceSize512m -Dorg.eclipse.mat.parser.index_path/tmp/mat_index说明-Xms4g和-Xmx12g是核心建议设为物理内存的 40%~60%且-Xmx至少为 hprof 文件大小的 3 倍例如 2.3GB hprof-Xmx至少 7g-Dorg.eclipse.mat.parser.index_path指定索引临时目录务必指向空间充足、IO 性能好的磁盘如 SSD 挂载点/data/mat_tmp避免默认/tmp空间不足或为内存盘导致解析失败-XX:UseG1GC显式启用 G1 垃圾回收器对大堆解析更稳定。2.3 hprof 文件预检三招快速判断是否可被 MAT 正常加载不是所有.hprof都能直接打开。在双击启动 MAT 前先执行以下检查文件完整性校验用file heap_dump.hprof查看文件头。正常 hprof 文件应输出类似Java Heap Dump (binary) data。若显示data或cannot open说明文件损坏或传输不完整常见于 FTP 二进制模式未开启、SCP 中断。格式版本确认用head -c 32 heap_dump.hprof | hexdump -C查看前 32 字节。标准 hprof 头部第 21–24 字节为格式版本号如00 00 00 1b表示 JDK 1.6 格式。MAT 1.14.0 支持0x0000001bJDK 6至0x00000024JDK 20。若出现00 00 00 25JDK 21则需降级 JDK 版本重新 dump 或等待 MAT 更新。最小化验证用jhat -J-Xmx2g heap_dump.hprofJDK 自带工具尝试启动。若jhat能成功解析并输出Reading from heap_dump.hprof...及对象统计则 MAT 加载成功率超 95%若jhat报Unrecognized magic numberMAT 必然失败。3. 三大核心视图实战Dominator Tree 定位最大内存持有者、Histogram 筛选异常类实例、Leak Suspects 自动生成报告3.1 Dominator Tree找到“谁占了最多内存”的树形真相Dominator Tree支配树是 MAT 最锋利的刀。它不按类分组而是按对象间的支配关系构建树若从 GC Roots 到对象 A 的每条路径都必须经过对象 B则 B 支配 A。根节点是 GC Roots叶子节点是被支配最深的对象。打开方式File → Open Heap Dump → 选择 hprof → Finish → 等待解析完成 → 右上角下拉菜单选 Dominator Tree。关键操作排序点击Retained Heap列降序顶部即内存“罪魁祸首”。例如某次分析中org.apache.catalina.loader.WebappClassLoader占用Retained Heap 1.2GB远超其他类立刻锁定为 ClassLoader 泄漏。展开支配链双击该 ClassLoader 行右侧自动展开其支配的所有对象。继续双击java.util.HashMap再双击其中某个Entry最终定位到static final MapString, Object中缓存了 50 万条未过期的 session 数据。对比差异若有多份 dump如 GC 前后用File → Compare With → Another Heap DumpDominator Tree 会高亮新增/增长的支配节点比肉眼扫 Histogram 高效十倍。3.2 Histogram用类名、包名、正则快速筛选百万级实例Histogram直方图是“数数”视图列出每个类的实例数量、Shallow Heap自身占用、Retained Heap自身所有被支配对象总和。打开方式Navigation → Histogram。高效筛选技巧按包名过滤在右上角Class Name输入框输入com.xxx.service.*回车立即聚焦业务代码包下的所有类实例。按正则匹配勾选Regex输入java\.util\..*Map可一次性列出HashMap、ConcurrentHashMap、LinkedHashMap所有实例及内存占比。导出可疑类详情右键某行如byte[]选List objects → with incoming references得到所有持有该byte[]的对象列表进而发现是org.springframework.web.multipart.commons.CommonsMultipartFile的bytes字段未清理。参数说明Shallow Heap是对象头字段占用如String对象本身约 24 字节Retained Heap才是真实泄漏代价如String持有的char[]数组。排查泄漏永远以Retained Heap为第一指标。3.3 Leak Suspects自动生成报告但必须人工交叉验证Reports → Leak Suspects是 MAT 的“一键诊断”功能。它基于启发式规则扫描检查是否存在java.lang.Thread持有大量对象检查java.util.concurrent线程池队列是否堆积检查java.lang.ClassLoader是否被意外强引用检查java.util.Map的 value 是否为大对象且 key 未释放。生成的 HTML 报告会标红 Top 3 泄漏嫌疑并给出Path to GC Roots截图。但切记这是线索不是结论。某次报告指出com.xxx.cache.CacheManager是泄漏源但深入Path to GC Roots发现其static cacheMap被org.quartz.core.QuartzSchedulerThread的ThreadLocal持有——真正问题在 Quartz 未正确 shutdown而非 CacheManager 本身。所以Leak Suspects 报告后必须手动进入Path to GC Roots视图逐层点击exclude weak/soft/phantom references确认强引用链真实存在。4. 避坑指南五类高频翻车现场与血泪经验总结4.1 现象MAT 启动后白屏/无响应日志报OutOfMemoryError: Java heap space原因MemoryAnalyzer.ini中-Xmx设置过小或未生效如 Windows 下误改了mat.exe.config而非mat.ini或系统/tmp目录空间不足MAT 默认在此建索引。解决用ps aux | grep mat确认 JVM 参数是否包含设置的-Xmx在MemoryAnalyzer.ini顶部添加-vm参数显式指定 JDK 路径如-vm /usr/lib/jvm/java-11-openjdk-amd64/bin避免 MAT 自动找错 JDK将-Dorg.eclipse.mat.parser.index_path改为绝对路径且确保磁盘剩余空间 hprof 文件大小 × 2。4.2 现象打开 hprof 后提示The heap dump contains errors and may be incomplete但部分视图可打开原因hprof 文件在生成过程中被截断如jmap -dump:formatb,fileheap.hprof pid执行时进程被 kill或使用了-XX:HeapDumpBeforeFullGC但 Full GC 未真正触发。解决用jmap -histo:live pid先确认进程是否存活且能响应重新生成 dump优先用jcmd pid VM.native_memory summary scaleMB辅助判断内存压力再执行jmap -dump:formatb,live,fileheap_full.hprof pid加live参数强制 GC 后 dump若只能用损坏文件尝试 MAT 的File → Import → IBM Heap Dump (.phd)导入PHD 格式容错性略高或用jhat解析后导出 JSON 再人工分析。4.3 现象Dominator Tree 中某对象 Retained Heap 为 0但 Histogram 显示其 Shallow Heap 很大原因该对象被多个 GC Root 强引用MAT 计算 Retained Heap 时只计入“唯一支配者”所持有的部分。若一个byte[]同时被ThreadLocal和static field引用其 Retained Heap 可能为 0因无单一支配者但 Shallow Heap 仍反映真实字节数。解决改用Histogram → 右键 byte[] → List objects → with outgoing references查看哪些对象引用了它或直接用 OQL 查询SELECT s FROM java.lang.String s WHERE s.value.retainedHeap 1000000绕过支配树逻辑。4.4 现象Leak Suspects 报告中Path to GC Roots显示ThreadLocal但点开后全是java.lang.ref.*弱引用原因MAT 默认显示所有引用类型而ThreadLocal的threadLocals字段实际是ThreadLocalMap其Entry继承WeakReferencekey 是弱引用value 是强引用。报告中的“弱引用”是 key真正泄漏的是 value。解决在Path to GC Roots视图右上角取消勾选Weak Reference仅保留Strong Reference和Soft Reference重点观察ThreadLocalMap$Entry.value字段指向的对象这才是泄漏主体。4.5 现象OQL 查询SELECT * FROM java.util.ArrayList返回空但 Histogram 明确显示有 2 万个实例原因OQL 默认只查询“可达对象”reachable而某些 ArrayList 可能处于 finalize 队列或已标记为待回收MAT 解析时将其归类为不可达。解决在 OQL 编辑框左下角勾选Include unreachable objects或改用更鲁棒的查询SELECT * FROM OBJECTS java.util.ArrayListOBJECTS关键字强制包含所有实例无论可达性。5. 进阶技巧用 OQL 写定制化内存审计脚本、批量导出对象到 CSV、与 GC 日志交叉验证5.1 OQL 实战三行代码揪出“缓存雪崩”元凶某次线上事故中GC 日志显示ParNew耗时突增 300%但 Histogram 未见明显异常类。此时需用 OQL 挖掘隐藏模式。目标找出所有ConcurrentHashMap中 size 10000 且loadFactor为默认 0.75 的实例暗示未预估容量导致频繁扩容。SELECT c, c.size AS size, c.loadFactor AS loadFactor, c.table.length AS tableLength FROM java.util.concurrent.ConcurrentHashMap c WHERE c.size 10000 AND c.loadFactor 0.75执行后得到 7 个结果双击任一结果在Properties视图中查看outgoingReferences发现全部被com.xxx.cache.LocalCache的cacheMap静态字段持有。进一步用Path to GC Roots确认该LocalCache类被Spring Context的static ApplicationContext引用——根源是 Spring Bean 作用域配置错误将本该prototype的缓存管理器声明为singleton。OQL 关键语法length获取数组长度retainedHeap获取保留堆大小outgoingReferences查看该对象引用了谁incomingReferences查看谁引用了它。所有字段名均区分大小写且必须存在MAT 不会自动补全不存在字段。5.2 批量导出把可疑对象列表导出为 CSV 供 Excel 分析当 Histogram 筛出 5000 个com.xxx.model.User实例需导出其id、createTime、status字段做分布分析时手工点开每个对象不现实。MAT 支持 OQL 结果导出执行 OQLSELECT u.id, u.createTime, u.status FROM com.xxx.model.User u结果列表右键 →Export Query Result...选择CSV格式勾选Include column headers指定保存路径。生成的 CSV 可直接用 Excel 打开用数据透视表统计status分布或用条件格式标出createTime超过 30 天的“僵尸用户”从而判断是否缓存未及时失效。5.3 GC 日志交叉验证用时间戳锁死泄漏发生窗口单看一份 dump 只能知道“现在谁占得多”但无法确定“什么时候开始涨”。必须结合 GC 日志定位时间点。假设 GC 日志中2024-05-20T14:22:18.1230800发生了一次耗时 8.2 秒的 Full GC且之后老年代使用率未回落用jstat -gc -h10 pid 1000实时监控确认该时间点前后老年代OUOld Used持续上升在此时间点附近如 ±5 分钟用jmap -dump:formatb,fileheap_before.hprof pid和heap_after.hprof各 dump 一次在 MAT 中Compare With → Another Heap Dump切换到Dominator Tree按Retained Heap排序重点关注Delta列为正且数值巨大的类——这些就是泄漏发生期间新增的内存大户。关键细节jmapdump 会触发 Full GC因此heap_before.hprof实际是 GC 后状态。更严谨的做法是用jcmd pid VM.native_memory detail在 GC 前后各执行一次对比Internal和Mapped区域变化再结合 MAT 分析堆内对象。从那以后我每次接到 OOM 报警第一反应不再是jmap而是先jstat -gc pid 1000看 GC 频率再jcmd pid VM.native_memory summary快速摸底最后才决定是否 dump。因为 80% 的“内存泄漏”其实是DirectByteBuffer的MappedByteBuffer未释放或Inflater/Deflater本地内存泄漏这些根本不在堆里MAT 也看不到——MAT 只是堆分析的终点不是内存问题的起点。希望帮到你。本文还有配套的精品资源点击获取
 与 data-* 自定义属性)
