能快速识别堆溢出隐患的关键是观察内存增长趋势与回收失效信号：老年代占用率持续攀升、Full GC 后残留内存不降反升、Metaspace 同步飙升等日志模式，结合 JVM 参数和业务场景交叉验证，30 秒内定位真泄漏或配置失衡。
面试中能快速从 GC 日志里揪出堆溢出隐患，关键不是背参数，而是抓住「内存增长趋势 + 回收失效信号」这两个硬指标。只要看懂三类典型日志模式，就能在 30 秒内判断是不是真有泄漏、还是单纯配置太小。
盯住老年代占用率是否持续攀高
堆溢出的前兆，往往不是新生代爆了，而是老年代“只进不出”。重点看 Full GC 后 ParOldGen（或 CMS Old Gen）的使用量：
- 如果每次 Full GC 后，老年代已用内存不降反升（比如从 3200K → 3500K → 3900K），说明对象正在批量晋升且无法回收——极大概率存在内存泄漏
- 若 Full GC 后老年代仍占 95%+（如 [ParOldGen: 9216K->9216K(9216K)]），而新生代还在频繁 Minor GC，这就是典型的“老年代堵死”，新对象进不去、旧对象出不来，OOM 近在咫尺
- 注意对比时间跨度：连续 5–10 次 Full GC 的老年代残留值，比单次数字更有说服力
识别“回收无果型”GC 行为
真正危险的日志，不是 GC 频繁，而是 GC 白干。这类日志会同时出现三个特征：
- Allocation Failure 频繁触发（说明分配压力大）
- Young GC 后 Survivor 区几乎清空（如 PSYoungGen: 6144K→512K），但老年代同步暴涨
- Full GC 耗时短、效果差（例如 [Full GC ... 0.008 secs] 却只回收了几百 KB），说明 GC 算法已无力清理，对象引用链顽固存在
结合启动参数交叉验证真实瓶颈
光看日志不够，必须和 JVM 参数对齐看：
- 如果 -Xmx 设的是 1g，但日志里老年代已稳定在 900MB+ 且持续上涨，先排除代码问题，直接说：“当前堆上限已逼近物理极限，建议先扩容验证；若扩容后问题复现，再深入分析对象分布”
- 发现 -Xmn 设置过小（比如 -Xms2g -Xmx2g -Xmn256m），而日志中 Young GC 每秒发生多次，且大量对象因 Survivor 区撑不下直接晋升——这不是泄漏，是年轻代配置失衡，该调 -Xmn 或改 survivorRatio
- 看到 Metaspace 使用量同步飙升（[Metaspace: 2048K→5120K]），要提醒：“需确认是否动态生成类（如 Groovy/字节码增强），否则可能掩盖真正的堆问题”
不复杂但容易忽略：真正一针见血的结论，永远来自 GC 日志趋势 + 参数意图 + 业务场景的三角印证。比如日志显示老年代缓慢爬升，而系统恰好在跑定时报表任务——那就直接问：“这个报表是否缓存了全量结果？有没有做分页或流式导出？”
