-Xms与-Xmx必须相等，根本原因是避免JVM运行时动态伸缩堆内存引发频繁Full GC；NewRatio影响新生代占比，合理设置可减少Minor GC频率与对象过早晋升，提升吞吐量。
为什么 -Xms 和 -Xmx 必须设成一样
根本原因不是“看起来整齐”，而是避免 JVM 在运行时反复向操作系统申请或归还堆内存。只要两者不等，JVM 就会根据当前空闲率（比如低于40%就扩容、高于70%就收缩）动态调整堆大小。每次调整都触发一次 Full GC——哪怕堆里还有很多对象没到回收时机，也得暂停所有线程来完成内存重映射和元数据更新。
这种“内存抖动”在监控图上表现为锯齿状的堆使用曲线：上升→接近阈值→扩容→GC→下降→空闲过多→收缩→再GC。高频抖动直接导致接口平均延迟飙升、P99毛刺明显、GC日志里频繁出现 “Full GC (Ergonomics)” 记录。
- 扩容前必先尝试 GC，若仍不够才伸缩；收缩前也要 GC 清理，再释放内存
- 伸缩操作本身涉及 mmap/munmap 系统调用，对内核有开销，尤其在容器环境受 cgroup 内存限制时更易失败或延迟
- 堆大小浮动导致 GC 周期不可预测，影响 G1 的停顿预测模型（-XX:MaxGCPauseMillis 失效）
-XX:NewRatio 怎么影响吞吐量
这个参数控制老年代与新生代的容量比例，直接影响对象晋升节奏和 GC 类型分布。默认 Server 模式下 NewRatio=2，即老年代 : 新生代 = 2 : 1，新生代占整个堆的 1/3。但默认值对大多数 Web 应用并不友好——短生命周期对象多，却只分到约 33% 堆空间，导致 Minor GC 频繁，Survivor 区快速填满，大量对象被迫提前晋升至老年代。
一旦老年代被过早填满，就会触发代价高昂的 Full GC 或并发模式下的 Mixed GC 回收风暴，系统吞吐量断崖式下跌。实测表明：将 NewRatio 从默认 2 调整为 1（即新生代占比升至 50%），配合 -Xms/-Xmx 一致设置，在高并发订单场景中 Minor GC 次数下降 40%，Full GC 彻底消失，整体吞吐量提升 50% 以上。
- NewRatio=1 → 新生代占 1/2 堆，适合短生命周期对象密集型服务（如 API 网关、Spring Boot REST 接口）
- NewRatio=3～4 → 新生代占 1/4～1/5，适合缓存类应用或含大量长生命周期对象的服务（如规则引擎、状态机服务）
- 务必配合 -XX:+PrintGCDetails 和 GCViewer 分析晋升率（Promotion Rate），避免 Survivor 区过小造成“Survivor Overflow”
生产环境推荐组合配置
固定堆 + 合理代际划分，是稳定高吞吐的前提。不建议照搬“4G”“8G”这类绝对值，而应基于容器内存限制反推：例如 Kubernetes 中容器 limit=8Gi，则 -Xms/-Xmx 设为 5g～6g（留出 2～3G 给 Metaspace、Direct Memory、线程栈等非堆内存）。
- 通用 Web 服务：-Xms6g -Xmx6g -XX:NewRatio=1 -XX:SurvivorRatio=8 -XX:+UseG1GC -XX:MaxGCPauseMillis=50
- 批处理/后台任务：-Xms4g -Xmx4g -XX:NewRatio=3 -XX:+UseParallelGC（吞吐优先，可接受稍长 STW）
- 内存敏感型微服务：-Xms2g -Xmx2g -XX:NewRatio=1 -XX:MaxMetaspaceSize=256m -XX:ReservedCodeCacheSize=240m
开发与生产要区分对待
开发阶段故意把 -Xms 设小（如 512m）、-Xmx 设大（如 2g），是有意为之：启动快、便于观察内存增长曲线、辅助定位内存泄漏。但上线前必须统一为相同值——这不是“最佳实践”的教条，而是线上稳定性的一道硬门槛。
至于 -XX:NewRatio，不要靠猜。压测时打开 GC 日志，重点关注 “PSYoungGen” 和 “ParOldGen” 的使用趋势、每次 Minor GC 后晋升到老年代的字节数。如果晋升量持续超过老年代可用空间的 10%，说明新生代太小，该调小 NewRatio 了。
