好的，JVM 参数调优是一个复杂但至关重要的技能。它没有“银弹”配置，必须根据实际应用特点、硬件资源和监控数据来设置。下面我将参数分为几大类，并提供设置依据和策略。
一、 核心参数分类
1. 堆内存相关 (Heap Memory)
这是最核心的调优区域。
| 参数 | 示例 | 作用 | 设置依据与策略 |
|---|---|---|---|
-Xms |
-Xms4g |
初始堆大小 | 策略: 通常设置为和 -Xmx 相同，避免堆在运行时动态扩张和收缩，减少性能抖动。依据: 系统可用内存。建议占系统总内存的 50%-70%，留给堆外内存、 metaspace、操作系统等。 |
-Xmx |
-Xmx4g |
最大堆大小 | 策略: 与 -Xms 一致。依据: 1. 应用类型: 数据密集型应用（如大数据处理）需要大堆；计算密集型或微服务可以适当调小。2. 监控数据: 通过 jstat -gcutil 观察老年代使用率，如果长期在 70%-80% 以上，应考虑增大。必须避免堆被耗尽导致 OOM。 |
-Xmn |
-Xmn2g |
新生代大小 | 策略: 现代 GC（如 G1）通常不建议手动设置，由 JVM 自适应。如果使用 Parallel Scavenge/CMS，可以设置。 依据: Sun 官方推荐为整个堆的 1/3 到 1/2。增大新生代能减少 Minor GC 频率，但会导致每次 GC 时间变长。需要根据 -XX:MaxTenuringThreshold 和对象生命周期调整。 |
-XX:NewRatio |
-XX:NewRatio=2 |
老年代/新生代的比例 | NewRatio=2 表示老年代是新生代的 2 倍，即新生代占堆的 1/3。与 -Xmn 冲突，设了 -Xmn 则此参数无效。 |
-XX:SurvivorRatio |
-XX:SurvivorRatio=8 |
Eden 区与一个 Survivor 区的比例 | SurvivorRatio=8 表示 Eden : S0 : S1 = 8:1:1。策略: 通常不需要调整。如果 Survivor 区溢出（jstat 看到 S0/S1 经常 100%），可以适当增大比例或增大 -Xmn。 |
-XX:MaxTenuringThreshold |
-XX:MaxTenuringThreshold=15 |
对象晋升老年代的年龄阈值 | 默认 15。如果应用产生大量中期存活的对象，可以适当调大，让这些对象在 Survivor 区多待一会，避免过早进入老年代触发 Full GC。 |
2. 垃圾回收器选择 (Garbage Collector)
根据吞吐量和延迟要求选择。
| 参数 | 作用 | 适用场景与设置依据 |
|---|---|---|
-XX:+UseG1GC |
启用 G1 垃圾回收器 | JDK9+ 默认。场景: 大堆（>4G）、追求低延迟（STW 时间可控）。依据: 若监控到 CMS 或 Parallel 的 Full GC 频繁或停顿时间长，可切换到 G1。 |
-XX:+UseZGC-XX:+UseShenandoahGC |
启用 ZGC / Shenandoah | 场景: 超大堆（TB 级别）、极致低延迟（STW 时间不超过 10ms）。依据: JDK11+ 可用，适用于对响应时间极其敏感的核心应用。 |
-XX:+UseParallelGC |
启用并行垃圾回收器 | JDK8 默认。场景: 后台计算、科学计算等追求高吞吐量的应用。对延迟不敏感。 |
-XX:ParallelGCThreads |
设置并行 GC 的线程数 | 默认与 CPU 核数相同。如果机器上运行多个 JVM，可以适当调小，避免线程争抢。 |
-XX:MaxGCPauseMillis |
目标最大暂停时间 (G1/ZGC) | G1 的关键调优参数。设置一个期望值（如 -XX:MaxGCPauseMillis=200），JVM 会尽力但不保证达到。策略: 不要设得太小（如 20ms），否则 JVM 会牺牲吞吐量和整体性能来达到目标。 |
-XX:InitiatingHeapOccupancyPercent |
IHOP 阈值 (G1) | 默认 45。当老年代占用整个堆的比例达到此值时，启动并发标记周期。策略: 如果并发标记周期启动太晚，导致 Full GC，可以适当调低此值（如 40）。 |
3. 元空间与非堆内存 (Metaspace & Off-Heap)
| 参数 | 示例 | 作用 | 设置依据 |
|---|---|---|---|
-XX:MetaspaceSize |
-XX:MetaspaceSize=256m |
元空间初始大小 | 策略: 比默认值（约 20M）设大一些，避免运行时频繁扩容触发 Full GC。 依据: 应用依赖的 Jar 包数量。大型项目建议 256m 或 512m。 |
-XX:MaxMetaspaceSize |
-XX:MaxMetaspaceSize=512m |
元空间最大大小 | 策略: 必须设置，防止元空间无限膨胀占用所有系统内存。 依据: 监控运行稳定后的元空间使用量，在此基础上增加一些缓冲。 |
-XX:MaxDirectMemorySize |
-XX:MaxDirectMemorySize=1g |
最大堆外内存（Direct Buffer） | 策略: 如果使用了 NIO（如 Netty），必须设置此参数来限制堆外内存的使用，防止意外的堆外内存泄漏拖垮整个系统。 |
4. GC 日志与监控 (Logging & Monitoring)
| 参数 | 示例 | 作用 | 设置依据 |
|---|---|---|---|
-Xlog:gc* (JDK9+) |
-Xlog:gc*,gc+heap=debug:file=gc.log:time,uptime:filecount=10,filesize=10m |
输出详细的 GC 日志 | 策略: 生产环境必选项。这是诊断 GC 问题的唯一可靠依据。配置日志轮转，防止打满磁盘。 |
-XX:+HeapDumpOnOutOfMemoryError |
-XX:+HeapDumpOnOutOfMemoryError |
在发生 OOM 时自动生成堆转储文件 | 策略: 生产环境必选项。用于事后分析内存泄漏的根本原因。 |
-XX:HeapDumpPath |
-XX:HeapDumpPath=./java_pid%p.hprof |
指定堆转储文件的路径 | 指定一个足够大的磁盘路径，%p 会自动替换为进程 PID。 |
-XX:+PrintFlagsFinal |
`-java -XX:+PrintFlagsFinal -version | grep HeapSize` | 打印所有参数的最终值 |
二、 参数设置策略与流程
明确目标：
- 吞吐量优先 (如数据导出、报表生成)：选用
ParallelGC。 - 低延迟优先 (如 Web 接口、交易系统)：选用
G1GC或ZGC。 - 避免频繁 Full GC：核心目标是减少
jstat中的FGC次数。
- 吞吐量优先 (如数据导出、报表生成)：选用
基准测试与监控：
- 使用
-Xlog:gc*开启 GC 日志。 - 使用
jstat -gcutil <pid> 1s实时监控。 - 使用 APM 工具（如 SkyWalking, Prometheus + Grafana）监控 JVM 指标。
- 使用
分析数据并迭代调整：
- 频繁 Minor GC：可能
-Xmn（新生代）太小，考虑增大。 - 对象过早晋升老年代：检查
-XX:MaxTenuringThreshold和-XX:SurvivorRatio。 - 频繁 Full GC：
- 如果是 MetaSpace 引起的，调整
-XX:MetaspaceSize。 - 如果是 老年代空间不足，首先分析
jmap -histo:live或堆转储，看是否存在内存泄漏。如果没有泄漏，则增大-Xmx。 - 如果是 G1，可以调整
-XX:InitiatingHeapOccupancyPercent。
- 如果是 MetaSpace 引起的，调整
- 频繁 Minor GC：可能
三、 典型场景配置示例
场景 1：4C8G 机器的 Web 应用（Spring Boot）
目标：低延迟，避免 Full GC。
java -Xms4g -Xmx4g \ # 堆大小设为系统内存一半，且固定
-XX:MetaspaceSize=256m \ # 元空间初始大小，避免扩容GC
-XX:MaxMetaspaceSize=512m \ # 限制元空间上限
-XX:MaxDirectMemorySize=1g \ # 限制堆外内存
-XX:+UseG1GC \ # 使用G1回收器
-XX:MaxGCPauseMillis=200 \ # 设定目标停顿时间
-XX:InitiatingHeapOccupancyPercent=45 \ # 并发标记触发阈值
-Xlog:gc*,gc+heap=debug:file=gc.log:time,uptime:filecount=10,filesize=10m \ # 详细GC日志
-XX:+HeapDumpOnOutOfMemoryError \ # OOM时生成dump
-XX:HeapDumpPath=./heap_dump.hprof \
-jar myapp.jar
场景 2：8C16G 的数据处理应用
目标：高吞吐量，尽快完成任务。
java -Xms12g -Xmx12g \ # 分配大内存
-XX:MetaspaceSize=256m \
-XX:MaxMetaspaceSize=512m \
-XX:+UseParallelGC \ # 使用并行回收器，吞吐量高
-XX:+UseParallelOldGC \ # 老年代也使用并行
-XX:ParallelGCThreads=6 \ # 根据CPU核数调整，留点资源给系统
-Xlog:gc*:file=gc.log::filecount=5,filesize=10m \
-jar my-batch-app.jar
最后强调：没有最好的参数，只有最适合当前场景的参数。一定要结合监控工具，用数据驱动决策，进行压测和调优迭代。