必须显式固定年轻代大小（如-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监控：S0C/S1C（Survivor 容量）是否被压缩、EC（Eden 容量）是否异常波动 - 老年代使用率上升斜率是否平缓；若 5 分钟内从 20% 涨到 80%，说明晋升失控，需检查对象生命周期或调小
-Xmn
不复杂但容易忽略。
