SurvivorRatio 过大（如默认8）导致 Survivor 区过小，Minor GC 后存活对象无法容纳而 age=1 即晋升老年代，引发老年代快速填满、碎片化及 Promotion Failed，最终 OOM；需结合 jstat 和 GC 日志调小该值并清理“假短命”对象。
SurvivorRatio 过小不是导致对象“过早晋升”的原因，恰恰相反——SurvivorRatio 过小会让 Survivor 区变大，反而延缓晋升；真正引发对象过早晋升老年代并最终 OOM 的，是 SurvivorRatio 设置过大（比如默认 8 或更高），导致 Survivor 空间严重不足。
为什么 SurvivorRatio 过大会引发过早晋升？
SurvivorRatio 表示 Eden 区与单个 Survivor 区的容量比。例如：
-
-XX:SurvivorRatio=8→ Eden : S0 : S1 = 8 : 1 : 1 → Survivor 合计仅占年轻代的 20% -
-XX:SurvivorRatio=4→ Eden : S0 : S1 = 4 : 1 : 1 → Survivor 合计占年轻代的 40%
当 SurvivorRatio 过大（如 8、10、12），Survivor 区太小，Minor GC 后存活的对象没地方放，JVM 只能将溢出部分直接晋升老年代——哪怕这些对象才活了 1 轮 GC（age=1）。日志中常见信号包括：
- GC 日志出现
Desired survivor size > actual -
tenuring threshold = 1（晋升阈值被自动压到 1） - 每次 Minor GC 后
PSYoungGen: xxxK->yyyK(zzzK)中箭头右侧数值（即晋升量）持续高于 5–10MB
过早晋升如何滚雪球式引发 OOM？
这不是一次性的内存耗尽，而是一个恶性循环：
立即学习“Java免费学习笔记（深入）”；
- 大量 age=1 对象涌入老年代 → 老年代占用率快速上升
- 老年代碎片化加剧，可用连续空间减少
- 下一次晋升请求到来时，即使老年代总剩余空间够，也因无法满足大对象连续分配而触发
Promotion Failed - Promotion Failed 强制触发 Full GC；若 Full GC 无法回收足够空间（尤其存在长期缓存、静态引用等），很快抛出
java.lang.OutOfMemoryError: Java heap space
怎么验证和调整 SurvivorRatio？
不能凭感觉调，必须结合运行时数据：
- 用
jstat -gc <pid> 1000观察S0U/S1U是否长期 >90%，且EU（Eden 使用率）频繁打满 - 开启
-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintTenuringDistribution，重点看每轮 GC 后的age分布和Desired survivor size - 压测中若发现
Desired survivor size常超 300MB，但实际 S0+S1 总和才 200MB，就该调小 SurvivorRatio（如从 8 → 4） - 固定新生代大小：
-Xmn512m -XX:SurvivorRatio=4，避免 JVM 动态伸缩干扰比例效果
调完 SurvivorRatio 还要防“假短命”对象
很多所谓“短命对象”，其实是代码层泄漏的伪装者：
- JSON 解析后未释放的
JsonNode树，反复被引用 - 线程局部缓存（ThreadLocal）里存的
StringBuilder或 byte[]，生命周期远超单次请求 - 中间 DTO 持有上游响应体（如 Base64 字符串），体积大、存活久
这类对象在 Eden 分配时不触发大对象规则（-XX:PretenureSizeThreshold），又因 Survivor 太小被迫提前晋升——它们才是压垮老年代的主力。调参只是止血，代码清理才是根治。
