8:1:1是新生代eden与两个survivor区的内存比例，源于对象生命周期经验分布，在eden大小、survivor容错能力与空间效率间取得平衡；对应eden占80%、每个survivor各占10%；仅对parallel、serial等复制算法收集器生效，g1动态调整，zgc/shenandoah无效；调优需依据gc日志问题而非盲目修改。
8:1:1 这个比例不是凭空设定的，而是基于大量实际应用中对象生命周期分布规律的经验性平衡结果——大多数新创建对象“朝生暮死”，只有极小一部分能活过几次 Minor GC。
为什么是 8:1:1 而不是其他比例？
这个划分本质是在三个目标之间找折中：
- Eden 区要足够大：让大批短命对象能集中分配、一次性回收，减少 Minor GC 频次
- Survivor 区不能太小：否则刚熬过一次 GC 的对象没地方放，只能直接晋升老年代，造成老年代过早膨胀
- Survivor 区也不能太大：新生代空间有限，过度倾斜给 Survivor 会压缩 Eden，反而增加 GC 次数
8:1:1 对应的实际内存占比怎么算？
注意：-XX:SurvivorRatio=8 表示的是 Eden : 单个 Survivor = 8 : 1，不是 Eden : S0 : S1 = 8 : 1 : 1 的直觉理解。但因为有两个 Survivor 区（S0 和 S1），且大小相等，所以最终比例确实是 Eden : S0 : S1 = 8 : 1 : 1。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
计算方式为：
总份数 = 8（Eden） + 1（S0） + 1（S1） = 10 份
→ Eden 占新生代的 8/10 = 80%
→ 每个 Survivor 各占 1/10 = 10%
这个比例在不同 GC 器下是否都生效？
它只对使用复制算法的分代式收集器有效：
- Parallel GC、Serial GC：严格遵循 -XX:SurvivorRatio，默认就是 8，完全生效
- G1 GC：不按固定比例划分；Survivor 区是动态选取若干 Region 构成的，参数仅作初始参考，实际比例由运行时决定
- ZGC、Shenandoah：无传统 Survivor 概念，该参数无效
调优时要不要改这个值？
改的前提是观察到明确问题，而不是“听说别人都调了”：
- 如果 GC 日志里频繁出现
Desired survivor size超出当前 Survivor 容量，说明 Survivor 不够用 → 可尝试降低 SurvivorRatio（如设为 4 或 2） - 如果 Minor GC 特别频繁，但每次回收后 Eden 几乎清空、Survivor 使用率长期低于 10%，说明 Eden 太小 → 可适当提高 SurvivorRatio（如 10 或 12）
- 多数业务系统跑默认值（8）完全够用，盲目修改反而可能引发晋升过早或 GC 加频
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
