survivor区大小固定不变，所谓“动态”实指晋升年龄阈值的动态调整：jvm每次minor gc后按年龄累加survivor中对象大小，首次超过其容量×targetsurvivorratio（默认50%）的年龄即设为新阈值，所有≥该年龄的对象晋升老年代，该阈值每轮可变，日志中“new threshold x”即体现此机制。

Survivor空间本身不支持动态扩展，它在JVM启动时就按固定比例（如-XX:SurvivorRatio=8）静态划分完毕，运行中大小恒定。所谓“动态”，实际是指对象晋升年龄阈值的动态调整机制，而非Survivor内存容量可伸缩。

Survivor区大小是静态分配的

新生代内Eden、S0、S1三者比例由-XX:SurvivorRatio决定，例如设为8时，Eden占8份，每个Survivor各占1份，总和10份。若-Xmn=1G，则每个Survivor固定为100MB，全程不可变。JVM没有提供运行时增大Survivor容量的参数或API。

• 所有GC日志中S0U/S1U数值变化，反映的是对象占用率，不是空间扩容
• 监控工具（如jstat）显示的S0C/S1C字段即committed size，始终不变
• 试图通过代码或JMX修改Survivor大小会失败，该区域由GC线程直接管理

真正“动态”的是晋升年龄阈值

Minor GC后，JVM扫描Survivor区中各年龄档对象的累计大小，一旦从age=1开始累加，首次达到Survivor总容量×TargetSurvivorRatio（默认0.5），就将该年龄设为新晋升起点——这就是常被误读为“Survivor动态扩展”的核心逻辑。

悟道

悟道是一款AI大模型工具，智源“悟道”大模型，中国首个+世界最大人工智能大模型。

下载

• 例如：Survivor共512KB，age1占200KB，age2占180KB，age3占140KB → age1+age2=380KB＜512KB×0.5，但age1+age2+age3=520KB≥256KB → new threshold=3
• 下次GC时，所有age≥3的对象直接进老年代，不管MaxTenuringThreshold设为多少
• 该阈值每轮Minor GC都可能重算，日志中“new threshold X”即体现此动态性

为什么容易误解为“Survivor能扩展”

当Survivor过小（如SurvivorRatio=8导致单个Survivor仅占10%），age1对象稍多就触发阈值下调（如new threshold 1），大量对象“一岁就走”。这种高频晋升现象，让人误以为Survivor“撑不住所以扩容了”，实则是空间不足倒逼年龄门槛降低。

• 典型症状：GC日志频繁出现“new threshold 1 (max 15)”且S0U/S1U长期低于10%
• 本质问题：不是Survivor要扩展，而是需要调大它（如改SurvivorRatio=4）来容纳更多年轻对象
• 扩容操作只能在重启JVM时通过参数调整，属于配置变更，非运行时动态行为

应对Survivor压力的实用做法

与其期待Survivor自动扩展，不如主动优化其配置与使用模式：

• 压测应用，观察-XX:+PrintTenuringDistribution输出，确认对象真实存活年龄分布
• 若age1占比持续＞40%，说明Survivor太小，应减小SurvivorRatio（如从8→4）扩大其占比
• 若对象生命周期短且集中（如Web请求VO），可配合-XX:MaxTenuringThreshold适当降低阈值，避免滞留
• 启用-XX:+UseAdaptiveSizePolicy时，JVM会自动调整SurvivorRatio，但仅限于Parallel GC，且效果有限