老年代内存持续高位说明对象长期驻留、gc回收不力，需紧盯o（老年代使用率）、fgc（full gc次数）和ou（old used）变化，结合gc日志分析allocation failure或promotion failed，并通过jmap dump与mat分析retained heap及gc roots定位静态缓存、threadlocal未remove等强引用根源。
老年代内存持续高位，说明对象长期驻留、回收不力，不是GC没运行，而是它清不动。关键不在“有没有GC”，而在“为什么清不掉”。
盯住三个核心指标：O、FGC、OU变化
用 jstat -gcutil PID 2000 每两秒刷新一次，重点看：
- O（Old Utlization）：老年代使用率。若长期 >85%，且每次 Full GC 后仅下降 1–3 个百分点，基本锁定泄漏或无效晋升
- FGC（Full GC 次数）和 FGCT（总耗时）：次数快速增加 + 单次耗时 >1s，说明 GC 已陷入低效循环
- OU（Old Used）绝对值趋势：对比多次 Full GC 前后 OU 数值，如果从 1.2G → 1.19G → 1.185G → 1.182G，缓慢下滑但不下拐点，就是典型的“缓存滞留”或“弱引用未生效”
查 GC 日志，区分是“占满触发”还是“晋升失败”
开启日志参数：-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps，关注以下两类关键模式：
- 出现 Allocation Failure + Tenured 区在 GC 前后几乎不变（如 Tenured: 102400K->102380K），说明新对象不断晋升进来，但老年代空间没腾出——大概率是缓存未清理、静态Map堆积、监听器未注销
- 出现 Promotion Failed 或 concurrent mode failure，说明 Survivor 区装不下、对象被迫直接进老年代，或 CMS/G1 担保失败——这时要调 -XX:MaxTenuringThreshold 或增大 Survivor 空间，而非只加堆
抓堆快照，直击大对象与强引用链
别等 OOM 才 dump，老年代使用率到 80%+ 就该行动：
- 执行 jmap -dump:live,format=b,file=heap.hprof PID（加 live 参数避免包含已死对象）
- 用 MAT 打开，看 Dominator Tree，排序按 “Retained Heap” 降序，重点关注：
- ConcurrentHashMap、HashMap、LinkedHashMap 实例是否排前三？总 retained heap 是否超堆 20%？
- 右键点击可疑 Map → Path to GC Roots → 勾选 “with all references”，看顶端是不是 static 字段、Spring 单例 Bean、ClassLoader 或 TimerThread
- 若发现引用链终点是 java.lang.ref.Finalizer 或大量 char[] / byte[] 被 String 持有，可能是 JSON 反序列化后未释放大文本缓存
验证是否为缓存类泄漏的三步交叉法
不用翻代码也能快速聚焦问题域：
- 执行 jmap -histo PID | head -15：如果 java.util.HashMap$Node、java.lang.String、你自定义的 CacheManager 类实例数上万，且 class name 出现多次，高度可疑
- 检查 GC 日志中是否有连续多段 Full GC (System.gc())：说明有代码或第三方库（如某些老版本 Druid、Log4j2 配置）主动触发，干扰正常 GC 节奏
- 观察 Metaspace 使用率：如果 M 也在同步上涨（jstat -gcutil PID 中 M 列持续升高），说明类加载泄漏（如热部署、CGLIB 动态代理反复生成类），此时老年代涨是副作用，根因在元空间
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
