JVM老年代上涨排查，长对象内存泄漏定位

老年代内存缓慢上涨往往并非传统意义上的内存泄漏，而是长生命周期对象因引用未及时释放而持续堆积的隐性风险，它虽不立即引发OOM，却会不断压缩GC余量、加剧Full GC频率并拖慢系统响应；本文系统梳理了从jstat观测OU阶梯式上升、jmap-histo跨时段比对定位增长对象、全量堆dump配合MAT深挖强引用链，到G1下Humongous大对象分配陷阱识别的完整排查路径，并强调需同步排除JVM参数失配、元空间/直接内存干扰及业务高峰期“伪稳定”假象，为高效定位缓存滞留、大对象直入老年代等真实瓶颈提供可落地的诊断逻辑与避坑指南。

老年代缓慢上涨 ≠ 内存泄漏，但必须当它可能是

老年代使用率（OU）在每次 Full GC 后无法回落到基线，且呈阶梯式或斜坡式缓慢上升，这是典型的“长生命周期对象堆积”信号——不一定是传统意义的泄漏（比如静态集合无清理），更可能是业务逻辑中本该释放、却因引用链未断而长期滞留的对象。这类问题不会立刻 OOM，但会压缩 GC 余量，最终触发频繁 Full GC，拖慢响应甚至卡顿。

关键判断依据是：jstat -gcutil 5000 观察连续几次 Full GC 后 OU 值是否逐次抬高。若从 65% → 72% → 78% → 85%，基本可锁定。

• 别急着 dump：先确认不是 JVM 参数失配——比如 -Xmx 过小、-XX:NewRatio 过大导致老年代天然偏紧
• 别只看堆内：OU 上涨也可能是元空间（MU）或直接内存（Direct Buffer）撑满后间接影响 GC 策略，需同步用 jstat -gcmetacapacity 和 jcmd VM.native_memory summary 排查
• 警惕“伪稳定”：有些服务在低流量期 OU 看似平稳，一到定时任务/批量导入就跳升，务必在业务高峰期采样

jmap -histo:live 要连着跑两次再比对

jmap -histo:live 是最轻量、不停机的初筛手段，但它单次结果意义有限。真正有价值的是变化量——哪些类的实例数/字节数在固定时间窗口内持续增长。

推荐做法：间隔 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 —— 它会先触发一次 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 日志+代码审计双印证。

终于介绍完啦！小伙伴们，这篇关于《JVM老年代上涨排查，长对象内存泄漏定位》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！