排查内存泄漏需紧盯老年代持续增长、回收无效、越收越慢三点，结合oom类型（如heap space、gc overhead）和年轻代异常（如promotion failed）综合判断，并用ibm pma等工具分析日志模式。

看 GC 日志排查内存泄漏，核心是盯住“老年代是否持续涨、涨了又不掉、越回收越费劲”这三点。不是所有内存增长都是泄漏，但符合这几个特征，基本可以锁定问题方向。

重点看老年代（Old Gen）的使用趋势

每条 GC 日志里类似这样的片段：
[ParOldGen: 5120K->9216K(9216K)]
括号外是当前使用量，括号内是总容量。关键要看：

• Full GC 前后，Old Gen 的 used 值只从 98% → 95%，甚至只降几十 KB —— 回收效率极低
• 多次 Full GC 后，Old Gen 占用率仍在缓慢但稳定上升，没有平台期
• 对比几次 Full GC 日志，发现回收量越来越小，而晋升到老年代的对象越来越多

结合 OOM 类型和 GC 行为交叉判断

日志末尾的报错类型，直接提示问题性质：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• java.lang.OutOfMemoryError: Java heap space → 老年代耗尽，重点查泄漏对象是否长期驻留
• GC overhead limit exceeded → GC 花了 98% 时间，却只回收不到 2% 空间，说明大量对象无法释放
• 没报错但 Full GC 频次从几小时一次变成几分钟一次，单次耗时超 1 秒 → 泄漏初期，还没爆，但已很危险

别忽略年轻代（Young Gen）的异常信号

年轻代本身不直接导致泄漏，但它的行为能暴露隐患：

• Minor GC 非常频繁（比如每秒好几次），但每次只回收一点点 → 可能 Survivor 区太小，或大量对象“活”过一轮就晋升
• 日志中出现 "promotion failed" 或 "to-space overflow" → 大对象或高存活率对象正被批量推入老年代
• Eden 区每次 GC 后几乎清零，但 Old Gen 持续吃紧 → 说明问题不在分配快，而在“退不出去”

用工具辅助识别模式，别靠人眼硬扫

生产环境 GC 日志动辄几百 MB，人工翻效率低且易漏。推荐用 IBM PMA（Pattern Modeling and Analysis Tool）这类工具：

• 自动汇总 GC 频率、停顿时间、各代使用率曲线
• 标出“分配速率突增”“老年代回收比持续下降”等异常模式
• 生成可视化报表，一眼看出哪段时间开始恶化

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南