动态年龄判定策略的核心是依据Survivor区实时占用率（≥50%）动态确定晋升年龄阈值，而非固定值；通过调整SurvivorRatio、MaxTenuringThreshold并监控GC日志中survivor使用率与晋升量来优化对象晋升节奏。
调优对象年龄判定策略，核心是让对象在新生代停留时间更合理——既不因过早晋升增加老年代压力，也不因滞留过久引发频繁 Minor GC。关键不在“设死一个固定年龄”，而在于理解并干预 JVM 动态晋升的触发逻辑。
理解动态年龄判定的真实含义
所谓“动态年龄判定”，不是指 JVM 随机决定年龄阈值，而是基于 Survivor 区实际占用情况实时计算：Minor GC 后，JVM 会按年龄从小到大累加 Survivor 中对象的总大小；当累计到某一年龄 N 时，总和首次超过 Survivor 总容量的约 50%（G1 可能略浮动），那么所有年龄 ≥ N 的对象就直接晋升到老年代。
这意味着：
- 年龄阈值不是预设的 15，而是每次 GC 都可能变化的“临界点”
- 真正起作用的是 Survivor 区的空间利用率，而非对象存活次数本身
- 如果 Survivor 区长期空闲，哪怕对象活了 10 次，也可能不晋升；反之，若小对象扎堆，年龄为 2 就可能触发晋升
调整 Survivor 容量来影响晋升节奏
Survivor 区大小直接决定“50% 累加线”的绝对值，是调控动态年龄最直接的杠杆：
- 增大 Survivor（如通过 -XX:SurvivorRatio=6 降低 Eden/Survivor 比例），相同数量的对象占空间比例变小，更难触发动态晋升 → 对象倾向多熬几次 GC
- 减小 Survivor（如 -XX:SurvivorRatio=8），小对象更容易堆满半区 → 年龄阈值提前下探，晋升加快
- 注意：Survivor 过小会导致“年龄 1 对象就超 50%”，大量对象刚进 Survivor 就晋升，失去新生代缓冲意义
配合 MaxTenuringThreshold 控制上限
-XX:MaxTenuringThreshold 不是默认晋升年龄，而是动态计算出的阈值的“天花板”。例如设为 6，即使动态算出应按年龄 8 晋升，也最多按 6 执行。
- 设为 0：禁用年龄晋升，所有存活对象 Minor GC 后直接进老年代（慎用）
- 设为 1：等效于关闭 Survivor 缓冲，仅保留 Eden → Survivor 复制流程，适合极短生命周期场景
- 生产环境建议保持默认 15 或设为 6–10，给动态机制留出调节空间，避免一刀切
观察与验证的关键指标
调优不能只改参数，必须结合 GC 日志确认效果：
- 关注每次 Minor GC 后的 survivor 区使用率（如 “S0: 45%”、“S1: 12%”）——持续高于 40% 说明 Survivor 偏紧，易触发早晋升
- 检查晋升对象大小（日志中 “tenured” 或 “promoted” 字段）——若单次晋升量突增，且对应 Survivor 使用率接近 50%，大概率是动态规则生效
- 对比调整前后 老年代增长速率 和 Minor GC 频次：理想状态是老年代缓慢增长、Minor GC 周期拉长、停顿稳定
