JVM通过动态年龄阈值决定对象晋升：每次Minor GC后，从年龄1起累加Survivor中各年龄对象大小，首次超Survivor容量一半时的年龄即为阈值，所有≥该年龄的对象晋升老年代。
JVM 并不会直接“判定对象年龄”来触发晋升，而是通过一个更底层、更务实的机制：当某次 Minor GC 后，Survivor 区中所有年龄为 N 的对象所占空间总和，**超过 Survivor 区总容量的一半**时，JVM 就会把所有年龄 ≥ N 的对象直接晋升到老年代。这个阈值（N）就是所谓的“动态年龄阈值”，它不是固定写死的，而是每次 GC 后重新计算得出。
动态年龄阈值的核心规则
该机制由 JVM 参数 -XX:MaxTenuringThreshold 设定理论最大年龄上限（默认 15），但实际触发晋升的年龄往往更低。关键判断逻辑是：
- 每次 Minor GC 后，JVM 统计每个年龄（1、2、3…）的对象在 Survivor 中的累计大小
- 从年龄 1 开始累加，直到累计大小首次超过 Survivor 空间的一半
- 此时的年龄值即为本次 GC 后的“动态年龄阈值”，所有达到或超过该年龄的对象全部晋升
- 例如：Survivor 大小为 10MB，GC 后年龄 1 对象占 3MB、年龄 2 占 4MB、年龄 3 占 2MB → 累加到年龄 2 时已达 7MB > 5MB → 动态阈值 = 2，所有年龄 ≥ 2 的对象全部晋升
为什么需要动态调整？
固定年龄晋升（如一律熬到 15 次 GC 才升）在真实场景中效率低下：
- 如果某类对象生命周期偏长（比如缓存对象），早早达到中等年龄就已稳定驻留，继续留在 Survivor 只是浪费复制开销
- 如果 Survivor 空间紧张，大量中龄对象堆积可能引发“Survivor 溢出”，被迫提前晋升，反而加剧老年代压力
- 动态机制能自适应应用对象年龄分布，平衡复制成本与晋升时机，在空间利用率和 GC 效率之间取得折中
如何观察和验证该行为？
启用 GC 日志可清晰看到动态年龄阈值的实际取值：
- 添加 JVM 参数：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps
- 日志中查找类似 Desired survivor size 5242880 bytes, new threshold 2 (max 15) 的行
- 其中 new threshold 2 表示本次 GC 后动态计算出的晋升年龄阈值为 2
- 配合 -XX:+UseSerialGC 或 -XX:+UseParallelGC 更易观察（G1/ZGC 使用不同晋升策略）
对调优的实际影响
理解该机制有助于避免误判 GC 问题：
- 若发现老年代增长快、Minor GC 频繁晋升，先检查是否因对象“早熟”——即动态阈值持续偏低（如长期为 1 或 2），说明 Survivor 容量相对过大，或对象平均寿命偏长
- 不建议盲目调高 MaxTenuringThreshold，它只设上限，不影响动态计算；真正有效的是调整 -XX:SurvivorRatio 或堆大小，改变 Survivor 实际容量，从而影响阈值计算结果
- 在对象年龄分布极不均匀的应用中（如大量短命 + 少量长命），该机制天然倾向保护长命对象快速晋升，减少无效复制
