动态年龄判定是JVM根据Survivor区各年龄段对象大小实时计算晋升阈值，而非固定等待指定GC次数；其核心是空间保底策略，防止Survivor区被占满，依据累计占比超50%确定new threshold，需配合SurvivorRatio等参数协同调优。
动态年龄判定不是“等对象活够几轮再搬家”，而是JVM在每次Minor GC后，根据Survivor区里各年龄段对象的实际大小分布，实时决定哪些对象该晋升。它让晋升行为更贴近真实内存压力，但也会导致对象提前进入老年代，进而影响GC频率和系统稳定性。
它让晋升年龄变得不固定
默认-XX:MaxTenuringThreshold=15只是上限，真正起作用的是动态算出的“new threshold”。比如：
- Survivor总空间512KB，age1对象占280KB（>50%）→ new threshold=1，所有age1及以上对象下次GC就进老年代
- age1占300KB，age2占200KB → 累计到age2达500KB（>50%）→ new threshold=2，age2及以上晋升
- 所有年龄段累加始终≤50% → 才退回到按MaxTenuringThreshold（如15）执行
容易引发老年代过早承压
当new threshold频繁为1或2时，大量本该短期存活的对象被提前送入老年代：
- 秒杀场景中批量生成的DTO对象生命周期高度一致，容易集中堆积在某一年龄段
- SurvivorRatio设置过小（如设为2，Survivor仅占年轻代1/4），空间紧张，加速触发判定
- 结果是老年代快速填满，Full GC频次上升，停顿时间不可控
它依赖多个参数协同生效
单独调大MaxTenuringThreshold没用，必须配合其他配置才能稳定控制晋升节奏：
立即学习“Java免费学习笔记（深入）”；
- -XX:SurvivorRatio=6～8：让每个Survivor占年轻代1/8～1/10，留出缓冲余量
- -XX:TargetSurvivorRatio=50（默认）：这是判定触发线，仅在-XX:+UseAdaptiveSizePolicy开启时有效（默认开）
- 必须配合-XX:+PrintGCDetails观察日志中的“new threshold X (max Y)”字段，才能确认实际生效值
本质是空间保底策略，不是生命周期判断
这套机制的核心目标不是“识别长期存活对象”，而是防止Survivor被大龄对象占死，导致后续Minor GC无法安置新存活对象：
- 哪怕一个对象只活了2次GC，只要它所在年龄档+更小年龄档的对象总和撑爆Survivor一半，它就得走
- 它不关心业务语义，只响应内存布局——这是JVM做实时权衡的结果，不是错误
- 因此优化方向不是“阻止晋升”，而是通过调参让Survivor容量与对象分布更匹配
