简介这是一款可离线使用的MATMemory Analyzer Tool完整发行包面向Java开发者、运维与性能优化人员用于解析JVM导出的hprof堆转储文件定位内存泄漏、排查内存占用过高及分析对象引用关系。资源共2000个文件包含183个jar运行库、1891个html帮助文档、217个png图表及大量css/js/xml配置与说明文件整体约75.44MB覆盖Eclipse MAT在各平台运行所需的组件和文档体系。已有6612人学习下载。使用时可借助支配树、泄漏嫌疑人报告、浅堆/保留堆对比以及OQL自定义查询等功能快速梳理堆内存中的对象分配与关联关系配套的说明文档与示例图表能帮助初学者理解关键视图也能让有经验的工程师直接对照分析是一套较为完整的Java内存分析工具包。1. 用MAT打开hprof先搞清楚这份堆快照到底告诉了你什么线上Java服务又OOM了这次运气好JVM在崩溃前把整个堆dump成了一个hprof文件。接手的人第一反应往往是这文件这么大从哪儿看起如果手里只有jhat或者jmap -histo的输出你大概率只能看到一串类名和数字看不出谁在拽着内存不放。MATEclipse Memory Analyzer就是专门干这个的它能把几十万条对象记录按占用内存排序、沿着引用链找出谁在强引用这个对象还能直接算出“如果把这个对象干掉能释放多少MB”。这份资源就是围绕MAT分析hprof文件的完整操作流程适合后端开发和Android端的同学尤其是手里攥着hprof却不知道下一步该点哪儿的场景。2. 为什么是MAThprof文件的分析原理与选型理由2.1 hprof到底记录了什么堆转储文件的结构与两种格式hprof不是一个神秘的加密文件它就是JVM在特定时刻对堆内存的一张“快照”。快照里记录了三类核心信息所有存活对象每个对象的类、字段值、数组长度、对象大小对象之间的引用关系谁持有着谁这是分析泄漏的关键GC RootsGC根包括线程栈上的局部变量、静态变量、JNI引用等GC判断可达性都从GC Roots出发如果你用文本编辑器打开一个标准的hprof二进制文件会看到文件头有14个字节以“JAVA PROFILE”开头的文本样式记录着文件的版本号比如JAVA PROFILE 1.0.3或者1.0.4。在这之后才是大量的二进制记录。这个格式是JVM定义的标准用jmap-dump:formatb,fileheap.hprof生成的文件就是这个格式MAT可以直接打开。另一种情况是Android的hprof早年间也是标准格式但从Android O开始系统dump出来的hprof变成了text/hprof格式里面是文本化的对象描述不是二进制。如果你直接把这种文件丢给MAT会直接报错后面避坑章节我会专门说这个转换问题。搞清楚格式的意义在于你拿到一个hprof文件时第一步不是急着打开而是先确认它是什么版本的格式。我一般会先用编辑器打开文件头看一眼如果是“JAVA PROFILE …”就交给MAT如果开头是文本化的Head dump描述就得先做一次转换。MAT本身虽然也能尝试解析部分变体但准确性没有保证格式不匹配时解析出来的对象关系会错得离谱。2.2 MAT的核心算法为什么它能从快照里“算”出泄漏hprof里存的是一张巨大的对象引用图。要回答“谁泄漏了”本质上是要回答两个问题哪个对象占用的内存最大这些对象是谁不让GC回收的MAT在这件事上做了三件关键的事构建对象图Object Graph把文件里的引用关系还原成一张有向图生成支配树Dominator Tree对象A支配对象B意味着所有从GC Roots到B的路径都要经过A。换句话说A是B的“必经之路”如果A被回收B也会被回收计算保留堆Retained Heap某个对象被回收后整个对象图中随之变成不可达的对象的集合大小之和。它衡量的是“真正能被释放的内存”这里要分清两个概念Shallow Heap是对象自身占用的内存不算字段引用的那些对象Retained Heap才是对象被回收后实际腾出来的内存。分析泄漏时Retained Heap才是真正值得关注的数字。比如一个ArrayList对象自身的Shallow Heap可能只有几十个字节但它引用着一个数组数组又引用着几万个对象它的Retained Heap可能就是几十MB。两个指标长得很像实际意义差很多我用一个表格来辅助区分指标含义适用场景Shallow Heap对象自身的内存占用不含引用对象排查单个大对象比如超大数组时看Retained Heap对象被回收后实际释放的内存总量定位内存泄漏主嫌疑对象时按这个排序实际打开hprof之后最直观的做法就是在Histogram直方图或者Dominator Tree里按Retained Heap从大到小排序。哪个类的Retained Heap总量最大泄漏的嫌疑就最大。这个排序结果通常不会说谎但要注意区分“临时创建的大数组”和“长期存活的缓存”后面实战章节会讲到怎么判断。2.3 从下载到第一个hprof环境准备与基础界面MAT是一个独立的桌面工具全称Eclipse Memory Analyzer。虽然它属于Eclipse生态但当前版本的MAT已经不再依赖Eclipse IDE解压就能跑。下载的时候注意区分Windows 64位、macOS和Linux版本对应各自的压缩包。有个细节值得提一下MAT基于Eclipse RCP运行需要JDK它自带的启动脚本会去找本机的JAVA_HOME。如果本机装的是JDK 17以上老版本的MAT比如1.6以下可能会因为反射权限问题启动失败建议用新版本。下载完解压之后Windows上双击MemoryAnalyzer.exemacOS/Linux执行同目录下的MemoryAnalyzer脚本。启动后通过菜单File → Open Heap Dump选择hprof文件。第一次打开一个比较大的文件比如1GB以上时MAT会弹出一个对话框询问要不要生成Leak Suspects Report泄漏嫌疑报告。这个报告会耗时较长但值得等待它会自动找出最可疑的几条引用链并估算每条链占用的内存百分比。如果只是想快速看数据可以选择No进主界面后再手动打开Histogram等视图。主界面的核心视图有四个Overview总览页显示堆大小、类数量、对象数量和Leak Suspects入口Histogram直方图按类汇总列出每个类有多少实例、Shallow Heap和Retained Heap是多少Dominator Tree支配树从根节点开始展示对象引用层级可以直接看到某个大对象嵌套在哪个父对象下面Leak Suspects泄漏嫌疑报告MAT自动生成的结论性页面这四个视图组成了分析hprof的基本工作流先看Overview确认文件解析是否正常再进Leak Suspects看结论或者直接进Histogram按保留堆排序。遇到具体对象就右键进入Dominator Tree看引用路径。新手最容易犯的错是只盯着Leak Suspects看其实很多场景下自己手动点出来的引用链比自动报告更可靠。3. 定位内存泄漏的主战场Histogram与Dominator Tree的配合3.1 第一步先看直方图找到“大头”类打开hprof之后我习惯的第一站是Histogram而不是Leak Suspects因为Leak Suspects经常给出的是结论但中间隔着MAT的猜测逻辑不如自己从数据里找答案来得快。操作路径如下点击主界面工具栏上的Open Histogram图标一个柱状图样子的按钮在直方图顶部的输入框里可以输入类名关键字做过滤比如输入你怀疑泄漏的类点击Retained Heap列头让所有类按保留堆从大到小排序排序之后页面上方几行的类就是内存的大头。这里需要留个心眼Retained Heap最大的类往往是byte[]、char[]、Object[]或者String这类基础数组因为业务对象最终都挂在数组上。它们本身不是泄漏根源你要做的是顺着数组向上找是谁引用了这个数组。所以在直方图里做一次筛选看哪个业务类的实例数量异常是更有价值的——比如一个应该只有几百个实例的缓存对象结果有几十万个实例这种“数量异常”比“体积异常”更容易暴露问题。直方图支持按Class Loader分组查看这个功能在分析Web应用和动态部署场景时非常有用。操作方法是点击直方图工具栏右上角的Group By下拉框选择By Class Loader。此时每一行显示一个ClassLoader展开后能看到这个ClassLoader加载的所有类实例。如果某个自定义ClassLoader下的对象数量剧增说明ClassLoader和它加载的类可能被全局对象持有了这是典型的类加载器泄漏。操作顺序直接照着做即可 1. File - Open Heap Dump 选择hprof文件 2. 弹窗Leak Suspects Report选择No先不生成报告省时间 3. 打开Histogram视图 4. 按Retained Heap列降序排序 5. Group By切换为By Class Loader观察每个加载器下的实例分布这五步做完你手里就有了一张“谁占了多少内存”的地图。接下来要做的就是从地图上挑一个嫌疑对象去追它的引用链。如果你对项目代码足够熟悉这一步通常就能锁定两三个候选类如果完全不熟悉从数量异常的业务类入手会比从byte[]入手有效得多。3.2 第二步用Dominator Tree顺着引用链找到持有者假设你在直方图里看到了自己项目里的某个类比如com.example.cache.UserCache对象Retained Heap有500MB直觉告诉你它不该占这么多内存。接下来要确认的是这500MB是谁在兜着如果没有任何人引用它它早被GC回收了。去看引用链的方法在Histogram里的对应类上右键 → Path to GC Roots → 选择with all references。菜单里通常还会有一个exclude all phantom/weak/soft etc. references的选项这个要重点说。GC Roots是JVM判断对象是否存活的起点。一个对象如果有一条从GC Roots出发的强引用链它就不会被回收。但Java里还有弱引用WeakReference、软引用SoftReference、虚引用PhantomReference它们不会阻止GC回收。分析泄漏时我们关心的是“谁在强引用它”所以通常要勾选排除弱引用和软引用只保留强引用路径。如果不排除MAT会列出大量经过WeakReference的路径这些路径不构成泄漏只会干扰判断。典型的引用链输出格式是Thread 0x7c1b2a88 main └─ local variable java.util.HashMap 0x7c2a4c20 └─ value com.example.cache.UserCache 0x7c5d8a10这条链的含义是main线程的局部变量持有一个HashMapHashMap的value放着一个UserCache。看到这种结构代码里的问题就很好定位了——不是UserCache自身的问题而是HashMap接收了不该长期持有的value。如果引用链很长中间夹杂着一些容器的内部节点比如HashMap$Node、ThreadLocal$ThreadLocalMap$Entry不要慌顺着链往上看终点一定是一个GC Root。容器节点只是路径上的中间人真正的持有者是链顶端的那个根。我追过一条链从一个小对象开始中间经过了七八层HashMap的Node最后停在了静态ConcurrentHashMap上——原因就是代码里把数据无条件put进了一个static Map只增不减。3.3 第三步结合代码复现确认泄漏点引用链只是把“谁持有谁”摆了出来它不直接等于泄漏结论。这一步有很多人会跳过回到代码里看这个位置的写法是否合理。比如一个常见的误判场景——某个缓存类被一个长期存活的线程持有看起来是泄漏但如果这个缓存的键值总数是恒定的大小波动符合业务预期那就只是“缓存设计就是这样”不是泄漏。确认是否真的泄漏我一般会做三件事对比引用链里的持有者和业务生命周期它是跟随应用启动创建的还是每次请求创建的如果每次请求都创建新的并放入全局容器且没有清理逻辑那就是泄漏看实例数量在直方图里右键这个类选择Show objects by class能列出具体每个对象。如果实例数还在动态增长配合两次dump做对比结论就更扎实看代码里的触发条件是不是只有异常分支才导致对象被放入全局map很多泄漏都是异常处理分支里顺手put进去没有remove这套流程走完基本能把一个hprof文件里的可疑点定位到具体的类、具体的对象、甚至具体的代码路径。Leak Suspects的自动报告可以作为辅助参考但最终下结论还得靠人把代码和引用链对照起来看。分析过程要多抓几次对比样本单次dump的偶然性太大多对比几次才能把临时性分配和长期泄漏区分开。4. 让MAT替你干活OQL查询与两个对比场景4.1 OQL语法用它直接查出“谁在持有我的对象”Histogram和Dominator Tree能解决“哪个类占大头”但解决不了“符合某些条件的对象有哪些”。这时候要用MAT内置的OQLObject Query Language对象查询语言。OQL的语法跟SQL接近但查询的目标是堆里的Java对象。打开方式工具栏上的Open OQL Console按钮或者菜单Window → Open Perspective然后选择OQL。一个最简单也最常用的查询找出所有不为null的User对象-- 查询所有com.example.model.User对象 SELECT * FROM com.example.model.User u如果想要看每个User的id和name字段可以这么写-- 查询User对象的两个字段并限制最多返回100行避免结果集过大卡死界面 SELECT u.id, u.name FROM com.example.model.User u LIMIT 100OQL还支持WHERE条件比如找出所有缓存类型为STATIC且size超过1024的对象-- 按字段值过滤两步条件同时生效 SELECT * FROM com.example.model.CacheHolder h WHERE h.cacheType STATIC AND h.size 1024最后这句查询的实用价值在于它能在几十万个对象里快速筛出符合特定条件的精准嫌疑而且OQL直接使用类名不需要你猜。如果想要按某个字段分组统计OQL也支持GROUP BY-- 按userAgent分组统计数量降序排列直接看出哪个来源的对象最多 SELECT u.userAgent, COUNT(u) AS cnt FROM com.example.model.User u GROUP BY u.userAgent ORDER BY cnt DESC代码逻辑说明OQL的核心逻辑是把堆里的对象当作一张逻辑表每个类对应一张表类的字段就是表的列。查询结果会以表格形式展示支持右键继续操作。LIMIT的用途是防止结果集过大导致MAT卡顿尤其是字符串匹配合集场景下不加LIMIT结果可能上万行。参数说明里最需要注意的是OQL使用的类型名必须是hprof里记录的“内部类名”比如内部类要写成com.example.Outer$Inner数组要写成int[]这种形式。用错了类名不会报错只会返回空结果。如果记不清确切的类名先在Histogram的过滤框里输入关键字确认一下完整的类名再从OQL里引用。4.2 比较两个hprof把“有问题”和“没问题”放到一起单看一个hprof很难判断“多少算多”。更可靠的做法是抓两个时间点的hprof做对比一个是正常运行时的快照一个是发生OOM前的快照。两者之间的差值能清楚地告诉你这几小时内存到底涨在了哪里。MAT的Compare Basket对比篮也叫对比篮就是干这个的。操作步骤先打开第一个hprof比如正常时点的dump在Histogram里右键任意一行选择Add to Compare Basket用同样方式把第二个hprofOOM前的dump的相关对象也加入Compare Basket打开Compare Basket视图工具栏上的Compare Basket按钮右键选择Compare To另一个heap dumpMAT会生成一个对比结果表列出每个类在两个dump里的对象数量和Shallow Heap/Retained Heap差值对比时优先看Retained Heap差值最大且数量增长明显的类。这里要注意字符串和byte数组的数量变化在绝大多数情况下是“果”而不是“因”——业务对象膨胀了自然会产生更多字符串和字节。真正要追的是那些业务类的数量增长。比如一次典型的ThreadLocal泄漏正常dump里com.example.web.UserSession只有几百个实例OOM前dump里变成了几万个这个增长趋势就是结论。如果有两次dump的时间间隔信息还能算出大概的增长速率对判断“多久会再次OOM”很有帮助。比较两个hprof还有一个应用场景验证修复是否生效。代码改完后在同样压测场景下再抓一个hprof理应与修复前有明显差距。如果对比结果没有变化说明修复没打到真正的持有链上。这时候回头看引用链通常会发现漏掉了另一条持有路径。4.3 设置MAT的内存参数文件太大打不开怎么办hprof文件变大之后第一个卡住的往往不是业务代码而是MAT自己。MAT解析一个5GB的hprof自身可能要占用10GB以上的内存因为对象图和索引的开销远大于文件本身。如果MAT自身内存不足界面会卡死日志里出现java.lang.OutOfMemoryError。解决的办法是在MAT安装目录下找到MemoryAnalyzer.ini修改堆内存参数# 内存参数设置单位是M注意-Xmx和-Xms通常两个一起改 -Xmx4096m -Xms1024m代码逻辑说明-Xmx是最大堆-Xms是初始堆。两个值拉开太大时JVM在运行中会频繁扩容缩容反而影响性能。我一般建议让-Xms和-Xmx保持一致或者至少让-Xms占到-Xmx的一半以上。参数设置要根据机器物理内存来定别一次性设到物理内存的上限要给操作系统留余量。解析2GB的hprof至少给MAT分配4GB堆内存解析5GB的hprof至少分配8GB。如果机器内存确实不够可以降低hprof文件的体积比如只dump部分代-XX:HeapDumpBeforeFullGC之类但注意别漏掉需要的对象。还有一个冷门但有效的做法MAT对于大文件支持“部分解析”模式在打开文件时取消勾选某些分析选项比如不生成Leak Suspects Report可以节省大量内存。文件打开后也能通过工具栏的Actions菜单按需生成报告不用在一开始全量计算。我在内存受限的服务器上分析大文件时基本都会关掉自动报告手动按需触发。5. MAT分析hprof的避坑指南从打不开到误判5.1 打不开Android的text/hprof格式与二进制混淆现象把手机抓出来的hprof文件拖进MAT直接报错弹窗显示Unknown HPROF version或者一堆看不懂的解析异常。原因Android从O版本开始系统dump出来的hprof格式从原来的二进制变成了text/hprof文本格式而MAT只认标准二进制的JAVA PROFILE格式。手机上用Debug.dumpHprofData抓的文件很多都是这个文本格式。直接把文本格式丢给MAT解析器根本不认。解决标准做法是先做格式转换。Android Studio自带一个hprof-conv工具路径通常在Android SDK的platform-tools目录下。命令行转换方式# 把text/hprof转成标准hprof注意输入输出文件顺序别反了 ./hprof-conv input.hprof output.hprof转换前建议先看下文件头的文本内容确认是文本格式再做转换。有些抓取工具导出的hprof本身已经是标准格式了直接能打开不用额外折腾。遇到打不开的文件时先确认来源再决定要不要转格式别一上来就无脑转。5.2 MAT自身OOM把堆参数当业务参数调现象hprof文件成功打开了但在点击Histogram或者生成Leak Suspects时MAT闪退或者日志里明确写着java.lang.OutOfMemoryError: Java heap space。原因MAT解析hprof时把整个对象图放在自己的堆里文件越大需要的MAT堆越大。没有调大-Xmx或者-Xms和-Xmx相差过大导致堆扩容频繁都会让MAT成为性能瓶颈。解决打开MemoryAnalyzer.ini将-Xmx调整为与hprof文件大小相匹配的值。调整完重启MAT再打开文件。经验值是2GB的hprof配4GB堆5GB的hprof配8GB堆。如果机器内存上限就那么大可以配合工具只导出部分对象或者用增量模式打开。5.3 找不到“大头”被ClassLoader过滤和直方图筛选误导现象明明业务方说内存里有几百MB的缓存对象直方图里前几行全是byte[]和Object[]看不到任何业务类或者某次操作之后业务类全部消失。原因直方图上方有一个类名过滤输入框输入了关键字之后只会显示匹配类右上角的ClassLoader下拉框如果选了某一个加载器则只显示该加载器下的类。这两个过滤条件是叠加的任何一个在生效都会“隐藏”你以为应该出现的行。一旦忘了清理过滤条件就会得出“对象不存在”的错误结论。解决分析前先把类名过滤框清空ClassLoader下拉框恢复为All。养成习惯后就不会在这上面反反复复。如果确实需要专注某个库的对象用过滤没问题但每次换方向时务必先全部清空。这个操作虽然简单但确实是新手最常卡住的地方。5.4 引用链太长把容器内部节点当成了持有者现象点击某对象查看Path to GC Roots引用链有十几层中间全是HashMap$Node、ThreadLocal$ThreadLocalMap$Entry、ConcurrentHashMap$Node这样的系统类不知道该看哪一层。原因引用链是完整的对象引用路径容器内部节点是数据结构的一部分它们既不是持有者也不是GC Roots。把视线停在中间层会误以为问题出在HashMap上实际上问题在上游那个把对象放进去的代码段。解决一路向上滚到链的顶端看谁是第一个非JDK类的对象。通常答案都在顶层两三层。如果链条顶部是一个Thread对象重点看它的threadLocals字段——那是ThreadLocal的线程私有存储ThreadLocal泄漏时这里会积压大量Entry。时刻记住容器内部节点只是路径上的中间人不是最终答案。5.5 误报WeakReference和软引用干扰判断现象查询某对象Path to GC Roots时不勾选排除弱引用所有路径都经过了一个WeakReference看起来很像是强引用链导致泄漏。原因JVM里WeakReference和SoftReference本身就不会阻止GC经过它们的路径不能解释“为什么没被回收”。默认显示的路径里包含了这些弱引用路径MAT没有替你排除需要手动过滤。解决在Path to GC Roots菜单里选择exclude all phantom/weak/soft etc. references再查看强引用路径。如果勾选排除后没有路径了说明该对象其实是弱引用的正常生命周期并非泄漏。这个操作在分析ThreadLocal相关对象时尤其关键默认模式下的结果往往面目全非。6. 进阶技巧用最小保留堆计算和一套固定流程收尾6.1 计算最小保留堆量化泄漏的“底线”MAT的每个对象在Dominate Tree里的位置不同一组对象如果被同一个上游持有它们共享的那部分内存不应该重复计算。选中多个可疑对象后右键 → Calculate Minimum Retained SizeMAT会估算如果这些对象全被回收至少能释放多少内存。这个数值往往和直方图里看到的Shallow Heap加起来不一样因为对象之间的共享引用会被去重。验证步骤 1. Histogram里选中多个可疑对象 2. 右键 - Calculate Minimum Retained Size等待估算完成 3. 记录释放字节数与JVM -Xmx对比判断是否值得优化 4. 修复代码后再次抓包用同样方式计算确认数值下降这个数值的用处在于可以把“我觉得泄漏”变成“这里能释放400MB”。评估优化优先级时我习惯先对这个数字排序数值最大的先处理。如果把修复前后两次的Minimum Retained Size数字放在一起对比就能直观看到改动到底释放了多少内存这个数字比任何代码review都有说服力。从那以后我每次拿到hprof都会强制走一遍这套流程先确认文件格式和版本再开Histogram排序找大头顺着Dominator Tree追引用链需要精细化时用OQL过滤最后用Minimum Retained Size量化结论。一套走完再下判断不在分析阶段反复横跳。这套流程救过我很多次希望帮到你。本文还有配套的精品资源点击获取
