-xx:maxtenuringthreshold 是对象晋升老年代的年龄上限（默认15），非强制阈值；实际晋升由 survivor 空间压力触发的动态年龄判定（≥某 age 对象超 survivor 50% 即晋升）主导，日志中 “new threshold x (max 15)” 即体现该动态下调结果。
MaxTenuringThreshold 控制对象在年轻代中“活够几轮”才晋升老年代，默认值是 15。但它不是一成不变的硬性门槛——JVM 会根据 Survivor 区实际使用情况动态下调，真正决定对象何时进老年代的，往往是 Survivor 区空间是否充足 和 动态年龄判定规则，而非这个参数本身。
晋升阈值的本质是“动态结果”，不是静态开关
这个参数只是上限，不是保证值。JVM 每次 Young GC 后都会评估 Survivor 区：如果某一年龄段（比如 age=3）的对象总大小已超过 Survivor 区容量的一半，那么所有 age ≥ 3 的对象就会直接晋升老年代，此时实际使用的晋升阈值就变成了 3 —— 无论你设的是 15 还是 10。
常见日志线索：
Desired survivor size 61054720 bytes, new threshold 2 (max 15)
这说明 JVM 刚把晋升阈值从默认 15 动态降到了 2，背后大概率是 Survivor 区太小或对象存活率偏高。
什么时候该调小 MaxTenuringThreshold？
调小（比如设为 1 或 5）只适用于明确知道对象生命周期短、但又因 Survivor 区挤不下而被迫提前晋升的场景。它本质是“让晋升更早发生”，避免 Survivor 区反复复制失败引发的额外开销。
- 对象创建后基本只用一次（如临时 DTO、HTTP 请求上下文），且数量大、体积小
- 观察到大量对象在 age=1 就因 Survivor 空间不足被直接送入老年代（GC 日志中 “promotion failed” 或 “to-space overflow”）
- 年轻代 GC 后老年代增长快，但老年代 GC 却不频繁（说明对象没立刻死，但也不该长期驻留）
什么时候该调大或保持默认？
调大（比如设为 15）适用于对象有明显“长尾存活”特征，且 Survivor 区足够容纳多轮幸存对象。盲目调大没用，前提是 Survivor 区真能装得下。
- 应用存在较多缓存类对象（如 Guava Cache 中的 entry）、连接池对象，它们通常要活几十秒甚至几分钟
- GC 日志显示多数对象在 age=3～6 就已死亡，说明 Survivor 区设计合理，没必要压缩晋升窗口
- 调大前先确认 -XX:SurvivorRatio 或 -Xmn 设置是否合理，否则再大的阈值也无意义
比改参数更关键的三件事
MaxTenuringThreshold 是表象，真正影响晋升行为的是底层资源配比和对象行为：
- 增大 Survivor 区：通过 -XX:SurvivorRatio（如设为 8，使每个 Survivor 占年轻代 1/10）或直接用 -Xmn 显式设置年轻代大小，给对象更多“缓冲轮次”
- 检查对象分配模式：是否存在短生命周期对象体积过大（接近 Survivor 区一半）？这类对象会直接触发动态年龄判定，应考虑拆分或复用
- 禁用自适应策略（谨慎）：-XX:-UseAdaptiveSizePolicy 可阻止 JVM 自动调整晋升阈值和空间比例，便于稳定复现和对比，但线上慎用
