JVM内存泄漏排查是按节奏推进的闭环动作：先确认真实泄漏而非正常波动，再锁定长期存活对象，最后切断强引用链。需通过监控曲线、堆转储和MAT分析定位static字段、ThreadLocal等根源，并代码层修复。
JVM内存泄漏排查不是靠经验猜，而是按节奏推进的闭环动作：先确认它真在发生，再锁定谁在“赖着不走”，最后切断它的生路。整个流程要能落地、可复现、不依赖重启。
一、确认是不是内存泄漏，而不是正常波动
看监控曲线比看日志更早发现问题。重点盯三个信号：
- 老年代（Old Gen）使用率持续爬升，每次Full GC后回落幅度越来越小，甚至不降反升；
- 堆内存整体占用呈“阶梯式上涨”，每轮GC后的低点逐次抬高；
- GC overhead limit exceeded 报错频繁出现，或 java.lang.OutOfMemoryError: Java heap space 在无明显流量突增时反复触发。
如果只是业务高峰期内存临时升高、高峰过后能回到基线，那大概率是压力大，不是泄漏。
二、保留现场，拿到能说话的证据
别等OOM才动手，提前配置好自动捕获机制：
- 启动参数加
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/，确保OOM时自动生成.hprof； - 日常怀疑有泄漏时，用
jmap -dump:live,format=b,file=heap_$(date +%s).hprof <pid>手动抓一份“活堆”快照； - 同步开GC日志：
-Xlog:gc*:file=/data/logs/gc.log:time,tags,level（JDK 11+），或老版本用-XX:+PrintGCDetails -Xloggc:gc.log。
三、用MAT分析堆转储，找“不该活却活着”的对象
打开.hprof后不急着看谁占内存多，而是聚焦“谁本该被回收却没被回收”：
- 先跑 Leak Suspects Report，MAT会标出几个高风险对象组，优先看；
- 切到 Dominator Tree，按 Retained Heap 排序，找排在前列的业务类（比如 UserService、DataBuffer、CacheHolder）；
- 对可疑对象右键 → Path to GC Roots → exclude all weak/soft references，看强引用链终点——90%以上指向 static 字段、ThreadLocal、未注销监听器、或线程池里长期持有的 Runnable；
- 特别注意容器类本身不泄漏，但里面装的元素没清理：HashMap 的 value 没 remove、ArrayList 的 item 没 clear、LogQueue 里的日志对象堆积。
四、代码层修复，从根源切断引用链
调大堆内存只能延缓死亡，修复代码才能真正止血：
- 静态集合类（如 static Map/List）必须配淘汰策略，或改用 WeakHashMap / ConcurrentHashMap + 定时清理；
- 缓存务必设过期时间（TTL）和最大容量（maxSize），避免无限增长；
- ThreadLocal 使用后必须显式调用
remove()，尤其在线程复用场景（如 Tomcat 线程池）； - 注册监听器、回调、事件订阅后，对应位置要有反注册逻辑；
- 数据库连接、文件流、NIO Buffer 等资源，用 try-with-resources 或 finally 显式关闭。
不复杂但容易忽略。
