聊聊内存泄漏排查时容易被忽视的几类对象

内存泄漏的排查，难点往往不在工具本身，而在"到底该盯住哪些对象"。绝大部分线上OOM事故，根因不是没有监控，而是监控的注意力被分散在了常规对象上，真正导致泄漏的几类对象反而被忽略了。这篇文章不打算从头讲MAT怎么用、Heap Dump怎么分析，只聚焦一件事——在排查内存泄漏时，哪些对象最容易被误判为"正常"，以及它们为什么该被高度怀疑。

ThreadLocal里藏着的线程级"长生命周期引用"

ThreadLocal导致的内存泄漏，几乎成了Java面试题里的保留节目，但线上环境中真正被排查出来的比例远低于预期。原因是多数人对ThreadLocal泄漏的认知停留在"忘记调用remove方法"这个层面，而实际场景中，框架层隐式创建的ThreadLocal才是重灾区。

以Spring的RequestContextHolder为例，它在内部维护了一个ThreadLocal存储当前请求的RequestAttributes对象。在一个线程池环境下，线程被复用后，如果某个请求处理过程中将大对象挂载到RequestAttributes上（比如大文件上传的字节流），而该线程下一次被分配去处理一个轻量请求，旧的大对象引用并不会被自动清理。只要线程不销毁，这个引用就一直存在，GC无法回收。

排查这类问题的关键不是去翻代码找remove调用，而是在Heap Dump中直接检索ThreadLocalMap的Entry数量。一个正常运行的线程池线程，ThreadLocalMap中Entry数量通常在个位数，如果某个线程的Entry数量异常偏高，或者单个Entry的value占用内存异常大，基本可以锁定问题线程。再通过Dominator Tree往下钻，找到具体是哪个ThreadLocal实例持有的引用，反向定位到框架代码，比肉眼翻业务代码高效得多。

匿名内部类隐式持有的外部类引用

匿名内部类会隐式持有外部类的引用，这是Java基础语法就决定了的行为。但在泄漏排查中，这个知识点被应用的概率极低——因为大部分开发者认为"我只是new了一个Runnable，怎么可能泄漏"。

问题出在组合场景。当一个匿名内部类实例被提交到线程池，而这个匿名内部类所在的外部类本身又是一个长生命周期对象（比如单例Service）的成员变量时，引用链就变成了：线程池线程 → 匿名内部类 → 外部类 → 外部类持有的各种资源。如果这个外部类里恰好有一个10MB的缓存Map，那么整个引用链上的所有对象都无法被回收，直到线程池线程被销毁或者线程池任务执行完毕。

排查时，在Heap Dump中看到某个线程的Thread中持有一个this$0引用，且this$0指向的对象内存占用异常，基本上就是这种场景。修复方案也很简单，把匿名内部类改成静态内部类，或者显式地在任务执行完毕后断开外部类引用。

静态集合类充当"缓存"时的无界增长

用一个静态HashMap当缓存，是很多项目早期快速实现时的常见做法。写代码的时候觉得"就存几个配置项，不会有问题"，上线后业务量上来，key的类型悄悄从String变成了动态拼接的业务ID，集合从几十条数据膨胀到几百万条，最终把堆内存撑爆。

这类泄漏的隐蔽性在于，它看起来像是"正常业务数据"，Heap Dump中按Retained Heap排序时，大对象排在前面，很容易被解释为"业务量大，正常内存占用"。区分的关键在于判断这个集合是否应该有理论上限。一个无界增长的缓存，其size是一个持续增长的趋势，而不是一个在固定范围内波动的指标。

监控手段比事后排查更有效。针对静态Map类型的缓存，在JVM层面加一个定时JMX指标暴露，定期打印Map的size和estimated memory footprint，设定一个阈值报警，比等OOM之后再dump分析要主动得多。

Listener和Observer未注销导致的"幽灵引用"

观察者模式在事件驱动架构中极其常见，但注册了Listener之后忘记注销，是内存泄漏的经典来源。这类泄漏的排查难度在于，Listener本身通常很小，单个Listener的Retained Heap可能只有几十字节，但被观察者持有的Listener列表会随着时间线性增长，累积效应最终导致OOM。

更隐蔽的情况是，Listener注销了，但注销的是包装后的Listener，而原始Listener的引用链中还有别的对象。比如使用Lambda表达式注册的Listener，Lambda表达式本身可能被正确注销，但Lambda中捕获的外部变量引用并不会因为Lambda被注销而自动断开——如果这些外部变量持有大对象，泄漏依然存在。

排查时，重点关注被观察者对象（通常是长生命周期的组件，比如EventBus、ApplicationContext）持有的Listener列表。在Heap Dump中查看List或Set类型的字段，如果元素数量异常大，逐个检查每个元素是否仍然需要存在，通常能找到未注销的Listener。

不同排查策略的对比

内存管理中最容易被忽略的，不是技术上的漏洞，而是"看起来没问题"的认知惯性。ThreadLocal没清干净，静态Map没设上限，Listener忘了注销——这些都不是什么高深的技术难题，但线上事故中反复出现的，恰恰就是这些"低级错误"。排查工具的使用技巧只占问题解决的一小部分，真正的分水岭是排查时脑子里有没有一套"嫌疑对象清单"，知道该优先盯住哪些地方。