JVM 性能调优

JVM性能调优是Java应用性能优化的重要环节。通过合理配置JVM参数，可以显著提升应用的吞吐量和响应速度。本章将介绍JVM调优的基本原则、常用参数和调优策略。

为什么要进行JVM调优？

常见性能问题

1. 内存不足：频繁GC，甚至OOM
2. GC停顿过长：影响用户体验
3. 吞吐量不足：系统处理能力受限
4. 响应延迟高：请求处理时间长

调优目标

JVM内存参数

堆内存设置

# 设置初始堆大小
-Xms512m

# 设置最大堆大小
-Xmx2g

# 推荐：初始堆和最大堆设置为相同值，避免动态扩容
-Xms2g -Xmx2g

设置原则：

• 堆大小通常设置为物理内存的50%-80%
• 预留足够内存给操作系统和其他进程
• 初始堆和最大堆设置为相同值

新生代设置

# 设置新生代大小
-Xmn512m

# 设置新生代与老年代比例（新生代占比）
-XX:NewRatio=2  # 新生代:老年代 = 1:2

# 设置Eden与Survivor比例
-XX:SurvivorRatio=8  # Eden:Survivor = 8:1:1

设置原则：

• 新生代太小：频繁Minor GC
• 新生代太大：老年代空间不足，Full GC频繁
• 一般设置为堆大小的1/3到1/4

元空间设置

# 设置元空间初始大小
-XX:MetaspaceSize=128m

# 设置元空间最大大小
-XX:MaxMetaspaceSize=512m

直接内存设置

# 设置直接内存最大大小
-XX:MaxDirectMemorySize=256m

垃圾收集器参数

Serial收集器

# 使用Serial收集器
-XX:+UseSerialGC

适用于：客户端应用、小内存场景

Parallel收集器

# 使用Parallel收集器（JDK8默认）
-XX:+UseParallelGC

# 设置最大GC停顿时间目标
-XX:MaxGCPauseMillis=200

# 设置吞吐量目标（GC时间占比）
-XX:GCTimeRatio=99  # 1/(1+99) = 1% GC时间

# 启用自适应调节
-XX:+UseAdaptiveSizePolicy

适用于：批处理、后台计算、吞吐量优先

G1收集器

# 使用G1收集器（JDK9+默认）
-XX:+UseG1GC

# 设置最大GC停顿时间目标
-XX:MaxGCPauseMillis=200

# 设置Region大小（1-32MB，2的幂）
-XX:G1HeapRegionSize=4m

# 设置触发并发GC的堆占用阈值
-XX:InitiatingHeapOccupancyPercent=45

# 设置Mixed GC次数
-XX:G1MixedGCCountTarget=8

适用于：服务端应用、大内存、低延迟

CMS收集器（JDK14已移除）

# 使用CMS收集器
-XX:+UseConcMarkSweepGC

# 设置CMS启动阈值
-XX:CMSInitiatingOccupancyFraction=75

# 启用CMS压缩
-XX:+UseCMSCompactAtFullCollection

ZGC收集器

# JDK 21+ 推荐使用分代ZGC
-XX:+UseZGC -XX:+ZGenerational

# 其他重要参数
-XX:SoftMaxHeapSize=12g        # 软最大堆大小
-XX:-ZUncommit                 # 禁用内存归还（低延迟优先时建议）
-XX:ZUncommitDelay=300         # 内存归还延迟（秒）
-XX:+UseLargePages             # 启用大页（性能提升）
-XX:+AlwaysPreTouch            # 预分配内存（减少运行时开销）

适用于：大内存、超低延迟、停顿时间小于1ms

GC日志参数

JDK8及之前

# 打印GC详细信息
-XX:+PrintGCDetails

# 打印GC时间戳
-XX:+PrintGCDateStamps

# 打印GC原因
-XX:+PrintGCCause

# 打印堆信息
-XX:+PrintHeapAtGC

# 输出GC日志到文件
-Xloggc:/path/to/gc.log

JDK9及之后

# 统一日志配置
-Xlog:gc*:file=/path/to/gc.log:time,level,tags

# 打印GC详细信息
-Xlog:gc*

# 打印GC原因
-Xlog:gc+cause

# 打印堆信息
-Xlog:gc+heap

常用调优策略

吞吐量优先

适用于批处理、后台计算任务：

java -Xmx4g -Xms4g \
     -XX:+UseParallelGC \
     -XX:NewRatio=2 \
     -XX:SurvivorRatio=8 \
     -XX:GCTimeRatio=99 \
     -XX:+UseAdaptiveSizePolicy \
     -jar app.jar

延迟优先

适用于Web服务、实时系统：

java -Xmx4g -Xms4g \
     -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=100 \
     -XX:InitiatingHeapOccupancyPercent=35 \
     -XX:G1HeapRegionSize=8m \
     -jar app.jar

大内存场景

适用于大数据处理、缓存服务：

# JDK 21+ 推荐：分代ZGC
java -Xmx16g -Xms16g \
     -XX:+UseZGC \
     -XX:+ZGenerational \
     -XX:SoftMaxHeapSize=12g \
     -XX:+UseLargePages \
     -XX:+AlwaysPreTouch \
     -jar app.jar

# JDK 11-20：非分代ZGC
java -Xmx16g -Xms16g \
     -XX:+UseZGC \
     -jar app.jar

容器环境

在Docker/Kubernetes中运行时，需要注意内存限制：

# JDK 8u191+ 自动识别容器内存限制
java -XX:+UseContainerSupport \
     -XX:MaxRAMPercentage=75.0 \
     -XX:InitialRAMPercentage=75.0 \
     -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=200 \
     -jar app.jar

# 明确指定内存（推荐用于Kubernetes）
# 注意：需要预留内存给操作系统和其他进程
java -Xmx4g -Xms4g \
     -XX:+UseG1GC \
     -jar app.jar

容器环境注意事项：

• 使用 -XX:+UseContainerSupport 让JVM识别容器资源限制
• 使用百分比配置（MaxRAMPercentage）比固定值更灵活
• 预留至少25%的容器内存给操作系统和JVM非堆内存
• 避免容器内存限制和JVM堆大小设置冲突

性能分析工具

jstat

实时查看GC统计信息：

# 每秒输出GC统计
jstat -gc <pid> 1000

# 输出GC汇总
jstat -gcutil <pid>

# 输出GC原因
jstat -gccause <pid>

jmap

生成堆转储文件：

# 生成堆转储
jmap -dump:format=b,file=heap.hprof <pid>

# 查看堆配置
jmap -heap <pid>

# 查看对象统计
jmap -histo <pid> | head -20

jstack

查看线程堆栈：

# 打印线程堆栈
jstack <pid>

# 检测死锁
jstack -l <pid>

VisualVM

图形化监控工具，JDK自带：

# 启动VisualVM
jvisualvm

JConsole

JMX监控工具：

# 启动JConsole
jconsole

Arthas

阿里开源的Java诊断工具：

# 启动Arthas
java -jar arthas-boot.jar

# 查看Dashboard
dashboard

# 监控方法执行
watch com.example.Service method '{params, returnObj}'

# 追踪方法调用路径
trace com.example.Service method

调优案例分析

案例1：频繁Full GC

现象：应用频繁Full GC，响应变慢

分析：

1. 查看GC日志，发现老年代快速增长
2. 使用jmap分析堆内存，发现大对象

解决：

# 增大堆内存
-Xmx4g -Xms4g

# 增大新生代，减少对象晋升
-Xmn1g

# 使用G1收集器
-XX:+UseG1GC

案例2：内存泄漏

现象：内存持续增长，最终OOM

分析：

1. 使用jmap生成堆转储
2. 使用MAT分析，发现某个集合持续增长

解决：

1. 修复代码中的内存泄漏
2. 使用WeakHashMap或设置缓存过期策略

案例3：响应延迟高

现象：接口响应时间不稳定，偶发延迟

分析：

1. 查看GC日志，发现GC停顿时间长
2. 使用G1收集器的Mixed GC

解决：

# 使用G1收集器
-XX:+UseG1GC

# 降低停顿时间目标
-XX:MaxGCPauseMillis=100

# 提前触发并发GC
-XX:InitiatingHeapOccupancyPercent=35

案例4：电商大促场景调优

场景描述：电商平台在促销期间QPS从1000飙升到10000，服务出现大量超时。

问题分析：

# 1. 监控指标
jstat -gcutil <pid> 1000

# 发现：
# - Young GC频率从每秒1次变成每秒10次
# - 老年代使用率快速上升
# - 开始出现Full GC

# 2. 分析原因
# - 对象创建速率暴增
# - 年轻代太小，对象过早晋升
# - 大量促销对象无法及时回收

调优过程：

# 初始配置
-Xmx4g -Xms4g -XX:+UseG1GC

# 第一步：增大堆内存
-Xmx8g -Xms8g -XX:+UseG1GC

# 第二步：增大年轻代
-Xmx8g -Xms8g -XX:+UseG1GC -XX:G1NewSizePercent=30

# 第三步：调整并发标记阈值
-Xmx8g -Xms8g -XX:+UseG1GC \
-XX:G1NewSizePercent=30 \
-XX:InitiatingHeapOccupancyPercent=30 \
-XX:MaxGCPauseMillis=100

# 第四步：禁用显式GC（如果代码中有System.gc()）
-XX:+DisableExplicitGC

调优效果：

指标	调优前	调优后
Young GC频率	10次/秒	3次/秒
Full GC频率	2次/分钟	0次
P99响应时间	2000ms	50ms
吞吐量	5000 QPS	12000 QPS

案例5：微服务容器化部署调优

场景描述：微服务部署在Kubernetes中，每个Pod限制4GB内存，服务偶发OOM Killed。

问题分析：

容器内存限制和JVM堆内存配置的关系：

容器总内存 (4GB)
├── JVM堆内存 (需要预留空间)
│   ├── 堆 (-Xmx)
│   └── 元空间 (-XX:MaxMetaspaceSize)
├── JVM非堆内存
│   ├── 线程栈 (-Xss × 线程数)
│   ├── 直接内存 (-XX:MaxDirectMemorySize)
│   ├── Code Cache
│   └── GC数据结构
└── 操作系统开销

调优配置：

# 错误配置：堆内存设置过大
-Xmx4g  # 会导致OOM Killed

# 正确配置：使用容器感知
-XX:+UseContainerSupport \
-XX:MaxRAMPercentage=70.0 \
-XX:InitialRAMPercentage=70.0 \
-XX:MaxMetaspaceSize=256m \
-XX:MaxDirectMemorySize=512m \
-Xss512k

# 完整的容器优化配置
java -XX:+UseContainerSupport \
     -XX:MaxRAMPercentage=70.0 \
     -XX:InitialRAMPercentage=70.0 \
     -XX:MaxMetaspaceSize=256m \
     -XX:MaxDirectMemorySize=512m \
     -Xss512k \
     -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=100 \
     -Xlog:gc*:file=/logs/gc.log:time,level,tags:filecount=5,filesize=50m \
     -jar app.jar

Kubernetes资源限制配置：

resources:
  limits:
    memory: "4Gi"
  requests:
    memory: "3Gi"

案例6：大数据批处理任务调优

场景描述：离线数据处理任务，处理1TB数据，要求在4小时内完成。

问题分析：

• 批处理任务关注吞吐量
• GC停顿对总时间影响较小
• 可以接受较长的GC停顿换取更高的吞吐量

调优配置：

# 使用Parallel GC，吞吐量优先
java -Xmx32g -Xms32g \
     -XX:+UseParallelGC \
     -XX:NewRatio=1 \
     -XX:SurvivorRatio=8 \
     -XX:GCTimeRatio=99 \
     -XX:+UseParallelOldGC \
     -XX:ParallelGCThreads=16 \
     -jar batch-job.jar

# 参数说明：
# - NewRatio=1: 年轻代和老年代各占一半
# - GCTimeRatio=99: 目标GC时间占比1%
# - ParallelGCThreads=16: 使用16个GC线程

案例7：实时交易系统调优

场景描述：高频交易系统，要求P99.99延迟小于10ms。

问题分析：

• 延迟敏感，不能容忍任何长停顿
• 需要使用ZGC的超低延迟特性

调优配置：

# 使用分代ZGC
java -Xmx64g -Xms64g \
     -XX:+UseZGC \
     -XX:+ZGenerational \
     -XX:+UseLargePages \
     -XX:+AlwaysPreTouch \
     -XX:-ZUncommit \
     -XX:ConcGCThreads=8 \
     -Xlog:gc*:file=/logs/gc.log:time,level,tags \
     -jar trading-system.jar

# 关键配置说明：
# - AlwaysPreTouch: 启动时预分配内存，避免运行时内存分配延迟
# - ZUncommit=false: 禁用内存归还，避免归还延迟
# - UseLargePages: 使用大页，减少TLB缺失
# - ConcGCThreads=8: 增加并发GC线程

进一步优化：CPU绑定

# 绑定到特定CPU核心，减少上下文切换
taskset -c 0-15 java -Xmx64g ...

# 或使用cgroups
cgexec -g cpuset:trading java ...

案例8：Spring Boot应用启动优化

场景描述：Spring Boot应用启动时间超过60秒，影响服务弹性伸缩。

问题分析：

启动慢的原因：

1. 类加载开销大
2. Bean初始化耗时长
3. JIT编译开销

优化方案：

# 1. 使用类数据共享（CDS）
# 第一次运行：生成共享归档
java -XX:ArchiveClassesAtExit=app.jsa -jar app.jar

# 后续运行：使用共享归档
java -XX:SharedArchiveFile=app.jsa -jar app.jar

# 2. 使用AppCDS（应用类数据共享）
# 生成类列表
java -Xshare:off -XX:+UseAppCDS -XX:DumpLoadedClassList=app.lst -jar app.jar

# 生成共享归档
java -Xshare:dump -XX:+UseAppCDS -XX:SharedClassListFile=app.lst -XX:SharedArchiveFile=app.jsa -cp app.jar

# 使用共享归档
java -Xshare:on -XX:+UseAppCDS -XX:SharedArchiveFile=app.jsa -jar app.jar

# 3. 使用GraalVM原生镜像（启动时间<100ms）
native-image -jar app.jar
./app

# 4. JVM参数优化
java -Xmx2g -Xms2g \
     -XX:+UseG1GC \
     -XX:+TieredCompilation \
     -XX:TieredStopAtLevel=1 \  # 只使用C1编译器，加快启动
     -Xverify:none \             # 跳过字节码验证（仅开发环境）
     -jar app.jar

启动时间对比：

优化方式	启动时间
无优化	60秒
CDS	45秒
AppCDS	35秒
TieredStopAtLevel=1	25秒
GraalVM原生镜像	0.1秒

调优最佳实践

1. 先监控，后调优

不要盲目调优，先收集数据：

1. 开启GC日志
2. 使用监控工具收集数据
3. 分析问题原因
4. 针对性调优

2. 调优参数最小化

只设置必要的参数，避免过度调优：

# 最小配置
-Xmx2g -Xms2g -XX:+UseG1GC -Xlog:gc*:file=gc.log

3. 代码优化优先

JVM调优是最后的手段，代码优化更重要：

• 减少对象创建
• 使用对象池
• 优化算法
• 避免内存泄漏

4. 测试验证

调优后必须进行测试验证：

• 压力测试
• 基准测试
• 对比调优前后性能

小结

JVM性能调优是一个系统工程：

1. 调优目标：吞吐量、延迟、内存占用
2. 内存参数：堆大小、新生代、元空间
3. 垃圾收集器选择：根据场景选择合适的收集器
4. 分析工具：jstat、jmap、jstack、VisualVM、Arthas
5. 调优策略：先监控、后调优、代码优化优先

参考资料

• HotSpot Virtual Machine Garbage Collection Tuning Guide (JDK 21)
• Java Performance Tuning Guide
• Arthas官方文档
• Container Support in JDK