必须显式固定年轻代大小（如-xmn1g），因jvm无动态扩缩机制；-xx:+useadaptivesizepolicy仅调eden/survivor比例，不改变总量，反而易致survivor过小、对象过早晋升老年代。

直接设固定年轻代大小，比指望“自动适应”更可靠。JVM 没有动态扩年轻代的机制，所谓自适应策略（-XX:+UseAdaptiveSizePolicy）只调 Eden 和 Survivor 的内部比例，不改变年轻代总量，反而容易压垮 Survivor 导致对象一次 GC 就逃逸进老年代。

为什么年轻代初始大小必须显式固定

年轻代总大小只由两个参数之一决定：

• -Xmn：优先级最高，如 -Xmn1g，年轻代恒为 1GB，完全不受流量波动影响
• -XX:NewRatio：仅在未设 -Xmn 时生效，比如 -XX:NewRatio=2 表示老年代:年轻代 = 2:1，堆为 6G 时年轻代固定为 2G

两者都不可变。JVM 不会因为 QPS 翻倍就把年轻代从 1G 自动拉到 2G —— 这不是缺失功能，而是设计使然。

如何用固定参数阻断代际逃逸链

突发流量下频繁代际逃逸（Premature Promotion）本质是 Survivor 区被 AdaptiveSizePolicy 压缩到几 MB，导致存活对象无处安放，直接进老年代。应对关键是：关干扰、保空间、控节奏。

• 关闭自适应：-XX:-UseAdaptiveSizePolicy（JDK 8+ 默认开启，高并发场景必须关）
• 固定年轻代大小：-Xmn1g（按压测结果定，4G 堆建议配 1~1.5G）
• 扩大 Survivor 容量：-XX:SurvivorRatio=6（Eden 占 75%，每个 Survivor 12.5%，避免一GC就溢出）
• 限制晋升年龄：-XX:MaxTenuringThreshold=1（强制短命对象快速回收或进老年代，不卡在 Survivor 循环复制）
• 拦截大对象：-XX:PretenureSizeThreshold=1048576（1MB 以上直入老年代，避开年轻代搬运）

验证是否真正堵住逃逸路径

光配参数不行，得看运行时数据：

• 压测时加日志：-XX:+PrintGCDetails -Xloggc:gc.log，重点观察每次 Young GC 后的 Promotion 字段是否稳定、无突增
• 用 jstat -gc <pid> 1s</pid> 监控：S0C/S1C（Survivor 容量）是否被压缩、EC（Eden 容量）是否异常波动
• 老年代使用率上升斜率是否平缓；若 5 分钟内从 20% 涨到 80%，说明晋升失控，需检查对象生命周期或调小 -Xmn

不复杂但容易忽略。