关键是从“对象该死却没死”入手：用jstat -gc <pid> 1000 10观察YGC高频但OU缓涨、S0U/S1U长期偏低、FGC后OU降幅极小；再用jmap -histo:live定位异常增长的POJO或集合类；最后jmap -dump结合MAT分析Path to GC Roots，重点排查static、ThreadLocal、未注销监听器等强引用持有者。
排查对象未及时释放引发的 GC 压力，关键不是等 Full GC 报警，而是从“对象该死却没死”入手——即存活时间远超预期，反复躲过 Minor GC，最终挤占老年代、拖慢整体回收节奏。
看 GC 行为是否暴露“对象滞留”信号
用 jstat -gc <pid> 1000 10 实时观察，重点关注三类异常模式：
- YGC 频次高（如每秒 ≥2 次），但 老年代使用量（OU）持续缓慢上涨 → 说明大量对象在 Survivor 区“赖着不走”，反复复制后晋升老年代
- S0U/S1U 使用率长期低于 5%，且每次 GC 后几乎清零 → Survivor 空间未被有效利用，对象不是“短命”，而是“卡在中间不死不活”
- FGC 间隔越来越短，但每次 Full GC 后 OU 下降幅度极小（如只降 1–2%）→ 老年代中存在强引用链，阻止大批对象回收
抓堆里“不该活这么久”的对象
执行 jmap -histo:live <pid> | head -30，重点筛查三类嫌疑对象：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 业务 POJO 类实例数达数十万级，且随请求量线性增长 → 很可能被缓存、监听器、ThreadLocal 或静态集合意外持有
- java.util.HashMap$Node、java.util.ArrayList 实例数占比突增 → 检查是否在循环中反复 new 集合，或 Map/List 被长期持有未清理
- javax.swing.*、java.awt.* 等 GUI 类大量存在（非 GUI 应用中）→ 提示资源未 dispose，或事件监听器注册后未注销
顺藤摸瓜找强引用持有者
生成堆快照：jmap -dump:format=b,file=heap.hprof <pid>，用 Eclipse MAT 或 VisualVM 打开，按以下路径深挖：
立即学习“Java免费学习笔记（深入）”；
- 打开 Dominator Tree，排序“Retained Heap”，找顶部几个大对象 → 它们大概率是泄漏源头或强引用容器
- 对可疑对象右键 → “Path to GC Roots”，勾选“exclude weak/soft references” → 显示谁在强持有它
- 特别关注路径中是否含 static 字段、ThreadLocalMap、匿名内部类、未注销的 Listener、未关闭的 Closeable 抽象（如 InputStream、Connection）
验证并定位泄漏代码点
若怀疑某模块（如订单服务、定时任务），可做轻量级定向验证：
- 加 JVM 参数 -XX:+PrintGCDetails -XX:+PrintReferenceGC，观察 Finalizer 队列是否积压 → 积压说明对象已不可达但因 finalize() 未执行完而卡住
- 对目标接口压测前后各 dump 一次，用 MAT 的 “Compare Basket” 功能对比对象数量变化 → 快速锁定增长最猛的类
- 检查 ThreadLocal 使用：是否用了 static ThreadLocal<?> 却未调用 remove()？尤其在 Tomcat 等线程池场景下极易导致内存滞留
