堆大小设置需结合应用特征、物理资源和GC行为，核心目标是避免频繁GC、减少OOM风险、控制停顿时间；关键在“合适”而非“最大”，推荐-Xms与-Xmx设为相同值以提升稳定性与可预测性。
堆大小设置不是拍脑袋定的，得结合应用特征、物理资源和 GC 行为来判断。核心目标是：避免频繁 GC、减少内存溢出风险、控制停顿时间。关键不在“最大”，而在“合适”。
看准初始值与最大值是否一致
-Xms 和 -Xmx 设成相同值是最常见也最稳妥的做法。这样 JVM 启动就分配好全部堆空间，省去运行中动态扩容/缩容的开销，也能让 GC 行为更可预测。
- 比如服务器有 16GB 物理内存，Java 应用独占，可设为 -Xms8g -Xmx8g
- 若应用启动后内存占用稳定在 3~4GB，但峰值偶尔冲到 7GB，设成 -Xms6g -Xmx6g 比设成 -Xms2g -Xmx8g 更稳——后者容易触发多次扩容和 CMS 或 G1 的自适应调整，反而增加 GC 压力
年轻代不能随便调，要配合回收器和对象生命周期
年轻代（-Xmn）大小直接影响 Minor GC 频率和晋升压力。设太大，Minor GC 耗时变长；设太小，对象频繁晋升到老年代，可能引发提前 Full GC。
- Sun 官方建议：年轻代占整个堆的 3/8 左右（例如堆 8GB，年轻代约 3GB）
- 使用 G1 时，不用直接设 -Xmn，改用 -XX:G1NewSizePercent 和 -XX:G1MaxNewSizePercent 更灵活
- 如果应用大量创建短生命周期对象（如 Web API 返回 JSON），可适当加大年轻代；若对象普遍存活时间长（如缓存服务），则需谨慎增大，避免 Survivor 区溢出导致快速晋升
别只盯着堆，留意元空间和线程栈的联动影响
堆设得再合理，若元空间（Metaspace）或线程栈（-Xss）没配好，照样 OOM。它们共享进程的虚拟地址空间，尤其在 32 位或受限容器中更敏感。
- 类多的应用（如 Spring Boot + 大量 Starter），建议显式设 -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m，避免启动期反复 Full GC 调整元空间
- 高并发场景下线程数多（如 Tomcat 默认 200 线程），-Xss 默认 1MB 会快速吃掉数百 MB 栈空间。若单线程不深，可降至 -Xss256k，节省内存并支持更多线程
- 注意：-Xss × 线程数 + 堆 + 元空间 ≈ 进程总内存。超了会触发 OutOfMemoryError: unable to create native thread
验证比猜测更重要
参数设完不能就放着，得用真实负载观察效果。重点关注 GC 日志里的晋升速率、老年代增长趋势和停顿时间分布。
- 加参数 -Xlog:gc*:file=gc.log:time,tags,level（JDK 11+）或 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps（旧版）收集日志
- 用 jstat -gc <pid> 查看实时 GC 统计，关注 YGC/YGCT、FGC/FGCT 和老年代使用率
- 如果发现老年代每小时涨 5%，且每次 Full GC 只回收 10MB，说明对象在年轻代没被及时回收，该查代码里是否有集合类长期持有引用，而不是盲目加堆
