JVM参数需匹配应用特征，盲目配置反而引发GC问题；应先用jstat、jmap和日志定位瓶颈，再针对性调优堆大小、GC算法、Metaspace及容器适配参数。
Java虚拟机参数不是加得越多越好，关键看是否匹配应用特征；盲目堆砌 -Xmx 或 -XX:+UseG1GC 可能反而引发更长的 GC 暂停或内存泄漏。
怎么判断该配哪些 JVM 参数
先看实际瓶颈，而不是照搬网上配置。用 jstat -gc 观察 GC 频率和耗时，用 jmap -histo 查大对象分布，再结合应用日志里的 OutOfMemoryError: Java heap space 或 Metaspace 报错决定方向。
- 频繁 Minor GC + 老年代缓慢增长 → 优先调
-Xmn和 SurvivorRatio - Full GC 频繁且老年代回收后空间仍不足 → 检查是否内存泄漏，再考虑增大
-Xmx - 出现
java.lang.OutOfMemoryError: Metaspace→ 增加-XX:MaxMetaspaceSize，而非默认不限 - 响应延迟毛刺明显，且 GC 日志显示单次 STW 超过 200ms → 换 GC 算法，如 G1 或 ZGC（JDK 11+）
常用参数组合的实际含义与陷阱
很多参数表面合理，但组合起来会冲突或失效。比如 -XX:+UseG1GC 必须配合 -XX:MaxGCPauseMillis 才有意义，而单独加它不会自动优化停顿；又比如 -Xms 和 -Xmx 不设为相等，在容器环境下容易被 cgroup 限制后触发 OOMKilled。
-
-Xms512m -Xmx4g：堆初始值远小于最大值 → JVM 启动慢，且运行中扩容可能触发额外 GC -
-XX:+UseG1GC -XX:G1HeapRegionSize=4M：区域大小必须是 2 的幂（1M/2M/4M/8M），且不能超过堆大小的 1/2048，否则启动失败报错Invalid argument: G1HeapRegionSize -
-XX:+PrintGCDetails -Xloggc:gc.log（JDK 8） vs-Xlog:gc*:gc.log（JDK 10+）：日志开关语法完全不同，混用会导致 JVM 启动失败
容器环境（Docker/K8s）下必须改的参数
JVM 默认不识别 cgroup 内存限制，会按宿主机总内存计算堆大小，导致进程被 OOMKilled。JDK 8u191+、JDK 10+ 默认开启 -XX:+UseContainerSupport，但仍需显式告诉 JVM 容器限制：
- 必须加
-X（JDK 8u191+ 默认开启，但建议显式写上）
X:+UseContainerSupport
- 推荐加
-XX:InitialRAMPercentage=50.0 -XX:MaxRAMPercentage=80.0替代硬编码-Xmx，让 JVM 自动按容器内存 limit 计算堆大小 - 避免使用
-Xmx4g这类固定值，尤其在 K8s 中 Pod memory limit 设为2Gi时，该参数会让 JVM 尝试分配超限内存
-XX:+UseContainerSupport -XX:InitialRAMPercentage=50.0 -XX:MaxRAMPercentage=80.0 -XX:+PrintGCDetails -Xloggc:/var/log/app/gc.log
GC 日志怎么看才有效
光有日志没用，重点看三类时间：Allocation Failure 触发点、GC 后存活对象大小、以及 STW 时间是否稳定。JDK 8 的 -XX:+PrintGCDetails 输出杂乱，建议升级到 JDK 11+ 用结构化日志。
- 关注
[GC pause (G1 Evacuation Pause) (young)]中的real时间（即 STW），持续超过 200ms 就要干预 - 如果
After GC的老年代使用量持续上涨，且 Full GC 很少发生 → 可能是 CMS 或 G1 的并发周期没跟上，需调-XX:G1ConcRefinementThreads或-XX:CMSInitiatingOccupancyFraction - 日志里反复出现
to-space exhausted→ Survivor 区太小或对象晋升过快，应调-XX:SurvivorRatio或-XX:MaxTenuringThreshold
真正难的不是记住参数，而是理解每个参数背后影响的是哪块内存区域、哪个 GC 阶段、以及它和你的业务请求模型是否匹配。比如高吞吐批处理适合 Parallel GC，而低延迟 Web API 更依赖 G1 或 ZGC 的可预测停顿——这没法靠参数列表背出来，得结合压测数据反复验证。
