老年代缓慢上涨是长生命周期对象堆积信号，非必然内存泄漏；需用jstat观察Full GC后OU阶梯上升，结合jmap-histo比对、全量dump及MAT分析，排查缓存、大对象及G1 Humongous分配问题。
老年代缓慢上涨 ≠ 内存泄漏，但必须当它可能是
老年代使用率（OU）在每次 Full GC 后无法回落到基线，且呈阶梯式或斜坡式缓慢上升，这是典型的“长生命周期对象堆积”信号——不一定是传统意义的泄漏（比如静态集合无清理），更可能是业务逻辑中本该释放、却因引用链未断而长期滞留的对象。这类问题不会立刻 OOM，但会压缩 GC 余量，最终触发频繁 Full GC，拖慢响应甚至卡顿。
关键判断依据是：jstat -gcutil <pid> 5000</pid> 观察连续几次 Full GC 后 OU 值是否逐次抬高。若从 65% → 72% → 78% → 85%，基本可锁定。
- 别急着 dump：先确认不是 JVM 参数失配——比如
-Xmx过小、-XX:NewRatio过大导致老年代天然偏紧 - 别只看堆内：
OU上涨也可能是元空间（MU）或直接内存（Direct Buffer）撑满后间接影响 GC 策略，需同步用jstat -gcmetacapacity <pid></pid>和jcmd <pid> VM.native_memory summary</pid>排查 - 警惕“伪稳定”：有些服务在低流量期
OU看似平稳，一到定时任务/批量导入就跳升，务必在业务高峰期采样
jmap -histo:live 要连着跑两次再比对
jmap -histo:live <pid></pid> 是最轻量、不停机的初筛手段，但它单次结果意义有限。真正有价值的是变化量——哪些类的实例数/字节数在固定时间窗口内持续增长。
推荐做法：间隔 30~60 分钟（避开 GC 波动周期），分别执行：
jmap -histo:live 12345 > histo1.txt jmap -histo:live 12345 > histo2.txt
然后用 diff 或 Excel 对比两份文件的 #instances 和 bytes 列。重点关注：
-
byte[]、char[]、java.util.HashMap$Node等基础容器——说明上层业务对象在不断扩容或缓存未清理 - 自定义类名（如
com.xxx.OrderProcessor）实例数线性增长，且没对应减少——极可能持有长生命周期状态 - 大量
java.lang.ref.Finalizer或java.lang.ref.PhantomReference——说明对象正排队等 finalize，回收被阻塞
dump 时不加 live 才能看清“谁占了老年代”
排查缓慢上涨，目标不是找“泄漏源”，而是找“谁在老年代里赖着不走”。这时不要用 jmap -dump:live,format=b,file=heap.hprof <pid></pid> —— 它会先触发一次 Full GC，把本该晋升但还没来得及晋升的对象清掉，dump 出来的全是“幸存者”，反而掩盖了正在涌入老年代的大对象或批量晋升对象。
正确做法是直接 dump 全量堆：
jmap -dump:format=b,file=/tmp/heap_full.hprof 12345
然后用 MAT（Memory Analyzer）打开，按以下路径深挖：
- “Dominator Tree” → 按
Retained Heap排序 → 看顶部几个类是否匹配jmap -histo中增长项 - 右键可疑类 → “Merge Shortest Paths to GC Roots” → 关闭 “with all references”，只勾选 “with outgoing references” 和 “with incoming references” → 查看谁在强引用它、它又持有了谁
- 特别注意
java.util.concurrent.ConcurrentHashMap、net.sf.ehcache.store.MemoryStore、org.springframework.cache.interceptor.CacheAspectSupport等常见缓存容器——它们本身在老年代，里面 value 若是大对象或未过期，就会把整块内存钉死
G1 下大对象（Humongous）是沉默的推手
用 G1 收集器时，只要对象大小超过 G1RegionSize 的 50%，就会被直接分配到老年代的 Humongous 区域。而 RegionSize 默认是 1MB～4MB（取决于堆大小），意味着一个 2MB 的 byte[] 就会跳过年轻代直奔老年代。
这种分配不会出现在 jmap -histo 的 top 类里（因为数组本身实例少），却会显著推高 OU。验证方法：
- 开 GC 日志：
-XX:+PrintGCDetails -Xloggc:/var/log/gc.log，搜索Humongous或mixed关键词，看是否规律性出现 - 查当前 RegionSize：
jinfo -flag G1HeapRegionSize 12345，再结合业务代码检查是否有周期性生成大对象的操作（如导出报表、批量序列化、图像处理） - 临时缓解：加
-XX:G1HeapRegionSize=1M（降低大对象阈值，让它们更早暴露）或-XX:G1MaxNewSizePercent=60（给年轻代多留点空间，减少晋升压力）
真正难缠的，是那些看起来合理、却在高频调用中累积成山的对象——比如每次请求都 new 一个 512KB 的 StringBuilder，1000 QPS 下每分钟就是 30GB 的 Humongous 分配。这种问题不在 dump 里显眼，得靠 GC 日志+代码审计双印证。
