动态对象年龄判定机制根据survivor区各年龄对象累计大小是否超过targetsurvivorratio（默认50%）动态设定晋升阈值，且不超过maxtenuringthreshold；需启用useadaptivesizepolicy才生效，可通过gc日志中“new threshold”确认实际值。
对象晋升老年代的临界阈值不是固定值，而是由 TargetSurvivorRatio 和实际 Survivor 中各年龄对象分布共同决定的动态结果；MaxTenuringThreshold 只是上限，不参与日常计算。
怎么看 GC 日志里的实际晋升年龄？
启用 -XX:+PrintGCDetails 后，Minor GC 日志中会出现类似这样的行：
Desired survivor size 524288 bytes, new threshold 2 (max 6)
其中 new threshold 2 就是本次 GC 后实际生效的晋升年龄——它可能比 max 6 小很多。这个值每轮 Minor GC 都可能变化，只要 Survivor 区内年龄 1 对象累计占了 55%，下一轮就直接按年龄 ≥1 晋升。
- 若日志中长期显示
new threshold 6 (max 6)，说明动态机制没触发，Survivor 空间太宽松或对象死得快 - 若频繁出现
new threshold 1或2，大概率是 Survivor 过小或某批对象生命周期高度一致（如批量请求生成的 DTO） -
Desired survivor size是 JVM 计算出的目标 Survivor 占用上限，不是当前实际使用量
为什么 TargetSurvivorRatio 默认 50% 很关键？
这个参数决定了“累计多少就算过半”，是动态年龄判定的触发开关。JVM 会从小到大累加各年龄对象大小：
- 年龄 1 对象占 40%，年龄 2 占 18% → 累计到年龄 2 为 58% > 50% →
new threshold = 2 - 年龄 1 占 30%，年龄 2 占 20%，年龄 3 占 10% → 累计到年龄 3 为 60% →
new threshold = 3 - 所有年龄累计都 ≤50% → 退回到按
MaxTenuringThreshold晋升
注意：TargetSurvivorRatio 不是 Survivor 实际使用率目标，而是一个判定阈值；它只在 UseAdaptiveSizePolicy 启用时才起作用（该参数默认开启，但被显式关闭后整个动态机制失效）。
SurvivorRatio 调得太小会放大动态阈值波动
当设置 -XX:SurvivorRatio=2（即 Eden:Survivor = 2:1，每个 Survivor 仅占年轻代 1/4），Survivor 空间极易被填满，导致：
- Minor GC 后存活对象稍多一点，To Space 就装不下 → 直接晋升老年代（非年龄原因）
- 即使对象年龄只有 1，只要这批对象总大小超过 Survivor 一半，就触发动态晋升 →
new threshold骤降到 1 - 老年代压力陡增，可能引发提前 Full GC，尤其在流量脉冲场景（如秒杀）
实践中更稳妥的配置是 -XX:SurvivorRatio=6（Eden:Survivor = 6:2），让每个 Survivor 占年轻代 1/4 → 实际是 25%，留出缓冲空间，降低误触发概率。
哪些操作会让动态年龄机制完全失效？
最常见的是人为关闭自适应策略：
-
-XX:-UseAdaptiveSizePolicy：直接禁用全部自适应行为，包括 Survivor 大小调整和动态年龄计算 → 所有对象严格按MaxTenuringThreshold晋升 - 使用 CMS + ParNew 组合但未配
-XX:+UseCMSCompactAtFullCollection：虽不影响动态年龄本身，但老年代碎片化会导致分配担保失败，间接掩盖真实晋升路径 - GC 日志没开
-XX:+PrintGCDetails：你根本看不到new threshold，只能靠猜
真正难调试的不是阈值怎么算，而是当 new threshold 在 1～4 之间高频跳变时，你得顺着它去查那批“刚好卡在临界点”的对象——它们往往来自同一段业务逻辑、共享同一个构造路径，而不是随机分布的垃圾。
