堆内存大小和垃圾回收器选择是影响Java应用吞吐量的两个硬杠杆：-Xms/-Xmx应设为相同值并占物理内存50%～75%，高吞吐优先选G1GC或ZGC；Metaspace需显式设置大小防OOM；JDK版本差异导致GC参数语义不同，须严格匹配；诊断参数应精简有效，避免过度开销。
哪些JVM参数对吞吐量影响最直接
堆内存大小和垃圾回收器选择是影响Java应用吞吐量的两个硬杠杆。不合理的-Xms和-Xmx设置会导致频繁GC或内存浪费；而默认的串行GC在服务端几乎从不适用。
-
-Xms和-Xmx建议设为相同值，避免运行时堆扩容带来的STW暂停；生产环境常见设为物理内存的50%～75%，但需预留至少2GB给OS和其他进程 - 高吞吐场景优先选
-XX:+UseG1GC（JDK 9+默认），搭配-XX:MaxGCPauseMillis=200控制停顿；若JDK 17+，可试-XX:+UseZGC，但注意它要求Linux 4.14+内核和-XX:+UnlockExperimentalVMOptions - 禁用
-XX:+UseParallelGC做响应敏感型服务（如API网关），它虽吞吐高，但单次停顿可能达秒级
如何避免元空间（Metaspace）OOM
类加载过多（尤其热部署、大量反射、动态代理）容易触发java.lang.OutOfMemoryError: Metaspace，这不是代码泄漏，而是JVM默认限制太保守。
- 必须显式设置
-XX:MetaspaceSize=256m和-XX:MaxMetaspaceSize=512m，否则JVM会从20MB开始动态扩容，首次扩容就会触发Full GC - Spring Boot应用常因自动配置类爆炸增长，建议配合
-XX:+PrintGCDetails观察Metaspace区增长趋势，而非盲目调大上限 - 使用
-XX:+TraceClassLoading和-XX:+TraceClassUnloading定位异常类加载行为，比单纯加内存更治本
JDK版本与GC参数的兼容性陷阱
同一个参数在不同JDK版本语义可能完全不同，甚至被废弃——例如-XX:PermSize在JDK 8已无效，但很多文档还在抄。
- JDK 8：用
-XX:PermSize/-XX:MaxPermSize配永久代，JDK 8u20后永久代已被移除，这些参数会被静默忽略 - JDK 9+：统一用
-XX:MetaspaceSize/-XX:MaxMetaspaceSize，且-XX:+UseConcMarkSweepGC在JDK 14被彻底删除 - JDK 17+：
-XX:+UseShenandoahGC无需解锁实验选项，但-XX:+UseZGC仍需-XX:+UnlockExperimentalVMOptions（JDK 21起才去掉）
线上环境该开哪些诊断参数
诊断参数不是越多越好，部分参数本身就有性能开销，比如高频日志或JIT编译跟踪。关键是要能快速定位问题，又不拖慢服务。
立即学习“Java免费学习笔记（深入）”；
- 必加：
-XX:+PrintGCDetails -Xloggc:/path/to/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M，确保GC日志可回溯且不撑爆磁盘 - 慎用：
-XX:+PrintCompilation会产生巨量输出，仅在排查JIT失效时临时开启；-XX:+TraceClassLoading同理，上线前务必关闭 - 推荐组合：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps/，配合jstat -gc实时观察，比等OOM再分析快得多1s
-Xmx才不白忙。 
