对象年龄从0开始，每次Minor GC后存活并复制到Survivor区则+1；实际晋升由JVM动态决策，取决于Survivor空间压力与年龄分布，而非机械达到默认阈值15。

对象在 Survivor 区经历多次 Minor GC 后进入老年代，核心依据是“年龄”这一运行时标记值，但实际晋升行为并非机械计数，而是由 JVM 动态决策的结果。关键不在于“是否满 15 次”，而在于 Survivor 空间是否能继续容纳这些存活对象。

年龄是怎么算出来的

对象年龄从 0 开始：新对象分配在 Eden 区，年龄为 0；每次 Minor GC 中存活下来并被复制到 Survivor 区（S0 或 S1），年龄就 +1。注意：只有在新生代 GC 中幸存并完成复制，年龄才增长；老年代 GC 不影响该计数。

• Eden 区对象 → Minor GC 后存活 → 复制到 S0 → 年龄变为 1
• S0 中对象 → 下次 Minor GC 后仍存活 → 复制到 S1 → 年龄变为 2
• 如此往复，每成功跨过一次 Minor GC，年龄加 1

默认阈值只是上限，不是保证

-XX:MaxTenuringThreshold 默认为 15（JDK 8+），但它仅表示“最多允许活到 15 岁才必须晋升”，不是“必须活满 15 岁才能晋升”。JVM 实际使用的晋升年龄可能远低于该值，取决于 Survivor 区的实时使用压力。

• 若 Survivor 区容量紧张，JVM 可能在 age=2 就把一批对象送入老年代
• 日志中出现 new threshold: 2 (max 15)，说明本次 GC 后动态下调了晋升门槛
• 哪怕设成 -XX:MaxTenuringThreshold=15，只要 Survivor 放不下，age=1 的对象也可能直接晋升

真正触发晋升的两种典型场景

晋升不是靠“等时间”，而是靠空间与分布两个硬指标：

• 动态年龄判定：Minor GC 后，JVM 扫描 Survivor 区，发现 age=3 的所有对象总大小 ≥ Survivor 总容量的 50%，则所有 age≥3 的对象全部晋升，不管是否达到阈值
• 空间担保失败：Minor GC 后存活对象总量 > 当前可用 Survivor 容量（比如 From+S1 全满，To 已无空间），JVM 只能将搬不下的对象直接推进老年代——此时年龄无关紧要，0 岁对象照进不误

怎么知道实际发生了什么

不能只看配置参数，必须依赖 GC 日志验证真实行为：

• 开启 -XX:+PrintGCDetails -XX:+PrintTenuringDistribution，关注 Age Table 输出，如 age 2: 524288 bytes, 524288 total —— 若该值接近或超过 Survivor 容量一半，就是动态年龄触发
• 留意 Desired survivor size 和实际转入量（total）的对比：Desired: 524288, total: 1200000 表明 Survivor 严重不足，走的是担保晋升
• jstat -gc 观察 S0U/S1U 是否长期接近 S0C/S1C，持续高于 80% 是 Survivor 过小的明确信号