生产环境JVM参数热修改仅限{manageable}标记参数，如PrintGCDetails、HeapDumpOnOutOfMemoryError等；-Xms、-Xmx、-XX:+UseG1GC等基础结构参数启动后不可更改，需滚动升级调整。
生产环境改 JVM 参数，核心原则就一条：能不动的坚决不动，必须动的要可控、可逆、可验证。
先分清哪些参数根本不能热改
堆大小、GC 类型、元空间上限这些基础结构参数，一旦 JVM 启动就锁死：
- -Xms / -Xmx（堆初始和最大值）
- -XX:MaxMetaspaceSize（元空间上限）
- -XX:MaxDirectMemorySize（直接内存上限）
- -Xss（线程栈大小）
- -XX:+UseG1GC 或 -XX:+UseZGC（GC 算法本身）
这类参数改了等于重启，强行尝试会失败或被忽略。别在 jinfo 里试，它只会报错。
只动标记为 manageable 的参数
真正支持运行时修改的，是 JVM 内部标记为 {manageable} 的开关类参数。确认方法很简单：
立即学习“Java免费学习笔记（深入）”；
java -XX:+PrintFlagsFinal -version | grep manageable
常见可热改项包括：
- GC 日志开关：-XX:+PrintGCDetails、-XX:+PrintGCDateStamps
- 堆转储触发：-XX:+HeapDumpOnOutOfMemoryError、-XX:HeapDumpPath
- G1/CMS 部分阈值：-XX:G1HeapRegionSize、-XX:CMSInitiatingOccupancyFraction（注意：仅部分版本支持）
- JIT 编译相关：-XX:+UnlockDiagnosticVMOptions、-XX:+LogCompilation（需先解锁）
操作统一用 jinfo -flag 命令，例如：
jinfo -flag +PrintGCDetails 12345（开启 GC 细节日志）
jinfo -flag -HeapDumpOnOutOfMemoryError 12345（关闭 OOM 自动 dump）
系统属性（-D 参数）可代码级动态调整
以 -D 开头的 JVM 系统属性，本质是 Java 运行时的键值对，完全支持运行时变更：
- System.setProperty("log.level", "DEBUG")
- System.setProperty("spring.profiles.active", "prod")
- System.setProperty("java.awt.headless", "true")
这类变更立即生效，但要注意：不是所有 -D 属性都会被框架实时感知（比如 Spring Boot 的 profile 切换需配合刷新上下文）。业务代码中读取属性时，应避免缓存旧值，建议每次调用 System.getProperty()。
变更前必须做的三件事
哪怕只是开个 GC 日志，也得走完这几步：
- 查当前值：jinfo -flags <pid> 先看目标参数是否已启用，避免重复操作
- 记变更时间点：在监控系统中标记该时刻，方便后续比对指标波动
- 设回滚预案：比如开启 PrintGCDetails 后，若发现日志量暴增影响磁盘 IO，立刻用 jinfo -flag -PrintGCDetails 回退
不依赖人工记忆，把命令和预期效果写进运维 checklist，贴在发布流程里。
真正需要改堆/GC 参数时怎么办
如果观察到频繁 Full GC 或 OOM，说明基础参数不合理——这不是热改能解决的，必须滚动升级：
- 在 Kubernetes 中：更新 Deployment 的 JAVA_OPTS，用滚动更新策略，逐台替换 Pod
- 在传统服务器上：用蓝绿部署或灰度切换，新实例带新参数上线，流量切过去后再下线旧实例
- 所有变更必须经过压测验证：相同流量模型下，对比 GC 频率、停顿时间、吞吐量变化
没有监控数据支撑的参数调整，都是盲人摸象。
