JVM 调优

1. JVM 调优概述

JVM 调优是 Java 应用性能优化的重要组成部分，特别是在生产环境中。合理的 JVM 参数配置可以显著提升应用性能，减少 GC 停顿时间，提高系统稳定性。

1.1 调优目标

提高吞吐量：减少 GC 时间，提高应用处理能力
- 在生产环境中，高吞吐量意味着系统能够处理更多的业务请求
- 通过优化 GC 策略，可以将 GC 时间从 10% 降低到 2-3%
- 对于电商、金融等高频交易系统，吞吐量提升直接影响业务收入
降低延迟：减少 GC 停顿时间，提高响应速度
- 生产环境中，用户对响应时间极其敏感
- GC 停顿时间过长会导致用户体验下降，甚至业务损失
- 通过调优可以将 GC 停顿时间控制在 100ms 以内
提高稳定性：避免 OOM，减少系统崩溃
- 生产环境 OOM 会导致服务不可用，影响业务连续性
- 合理的内存配置可以避免因内存不足导致的系统崩溃
- 通过内存调优可以提升系统可用性到 99.9% 以上
优化内存使用：合理分配堆内存，避免内存浪费
- 生产环境资源成本高，合理的内存配置可以节省服务器成本
- 避免内存浪费可以提高资源利用率
- 合理的内存分配策略可以提升系统整体性能

1.2 调优原则

先分析后调优：通过监控工具分析性能瓶颈
- 生产环境调优必须基于数据驱动，不能盲目调整
- 使用 JVisualVM、JProfiler 等工具分析性能瓶颈
- 通过 GC 日志分析 GC 频率、停顿时间等关键指标
逐步调优：一次调整一个参数，观察效果
- 生产环境稳定性优先，避免一次性调整多个参数
- 每次调整后需要观察 24-48 小时，确保系统稳定
- 记录每次调整的效果，建立调优历史
生产环境谨慎：在生产环境调优需要充分测试
- 调优前必须在测试环境充分验证
- 制定回滚方案，确保调优失败时能快速恢复
- 选择业务低峰期进行调优，降低风险
记录变更：详细记录每次调优的参数和效果
- 建立调优档案，记录参数变更历史
- 记录调优前后的性能指标对比
- 为后续调优提供参考依据

2. 内存调优

内存调优是 JVM 调优的核心，直接影响应用的性能、稳定性和资源利用率。在生产环境中，合理的内存配置可以避免 OOM、减少 GC 频率、提高系统吞吐量。

2.1 堆内存设置

堆内存是 Java 应用的主要工作区域，合理设置堆内存大小是生产环境调优的关键。

2.1.1 基础参数

# 设置堆内存大小
-Xms2g          # 初始堆大小
-Xmx4g          # 最大堆大小

# 设置新生代大小
-Xmn1g          # 新生代大小（建议为堆的1/3-1/4）

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

生产环境调优要点：

-Xms 和 -Xmx 设置相同值：避免堆内存动态扩展导致的性能波动
- 生产环境建议设置为相同值，如 -Xms4g -Xmx4g
- 避免堆内存扩展时的 GC 停顿，提高系统稳定性
- 减少内存分配的开销，提升应用性能
堆内存大小选择：
- 小应用（< 2GB）：-Xms512m -Xmx1g
- 中等应用（2-8GB）：-Xms2g -Xmx4g
- 大应用（> 8GB）：-Xms8g -Xmx16g
- 超大应用（> 16GB）：考虑使用 G1 收集器
元空间设置：
- 元空间用于存储类元数据，避免永久代 OOM
- 生产环境建议设置合理的上限，避免元空间无限增长
- 监控元空间使用情况，及时调整大小

2.1.2 内存分配策略

# 新生代和老年代比例
-XX:NewRatio=2          # 老年代:新生代 = 2:1

# Eden和Survivor比例
-XX:SurvivorRatio=8     # Eden:Survivor = 8:1:1

# 设置大对象阈值
-XX:PretenureSizeThreshold=1m

生产环境内存分配策略：

新生代设置：
- 新生代大小直接影响 Minor GC 频率
- 新生代过小会导致频繁的 Minor GC，影响性能
- 新生代过大会导致 Minor GC 时间过长
- 生产环境建议新生代为堆内存的 1/3-1/4
Eden 和 Survivor 比例：
- SurvivorRatio=8 表示 Eden:Survivor = 8:1:1
- 合理的比例可以减少对象在 Survivor 区的复制次数
- 生产环境建议根据对象生命周期调整比例
大对象处理：
- PretenureSizeThreshold 设置大对象直接进入老年代的阈值
- 避免大对象在新生代中频繁复制
- 生产环境建议根据业务特点设置合适的阈值

2.2 内存调优策略

生产环境的内存调优需要根据应用特点、业务场景和系统资源进行针对性配置。

2.2.1 根据应用特点调整

# 高并发应用
-Xms4g -Xmx4g -Xmn2g -XX:SurvivorRatio=8

# 大数据处理应用
-Xms8g -Xmx8g -Xmn4g -XX:NewRatio=1

# 微服务应用
-Xms512m -Xmx1g -Xmn256m

生产环境应用场景分析：

高并发 Web 应用：
- 特点：用户请求频繁，对象生命周期短，需要快速响应
- 内存配置：较大的新生代，较小的老年代
- 调优重点：减少 Minor GC 频率，提高响应速度
- 监控指标：响应时间、吞吐量、GC 频率
大数据处理应用：
- 特点：处理大量数据，对象生命周期长，需要大内存
- 内存配置：较大的堆内存，合理的新生代比例
- 调优重点：避免 Full GC，提高处理效率
- 监控指标：处理速度、内存使用率、GC 停顿时间
微服务应用：
- 特点：服务轻量，资源有限，需要快速启动
- 内存配置：较小的堆内存，合理的新生代设置
- 调优重点：减少内存占用，提高启动速度
- 监控指标：内存使用率、启动时间、GC 频率

2.2.2 内存溢出处理

# 发生OOM时生成堆转储文件
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/path/to/dump/

# 设置OOM后退出
-XX:+ExitOnOutOfMemoryError

生产环境 OOM 处理策略：

OOM 预防：
- 合理设置堆内存大小，避免内存不足
- 监控内存使用情况，及时调整配置
- 优化代码，避免内存泄漏
- 使用内存分析工具定期检查
OOM 诊断：
- 开启堆转储功能，生成 OOM 时的内存快照
- 使用 MAT 等工具分析堆转储文件
- 定位内存泄漏的具体原因
- 分析大对象和内存占用情况
OOM 恢复：
- 设置 OOM 后自动退出，避免系统不稳定
- 配置自动重启机制，快速恢复服务
- 建立告警机制，及时通知运维人员
- 制定应急处理流程，确保业务连续性

3. 垃圾收集器调优

垃圾收集器是 JVM 调优的核心组件，直接影响应用的性能表现。在生产环境中，选择合适的垃圾收集器并正确配置参数，可以显著提升系统性能。

3.1 垃圾收集器选择

生产环境垃圾收集器的选择需要综合考虑应用特点、硬件资源和性能要求。

3.1.1 串行收集器（Serial GC）

# 适用于单核或小内存应用
-XX:+UseSerialGC

生产环境适用场景：

单核服务器或资源受限环境
小内存应用（< 100MB）
对吞吐量要求不高的应用
开发测试环境

特点分析：

优点：简单稳定，资源占用少
缺点：GC 停顿时间长，不适合高并发应用
生产环境使用较少，主要用于特殊场景

3.1.2 并行收集器（Parallel GC）

# 适用于多核服务器，追求吞吐量
-XX:+UseParallelGC
-XX:ParallelGCThreads=4
-XX:MaxGCPauseMillis=200
-XX:GCTimeRatio=19

生产环境适用场景：

多核服务器（4 核以上）
对吞吐量要求高的应用
批处理系统、数据分析系统
对响应时间要求不严格的应用

生产环境调优要点：

ParallelGCThreads：设置为 CPU 核心数，避免过多线程竞争
MaxGCPauseMillis：设置合理的 GC 停顿时间目标
GCTimeRatio：控制 GC 时间占比，默认 19 表示 GC 时间不超过 5%
适合 CPU 密集型应用，不适合对延迟敏感的应用

3.1.3 并发收集器（CMS）

# 适用于对响应时间敏感的应用
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSInitiatingOccupancyOnly

生产环境适用场景：

对响应时间敏感的应用
Web 应用、API 服务
实时性要求高的系统
老年代对象生命周期较长的应用

生产环境调优要点：

CMSInitiatingOccupancyFraction：设置 CMS 启动阈值，避免并发模式失败
监控并发模式失败情况，及时调整参数
注意内存碎片问题，定期进行 Full GC
适合中等规模应用（2-8GB 堆内存）

3.1.4 G1 收集器（推荐）

# 适用于大内存应用，低延迟要求
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:G1HeapRegionSize=16m
-XX:G1NewSizePercent=30
-XX:G1MaxNewSizePercent=40
-XX:G1MixedGCCountTarget=8

生产环境适用场景：

大内存应用（> 8GB）
对延迟要求严格的应用
现代 Java 应用的首选
云原生、微服务架构

生产环境调优要点：

MaxGCPauseMillis：设置合理的停顿时间目标，通常 100-200ms
G1HeapRegionSize：根据堆大小设置，大堆使用更大的 region
G1NewSizePercent：新生代占比，根据对象生命周期调整
适合现代 Java 应用，是生产环境的主流选择

3.2 GC 调优参数

3.2.1 通用 GC 参数

# GC日志配置
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationStoppedTime
-Xloggc:/path/to/gc.log

# GC日志轮转
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=100M

3.2.2 性能监控参数

# JVM性能监控
-XX:+PrintCompilation
-XX:+PrintInlining
-XX:+PrintAssembly

# 类加载信息
-XX:+TraceClassLoading
-XX:+TraceClassUnloading

3.3 生产环境调优案例

3.3.1 案例一：电商系统响应时间过长

问题描述：

电商系统在高峰期响应时间超过 2 秒
用户投诉页面加载缓慢
系统吞吐量下降 30%

问题分析：

# 通过 GC 日志分析发现问题
# 发现 Full GC 频繁，每次停顿 3-5 秒
# 老年代使用率经常达到 95% 以上

调优方案：

# 原始配置
-Xms2g -Xmx4g -XX:+UseParallelGC

# 调优后配置
-Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:G1HeapRegionSize=16m

调优效果：

GC 停顿时间从 3-5 秒降低到 100-200ms
响应时间从 2 秒降低到 500ms
系统吞吐量提升 40%

3.3.2 案例二：大数据处理系统内存溢出

问题描述：

数据处理系统运行 2 小时后出现 OOM
系统处理大量数据时内存使用率持续上升
频繁的 Full GC 导致处理效率下降

问题分析：

# 通过堆转储分析发现
# 大量大对象直接进入老年代
# 新生代设置过小，对象过早晋升

调优方案：

# 原始配置
-Xms4g -Xmx8g -Xmn1g -XX:+UseParallelGC

# 调优后配置
-Xms8g -Xmx8g -Xmn3g -XX:+UseG1GC -XX:PretenureSizeThreshold=2m -XX:G1NewSizePercent=40

调优效果：

避免 OOM 问题，系统稳定运行
减少 Full GC 频率 60%
提高数据处理效率 25%

3.3.3 案例三：微服务应用启动缓慢

问题描述：

微服务应用启动时间超过 2 分钟
容器环境资源受限
服务启动后内存使用率过高

问题分析：

# 通过启动日志分析发现
# 类加载时间过长
# 初始堆内存设置不合理

调优方案：

# 原始配置
-Xms512m -Xmx1g -XX:+UseSerialGC

# 调优后配置
-Xms256m -Xmx512m -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+UseStringDeduplication

调优效果：

启动时间从 2 分钟降低到 30 秒
内存使用率降低 40%
服务响应时间提升 50%

3.3.4 案例四：高并发系统 GC 频繁

问题描述：

高并发 Web 应用 Minor GC 频率过高
每次 Minor GC 停顿时间 200-300ms
系统吞吐量受限

问题分析：

# 通过监控发现
# Minor GC 每 10 秒发生一次
# 新生代对象生命周期短
# Survivor 区设置不合理

调优方案：

# 原始配置
-Xms2g -Xmx4g -Xmn1g -XX:SurvivorRatio=8

# 调优后配置
-Xms4g -Xmx4g -Xmn2g -XX:SurvivorRatio=6 -XX:+UseG1GC -XX:MaxGCPauseMillis=100

调优效果：

Minor GC 频率降低 50%
GC 停顿时间降低到 50-100ms
系统吞吐量提升 35%

3.3.5 案例五：内存泄漏导致系统崩溃

问题描述：

系统运行 1 周后出现 OOM
内存使用率持续上升
频繁的 Full GC 无法释放内存

问题分析：

# 通过 MAT 分析堆转储发现
# 大量对象被静态集合持有
# 缓存对象没有及时清理

调优方案：

# 原始配置
-Xms2g -Xmx4g -XX:+UseParallelGC

# 调优后配置
-Xms4g -Xmx4g -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/

调优效果：

通过代码优化解决内存泄漏
系统稳定运行，不再出现 OOM
内存使用率保持在合理范围

3.3.6 案例六：容器环境资源限制

问题描述：

容器内存限制 1GB，应用经常被 OOMKilled
系统资源利用率低
服务不稳定

问题分析：

# 通过监控发现
# 堆内存设置过大，超出容器限制
# 没有考虑容器环境的特点

调优方案：

# 原始配置
-Xms1g -Xmx2g -XX:+UseParallelGC

# 调优后配置
-Xms512m -Xmx768m -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+UseStringDeduplication

调优效果：

避免容器 OOMKilled 问题
提高资源利用率 30%
服务稳定性显著提升

3.4 如何识别需要调整的参数

3.4.1 性能指标监控

关键性能指标：

GC 相关指标

# 监控 GC 频率和耗时
jstat -gc <pid> 1s

# 关键指标说明：
# YGC: Young GC 次数
# YGCT: Young GC 总耗时
# FGC: Full GC 次数
# FGCT: Full GC 总耗时
# GCT: GC 总耗时

内存使用指标

# 监控堆内存使用情况
jstat -gcutil <pid> 1s

# 关键指标说明：
# S0: Survivor 0 使用率
# S1: Survivor 1 使用率
# E: Eden 区使用率
# O: 老年代使用率
# M: 元空间使用率

系统资源指标

# 监控 CPU 使用率
top -p <pid>

# 监控内存使用
free -h

# 监控磁盘 I/O
iostat -x 1

3.4.2 问题识别方法

3.4.2.1 GC 问题识别

Minor GC 频繁：

# 现象：YGC 次数增长过快
# 判断标准：每分钟 Minor GC 超过 10 次
# 需要调整：-Xmn 参数，增加新生代大小

Full GC 频繁：

# 现象：FGC 次数过多
# 判断标准：每小时 Full GC 超过 5 次
# 需要调整：-Xmx 参数，增加堆内存大小

GC 停顿时间长：

# 现象：单次 GC 停顿时间过长
# 判断标准：停顿时间超过 200ms
# 需要调整：切换到 G1 收集器

3.4.2.2 内存问题识别

堆内存不足：

# 现象：OOM 异常
# 判断标准：出现 OutOfMemoryError
# 需要调整：-Xmx 参数，增加最大堆内存

元空间不足：

# 现象：Metaspace OOM
# 判断标准：出现 Metaspace OutOfMemoryError
# 需要调整：-XX:MaxMetaspaceSize 参数

内存泄漏：

# 现象：内存使用率持续上升
# 判断标准：内存使用率超过 90% 且持续上升
# 需要调整：代码优化，及时释放对象

3.4.2.3 性能问题识别

响应时间过长：

# 现象：用户请求响应时间超过 1 秒
# 判断标准：平均响应时间超过业务要求
# 需要调整：GC 收集器选择和参数优化

吞吐量下降：

# 现象：系统处理能力下降
# 判断标准：TPS 下降超过 20%
# 需要调整：减少 GC 时间，提高系统吞吐量

CPU 使用率过高：

# 现象：CPU 使用率持续超过 80%
# 判断标准：CPU 使用率异常高
# 需要调整：GC 线程数，减少 CPU 消耗

3.4.3 参数调整决策树

3.4.3.1 内存相关参数调整

# 堆内存调整决策
if (出现 OOM) {
    if (堆内存不足) {
        调整: -Xmx 增加最大堆内存
    } else if (元空间不足) {
        调整: -XX:MaxMetaspaceSize 增加元空间
    }
}

# 新生代调整决策
if (Minor GC 频繁) {
    if (新生代太小) {
        调整: -Xmn 增加新生代大小
    } else if (对象过早晋升) {
        调整: -XX:SurvivorRatio 调整 Survivor 比例
    }
}

3.4.3.2 GC 收集器选择决策

# GC 收集器选择决策
if (应用特点 == "高并发") {
    选择: G1 收集器
    参数: -XX:+UseG1GC -XX:MaxGCPauseMillis=200
} else if (应用特点 == "大数据处理") {
    选择: Parallel GC
    参数: -XX:+UseParallelGC -XX:ParallelGCThreads=8
} else if (应用特点 == "微服务") {
    选择: G1 收集器
    参数: -XX:+UseG1GC -XX:MaxGCPauseMillis=100
}

3.4.3.3 性能优化参数调整

# 性能优化参数调整
if (GC 停顿时间长) {
    调整: 切换到 G1 收集器
    参数: -XX:+UseG1GC -XX:MaxGCPauseMillis=200
}

if (内存使用率高) {
    调整: 启用字符串去重
    参数: -XX:+UseStringDeduplication
}

if (启动时间长) {
    调整: 优化启动参数
    参数: -XX:+UseCompressedOops -XX:+UseStringDeduplication
}

3.4.4 参数调整验证方法

3.4.4.1 调优前基线建立

# 1. 收集当前性能数据
jstat -gc <pid> 1s > gc_before.log
jstat -gcutil <pid> 1s > gcutil_before.log

# 2. 记录关键指标
# - GC 频率和耗时
# - 内存使用率
# - 响应时间
# - 吞吐量

3.4.4.2 调优后效果验证

# 1. 收集调优后数据
jstat -gc <pid> 1s > gc_after.log
jstat -gcutil <pid> 1s > gcutil_after.log

# 2. 对比分析
# - GC 频率是否降低
# - GC 停顿时间是否减少
# - 内存使用是否合理
# - 性能是否提升

3.4.4.3 持续监控

# 1. 建立监控告警
# - GC 停顿时间超过阈值告警
# - 内存使用率超过阈值告警
# - 响应时间超过阈值告警

# 2. 定期分析
# - 每周分析性能趋势
# - 每月评估调优效果
# - 及时调整参数配置

3.4.5 常见参数调整场景

3.4.5.1 场景一：新应用部署

# 初始参数设置
-Xms2g -Xmx4g -Xmn1g -XX:+UseG1GC

# 监控指标
# - 观察 1-2 周运行情况
# - 分析 GC 日志
# - 调整参数配置

3.4.5.2 场景二：性能问题排查

# 问题排查步骤
# 1. 分析 GC 日志
# 2. 检查内存使用情况
# 3. 分析性能瓶颈
# 4. 调整相关参数

3.4.5.3 场景三：容量规划

# 容量规划考虑因素
# - 业务增长预期
# - 硬件资源限制
# - 性能要求
# - 成本考虑

3.4.6 参数调整检查清单

3.4.6.1 调优前检查清单

性能基线检查：

[ ] 收集 1-2 周的系统运行数据
[ ] 记录 GC 频率、耗时和停顿时间
[ ] 监控内存使用率和峰值
[ ] 统计响应时间和吞吐量
[ ] 分析 CPU 使用率趋势

问题识别检查：

[ ] 分析 GC 日志，识别 GC 问题
[ ] 检查内存使用情况，识别内存问题
[ ] 分析性能指标，识别性能瓶颈
[ ] 确定调优目标和优先级
[ ] 制定调优方案和计划

风险评估检查：

[ ] 评估调优对系统稳定性的影响
[ ] 制定回滚方案和应急措施
[ ] 选择业务低峰期进行调优
[ ] 准备监控和告警机制
[ ] 通知相关业务人员

3.4.6.2 调优过程检查清单

参数调整检查：

[ ] 一次调整一个参数，避免同时调整多个参数
[ ] 记录每次调整的参数和原因
[ ] 观察调整后的系统表现
[ ] 监控关键性能指标变化
[ ] 验证业务功能正常运行

效果验证检查：

[ ] 对比调优前后的性能指标
[ ] 验证 GC 频率和停顿时间是否改善
[ ] 检查内存使用是否合理
[ ] 确认响应时间和吞吐量是否提升
[ ] 验证系统稳定性是否保持

持续监控检查：

[ ] 建立性能监控告警
[ ] 设置合理的告警阈值
[ ] 定期分析性能趋势
[ ] 及时响应性能问题
[ ] 记录调优经验和教训

3.4.6.3 调优后验证检查清单

性能指标验证：

[ ] GC 停顿时间是否减少
[ ] GC 频率是否降低
[ ] 内存使用率是否合理
[ ] 响应时间是否改善
[ ] 吞吐量是否提升

系统稳定性验证：

[ ] 系统运行是否稳定
[ ] 是否出现新的错误或异常
[ ] 业务功能是否正常
[ ] 用户体验是否改善
[ ] 系统可用性是否提升

调优效果评估：

[ ] 调优目标是否达成
[ ] 性能提升是否明显
[ ] 成本效益是否合理
[ ] 是否需要进一步调优
[ ] 调优经验是否可复用

4. 编译器调优

4.1 JIT 编译器优化

# 启用分层编译
-XX:+TieredCompilation

# 设置编译阈值
-XX:CompileThreshold=10000

# 设置编译线程数
-XX:CICompilerCount=2

# 禁用某些优化（调试用）
-XX:-UseCompressedOops
-XX:-UseCompressedClassPointers

4.2 代码缓存调优

# 设置代码缓存大小
-XX:ReservedCodeCacheSize=256m
-XX:InitialCodeCacheSize=64m

# 代码缓存清理
-XX:+UseCodeCacheFlushing
-XX:CodeCacheExpansionSize=32k

5. 线程调优

5.1 线程池配置

# 设置最大线程数
-XX:MaxDirectMemorySize=1g

# 线程栈大小
-Xss1m

# 线程本地分配缓冲区
-XX:TLABSize=256k

5.2 并发优化

# 启用偏向锁
-XX:+UseBiasedLocking

# 启用自旋锁
-XX:+UseSpinning

# 设置自旋次数
-XX:PreBlockSpin=10

6. 生产环境调优实践

生产环境调优是一个系统性的工程，需要遵循科学的流程和方法，确保调优效果的同时保证系统稳定性。

6.1 调优步骤

6.1.1 性能基线建立

监控工具选择：

JVisualVM：免费的 JVM 监控工具
- 实时监控堆内存、GC 情况
- 线程分析、CPU 使用率监控
- 适合生产环境长期监控
JProfiler：商业性能分析工具
- 功能强大，分析深入
- 适合复杂性能问题诊断
- 成本较高，适合关键系统
MAT (Memory Analyzer Tool)：内存分析工具
- 分析堆转储文件
- 定位内存泄漏问题
- 免费且功能强大
GCViewer：GC 日志分析工具
- 可视化 GC 日志分析
- 识别 GC 性能问题
- 免费且易于使用

关键指标监控：

堆内存使用率：
- 监控堆内存使用趋势
- 识别内存泄漏风险
- 设置合理的告警阈值
GC 频率和耗时：
- Minor GC 频率和耗时
- Full GC 频率和耗时
- GC 停顿时间分布
CPU 使用率：
- 应用 CPU 使用率
- GC 线程 CPU 使用率
- 系统 CPU 使用率
响应时间：
- 应用响应时间
- 数据库响应时间
- 网络延迟

6.1.2 调优流程

# 1. 收集基线数据
jstat -gc -t <pid> 1s

# 2. 分析GC日志
java -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

# 3. 逐步调整参数
# 4. 验证调优效果
# 5. 记录调优结果

生产环境调优流程详解：

基线数据收集（1-2 周）：
- 收集系统运行 1-2 周的完整数据
- 包括内存使用、GC 情况、CPU 使用率等
- 识别性能瓶颈和问题点
问题分析：
- 分析 GC 日志，识别 GC 问题
- 使用 MAT 分析内存使用情况
- 确定调优目标和方向
参数调整：
- 一次调整一个参数
- 每次调整后观察 24-48 小时
- 记录调整效果和影响
效果验证：
- 对比调优前后的性能指标
- 验证业务功能正常
- 确认系统稳定性
结果记录：
- 详细记录调优过程和结果
- 建立调优档案
- 为后续调优提供参考

6.2 常见调优场景

生产环境中的不同应用场景有不同的调优重点，需要根据业务特点进行针对性优化。

6.2.1 高并发 Web 应用

# 推荐配置
-Xms4g -Xmx4g
-Xmn2g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:G1HeapRegionSize=16m
-XX:+UseStringDeduplication

应用特点：

用户请求频繁，响应时间要求严格
对象生命周期短，大部分对象在新生代回收
对 GC 停顿时间敏感，需要低延迟

调优重点：

使用 G1 收集器，控制 GC 停顿时间
合理设置新生代大小，减少 Minor GC 频率
启用字符串去重，节省内存空间
监控响应时间，确保用户体验

生产环境注意事项：

选择业务低峰期进行调优
监控 GC 停顿时间，确保在可接受范围内
建立性能基线，持续监控调优效果

6.2.2 大数据处理应用

# 推荐配置
-Xms8g -Xmx8g
-Xmn4g
-XX:+UseParallelGC
-XX:ParallelGCThreads=8
-XX:MaxGCPauseMillis=500

应用特点：

处理大量数据，内存使用量大
对吞吐量要求高，可以容忍较长的 GC 停顿
对象生命周期较长，老年代对象较多

调优重点：

使用 Parallel GC，追求高吞吐量
设置较大的堆内存，满足大数据处理需求
合理设置新生代比例，平衡 GC 频率和停顿时间
监控内存使用情况，避免 OOM

生产环境注意事项：

根据数据量大小调整堆内存
监控 GC 时间占比，确保在合理范围内
定期检查内存泄漏，避免长期运行问题

6.2.3 微服务应用

# 推荐配置
-Xms512m -Xmx1g
-Xmn256m
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100
-XX:+UseStringDeduplication

应用特点：

服务轻量，资源占用少
启动速度快，响应时间要求严格
部署在容器环境中，资源受限

调优重点：

使用 G1 收集器，适应容器环境
设置较小的堆内存，节省资源
启用字符串去重，减少内存占用
优化启动时间，提高部署效率

生产环境注意事项：

根据容器资源限制调整内存配置
监控资源使用情况，避免超出限制
优化启动参数，提高服务启动速度

6.3 调优检查清单

生产环境调优需要严格的检查流程，确保调优效果的同时保证系统稳定性。

6.3.1 调优前检查

性能基线数据：

[ ] 收集 1-2 周的系统运行数据
[ ] 记录内存使用趋势和峰值
[ ] 统计 GC 频率、耗时和停顿时间
[ ] 监控 CPU 使用率和响应时间
[ ] 建立性能基线报告

当前 JVM 参数配置：

[ ] 记录当前所有 JVM 参数
[ ] 分析参数设置的合理性
[ ] 识别可能的配置问题
[ ] 准备参数调整方案

系统资源使用情况：

[ ] 检查服务器 CPU 核心数和频率
[ ] 确认可用内存大小
[ ] 分析磁盘 I/O 性能
[ ] 评估网络带宽情况

业务高峰期时间：

[ ] 识别业务高峰期时间段
[ ] 避开高峰期进行调优
[ ] 准备应急回滚方案
[ ] 通知相关业务人员

6.3.2 调优后验证

GC 停顿时间是否减少：

[ ] 对比调优前后的 GC 停顿时间
[ ] 确认停顿时间在可接受范围内
[ ] 监控 GC 停顿时间分布
[ ] 验证用户体验是否改善

吞吐量是否提升：

[ ] 测量系统处理能力是否提升
[ ] 对比调优前后的业务指标
[ ] 确认系统负载能力是否增强
[ ] 验证资源利用率是否提高

内存使用是否合理：

[ ] 检查堆内存使用是否合理
[ ] 确认元空间使用情况
[ ] 监控内存泄漏风险
[ ] 验证内存分配效率

系统稳定性是否保持：

[ ] 确认系统运行稳定
[ ] 检查错误日志和异常情况
[ ] 验证业务功能正常
[ ] 监控系统可用性指标

7. 监控和诊断

7.1 监控工具

7.1.1 命令行工具

# 查看JVM进程
jps -l

# 查看GC情况
jstat -gc <pid> 1s

# 查看堆内存
jmap -heap <pid>

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

7.1.2 图形化工具

JVisualVM：免费的 JVM 监控工具
JProfiler：商业性能分析工具
MAT：内存分析工具
GCViewer：GC 日志分析工具

7.2 性能分析

7.2.1 GC 分析

# 分析GC日志
java -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

# 使用GCViewer分析
# 关注指标：
# - GC频率
# - GC停顿时间
# - 内存回收效率

7.2.2 内存泄漏诊断

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

# 使用MAT分析
# 关注：
# - 大对象
# - 内存泄漏
# - 对象引用关系

7.3 生产环境诊断案例

7.3.1 案例一：GC 日志分析

问题现象：

# GC 日志显示频繁的 Full GC
[GC (Allocation Failure) [PSYoungGen: 1024K->0K(1536K)] 1024K->1024K(2560K), 0.0012345 secs]
[Full GC (Ergonomics) [PSOldGen: 1024K->1024K(1024K)] 1024K->1024K(2560K), 0.1234567 secs]

诊断步骤：

分析 GC 日志，发现 Full GC 频繁
检查老年代使用率，发现接近 100%
分析对象分配模式，发现大对象过多

解决方案：

# 调整新生代大小，减少对象过早晋升
-Xmn2g -XX:NewRatio=1

# 设置大对象阈值
-XX:PretenureSizeThreshold=1m

7.3.2 案例二：内存使用率分析

问题现象：

# jstat 显示内存使用率持续上升
jstat -gc <pid> 1s
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
1024.0 1024.0  0.0   0.0    8192.0   8192.0   2048.0     2048.0   4480.0 4480.0  512.0  512.0      1    0.001   1      0.123   0.124

诊断步骤：

监控内存使用趋势，发现持续上升
分析对象生命周期，发现长生命周期对象过多
检查代码，发现静态集合持有大量对象

解决方案：

# 增加堆内存大小
-Xms4g -Xmx8g

# 优化代码，及时清理不需要的对象
# 使用弱引用或软引用

7.3.3 案例三：GC 停顿时间分析

问题现象：

# GC 日志显示停顿时间过长
[GC (Allocation Failure) [PSYoungGen: 1024K->0K(1536K)] 1024K->1024K(2560K), 0.1234567 secs]
[Full GC (Ergonomics) [PSOldGen: 1024K->1024K(1024K)] 1024K->1024K(2560K), 1.2345678 secs]

诊断步骤：

分析 GC 停顿时间，发现超过 1 秒
检查 GC 收集器类型，发现使用 Parallel GC
分析堆内存大小，发现设置不合理

解决方案：

# 切换到 G1 收集器
-XX:+UseG1GC -XX:MaxGCPauseMillis=200

# 调整堆内存大小
-Xms4g -Xmx4g

7.3.4 案例四：线程分析

问题现象：

# jstack 显示大量线程等待
"http-nio-8080-exec-1" #1 daemon prio=5 os_prio=0 tid=0x00007f8b8c000000 nid=0x1234 waiting for monitor entry

诊断步骤：

分析线程状态，发现大量线程等待
检查锁竞争情况，发现热点锁
分析业务逻辑，发现同步代码过多

解决方案：

# 调整线程池大小
-XX:CICompilerCount=2

# 优化代码，减少同步操作
# 使用无锁数据结构

7.3.5 案例五：类加载分析

问题现象：

# 启动日志显示类加载时间过长
[Loaded java.lang.String from /usr/lib/jvm/java-8-openjdk/jre/lib/rt.jar]
[Loaded java.lang.Object from /usr/lib/jvm/java-8-openjdk/jre/lib/rt.jar]

诊断步骤：

分析启动日志，发现类加载时间过长
检查类路径，发现不必要的 jar 包
分析类加载器，发现重复加载

解决方案：

# 优化类路径，移除不必要的 jar 包
# 使用类加载器缓存
-XX:+UseCompressedOops

7.3.6 案例六：CPU 使用率分析

问题现象：

# top 显示 Java 进程 CPU 使用率过高
PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
1234 java     20   0 1234567 123456  1234 R  99.9  12.3   1:23.45 java

诊断步骤：

分析 CPU 使用率，发现持续 99%
检查 GC 线程，发现 GC 线程占用大量 CPU
分析业务逻辑，发现死循环或无限递归

解决方案：

# 调整 GC 线程数
-XX:ParallelGCThreads=4

# 优化代码，避免死循环
# 使用异步处理

8. 常见问题和解决方案

8.1 常见问题

8.1.1 OutOfMemoryError

# 问题：堆内存不足
# 解决：增加堆内存或优化代码
-Xmx4g

# 问题：元空间不足
# 解决：增加元空间大小
-XX:MaxMetaspaceSize=512m

8.1.2 GC 频繁

# 问题：新生代太小
# 解决：增加新生代大小
-Xmn2g

# 问题：老年代回收频繁
# 解决：调整新生代比例
-XX:NewRatio=2

8.1.3 响应时间过长

# 问题：GC停顿时间长
# 解决：使用G1收集器
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200

8.2 问题诊断和解决案例

8.2.1 案例一：系统突然变慢

问题现象：

系统运行正常，突然响应时间变慢
用户投诉页面加载缓慢
系统监控显示 CPU 使用率正常

诊断过程：

# 1. 检查 GC 日志
tail -f gc.log
# 发现频繁的 Full GC，每次停顿 2-3 秒

# 2. 分析内存使用
jstat -gc <pid> 1s
# 发现老年代使用率 95% 以上

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

解决方案：

# 调整堆内存大小
-Xms4g -Xmx4g

# 切换到 G1 收集器
-XX:+UseG1GC -XX:MaxGCPauseMillis=200

效果验证：

GC 停顿时间从 2-3 秒降低到 100-200ms
响应时间从 5 秒降低到 1 秒
系统吞吐量提升 40%

8.2.2 案例二：内存使用率持续上升

问题现象：

系统运行 1 周后内存使用率从 60% 上升到 95%
频繁的 Full GC 无法释放内存
系统最终出现 OOM

诊断过程：

# 1. 监控内存使用趋势
jstat -gc <pid> 1s | grep -E "OU|MU"
# 发现老年代和元空间使用率持续上升

# 2. 分析堆转储
# 使用 MAT 分析发现大量对象被静态集合持有
# 发现缓存对象没有及时清理

解决方案：

# 增加堆内存大小
-Xms8g -Xmx8g

# 优化代码，及时清理缓存
# 使用弱引用或软引用
# 设置缓存过期时间

效果验证：

内存使用率稳定在 70% 左右
不再出现 OOM 问题
系统稳定运行

8.2.3 案例三：容器环境资源限制

问题现象：

容器内存限制 1GB，应用经常被 OOMKilled
系统资源利用率低
服务不稳定，频繁重启

诊断过程：

# 1. 检查容器资源限制
docker stats <container_id>
# 发现内存使用超过 1GB 限制

# 2. 分析 JVM 内存配置
# 发现堆内存设置过大，没有考虑容器环境

解决方案：

# 调整堆内存大小，考虑容器限制
-Xms512m -Xmx768m

# 使用 G1 收集器，适应容器环境
-XX:+UseG1GC -XX:MaxGCPauseMillis=100

# 启用字符串去重
-XX:+UseStringDeduplication

效果验证：

避免容器 OOMKilled 问题
提高资源利用率 30%
服务稳定性显著提升

8.2.4 案例四：高并发系统性能下降

问题现象：

高并发 Web 应用在高峰期性能下降
响应时间从 100ms 增加到 2 秒
系统吞吐量下降 50%

诊断过程：

# 1. 分析 GC 日志
# 发现 Minor GC 频率过高，每 5 秒一次
# 每次 Minor GC 停顿时间 200-300ms

# 2. 检查新生代设置
# 发现新生代设置过小，对象过早晋升

解决方案：

# 增加新生代大小
-Xmn2g

# 调整 Survivor 比例
-XX:SurvivorRatio=6

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

效果验证：

Minor GC 频率降低 60%
GC 停顿时间降低到 50-100ms
系统吞吐量提升 35%

8.2.5 案例五：启动时间过长

问题现象：

微服务应用启动时间超过 3 分钟
容器环境资源受限
服务部署效率低

诊断过程：

# 1. 分析启动日志
# 发现类加载时间过长
# 发现初始堆内存设置不合理

# 2. 检查 JVM 参数
# 发现使用了串行 GC，不适合多核环境

解决方案：

# 优化启动参数
-Xms256m -Xmx512m

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

# 启用字符串去重
-XX:+UseStringDeduplication

# 优化类加载
-XX:+UseCompressedOops

效果验证：

启动时间从 3 分钟降低到 30 秒
内存使用率降低 40%
服务响应时间提升 50%

8.3 最佳实践

8.2.1 参数设置原则

堆内存设置：根据应用实际需求设置
新生代设置：通常为堆的 1/3-1/4
GC 选择：根据应用特点选择合适的收集器
监控配置：开启必要的监控参数

8.2.2 调优注意事项

逐步调优：一次调整一个参数
充分测试：在生产环境前充分测试
记录变更：详细记录每次调优
监控效果：持续监控调优效果

9. 总结

JVM 调优是一个持续的过程，需要根据应用特点和业务需求进行针对性优化。在生产环境中，合理的 JVM 调优可以带来显著的性能提升和成本节约。

9.1 调优核心要点

先分析后调优：通过监控工具分析性能瓶颈
- 建立完善的性能监控体系
- 使用专业的分析工具定位问题
- 基于数据驱动进行调优决策
- 避免盲目调整参数
选择合适的 GC：根据应用特点选择垃圾收集器
- 高并发应用选择 G1 收集器
- 大数据处理选择 Parallel GC
- 微服务应用选择 G1 收集器
- 根据硬件资源选择合适的收集器
合理设置内存：根据实际需求设置堆内存大小
- 根据应用特点设置堆内存大小
- 合理配置新生代和老年代比例
- 设置元空间大小避免 OOM
- 监控内存使用情况及时调整
持续监控：建立完善的监控体系
- 建立性能基线数据
- 设置合理的告警阈值
- 定期分析性能趋势
- 及时响应性能问题
记录和总结：详细记录调优过程和效果
- 建立调优档案和知识库
- 记录调优前后的性能对比
- 总结调优经验和教训
- 为后续调优提供参考

9.2 生产环境调优价值

性能提升价值：

减少 GC 停顿时间 50-80%
提高系统吞吐量 20-50%
降低响应时间 30-60%
提升用户体验和业务价值

成本节约价值：

减少服务器资源需求 20-40%
降低硬件采购成本
提高资源利用率
减少运维工作量

稳定性提升价值：

避免 OOM 导致的系统崩溃
减少 GC 导致的性能波动
提高系统可用性到 99.9% 以上
增强业务连续性保障

9.3 调优成功要素

技术要素：

深入理解 JVM 工作原理
掌握各种垃圾收集器特点
熟练使用监控和分析工具
具备丰富的调优经验

流程要素：

建立科学的调优流程
制定详细的调优计划
严格执行调优步骤
持续监控调优效果

团队要素：

具备专业的调优团队
建立完善的调优规范
形成调优知识积累
建立调优经验分享机制

9.4 未来发展趋势

技术发展趋势：

ZGC 和 Shenandoah 等低延迟收集器
云原生环境下的 JVM 调优
AI 辅助的自动调优技术
容器化环境下的资源优化

实践发展趋势：

自动化调优工具的发展
基于机器学习的参数优化
实时性能监控和调优
跨平台调优经验的积累

通过合理的 JVM 调优，可以显著提升 Java 应用的性能，提高系统的稳定性和用户体验。在生产环境中，JVM 调优不仅是技术问题，更是业务价值的重要保障。