java对象晋升老年代的年龄阈值由-xx:maxtenuringthreshold控制，默认通常为15（cms为6，g1基本忽略）；它设的是最大允许年龄上限，实际晋升阈值由jvm根据survivor空间使用率动态下调，日志中“new threshold x (max 15)”即体现该动态结果。
Java 对象晋升老年代的年龄阈值由 JVM 参数 -XX:MaxTenuringThreshold 控制，默认值通常是 15（在 CMS 和 G1 中可能为 6，具体取决于 GC 算法和 JDK 版本）。这个值表示对象在 Survivor 区中“熬过”多少次 Minor GC 后，就会被晋升到老年代。
如何查看当前阈值
可通过 JVM 启动参数显式设置，也可通过 GC 日志观察实际行为：
- 添加 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 启动应用，观察日志中类似
Desired survivor size …, new threshold …的输出，它反映 JVM 运行时动态计算出的当前晋升阈值（受 Survivor 空间使用率影响） - 注意：运行时阈值 ≤ MaxTenuringThreshold，JVM 会根据 Survivor 容量自动下调，避免 Survivor 溢出
如何调整阈值
在 JVM 启动参数中设置：
- -XX:MaxTenuringThreshold=10：将最大允许阈值设为 10（范围是 0–15，部分 JDK 支持设为 0 表示对象 Eden 区分配后直接晋升）
- 设为 0 是特殊场景：适用于大量短命大对象，避免 Survivor 复制开销；但会增加老年代压力，需配合老年代 GC 能力评估
- 该参数仅对使用“分代 + 复制算法”的 GC 生效（如 Parallel GC、CMS；G1 不使用传统年龄晋升机制，而是基于对象年龄和回收收益决策）
调整前要注意什么
阈值不是调得越高越好，也不是越低越优，需结合实际对象生命周期分布：
- 阈值过高（如保持默认 15）：若多数对象其实 3 次 GC 就该死了，却硬拖到 15 次才晋升，会浪费 Survivor 空间，抬高 Minor GC 频率
- 阈值过低（如设为 1）：导致本可复用的中等寿命对象过早进入老年代，加剧老年代碎片或 Full GC 风险
- 建议先用 -XX:+PrintGCDetails 观察几轮 GC 后的
age分布（日志中显示各年龄对象大小），再决定是否调整及调至何值
不同 GC 算法的差异
并非所有 GC 都严格遵循该阈值：
- Parallel GC / Serial GC：完全依赖 MaxTenuringThreshold 和动态年龄判定（满足某年龄对象总和 > Survivor 空间一半时，该年龄及以上全部晋升）
- CMS：基本同 Parallel GC，但更倾向保守晋升以减少老年代碎片
-
G1：不使用固定年龄阈值；对象年龄记录在元数据中，晋升决策基于 Region 回收优先级、存活对象比例和预测停顿时间，
MaxTenuringThreshold在 G1 中仅作为参考上限，实际很少生效 - ZGC / Shenandoah：无传统分代晋升概念，对象创建即在堆任意位置，靠并发标记与重定位管理生命周期，该参数无效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
