调优 SurvivorRatio 的核心目标是让对象在新生代中“该死的及时死、该活的稳住活”，避免因 Survivor 空间不足导致短命或中寿对象过早晋升到老年代；其值为 Eden 区大小与单个 Survivor 区大小之比，如 -XX:SurvivorRatio=8 表示 Eden:S0:S1=8:1:1；需结合 GC 日志中 Desired survivor size、age table 晋升年龄及 tenuring threshold 判断是否真需调整；应按应用对象生命周期选择：Web 类用 10~15，中寿对象多用 4~6，通用场景默认 8；且须确保年轻代大小已固定，并关闭自适应策略（-XX:-UseAdaptiveSizePolicy）以使设置生效。
调优 SurvivorRatio 的核心目标，是让对象在新生代中“该死的及时死、该活的稳住活”，避免因 Survivor 空间不足导致短命或中寿对象过早晋升到老年代。
先搞清它到底控制什么
SurvivorRatio = Eden 区大小 ÷ 单个 Survivor 区大小，不是 Eden 对两个 Survivor 的总和比。比如 -XX:SurvivorRatio=8 表示 Eden : S0 : S1 = 8 : 1 : 1，即 Eden 占年轻代的 80%，每个 Survivor 各占 10%。S0 和 S1 始终等大、角色互换，只有一块在用，另一块清空备用。
看 GC 日志，判断是否真需要调
别凭感觉调，重点盯这两条日志线索：
- 日志里频繁出现
Desired survivor size远大于实际可用 Survivor 空间（如 “Desired: 2097152 bytes, new threshold: 1 (max: 15)”）→ Survivor 不够用 -
Age table中大量对象在年龄 1 或 2 就被强制晋升 → Survivor 没地方放，只能提前送走 -
tenuring threshold被 JVM 动态压到 1 或 2 → 自适应策略已“认输”，说明 Survivor 区持续吃紧
按对象生命周期选合适值
不追求统一标准，而要匹配你应用的对象行为：
-
Web 请求类（大量瞬时对象）：Eden 要宽，Survivor 可略小 →
SurvivorRatio=10~15（Eden 占 88%~94%，Survivor 合计仅 6%~12%） -
含缓存/会话/临时 DTO 的中寿对象较多：Survivor 得撑住几轮 GC →
SurvivorRatio=4~6（Eden 占 67%~80%，每个 Survivor 占 11%~17%，缓冲更足） -
通用平衡场景（默认够用）：保持
SurvivorRatio=8（Eden 80%，S0/S1 各 10%），适合多数 Spring Boot、微服务应用
配合其他参数一起看才有效
SurvivorRatio 不是孤立变量：
- 它生效的前提是年轻代大小已确定（靠
-Xmn或-XX:NewRatio）。若年轻代本身太小，再调 SurvivorRatio 也无济于事 - 若开启
-XX:+UseAdaptiveSizePolicy（默认常开），JVM 会动态覆盖你设的 SurvivorRatio → 调优前建议显式关闭：-XX:-UseAdaptiveSizePolicy - 搭配
-XX:+PrintTenuringDistribution观察每轮 GC 后各年龄对象分布，验证调参后“年龄曲线”是否更平缓、晋升是否延迟
