核心是让对象“该死在年轻代就别活到老年代”——减少晋升，等于减轻老年代压力，自然降低 Full GC 频率。关键不在强行卡年龄，而在匹配对象真实生命周期，同时堵住非正常晋升通道。JVM 依据 Survivor 区使用率动态决定晋升：Minor GC 后按年龄累加存活对象大小，超 Survivor 总容量约 50% 时，≥临界年龄的对象直接晋升；日志中频繁出现 “age 2 promoted” 或 “S0: 68%” 表明 Survivor 拥塞、阈值下探；对长期空闲却直入老年代的中等对象（如 4MB），可用 -XX:PretenureSizeThreshold 强制其走年轻代；需排查装箱类型滥用、未关闭流、静态集合无上限等导致 Survivor 占用异常或生命周期假象的问题；调优后须通过 GC 日志验证：Survivor 使用率应稳定在 30%～45%，超 50% 说明偏小或对象存活异常；单次晋升量突增（如从 200KB 跃至 1.5MB）且对应 GC 中 Survivor 使用率达 48%，即为动态晋升触发。
核心是让对象“该死在年轻代就别活到老年代”——减少晋升，等于减轻老年代压力，自然降低 Full GC 频率。关键不在强行卡年龄，而在匹配对象真实生命周期，同时堵住非正常晋升通道。
看懂晋升实际怎么发生的
JVM 并不机械执行 -XX:MaxTenuringThreshold 设的数字。它真正依据的是 Survivor 区使用率：每次 Minor GC 后，按年龄从小到大累加存活对象大小，一旦累计超过 Survivor 总容量的约 50%，所有年龄 ≥ 当前临界点的对象，就直接晋升老年代。
- 日志里频繁出现 “age 2 promoted” 或 “S0: 68%”，说明 Survivor 已被挤占过半，年龄阈值被迫下探
- 如果 Survivor 长期空闲（比如 S1 始终
- 默认 -XX:SurvivorRatio=8（Eden:S0:S1 = 8:1:1）意味着 Survivor 总共只占年轻代 20%，极易触达 50% 累加线
调 Survivor 比例，稳住晋升节奏
这是最直接、见效最快的干预手段：
- 把 -XX:SurvivorRatio=4（Eden:S0:S1 = 4:1:1），Survivor 总容量翻倍，同样一批对象只占约 25% 空间，更难触发动态晋升
- 配合设一个合理上限，如 -XX:MaxTenuringThreshold=6，既给动态机制留余地，又防极端情况（如某次突发流量导致 Survivor 突然爆满）造成 age 1 就晋升
- 避免设 MaxTenuringThreshold=0——这等于禁用 Survivor，所有存活对象 GC 后直奔老年代，对短期对象反而是雪上加霜
同步清理干扰晋升的“漏洞”
晋升年龄只是表象，背后常混着其他问题：
立即学习“Java免费学习笔记（深入）”；
- 检查代码是否调用 System.gc()，加上 -XX:+DisableExplicitGC 强制屏蔽
- 确认有没有大对象（如 >1MB 的 byte[]、List）被直接分配进老年代，通过 -XX:PretenureSizeThreshold=4194304（4MB）显式设阈值，让中等大小对象仍走年轻代路径
- 排查装箱类型滥用（如大量 Integer、Boolean 频繁创建）、未关闭的流、静态集合缓存无上限等，这些都会推高 Survivor 占用或制造长生命周期假象
用日志验证是否真起效
改完参数后必须立刻看 GC 日志，盯两个硬指标：
- Survivor 使用率：关注每次 Minor GC 后 S0/S1 的百分比（如 “S0: 32%”）。目标是稳定在 30%～45%，长期 >50% 就说明 Survivor 还是偏小，或对象存活异常
- 单次晋升量：找日志里 “tenured” 或 “promoted” 字段后的字节数。若从平均 200KB 跳到 1.5MB，且对应那次 GC 的 Survivor 使用率达 48%，基本就是动态晋升被触发了
