年轻代与老年代比例调优需依对象生命周期动态匹配：短生命周期场景增大年轻代（如-xx:newratio=1），长生命周期场景缩小年轻代（如-xx:newratio=4~6），混合业务从默认2起步；survivorratio调小可扩大survivor区防过早晋升；须结合gc日志验证效果，大堆建议用-xmn直接设年轻代大小，g1收集器无需调newratio。
年轻代与老年代比例调优不是“设个参数就完事”，而是要根据对象生命周期特征，动态匹配内存分配节奏，从而减少 GC 停顿、降低晋升压力、避免 Full GC。核心在于用对 -XX:NewRatio 和 -XX:SurvivorRatio，而不是盲目调大或调小。
看对象生命周期定比例方向
应用的对象“活多久”决定该给哪一代更多空间：
- Web API、电商下单等短生命周期场景：90%以上对象在几秒内死亡 → 增大年轻代比例（如
-XX:NewRatio=1，年轻代占堆 50%），让对象尽量在年轻代被回收，不进老年代 - 缓存服务（如 Redis 客户端本地缓存）、连接池、长会话对象：大量对象存活数分钟甚至更久 → 缩小年轻代、扩大老年代（如
-XX:NewRatio=4~6），避免老年代频繁填满触发 Full GC - 混合型业务（如后台管理+实时报表）：建议从默认
-XX:NewRatio=2（年轻代占 1/3）起步，再根据监控调整
用 SurvivorRatio 控制对象“多活一轮”
年轻代内部 Eden 和 Survivor 的比例，直接影响对象是否“过早晋升”。Survivor 区太小，哪怕对象只活过一次 GC，也会因空间不足被直接送进老年代：
- 默认
-XX:SurvivorRatio=8→ Eden 占年轻代 80%，每个 Survivor 仅 10% - 若 GC 日志中看到
Promotion failed或tenured gen occupancy上升快 → 说明 Survivor 不够用，可调为-XX:SurvivorRatio=4（Eden 66.7%，每个 Survivor 16.7%） - 特别注意：SurvivorRatio 调小（数值变小）= Survivor 区变大，不是变小；数值越大，Eden 越“胖”，Survivor 越“瘦”
结合 GC 日志验证真实效果
调参后不看日志，等于没调。关键指标要盯住：
- 加参数启动：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log - 重点关注字段：
GC pause时长、Young GC间隔（理想 >10 秒）、Promoted（每次 Young GC 晋升到老年代的字节数） - 典型失衡信号：
– Young GC 频繁（– Promoted 值持续偏高（接近每次 Young GC 回收量的 20% 以上）→ Survivor 不足或晋升阈值过低
– Full GC 出现 → 老年代真的撑不住了，要么扩容，要么减少晋升
避开常见踩坑点
很多性能问题其实来自“合理但错配”的配置：
-
别和 -Xmn 同时用：显式设置
-Xmn（如-Xmn2g）会覆盖-XX:NewRatio，两者选其一 -
大堆慎用 NewRatio：堆 >8GB 时，建议用
-Xmn直接指定年轻代大小，更可控；NewRatio 在大堆下容易导致年轻代过大（如 16GB 堆设 NewRatio=2 → 年轻代约 5.3GB），反而增加 Minor GC 停顿 -
G1 收集器不用调这个：G1 是区域化收集器，自动管理分代比例，
-XX:NewRatio对它基本无效，应专注-XX:MaxGCPauseMillis等 G1 特有参数
