java内存泄漏排查需依证据链闭环：先通过jvm运行指标确认泄漏现象，再对比多份堆快照定位增长源，聚焦静态集合、threadlocal等常见模式代码验证，最后用工具监控并复测验证。
Java 内存泄漏排查不是靠猜，而是靠证据链：从现象定位、堆快照分析，到代码验证闭环。关键在快速缩小范围，避免陷入全量代码审查。
一、先确认是不是真泄漏
别一上来就 dump 堆内存。先看 JVM 运行时表现是否符合泄漏特征：
- 老年代（Old Gen）使用率持续缓慢上涨，Full GC 后回收极少，且频率逐渐变高
- 应用吞吐量稳定，但 RSS（进程实际内存占用）持续增长，远超 -Xmx 设置值
- 频繁出现 java.lang.OutOfMemoryError: Java heap space，且 OOM 前堆使用曲线呈阶梯式上升
用 jstat -gc
二、抓取并对比多个堆快照（Heap Dump）
单个 dump 只能看“快照”，多个时间点的 dump 才能发现“增长源”。推荐操作：
- 用 jmap -dump:format=b,file=heap1.hprof
抓第一个（基线） - 等业务运行 10–20 分钟后，再抓第二个：jmap -dump:format=b,file=heap2.hprof
- 用 Eclipse MAT（Memory Analyzer Tool）打开两个 dump，用 Compare Basket 功能比对“Dominator Tree”中对象数量/保留大小增长最显著的类
重点看：哪些对象的 Retained Heap 显著变大？它们被谁强引用？有没有本该被回收却一直活在 GC Roots 链上的对象（比如静态集合、ThreadLocal、未注销监听器）？
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
三、聚焦常见泄漏模式，直查代码
80% 的泄漏集中在几类典型场景，按优先级检查：
-
静态集合类持有对象：如
private static Map<string object> cache = new HashMap();</string>—— 检查是否漏了清理逻辑或用了弱引用 - ThreadLocal 未 remove()：尤其在线程池场景下，线程复用导致 value 累积；确认所有 set() 后都有对应 remove()
- 内部类持有外部类引用：非静态匿名内部类（如监听器、Runnable）隐式持有所在 Activity/Service/Controller 实例，导致其无法回收
- 资源未关闭 + 回调未注销：数据库连接、文件流、RxJava 订阅、Spring 事件监听器、GUI 组件监听器等，注册后未在生命周期结束时显式注销
搜索关键词：static.*Map\|List\|Set、ThreadLocal.*set、new .*Listener、subscribe.*、@PostConstruct.*@PreDestroy，结合业务上下文判断生命周期匹配性。
四、用工具辅助验证和监控
人工分析易漏，用工具固化检查点：
- 启动时加 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps/，让 OOM 自动落盘
- 集成 VisualVM / JProfiler 实时监控对象分配热点，开启“Allocation Profiling”看哪段代码高频创建特定对象
- 在测试环境用 Arthas 动态诊断：
vmtool --action getInstances --className com.example.User --limit 10查活对象；ognl '@java.lang.ref.WeakReference@get()'辅助验证引用强度 - 上线前加轻量级监控：用 Micrometer + Prometheus 记录关键缓存 size、监听器注册数、活跃线程数等指标，设置突增告警
不复杂但容易忽略：每次修复后，务必用相同压测路径复现，对比新旧 dump 中目标类的实例数与 Retained Heap 是否回归平稳。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
