-Xms和-Xmx必须写在java命令后、-jar或类名前，不加引号、不换行、不漏单位；设为相同值可避免堆扩容引发的GC波动，且需统筹Metaspace、直接内存、线程栈等额外内存开销。
Java启动时设置-Xms和-Xmx的正确写法
直接给结论：必须写在java命令的**JVM参数位置**，即java之后、-jar或类名之前，且不能加引号、不能换行、不能漏单位。
常见错误是把它们塞进应用参数里，比如：java -jar app.jar -Xms512m -Xmx2g——这会让JVM完全忽略这两个参数，因为此时-Xms和-Xmx被当成传给app.jar的程序参数了。
-
-Xms和-Xmx必须紧挨着java命令，例如：java -Xms512m -Xmx2g -jar app.jar - 单位大小写敏感：
m或M都行，但g推荐小写（2g比2G更稳妥，某些旧版本JVM对大写G解析异常） - 数值不能带空格：
-Xmx 2g（中间有空格）会报错：Unrecognized option: -Xmx - 如果用脚本启动，确保变量拼接时没引入不可见字符（比如Windows编辑器保存的BOM头，可能让
-Xmx失效）
为什么-Xms和-Xmx建议设为相同值
设成一样（比如-Xms2g -Xmx2g）不是为了“省事”，而是避免堆内存动态扩容带来的GC停顿波动。JVM默认-Xms很小（通常256m），启动后按需扩展到-Xmx，每次扩容都要触发Full GC或复杂内存整理。
- 容器环境（如K8s）中尤其关键：内存限制（
memory limit）和-Xmx不一致时，JVM可能因申请不到足够堆外内存而被OOMKilled，但日志里只显示Killed process，无Java堆溢出痕迹 -
-Xms设太小（如128m），而应用一上来就分配大量对象，会导致频繁Young GC+晋升压力，反而拖慢冷启动 - 设相等后，JVM启动时就向OS申请完整堆空间，能更快暴露内存不足问题（比如直接启动失败），比运行几小时后突然OOM更容易定位
-Xms/-Xmx与Metaspace、直接内存的关系
很多人以为设置了-Xmx2g，整个JVM就只用2GB，其实不是。-Xmx只管堆内存，而Metaspace（类元数据）、Compressed Class Space、直接内存（ByteBuffer.allocateDirect）、线程栈（-Xss）都额外算。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- Metaspace默认无上限，容易吃光剩余内存；生产环境务必加
-XX:MaxMetaspaceSize=256m - Netty等框架默认使用直接内存，若未限制
-XX:MaxDirectMemorySize，它可能突破-Xmx限制，导致OS级OOM - 每个线程栈默认1MB（
-Xss1m），开1000个线程就额外占1GB——这跟-Xmx完全无关，但总内存会超限 - 实际总内存 ≈
-Xmx+MaxMetaspaceSize+MaxDirectMemorySize+线程数 × Xss+ JVM自身开销（约100~200MB）
验证参数是否生效的三个可靠方法
别信启动日志里的“Picked up JAVA_TOOL_OPTIONS”，那个不一定生效；也别只看jps -lv输出——它可能截断长参数。真正靠谱的方式只有这几个：
- 在代码里打印：
Runtime.getRuntime().maxMemory()（返回-Xmx值，单位字节），注意这是最大可用堆，不是已分配值 - 用
jstat -gc <pid></pid>看max列（对应S0C、S1C、EC、OC等），其中OC.max就是老年代最大容量，应接近-Xmx减去年轻代预留 - 启动时加
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，首行GC日志会明确写出Initial heap size和Maximum heap size
最容易被忽略的是：不同JDK版本对同一参数的解释可能不同。比如JDK 8u292之后，-Xmx在容器中会自动适配cgroup limit，但JDK 11+需要显式加-XX:+UseContainerSupport才生效——不验证，永远不知道实际用了多少。
