标准参数需置于java命令后、主类/JAR前且语法严格；-X参数控制内存但需注意版本兼容与系统资源；-XX参数最不稳定，须匹配JDK版本并正确启用；验证生效应使用jinfo -flags或-XX:+PrintCommandLineFlags。
标准参数（-D、-server 等）为什么改了没生效？
标准参数是 JVM 规范定义的、跨版本兼容性最强的一类参数，比如 -Dfile.encoding=UTF-8、-server（旧版 JDK）、-version。它们的特点是：语法固定、无前缀或单短横前缀、JVM 启动时立即解析。
常见错误是把非标准参数误当标准参数用，比如写成 -XX:+UseG1GC 却放在标准参数位置——JVM 会直接报错 Unrecognized option；或者把 -Xmx2g 当作标准参数，在某些脚本里漏掉 -X 前缀，导致被忽略。
-
-D参数必须写在-jar或主类名之前，否则会被当成程序参数传给应用 -
-server在 JDK 8 及以后已默认启用且废弃，再写不会报错但无效 - 所有标准参数不区分顺序，但必须出现在 JVM 可识别的位置（即
java命令后、主类/ jar 前）
-X 参数（如 -Xms、-Xmx）为什么堆内存总没按预期分配？
-X 参数是 JVM 厂商提供的非标准扩展，但已被广泛接受为“事实标准”，主要用于内存与运行时行为控制，比如 -Xms、-Xmx、-Xss。它们不带等号，值可接数字+单位（k/m/g），大小写敏感。
典型问题是 -Xms 和 -Xmx 设得不一致，又没配 GC 日志，结果发现老年代频繁扩容缩容；或者用 -Xmx4g 却忘了系统只剩 3.5g 可用内存，JVM 直接启动失败并报 Could not reserve enough space for object heap。
-
-Xms和-Xmx强烈建议设为相同值，避免运行时堆伸缩带来的 STW 波动 -
-Xss过小（如-Xss128k）会导致深度递归或高并发线程场景下抛StackOverflowError - JDK 11+ 中部分
-X参数（如-Xnoclassgc）已被移除，需查对应版本文档
-XX 参数（如 -XX:+UseZGC）为什么加了反而启动不了？
-XX 是最底层、最不稳定的参数类型，用于调试、实验性功能或精细调优，比如 -XX:+UseZGC、-XX:MaxMetaspaceSize、-XX:+PrintGCDetails。它们分布尔型（+/- 开关）和键值型（= 赋值），且大量参数版本间不兼容。
最容易踩的坑是复制网上 JDK 8 的 ZGC 配置到 JDK 17 上——ZGC 在 JDK 11 才转正，JDK 8 根本不识别 -XX:+UseZGC，直接报错退出；或者开了 -XX:+UnlockExperimentalVMOptions 却没跟上真正的实验参数，JVM 认为“解锁了却不用”，静默忽略。
- 布尔型参数必须写全
+或-，-XX:UseZGC（漏掉+）是无效语法 - 实验性参数（如
-XX:+UseEpsilonGC）需配合-XX:+UnlockExperimentalVMOptions，且仅限特定 JDK 版本 -
-XX:+PrintGCDetails必须搭配-Xlog:gc*（JDK 10+）或输出重定向，否则日志可能刷到 stderr 而被脚本截断
如何验证参数是否真正生效？别只信 ps aux 的输出
ps aux | grep java 看到的命令行只是启动快照，不能反映运行时实际生效的参数，尤其 -XX 类参数可能被 JVM 内部覆盖或降级（比如指定 -XX:+UseG1GC 但堆太小，JVM 自动切回 Serial GC）。
真正可靠的验证方式只有两个：一是用 jinfo -flags <pid> 查运行中 JVM 的最终解析参数（JDK 8+）；二是通过 -XX:+PrintCommandLineFlags 让 JVM 启动时自动打印它“真正采纳”的参数（含默认值）。
-
jinfo对容器内进程可能失效（/proc/<pid>/cmdline 权限受限），此时需进容器用jps+jinfo -
-XX:+PrintCommandLineFlags输出里看到的-XX:MaxHeapSize=4294967296就是最终生效的-Xmx4g，不是你写的原始形式 - JDK 9+ 的
jcmd <pid> VM.flags比jinfo更稳定，推荐优先使用
-XX:+PrintCommandLineFlags 确认真实加载结果。 
