晋升阈值由survivor区使用压力动态决定，非固定值；-xx:maxtenuringthreshold仅设上限，默认15，实际阈值如“new threshold 2 (max 15)”所示；调优首选-xx:survivorratio增大survivor容量，配合合理上限防止age=1即晋升。
调整对象晋升老年代的年龄阈值，核心不是硬设一个固定数字，而是让晋升节奏匹配对象真实存活时间——短期对象该在新生代“自然死亡”，别挤进老年代添乱。
理解 MaxTenuringThreshold 是上限，不是指令
-XX:MaxTenuringThreshold 设置的是晋升年龄的**最大允许值**（默认 15），但 JVM 实际采用的晋升阈值由 Survivor 区使用压力动态决定。日志里出现 “new threshold 2 (max 15)” 就说明：JVM 已把实际阈值压到 2，因为 age≥2 的对象总大小已超 Survivor 容量的一半。
- 这个动态机制由 -XX:TargetSurvivorRatio 控制，默认为 50（即 50% 占用率触发晋升）
- 真正影响“什么时候晋升”的，是 Survivor 空间大小和对象分布密度，不是你写的那个 MaxTenuringThreshold 数字
- 盲目设成 0 或 1，等于废掉 Survivor 缓冲，所有存活对象 GC 后直奔老年代，反而加重老年代压力
用 SurvivorRatio 主动调控晋升节奏
最直接、最有效的干预方式是调整 Survivor 区占比，从而改变“50% 触发线”的实际容量门槛：
- 原配置 -XX:SurvivorRatio=8 → Eden:S0:S1 = 8:1:1，Survivor 总共只占年轻代 1/5，容易被填满 → 阈值下探 → 小对象早晋升
- 改成 -XX:SurvivorRatio=4 → Eden:S0:S1 = 4:1:1，Survivor 总容量翻倍 → 同样一批对象只占约 25% 空间 → 更难触达 50% 累加线 → 对象多熬几次 Minor GC
- 配合 -XX:MaxTenuringThreshold=6 设个合理上限，既给动态机制留空间，又防极端情况（如 Survivor 突然爆满）导致 age=1 就晋升
盯紧两个日志指标验证效果
改完参数必须立刻看 GC 日志，确认是否真起作用：
- Survivor 使用率：关注每次 Minor GC 后 S0/S1 的百分比（如 “S0: 32%”）。目标是稳定在 30%～45%，长期 > 50% 就说明 Survivor 还是偏小，或对象存活异常
- 单次晋升量：找日志中 “tenured” 或 “promoted” 字段后的字节数。若从平均 200KB 跳到 1.5MB，且对应那次 GC 的 Survivor 使用率达 48%，基本就是动态晋升被触发了
顺手堵住其他早晋升漏洞
晋升年龄只是其中一环，还得同步清理常见干扰项：
- 检查代码有没有显式调用 System.gc()，加上 -XX:+DisableExplicitGC 强制禁用
- 排查大对象误入新生代：用 -XX:PretenureSizeThreshold 把超阈值的大对象直接分配到老年代
- 避免装箱类型滥用（如频繁 Integer.valueOf(128)），这类对象生命周期短但体积不小，易撑满 Survivor
- 确认 GC 回收器类型（Parallel/G1/CMS），不同回收器对动态阈值的实现细节略有差异，G1 默认 max=15，CMS 默认 max=6
