-xx:maxtenuringthreshold 是晋升年龄的上限值而非固定阈值，jvm根据survivor空间动态调整实际晋升年龄；设为15常无效，因默认即15且自适应策略会主动降低；g1/zgc等新gc器不使用该参数；应结合gc日志观察desired survivor size与new threshold，优先调优survivorratio或xmn。
什么是 -XX:MaxTenuringThreshold 的实际作用
它不是“对象必须活过多少次 GC 才进老年代”的硬性计数器，而是 JVM 动态计算晋升年龄的**上限值**。真实晋升年龄由 JVM 运行时根据幸存区空间使用情况动态决定，MaxTenuringThreshold 只是兜底限制——哪怕对象在 Survivor 中只熬过 2 次 GC，只要 Survivor 空间快撑不住了，JVM 就可能提前把它推进老年代，哪怕当前阈值设的是 15。
为什么调高 -XX:MaxTenuringThreshold=15 常常没效果
HotSpot 默认就是 15（CMS 是 6，G1 不用这个参数），但多数情况下你根本看不到对象真按 15 次才晋升。原因很实在：
- Survivor 区太小，几轮 GC 后就塞满，JVM 主动降级阈值（日志里会打印
Desired survivor size和new threshold） - 开启了
-XX:+UseAdaptiveSizePolicy（默认开启），JVM 会持续重算阈值，你的静态设置只是天花板 - G1、ZGC、Shenandoah 等新垃圾收集器压根不看这个参数，它们用完全不同的晋升逻辑
真正该盯住的日志和参数组合
光改 MaxTenuringThreshold 是盲调。得结合 GC 日志确认行为是否符合预期：
- 加
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，重点看每次 Young GC 后的Desired survivor size和new threshold - 如果
new threshold总是远低于你设的值（比如设了 15，日志却总写new threshold = 2），说明 Survivor 容量才是瓶颈 - 此时应优先调
-XX:SurvivorRatio（如设为 8，让 Eden:Survivor = 8:1:1）或直接用-Xmn加大年轻代，而不是猛提阈值
常见误操作：把 -XX:InitialTenuringThreshold 当成初始值硬设
这个参数只影响第一次 Young GC 时的初始阈值，之后全由 JVM 自适应接管。设它为 5 或 10，对后续 GC 几乎没影响。更麻烦的是：如果你同时开了 -XX:-UseAdaptiveSizePolicy（禁用自适应），那 InitialTenuringThreshold 才会固定生效——但这等于关掉了 JVM 最重要的年轻代容量调节能力，极易引发频繁 GC 或 Survivor 溢出。
立即学习“Java免费学习笔记（深入）”；
真正稳定可控的做法，是让 JVM 自己算，然后通过 -XX:SurvivorRatio 和 -Xmn 给它留够腾挪空间。阈值本身，多数时候只是个安静的上限。
