JVM参数配置需匹配应用特性：-Xms与-Xmx应设为相等避免动态调整开销；新生代比例需据对象生命周期调优；元空间必须设MaxMetaspaceSize防内存耗尽；G1GC适用于多数Web服务，ZGC适配超低延迟场景。
JVM 参数配置直接影响 Java 应用的响应速度、吞吐量、稳定性与资源利用率。配置不当不仅不能提升性能，反而容易引发停顿加剧、内存耗尽甚至服务中断。
堆内存设置不当会放大 GC 压力
初始堆（-Xms）和最大堆（-Xmx）不一致，会导致 JVM 运行中动态扩容缩容，触发额外的 Full GC；堆设得过大，可能挤占系统可用内存，诱发 Swap，使 GC 停顿从毫秒级飙升至秒级甚至分钟级；堆设得太小，则 Minor GC 频繁，GC overhead 超过 90%，业务线程几乎无法执行。
- 生产环境建议 -Xms 和 -Xmx 设为相同值，例如 -Xms2g -Xmx2g
- 容器环境优先使用 -XX:MaxRAMPercentage=75，避免硬编码导致超限
- 通过 -Xlog:gc* 观察 GC 频率与堆使用趋势，再决定是否调大或优化代码
新生代与老年代比例失衡加速对象晋升
默认 -XX:NewRatio=2（老年代:新生代=2:1），但若应用短期对象极少、长期缓存多，该比例会让老年代过小，频繁触发 Full GC；反之，若大量短生命周期对象，新生代太小会导致 Eden 区快速填满，存活对象来不及复制就“直接晋升”到老年代，提前耗尽老年代空间。
- 可通过 -Xmn 显式设定年轻代大小，比依赖 NewRatio 更直观可控
- 搭配 -XX:SurvivorRatio=8（Eden:Survivor=8:1），确保 Survivor 区有足够空间容纳跨 GC 存活对象
- 观察 GC 日志中的 “promotion failed” 或 “to-space overflow”，是晋升异常的关键信号
垃圾回收器选型错配带来延迟抖动
G1GC 在 4–16GB 堆场景下兼顾吞吐与延迟，适合多数 Web 服务；ZGC 适用于堆 ≥ 8GB 且要求单次停顿 ≤ 10ms 的实时系统；Parallel GC 吞吐高但停顿长，不适合交互型应用；CMS 已在 JDK 14+ 中移除，继续使用存在兼容与安全风险。
- 不要在低延迟场景强行用 Parallel GC，也不要在小堆（
- 启用 G1 时建议加 -XX:+UseStringDeduplication 减少字符串重复内存占用
- ZGC 需配合 -XX:+UnlockExperimentalVMOptions（JDK 11–15）或直接启用（JDK 16+）
元空间与线程栈配置疏忽引发隐性故障
元空间（Metaspace）无默认上限，若应用大量使用反射、动态代理或热加载，可能持续增长直至耗尽系统内存，被 OOM Killer 杀死进程；线程栈（-Xss）设得过大，会显著减少可创建线程数，在高并发场景下出现 “unable to create new native thread” 错误。
- 显式配置 -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m，便于监控与预警
- 常规服务推荐 -Xss256k，微服务或 IO 密集型可降至 128k，避免栈内存浪费
- 通过 JMX 检查 MetaspaceUsed 和 ThreadCount，早于崩溃前发现趋势异常
