动态年龄判定是jvm在每次minor gc后，按年龄从小到大累加survivor区对象大小，首次累计≥survivor容量50%时，将≥该年龄的对象全部晋升老年代；其阈值每轮gc动态计算，不固定依赖maxtenuringthreshold。
动态年龄判定机制里，“同龄对象总大小超过 Survivor 区一半即触发晋升”不是一条静态红线，而是一条自适应的生产防御线——它不靠人工预设，而是 JVM 在每次 Minor GC 后实时计算、主动收缩或放宽的生存压力响应策略。
这条线为什么是“防御性”的？
它本质是在防止两类系统性风险：
- Survivor 区雪崩式溢出：如果大量中龄对象（比如 age=2、3）持续堆积，又不及时释放空间，下一次 Minor GC 可能连存活对象都复制不完，直接触发担保失败（HandlePromotionFailure），把本可暂存的对象全塞进老年代，加剧老年代碎片与 Full GC 频率
- 无效复制开销失控：一个 age=4 的对象若已稳定驻留、大概率长期存活，继续让它在 S0/S1 之间来回拷贝，纯属浪费 CPU 和内存带宽；提前晋升反而降低年轻代 GC 停顿时间
它如何动态“布防”？
JVM 每次 GC 后执行三步现场评估：
- 扫描 Survivor 区，按 age=1、2、3…分组统计各档对象占用字节数
- 从 age=1 开始累加，一旦累计和 ≥ Survivor 总容量 × 0.5，立即锁定当前 age 为本次晋升阈值
- 所有 age ≥ 该值的对象，在本轮 GC 结束前统一晋升，不等待下次 GC
例如：Survivor 容量为 8MB，GC 后 age=1 占 2MB、age=2 占 2.5MB、age=3 占 1.8MB → 累加到 age=2 时已达 4.5MB ＞ 4MB → 动态阈值定为 2，age≥2 全部晋升。
生产环境怎么守住这条线？
防御重点不在调大 -XX:MaxTenuringThreshold，而在匹配对象生命周期分布：
- 监控 GC 日志中的 new threshold: X 字样，连续出现 new threshold: 1 或 new threshold: 2，说明中龄对象占比畸高，需检查是否存在缓存未清理、连接池泄漏、长生命周期 DTO 等问题
- 避免盲目调大 Survivor：-XX:SurvivorRatio=6（S 区占年轻代 1/8）可能比默认 8（1/10）更合理；但若设为 2（S 区占 1/4），虽缓解溢出，却显著延长复制时间，得不偿失
- 对已知中长生命周期对象（如 Netty ByteBuf 池、RPC 上下文容器），可结合 -XX:PretenureSizeThreshold 或对象池复用，绕过年轻代流转，从源头减少 Survivor 压力
