动态年龄判定机制在survivor区过小或targetsurvivorratio配置失当时，会触发早晋升，导致大量中龄对象涌入老年代，引发老年代快速填满、碎片化加剧及full gc雪崩；其根本底线是单survivor区容量≥峰值下3轮存活对象内存的1.5倍，且maxtenuringthreshold≥4并大于实测生命周期轮次。

生产底线不是“能不能跑”，而是“会不会在高负载下突然卡死或OOM”。动态年龄判定机制本身不制造问题，但若配置失当或流量突变，它会把压力直接放大成老年代雪崩。

Survivor区容量必须撑住最差分布

动态年龄判定的触发条件是“某年龄及以下对象总大小 ≥ Survivor区容量 × TargetSurvivorRatio（默认50%）”。这意味着：一旦Survivor区实际可用空间长期低于理论值的50%，机制就会频繁提前晋升——哪怕对象才2岁。

• 根本风险点：Survivor区太小 → 存不下几轮存活对象 → 累加很快超阈值 → 大量中龄对象涌进老年代
• 典型诱因：-XX:SurvivorRatio设得过大（如16），导致S0/S1各只占年轻代约3%，物理空间极窄
• 底线建议：Survivor区单区容量 ≥ 预估峰值下3轮Minor GC后仍存活对象总内存的1.5倍（留出缓冲）

TargetSurvivorRatio不能脱离实际存活率硬调

默认50%是平衡点，不是安全线。若业务对象平均存活轮次为4～5轮，Survivor区占用常态达60%以上，此时还用50%，等于每天都在主动“清仓甩卖”。

• 现象：GC日志里频繁出现“age ≥ 2 → promoted”，但对象其实本可再活2轮
• 后果：老年代快速碎片化 + Full GC频率翻倍 + 暂停时间不可控增长
• 底线建议：通过-XX:+PrintGCDetails持续采样1小时以上，观察Survivor After GC占用率中位数；若稳定＞65%，应调高TargetSurvivorRatio（如60或70），并同步增大Survivor区

MaxTenuringThreshold必须兜底防误判

动态计算出的晋升年龄N，上限受-XX:MaxTenuringThreshold硬性约束。若该值被设为1（极端配置），等于关闭兜底——所有年龄≥1的对象，只要Survivor一满就全进老年代。

• 真实事故场景：某支付系统将MaxTenuringThreshold误配为1，大促时Survivor区瞬时占用达51%，结果98%的存活对象单轮GC后全部晋升，10分钟内老年代使用率从30%飙到95%
• 底线建议：MaxTenuringThreshold ≥ 4（保障至少熬过3轮GC），且必须大于等于业务实测的“典型中期对象生命周期轮次”

不能忽略TLAB与对象对齐带来的隐性挤压

TLAB在Eden区内部分配，但对象头、数组填充、8字节对齐等会导致实际内存占用比逻辑大小多5%～20%。这部分“看不见的膨胀”会悄悄吃掉Survivor空间预算。

• 影响链：TLAB分配偏移 → Eden中对象实际布局更稀疏 → Minor GC后复制到Survivor的对象密度下降 → 同样数量对象占更多Survivor字节 → 更早触发动态晋升
• 底线建议：压测时开启-XX:+PrintTLAB，检查Average TLAB size与Waste占比；若Waste > 15%，需调小-XX:TLABSize或启用-XX:+UseTLAB优化对齐