老年代内存泄漏隐患的核心判断标准是full gc后老年代使用量持续不降或反升；需分析回收前、后用量及总容量，低回收率（如仅释放几mb）是首要信号。
识别老年代内存泄漏隐患，核心是看 Full GC 后老年代使用量是否持续不降、甚至反升，而不是只盯“有没有 OOM”或“用了多少百分比”。关键在变化趋势和回收效率。
看 Full GC 的回收效果：低回收率是第一信号
在 GC 日志中找到 Full GC 条目，重点提取三组数字：
- 老年代回收前使用量（如 PSOldGen: 1843200K）
- 回收后剩余量（如 ->1835000K）
- 老年代总容量（如 (2097152K)）
若单次 Full GC 仅释放几 MB（例如 回收率 ），且该现象反复出现，说明大量对象长期存活、无法被回收——这已不是配置问题，而是典型的内存泄漏前置表现。
查老年代占用趋势：稳升不降比峰值更危险
连续观察 5–10 次 Full GC 日志，画个简易时间线：
- 如果每次 Full GC 后老年代使用量都比上一次更高（如 1835000K → 1836200K → 1837500K），说明有对象在持续“漏进”老年代且永不释放
- 特别警惕“回收后略降、但下一轮分配前又快速打满”的节奏，这是缓存类、监听器、静态集合等泄漏的典型行为模式
结合线索交叉验证：不止看堆，还要扫异常提示
以下日志特征不是孤立出现的，往往伴随老年代缓慢爬升：
- 频繁出现 “concurrent mode failure”（CMS）或 “to-space overflow”（G1）：说明晋升压力大，而老年代又清不干净，两头挤压
- Full GC 触发原因写的是 “Ergonomics” 或 “Metadata GC Threshold”：可能掩盖了真实泄漏，需进一步查 Metaspace 是否同步膨胀
- 堆外线索：日志顶部或错误栈出现 java.lang.OutOfMemoryError: Metaspace 或 Direct buffer memory：说明泄漏源可能在类加载器或 NIO 缓冲区，间接推高老年代压力
快速定位常见泄漏源头
一旦确认存在老年代缓慢增长，优先排查这几类代码结构：
-
static 集合类容器（如 static Map
cache）：未设过期策略、未做 size 控制、未配合 weak/soft 引用 - 未注销的监听器或回调（尤其在动态模块、插件化场景）：注册了却没在生命周期结束时 remove
- ThreadLocal 持有长生命周期对象：线程池复用下，ThreadLocal 变量未 remove，导致绑定的对象随线程长期驻留
- ClassLoader 泄漏：热部署、OSGi、自定义类加载器场景中，旧 ClassLoader 被新实例引用而无法卸载，连带其加载的所有类和静态变量
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
