JVM参数调优核心是匹配业务特征：高吞吐批处理优先Parallel GC，低延迟接口首选G1或ZGC，缓存服务需扩大老年代；必须基于GC日志、内存趋势和线程状态明确瓶颈，再针对性配置-Xms/-Xmx相等、合理新生代比例、元空间限制及OOM自动转储等参数，并持续监控验证效果。
Java 应用性能分析中 JVM 参数调优，核心是“看数据、配参数、验效果”，不是堆越大越好，也不是参数越多越强。关键在于匹配业务特征——是高吞吐批处理？低延迟接口？还是内存密集型缓存服务？不同场景优先级完全不同。
先明确应用类型和瓶颈特征
调优前必须回答三个问题：
- GC 日志里 Full GC 是否频繁？单次耗时是否超过业务容忍（比如实时接口不能超100ms）
- 堆内存各区域（Eden/Survivor/Old/Metaspace）使用趋势是否陡升或长期高位？是否存在 Survivor 区对象反复复制后直接晋升老年代？
- 线程数是否持续增长？是否有大量 BLOCKED 或 WAITING 线程堆积？JIT 编译是否停滞？
例如：一个 Spring Boot Web 服务响应慢，jstat -gcutil 查到 Old 区使用率每小时涨 5%，且每 2 小时触发一次 Full GC，大概率是对象过早晋升或内存泄漏，而非简单加大堆内存。
生产常用参数组合（JDK 8–17，4–16GB 堆）
这不是万能模板，而是有依据的起点配置：
立即学习“Java免费学习笔记（深入）”；
- -Xms4g -Xmx4g：初始与最大堆一致，避免运行期扩容抖动；物理内存 32G 的机器，不建议单实例堆超 16G
- -XX:+UseG1GC：JDK 9+ 默认，但显式声明更清晰；适合 4GB 以上堆，兼顾吞吐与停顿
- -XX:MaxGCPauseMillis=200：G1 的目标停顿时间（非硬性保证），按业务 SLA 调整，如支付接口可设为 100
- -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m：防止类加载过多引发 Metaspace OOM 或 Full GC
- -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/jvm/dump/：OOM 时自动生成快照，必备排障项
- -Xlog:gc*:file=/var/log/java/gc.log:time,level:filecount=5,filesize=20M：JDK 11+ 推荐日志格式，替代旧版 -XX:+PrintGCDetails
必须监控的关键指标
没监控的调优等于蒙眼开车。上线后至少要采集：
- 内存：Eden 使用率波动频率、Survivor 幸存区占比、Old 区增长斜率、Metaspace 已用大小
- GC：Young GC 频率与平均耗时、Full GC 次数与单次耗时（>1s 需立即干预）
- 线程：活动线程数、峰值线程数、死锁状态、BLOCKED 线程数量
- 类与编译：已加载类总数、JIT 编译方法数、是否出现 “made not entrant” 日志
推荐工具链：jstat 快速排查（jstat -gc -h10 <pid> 2000）、Prometheus + Micrometer 做长期趋势、Async Profiler 抓 CPU/Alloc 热点、MAT 分析 heap.hprof 定位大对象或泄漏源头。
避开高频反模式
这些操作看似“优化”，实则埋雷：
- 把 -Xmx 设到物理内存 80% —— 忽略了 OS、Direct Buffer、CodeCache、线程栈等非堆内存，容易触发 OOM Killer
- 频繁手动 System.gc() —— 强制触发 Full GC，破坏 JVM 自适应策略，几乎总是有害
- 只调 -Xmx，不调 -XX:NewRatio 和 -XX:MaxTenuringThreshold —— 导致短生命周期对象滞留 Survivor 区失败，直接进入老年代，加速碎片化
- 在容器中未启用 -XX:+UseContainerSupport（JDK 10+）或 -XX:MaxRAMPercentage=75（JDK 8u191+）—— JVM 无法感知容器内存限制，可能申请超限内存
