-Xmn直接控制新生代大小，是影响Minor GC频率和吞吐量最敏感的JVM参数；需结合GC日志判断是否过小（如间隔＜5秒、Survivor使用率＞70%、早晋升等），按业务特征设为堆内存30%–60%，并同步调整SurvivorRatio与MaxTenuringThreshold，最终以GC次数降≥40%、GCTimeRatio＜3%等指标验证效果。

-Xmn 直接控制新生代大小，是影响 Minor GC 频率和系统吞吐量最敏感的 JVM 参数之一。调得过小，对象分配快满，GC 次数飙升；调得过大，虽降低频率，但单次停顿可能拉长，还可能挤压老年代空间，诱发 Major GC 或 Full GC。实战中不能凭经验拍值，而要结合应用内存行为做定向调整。

看懂当前新生代是否“太小”

关键观察点来自 GC 日志：

• Minor GC 平均间隔是否短于 5 秒（如每 2–3 秒一次）
• 每次 Minor GC 后 Eden 区是否几乎清零、Survivor 区使用率长期高于 70%
• 日志中频繁出现 “Desired survivor size” 接近实际 Survivor 容量，或出现 “to-space overflow”
• 对象晋升年龄远低于 -XX:MaxTenuringThreshold（比如阈值设 15，但多数对象 2–3 次 GC 就进老年代）

按业务特征合理设定-Xmn值

不追求绝对值，而看比例与节奏：

• 高并发短生命周期服务（如 API 网关、Spring Boot Web）：新生代建议占堆内存 40%–60%。例如总堆 4G，可设 -Xmn2g 或 -Xmn2400m
• 批处理/定时任务类（对象存活稍长、偶有大集合）：新生代占 30%–40%，避免 Survivor 区反复溢出，如堆 8G，设 -Xmn2.5g
• 注意底线：-Xmn 不宜超过物理内存的 1/2，且需为老年代留足空间（至少 2G 起步），否则易触发 CMS 并发失败或 G1 Mixed GC 压力过大

配合-SurvivorRatio同步优化

只调 -Xmn 不调比例，可能让 Survivor 区变“窄”，加剧早晋升。建议同步显式设置：

• 若发现对象存活较多但 Survivor 不够用，改用 -XX:SurvivorRatio=6（Eden:S0:S1 = 6:2:2），提升 Survivor 总占比至约 33%
• 默认 8:1:1（即 -XX:SurvivorRatio=8）适合对象极短命场景；但多数中高负载业务更适合 6 或 4
• 搭配 -XX:MaxTenuringThreshold=6 或 8，让对象在 Survivor 多“熬”几轮，真正该进老年代的才进去

验证效果的核心指标

调完不是结束，要用数据确认是否真提升了吞吐量：

• Minor GC 次数下降 ≥40%，单次耗时增幅 ≤15% → 净收益明显
• YGC 总耗时占应用运行时间比（GCTimeRatio）从 8% 降到 3% 以下
• TP99 响应时间稳定，无因 GC 抖动导致的尖刺（可用 Prometheus + Grafana 监控 jvm_gc_pause_seconds_count）
• 老年代增长速率变缓，Major GC 间隔延长 2 倍以上