年轻代GC晋升老年代的核心是Survivor区空间压力触发的动态年龄阈值，而非固定MaxTenuringThreshold；GC日志中“new threshold”由各龄对象累加占比决定，需结合Survivor使用率与晋升量联动分析。

分析年轻代 GC 晋升老年代的临界条件，核心不是查“对象活了几轮”，而是看 Survivor 区空间压力如何触发动态晋升。JVM 实际执行晋升时，真正起作用的是每次 Minor GC 后的 Survivor 占用分布 和 累加占比阈值，而非你设置的 -XX:MaxTenuringThreshold 数字。

看 GC 日志里的动态晋升年龄（new threshold）

开启 -XX:+PrintGCDetails 后，Minor GC 日志中会出现类似这一行：

Desired survivor size 524288 bytes, new threshold 3 (max 6)

其中 new threshold 3 就是本次 GC 动态算出的晋升起点年龄——它由 Survivor 中各年龄段对象大小累加决定。重点关注：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 若长期出现 new threshold 1 或 2：说明 Survivor 区太小或某类对象生命周期高度集中（如批量请求生成的 DTO），刚存活一轮就被迫晋升
• 若始终显示 new threshold 6 (max 6)：说明 Survivor 空间宽松，动态机制未触发，实际按你设的上限走
• 若日志里频繁出现 age 1: XXX bytes, XXX total 且 total 接近或超过 Desired survivor size 的一半，就是 age 1 晋升的直接证据

盯紧 Survivor 使用率与晋升字节数

每次 Minor GC 日志都会报告 S0/S1 的使用率（如 “S0: 68%”）和晋升到老年代的字节数（如 “tenured: 1245678”）。这两个指标必须联动看：

• Survivor 使用率持续 > 50%（尤其 > 60%）：说明 Survivor 区已逼近临界，下一次 GC 很可能触发更低年龄晋升
• 晋升量突然飙升（比如从 200KB 跳到 1.5MB），同时对应那次 GC 的 S0/S1 使用率达 48%～52%：基本可断定是动态年龄判定被触发
• 晋升量大但 Survivor 使用率却很低（如 S1: 12%）：说明不是空间不足导致，而是有大量大对象直入老年代或分配担保失败

验证 SurvivorRatio 对晋升节奏的实际影响

-XX:SurvivorRatio 控制 Eden 与单个 Survivor 的比例（默认 8 → Eden:S0:S1 = 8:1:1）。这个参数直接改变 Survivor 总容量，从而影响累加占比是否触达 50%：

• 设为 -XX:SurvivorRatio=2：每个 Survivor 占年轻代 1/4，总 Survivor 空间翻倍 → 更容易填满 → new threshold 更低
• 设为 -XX:SurvivorRatio=8：Survivor 总共只占年轻代 1/5 → 容易被少量对象撑满 → 常见 age 2 就晋升
• 推荐先试 -XX:SurvivorRatio=6 或 8，再根据日志中 S0/S1 使用率稳定在 30%～45% 来微调

排除干扰项，确认晋升真实动因

晋升量异常不一定是年龄或 Survivor 问题，需同步排查其他常见诱因：

• 检查代码是否调用 System.gc()：加上 -XX:+DisableExplicitGC 可屏蔽这类干扰
• 搜索 GC 日志中是否有 “PretenureSizeThreshold” 相关提示，或大量大对象（如 >1MB 字节数组）直接分配在老年代
• 观察是否存在装箱类型滥用（如 Integer.valueOf(1000) 频繁创建）、缓存未清理、静态集合持续 add 等导致对象长期存活
• 确认 -XX:+UseAdaptiveSizePolicy 是否启用（默认开）：若被显式关闭，动态年龄判定机制将失效