大概半年前我们内部有个消息中间件服务在业务高峰期反复拉起内存告警老年代占用一路从60%爬到99%Full GC从几个小时一次恶化到半小时一次我盯着监控面板怀疑人生。后来把堆快照导出来用MAT工具链一步步拆半小时就定位到一个很隐蔽的缓存泄漏点。这个复盘我一直想写进系列笔记正好写到第十四章我干脆把MAT从取快照、看报告、追引用链到OQL精准定位的完整套路一次讲透。你如果之前只会jmap看一下堆大小、用VisualVM看个曲线就草草收场那这篇应该能帮你把内存泄漏排查这件事真正做到底无论是后端的JVM进程还是现在越来越常见的前端页面内存问题这套方法论都适用。1. 内存泄漏这件事先搞清楚垃圾到底怎么定义1.1 可达性分析才是判断依据很多研发对内存泄漏的第一反应是内存不够用了这个理解有偏差。JVM判断一个对象能否被回收根本机制是可达性分析从GC Roots出发沿着引用链往下走凡是能走到的对象都算活的走不到的统统当垃圾处理。GC Roots包括静态变量、活跃线程栈里的局部变量、JNI引用、同步锁持有的对象等几大类。所以内存泄漏的本质描述应该是有一批对象在业务上已经没有任何价值却仍能通过某个引用链被GC Roots够到导致垃圾回收器每次扫描都认为它们还活着不敢动。这就好比你家阳台上的旧纸箱早就不用了但只要你一直没把它扔下楼它就一直占着阳台空间最后连走路的地方都没有。1.2 四个最容易出现的泄漏场景根据我的排查经验90%的泄漏都能归入四类静态容器长期持有对象最常见。把对象塞进static Map、static List后忘了清理这个容器就成了永久性GC Roots。缓存类泄漏十有八九是这个原因。监听器、回调注册了没有注销事件监听器在组件生命周期结束时没移除或框架把匿名对象注册到全局事件总线对象被事件源间接引用。ThreadLocal没有执行remove线程池里的线程是长期复用的ThreadLocal里塞了大对象又不清除等于线程池替你永久保管了一堆废数据。ClassLoader无法被卸载多应用部署或动态加载类的场景里ClassLoader被静态引用钉住整个类元数据都释放不了这个问题通常表现为Metaspace持续上涨。1.3 为什么泄漏问题这么难肉眼发现堆里有几百万个对象你根本看不出哪个该死。即使看到某个对象数量异常也得解释它为什么没被回收这需要把引用链一路回溯到GC Roots。MAT这类工具的价值就在这里它把堆里的对象关系整理成可视化结构自动计算支配关系再用引用链回答谁在引用它。工具交给你的不是答案而是一条能顺着摸到根因的路。2. MAT工具链的完整构成离线快照分析的正确打开方式2.1 MAT的角色定位MAT全称是Eclipse Memory Analyzer Tool现在有独立发行版不用装Eclipse。它在内存排查链路里的定位非常清晰读取hprof堆快照然后以离线方式分析堆里的对象分布、支配关系、引用链和泄漏嫌疑。它不是监控工具不负责什么时候该dump那是监控系统的事它负责回答这份快照里到底有什么、哪些东西不该在这里。我见过不少同行在MAT和jmap、VisualVM之间摇摆其实分工很明确jmap负责取快照和看基础堆信息jstat负责看GC趋势VisualVM适合实时观察曲线真正到了线上出了OOM手上只有一堆hprof文件的时候MAT才是能一路挖到代码行级别的那个工具。2.2 拿到堆快照的常用姿势能不能分析高质量的快照直接决定MAT分析的成败。我常用的获取方式有四种方式命令/参数适用场景注意点jmapjmap -dump:formatb,fileheap.bin pid手动触发线上应急会短暂STW高并发慎用jcmdjcmd pid GC.heap_dump -all heap.bin比jmap更推荐JDK自带可指定只导live对象JVM参数-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/dump预防性配置OOM时自动留证生产环境强烈建议加上Arthasheapdump /tmp/heap.bin不想记jmap参数时用依赖Arthas已接入提示jmap -dump:live只导存活对象分析GC Roots引用链够用若想分析幽灵对象、排查本该回收却没回收的缓存类泄漏最好导全量dump。2.3 三个核心视图和一套查询语言MAT界面默认展示Overview里面有几个入口。真正干活的就四样Histogram直方图按类统计对象实例数、Shallow Heap浅堆对象自身占用的内存、Retained Heap深堆对象被回收后能释放的总内存。Dominator Tree支配树把谁支配谁画成一棵树一眼看出哪些对象占用了大量retained内存。Leak SuspectsMAT自动扫描后给出的嫌疑报告标出它认为最可疑的几块区域。OQL类SQL查询语言用来按自定义条件精确筛选对象。这四个入口的关系很清晰Leak Suspects负责提示方向Histogram和Dominator Tree负责缩小范围OQL负责最后一击。很多人只盯着Leak Suspects看看完就说MAT给的都是废话其实是没用对——Leak Suspects只是线索不是判决书后面我会用实际案例说明为什么不能盲信它。3. 四步排查法从快照到根因的固定套路3.1 先把Leak Suspects报告当线索而非结论拿到hprof后我建议第一件事还是点开Leak Suspects但不是为了直接看它的结论而是为了获取方向。它会告诉你系统里哪几个对象占用的retained heap最大、数量最异常通常附上一段简要分析比如由ThreadLocal持有或被一个Component引用。但这里有个至关重要的心态它的嫌疑只是统计学意义上的不代表真的泄漏。一个正常的大缓存对象也可能被标记为嫌疑对象因为它确实占了很多内存。所以我的用法是从Leak Suspects里挑出两三个重点区域记录下类名和实例数然后立刻跳到Histogram和Dominator Tree做交叉验证。3.2 用Dominator Tree找支配内存的大对象Dominator Tree是排查过程的第二个动作。它展示的是支配关系——如果回收对象A连带能释放BB又被A独占引用那B就被A支配。把retained heap排序后你通常能看到头顶上聚集着一批大块头。这个视图最适合回答内存到底被谁占用了这个最原始的问题。我一般会把排序切换到retained heap降序然后从上往下扫重点关注两类一是不应该在业务里出现的大集合、大数组、大字符串二是某个业务对象实例数异常膨胀。发现可疑对象后右键选Path to GC Roots排除掉weak/soft/phantom引用在弹出的窗口里选exclude all phantom/weak/soft etc. references就能看到一条从GC Roots到该对象的完整引用链。3.3 用Histogram看实例数量异常而不是盯着总大小Histogram要关注的指标是两个实例数和Retained Heap而且很多时候实例数比大小更敏感。一个对象就算单个几百字节如果有几百万个实例那它就是颗埋在堆里的雷。我的固定操作是先把Histogram按对象数量降序排一遍把对象数量大、但业务上不应该有这么多实例的类全部标记下来然后按Retained Heap降序再排一遍把内存占比高、但实例数正常的类标记下来。两组结果交叉后重合的那个类大概率就是问题所在。比如下面这种OQL可以直接定位那些实例数异常的对象SELECT c, COUNT(*) AS cnt, SUM(c.retainedHeapSize) AS retained FROM OBJECTS c WHERE c.retainedHeapSize 1024 * 1024 GROUP BY c ORDER BY cnt DESC3.4 用Path to GC Roots验证最后一米前面几步能告诉我们哪里内存大但还不能证明这个对象是泄漏的。真正的判据是引用链。对可疑对象执行Merge Shortest Paths to GC Roots看它到底被谁牵着。如果牵着它的链条是某个静态缓存容器→业务数据→本该过期的数据那就可以下定论了。这一步要养成一个习惯同时检查引用链上每一环的语义合理性。比如一个Entry被HashMap持有HashMap被一个静态实例持有静态实例是被Spring管理的长生命周期Bean——链条上每一环看起来都正常但结合业务逻辑你就会发现Entry早就没有存在的意义了这就是隐患。4. 一次缓存服务泄漏的完整排查实录4.1 现象GC越来越勤却基本回收不回来为了让你看到这套套路怎么落地我复述一个完整的实战记录。当时我们的消息网关模块里内置了一个轻量缓存用于存储客户端连接会话的部分元数据。上线一个多月后监控显示老年代使用率以每天约5%的速度爬升Minor GC后年轻代能回收但老年代持续膨胀Full GC触发越来越频繁每次GC后老年代顶多下降3%到5%。我第一反应是缓存没有过期机制或者过期了但没清干净。但代码review后没发现明显问题缓存明明有清理线程每30秒执行一次清理逻辑看起来也是对的。于是决定上MAT看真实数据。4.2 Leak Suspects给出的第一个线索为什么不能盲信我用jmap导了全量堆快照文件大概1.6GB用MAT打开后等着看Leak Suspects。报告很快出来了里面排行第一的是一个java.util.HashMap$Node[]占了老年代将近一半的retained heap。看快照时它被标记为由一个静态的ConcurrentHashMap持有。乍一看这简直是教科书级别的泄漏现场静态Map永不清除。但我盯了一会儿觉得不对劲我们的缓存容器本身就是长期存活的它持有大量节点是正常的关键要看里面的数据是不是还有效。Leak Suspects只告诉你这里有一大块驻留内存它管不着这些数据该不该活。如果我当场下结论缓存没做清理那就跟线上真实问题失之交臂了。4.3 从十万个实例里挖出真正的病根我切到Histogram按实例数排序后发现自定义的SessionMeta对象有接近17万个实例。这个数字很讽刺当时缓存设计的是最多存5万个会话元数据实际运行的会话峰值也就两三万17万已经远远超出了合理范围。随手写了一条OQL来定位这批对象的内容SELECT t.key, t.value.toString(), t.value.retainedHeapSize FROM java.util.concurrent.ConcurrentHashMap$Node t WHERE t.value.class.name LIKE %SessionMeta%结果很直观里面躺着大量lastAccessTime停留在三天前的旧数据。然后右键任意一个SessionMeta走Path to GC Roots引用链是这样的GC Root (static) - 缓存管理器的静态单例 - ConcurrentHashMap - Node - SessionMeta链条不长说明问题出在清理逻辑本身。回到代码里排查发现问题不在要不要清理而在清理哪些清理线程根据Map.size()判断是否需要触发清理触发后又用entrySet()遍历但遍历后判断是否过期时取的是lastAccessTime字段而这个字段在并发更新时没有加锁部分会话更新后没有刷新它于是这批数据永远看起来没过期。4.4 修复后的数据对比与复盘结论修复方式其实不复杂给lastAccessTime加了原子更新同时在清理线程里增加了对最长存活时间的兜底判断——不管会话是否活跃超过24小时未写入的数据一律视为可清理。上线后观察一周老年代使用率明显回落并稳定在45%附近Full GC频率恢复到了每天个位数。复盘时我特别感慨的点是代码review两遍都漏掉的问题MAT只用了半小时就指到了正确方向。但另一方面MAT不会替你得出这是泄漏的结论它的报告只是数据真正的判断必须结合业务语义。如果当时看到HashMap节点多就直接改缓存策略反而可能引入新的性能问题因为你没搞懂数据滞留的真实原因。5. 前端内存泄漏排查方法论完全搬得过去5.1 浏览器里同样存在不可达却活着的对象说到内存泄漏很多人默认是后端JVM的事。但前端内存泄漏怎么排查这两年越来越成为社区热议话题原因很简单浏览器端JS引擎同样有垃圾回收机制同样存在对象被意外引用导致内存无法释放的问题。一个页面越用越卡、内存越占越多最终甚至被系统强杀这在单页应用里特别常见。前端的GC Roots逻辑和JVM不完全一样但可达性的思想是共通的全局对象window、正在执行的函数调用栈、DOM树中被引用的节点都能充当根。当你的代码里有个定时器一直没清、事件监听器挂了一堆没移除、闭包意外捕获了大对象这些对象的生命周期就跟页面一样长泄漏就这么形成了。前端典型症状可能根因排查手段页面长期操作后内存只增不减定时器未清理、全局变量持有大对象Performance Monitor看JS Heap切换路由/关闭弹窗后内存不回落组件卸载未解绑事件、EventBus残留Heap Snapshot对比移动端页面被系统杀进程DOM节点分离但仍被JS引用快速Heap Snapshot后搜索Detached DOM5.2 Chrome DevTools里的MAT式思维Chrome DevTools的Memory面板本质上就是浏览器版的MAT。操作套路完全能复刻打开Performance Monitor观察JS Heap的实时曲线如果一段操作结束后曲线没有阶梯式回落说明有东西滞留。接着切到Memory面板做一次Heap Snapshot把它当成浏览器版Histogram按Constructor过滤重点看String、Array、DOMWrapper等大类型。再录一段Allocation instrumentation on timeline重现用户高频操作路径工具会标出每个对象的分配调用栈——这一步相当于前端的Path to GC Roots。我之前排查过一个在线协作编辑器卡顿的问题就用这个思路录了5分钟打字和选中文案的操作快照里冒出了一堆被window._tempCache引用的DOM片段。原因是代码里为了优化选区性能把最近操作的DOM节点顺手塞到了全局变量但清理条件写成了下次选区事件触发时才清只要用户不动选区这些DOM就一直被钉在内存里。用MAT的思路一对照根因立刻清晰——它根本没到GC Roots的最后一米第一步就看出来了。5.3 给前端团队的一份自查清单如果你们团队正被页面内存问题困扰我建议按这张清单快速自查全局变量和window上挂载的对象是否有清理时机。定时器/轮询是否在组件卸载后调用了clearInterval/clearTimeout。事件监听是否以匿名函数形式addEventListener且从未remove。闭包是否意外捕获了不需要的大数组、DOM节点。路由切换后历史页面组件是否还被store、EventBus或全局状态引用。长列表、虚拟列表是否保留了对滚动容器内节点的JS引用。防抖、节流的内部缓存是否无限制累积。这套清单后端的等价物就是线程局部变量有没有remove、静态容器有没有清空、监听器有没有解绑。两边的排查哲学完全一样找引用找该断没断的引用。6. 踩坑总结几个MAT不会主动告诉你的细节6.1 一份快照会骗人两组快照才不会单看一份快照很容易误判。某对象占内存大可能是因为它正在被正常业务使用也可能是因为它泄漏了只看静态快照很难区分。我的做法是至少取两组快照业务低谷期一份、高峰期或异常期一份在MAT里用Compare Tables对比Histogram观察哪些类的实例数和retained heap增量最离谱。增量异常才是硬线索。前端也一样。Chrome DevTools里对比用户操作前后的两个Heap Snapshot挑出新增对象最多的几个类远比只看一个快照可靠。6.2 分析大快照之前先看MAT自身的内存配置MAT本身是个Java程序分析1GB以上的大hprof时默认内存可能不够会报java.lang.OutOfMemoryError很多人第一次分析就栽在这里。解决办法是改安装目录下的MemoryAnalyzer.ini文件把-Xmx调大例如-Xms1024m -Xmx4096m如果你在服务器上跑MAT建议多留一点余量按堆快照大小的一半以上再翻倍去做基础估算。另外文件过大时可以先在MAT里用Keep Unreachable Objects选项来控制保留对象范围减少分析压力。6.3 dump时机和工具选择上的经验和教训最后说几个我自己踩出来的实操细节。第一线上的高并发服务jmap -dump:live触发时会造成较长的暂停最好在低峰期操作或者直接依赖JVM参数-XX:HeapDumpOnOutOfMemoryError让进程在OOM前自动留证这是成本最低、最不容易踩雷的做法。第二dump完不要反复用jmap取多份快照会加剧线上问题。尽量做到出事→取一份→分析→验证→再取把对业务的影响降到最小。第三如果分析了半天还是没结论多半是快照取得太晚。比如Full GC频繁到一定程度一些弱引用和软引用也可能被强回收原本的泄漏证据被冲掉了。所以经验是拿到监控异常报告后尽快取快照不要等OOM彻底发生才动手。第四Leak Suspects里的嫌疑对象标红不代表就是泄漏它只是内存占用密集白色未标红的类也有可能是最隐蔽的泄漏源。一切以引用链和业务语义的双重验证为准。有一次我只盯着标红的HashMap分析了两小时最后发现真正有问题的是一个完全没标红、但实例数翻了20倍的BitSet教训深刻。这几年的排查工作下来我越来越觉得内存泄漏问题拼的不是天才直觉而是稳定的操作流程和严谨的验证习惯。MAT这套工具链最大的价值不是代替你思考而是把堆里几百万个对象的嫌疑名单和引用路径整理成看得懂的线索剩下的判断还是得靠你对业务逻辑的理解。把上面这套四步流程多跑几次你也会形成肌肉记忆再遇到类似问题开场半小时基本上就能锁定方向。