eden与survivor比例应根据业务对象生命周期动态调整：短命对象多则增大eden（如survivorratio=8），中长寿命对象多则扩大survivor（如ratio=4），需禁用自适应策略并联动maxtenuringthreshold与-xmn调优。
直接看业务对象生命周期——这是决定Eden与Survivor比例的底层依据。比例本身不是固定值，而是对应用内存行为的映射：短命对象多，就该让Eden更大；中长生命周期对象多，Survivor就得留足空间扛住多次复制。
先搞清你的对象“活多久”
多数Web服务请求对象存活时间极短（毫秒级），这类场景下，80% Eden + 10%+10% Survivor（即-XX:SurvivorRatio=8）往往够用。但若业务含较多缓存对象、会话状态或中间计算结构（比如批处理中的聚合实体），它们常在Minor GC后仍存活2~5轮，此时默认Survivor就容易溢出。
- 用-XX:+PrintGCDetails -XX:+PrintGCDateStamps开启详细GC日志
- 重点关注每次Minor GC后S0U/S1U（Survivor使用量）是否持续高于70%
- 观察YGC次数和YGCT（耗时），高频低耗说明Eden偏小；低频高耗可能Survivor不足导致对象提前晋升
动手调参：从SurvivorRatio开始试错
调整不是拍脑袋，而是按梯度验证：
- 若Survivor使用率长期＞85%，尝试-XX:SurvivorRatio=4（Eden占40%，每个Survivor升至30%）
- 若Minor GC频繁（如每秒多次）且Eden几乎一填就满，可试-XX:SurvivorRatio=10（Eden占83.3%，Survivor各占8.3%）
- 注意：改完必须关掉自适应策略——加-XX:-UseAdaptiveSizePolicy，否则JVM会动态覆盖你的设置
配合其他参数形成闭环
单独调SurvivorRatio效果有限，要和年龄阈值、年轻代总量联动：
- Survivor空间增大后，可适当降低晋升门槛：-XX:MaxTenuringThreshold=4（避免对象在Survivor反复拷贝浪费CPU）
- 若发现老年代增长变快，说明仍有对象过早晋升，这时需结合-Xmn整体扩大年轻代，而非只调比例
- 对G1收集器不适用此模型——它没有固定Eden/Survivor概念，应改用-XX:MaxGCPauseMillis和-XX:G1HeapRegionSize调控
验证是否真的变好
别只看GC次数减少，重点盯三个指标：
- 老年代占用增速：下降说明晋升减少，调优有效
- Full GC触发频率：明显降低是最大收益点
- 应用P99延迟波动：Minor GC停顿变短且更稳定，说明内存布局匹配业务节奏
