年轻代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 中各年龄段对象大小累加决定。重点关注：
- 若长期出现 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 是否启用（默认开）：若被显式关闭，动态年龄判定机制将失效
