标准参数如-D、-server必须置于java命令与-jar或主类名之间才生效，顺序错误会被当作应用参数；-server在JDK9+已废弃；-X参数需注意单位大小写及平台差异；-XX参数中布尔型可直接启用，带值型须结合GC日志验证。
标准参数（-D、-server 这类）怎么设才不被忽略
Java 启动时加的 -Dfile.encoding=UTF-8 或 -server 属于标准参数，JVM 会识别并生效，但**顺序很重要**：它们必须放在 java 命令和 -jar 或主类名之间，否则会被当成应用参数传给程序，JVM 根本不处理。
-
-D参数写在-jar xxx.jar后面 → 应用收到，JVM 不读，System.getProperty("file.encoding")仍是默认值 -
-server在 JDK 8 及以前有效，JDK 9+ 已废弃，但某些旧脚本里还留着，实际没作用，别白加 -
-version、-help这类纯查询参数，执行完就退出，不会启动应用，调试时别误以为“参数生效了”
-X 参数（如 -Xmx、-Xss）为什么设了也不起作用
-Xmx、-Xms、-Xss 是非标准但广泛支持的参数，问题常出在单位混淆和平台差异上。比如 -Xmx2g 在部分老版本 JVM 上不认 g，得写成 -Xmx2048m；Windows 下用 -Xss1m 可能触发栈溢出，而 Linux 同样值却没事——因为系统线程默认栈大小不同。
- 单位后缀区分大小写：
-Xmx2G在 OpenJDK 11+ 报错，必须小写g或m -
-Xms和-Xmx设成不等值，GC 频率会随堆动态伸缩波动，监控时看到老年代占用忽高忽低，容易误判为内存泄漏 -
-Xss设太小（如128k），Spring Boot 启动时可能抛StackOverflowError，尤其用了大量 AOP 或嵌套较深的配置类
-XX 参数（如 -XX:+UseG1GC）哪些能随便开，哪些要验证
-XX 参数分两类：带 +/- 的布尔开关（如 -XX:+UseG1GC），和带值的（如 -XX:MaxGCPauseMillis=200）。前者多数可直接启用，后者几乎都需要配合 GC 日志验证效果，否则极易适得其反。
-
-XX:+UseG1GC在 JDK 9+ 是默认 GC，但 JDK 8 需显式开启；若同时写了-XX:+UseParallelGC，后者会覆盖前者，JVM 不报错，只静默生效最后一个 -
-XX:MaxGCPauseMillis=50是目标值，不是保证值，设太激进会导致 GC 频繁、吞吐下降，反而拖慢响应 -
-XX:+HeapDumpOnOutOfMemoryError必须配-XX:HeapDumpPath=/path/to/dump.hprof，否则 dump 文件生成在当前工作目录，容器环境常因权限或路径不存在而静默失败
JVM 参数顺序和组合冲突的实际影响
参数顺序不仅影响识别，还会引发隐性覆盖。JVM 按从左到右解析，同名参数以最后一次出现为准；更麻烦的是某些组合根本无效，比如 -XX:+UseZGC 和 -Xmx64g 在 JDK 11 中可以，但在 JDK 15 以下不支持 ZGC 大于 16TB 地址空间，参数本身合法，但运行时报 Unrecognized VM option '+UseZGC' —— 因为 ZGC 在该版本默认未启用，需额外加 -XX:+UnlockExperimentalVMOptions。
立即学习“Java免费学习笔记（深入）”；
-
-Xmx4g -XX:MaxRAMPercentage=75.0：后者会覆盖前者，最终堆大小按容器 cgroup 内存限制算，本地调试时若没设 memory limit，MaxRAMPercentage可能算出远超物理内存的值，启动失败 -
-XX:+UseConcMarkSweepGC在 JDK 9 被标记废弃，JDK 14 彻底移除，但参数仍能通过启动校验，直到首次 GC 才抛Unrecognized VM option - 多个
-XX:CompileCommand文件引用，JVM 只加载第一个，后续的被忽略，且不提示
最麻烦的不是参数写错，而是参数“看起来生效了”，但实际行为和预期差一截——比如 GC 日志显示用了 G1，但停顿时间始终下不来，最后发现是 -XX:G1HeapRegionSize 和堆大小不匹配，导致 region 数量异常，调度失衡。这类问题没法靠文档速查，得看日志、测数据、比结果。
