答案是：-Xms设初始堆大小，-Xmx设最大堆大小；生产环境建议二者相等以避免动态调整抖动，运行时可用jstat、jmap等命令实时查看堆内存使用情况。
直接在启动命令里加参数就能设置堆内存大小，运行时用工具命令可实时查看当前分配情况。关键不是“能不能调”，而是“怎么调得稳、查得准”。
启动时设置堆大小的核心参数
最常用也最必须掌握的是两个基础参数：
-
-Xms：指定 JVM 启动时立刻分配的堆内存大小（初始堆），比如
-Xms2g表示 2GB； -
-Xmx：指定 JVM 堆能增长到的最大值（最大堆），比如
-Xmx4g表示上限 4GB。
生产环境强烈建议设为相等（如 -Xms4g -Xmx4g），避免 GC 后动态扩容缩容带来的停顿抖动。不设 -Xms 时默认为物理内存的 1/64，-Xmx 默认为 1/4，但这些默认值通常不适合实际业务。
如果还要精细控制年轻代，可用：
-
-Xmn：直接固定年轻代总大小（含 Eden + 两个 Survivor），例如
-Xmn1g； -
-XX:NewRatio：设老年代与年轻代比例，如
-XX:NewRatio=2表示老年代:年轻代 = 2:1（年轻代占堆 1/3）； -
-XX:SurvivorRatio：设 Eden 与单个 Survivor 区的比例，如
-XX:SurvivorRatio=8表示 Eden 占新生代 8/10，每个 Survivor 各占 1/10。
运行中查看堆内存使用情况
不需要重启，用 JDK 自带命令即可快速诊断：
-
jstat -gc <pid>：显示各代内存容量、已用空间、GC 次数与耗时，例如
jstat -gc 12345 1000 5表示每秒打印一次，共 5 次； - jstat -gcutil <pid>：更简洁地展示 Eden、Survivor、老年代、元空间的使用率百分比；
- jmap -heap <pid>：输出完整堆结构，包括初始/最大值、分代边界、GC 器类型等，适合做配置复核；
- jconsole 或 VisualVM：图形化连接进程后，在“内存”页签里直观看到实时曲线和各区域占比。
常见误配与规避建议
很多 OOM 或 GC 频繁问题其实源于参数逻辑冲突或脱离实际场景：
- 容器环境下（如 Docker）必须显式设
-Xmx，且不能超过容器内存限制，否则会被 OS 杀掉（OOMKilled），JVM 自身无法感知 cgroup 限制； - 元空间（Metaspace）不属堆内存，但若加载大量类（如 Spring Boot + 多模块），需额外设
-XX:MaxMetaspaceSize=256m，否则可能无限增长导致系统内存耗尽； - 别盲目增大堆——堆越大，Full GC 时间越长；高并发服务更应优先保障年轻代大小（如堆的 1/3～1/2），减少 Minor GC 频率；
- 加
-XX:+AlwaysPreTouch可让 JVM 启动时就将堆内存锁定并清零，避免运行中缺页中断，对延迟敏感服务很有效。
验证配置是否生效
启动后第一件事就是确认参数真被读取了：
- 启动时加
-XX:+PrintFlagsFinal -version | grep -E "HeapSize|NewSize"，会输出所有内存相关参数的实际值； - 或运行中执行
jinfo -flag MaxHeapSize <pid>查看当前生效的-Xmx值； - 注意：部分参数（如
-Xms）只能在启动时设置，运行中不可动态修改。
