JVM调优“瞎调”——没分析GC日志，乱改堆内存参数导致OOM

admin
Java
14天前
13热度
0评论

JVM调优实战：正确分析GC日志避免“瞎调”堆内存导致OOM

在进行JVM调优时，很多时候开发者会因为缺乏对系统实际状况的了解和深入分析而盲目修改参数，最终导致性能问题。这篇文章将通过几个真实案例详细解析如何通过正确的步骤来优化JVM配置，并避免常见的错误做法。

一、典型“瞎调”场景

场景：感觉系统慢，上来就改堆内存

当感觉到系统的响应变慢时，一些开发者常常会直接增大堆内存参数，而没有进行详细的分析。这种“经验主义”的调整方式可能会带来意想不到的问题：

# 常见“经验主义”调参
-Xms8g -Xmx8g -Xmn4g -XX:SurvivorRatio=8

结果：

老年代内存设置过大，导致Full GC时间过长。
系统频繁卡顿或直接死锁。
整体性能下降。

正确的调优流程

观察现状
分析GC日志
定位问题
针对性调整
验证效果

今天我们将按照这个流程，一步步带你学习如何正确进行JVM参数优化。

二、第一步：学会看GC日志

2.1 开启GC日志（必做）

开启详细的GC日志记录是分析问题的必备步骤。根据不同的JDK版本，配置方式有所不同：

JDK 8：

-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-XX:+PrintGCTimeStamps 
-Xloggc:/path/to/gc.log 
-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=5 
-XX:GCLogFileSize=20M

JDK 9+：

-Xlog:gc*:file=/path/to/gc.log:time,uptime,level,tags:filecount=5,filesize=20M

2.2 看懂GC日志的关键指标

Young GC 日志示例：

2024-01-15T10:30:25.123+0800: 120.456: [GC (Allocation Failure) 
[PSYoungGen: 524288K->87345K(611840K)] 524288K->123456K(2015232K), 
0.0234567 secs] [Times: user=0.06 sys=0.01, real=0.02 secs]

拆解：

PSYoungGen: 524288K->87345K —— Young区回收前后大小
(611840K) —— Young区总容量
524288K->123456K(2015232K) —— 堆整体回收前后大小
0.0234567 secs —— GC耗时
real=0.02 secs —— 实际停顿时间

Full GC 日志示例：

2024-01-15T10:35:12.456+0800: 420.789: [Full GC (Metadata GC Threshold) 
[PSYoungGen: 0K->0K(139776K)] 
[ParOldGen: 1023456K->1023456K(1398272K)] 
1023456K->1023456K(1538048K), [Metaspace: 98765K->98765K(1099776K)], 
0.8765432 secs] [Times: user=0.89 sys=0.01, real=0.88 secs]

关键信号：

Full GC耗时超过1秒
垃圾回收后老年代占用不降，可能存在内存泄漏
元空间不够或类加载导致的Metadata GC Threshold

三、案例一：堆内存改太大，GC停顿几十秒

现象描述

系统TP99从50ms飙升到5秒，监控显示每次Full GC耗时长达20-30秒。

GC日志分析：

2024-01-15T10:30:25.123+0800: 120.456: [GC (Allocation Failure) 
[PSYoungGen: 1048576K->1024000K(1258304K)] 
1048576K->1024000K(8192000K), 0.5234567 secs]  # Young GC耗时500ms

2024-01-15T10:30:45.123+0800: 140.456: [Full GC (Ergonomics) 
[PSYoungGen: 1024000K->0K(1258304K)] 
[ParOldGen: 6144000K->6144000K(6933696K)] 
7168000K->6144000K(8192000K), 25.6789012 secs]  # Full GC耗时25秒！

问题定位

老年代内存接近7G，每次Full GC需要扫描大量数据。
每次GC停顿时间过长导致服务响应超时。

根本原因与解决方案

堆内存不是越大越好。 大的堆内存会显著增加垃圾回收的时间。因此，我们需要根据对象生命周期来调整堆大小和比例：

# 调整前
-Xms8g -Xmx8g

# 调整后：根据对象生命周期分析
-Xms4g -Xmx4g -Xmn1.5g -XX:SurvivorRatio=8 
-XX:MaxGCPauseMillis=100  # 设置目标停顿时间

堆内存选择原则：

场景	建议堆大小	原因
响应优先（互联网）	2-4GB	GC暂停时间可控
吞吐优先（批处理）	4-8GB	可接受较长的GC时间
大内存系统	8GB+ 使用G1GC	分区回收，控制暂停时间

> 记住：4GB以上的堆内存建议使用G1GC以实现更好的性能和稳定性。

四、案例二：堆内存改太小，频繁Full GC

现象描述

系统CPU持续在30%，QPS正常但RT升高，监控显示每分钟内多次发生Full GC。

GC日志分析：

# 1分钟内的日志片段
2024-01-15T10:30:25.123+0800: 120.456: [Full GC (Allocation Failure) 
[PSYoungGen: 102400K->1024K(153600K)] 
[ParOldGen: 307200K->307200K(409600K)] 
409600K->308224K(563200K), 0.5234567 secs]

2024-01-15T10:31:05.456+0800: 160.789: [Full GC (Allocation Failure) 
[PSYoungGen: 102400K->1024K(153600K)]

### 问题定位

在分析GC日志后发现老年代的大小几乎不变，每次Full GC之后仍然保持400M的状态。这说明应用程序的实际内存需求超过了设定的老年代容量，导致Young GC中晋升的对象无法被老年代容纳。

### 根本原因

**堆内存配置不足** 是导致频繁Full GC的根本原因。具体来说，当年轻代中的对象升迁到老年代时，由于老年代的空间不足以保存这些对象，系统会触发Full GC来回收整个Java堆空间的垃圾。

### 解决方案

1. **分析真实内存需求**
   使用`jstat`工具监控和记录GC周期内的内存占用情况。通过统计信息确定应用程序的实际内存使用趋势。

2. **调整堆内存参数** 
    根据上述数据结果，适当增加JVM的初始（-Xms）及最大（-Xmx）堆大小，并合理分配年轻代和老年代的比例，例如：
   ```ruby
   -Xms2g -Xmx2g -Xmn768m -XX:SurvivorRatio=8
   -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m

观察对象年龄分布 启用打印tenuring分布的信息，以便更好地了解晋升到老年代的对象情况。

堆内存大小的经验公式：

年轻代的大小通常为总堆大小的1/3到1/4之间；
老年代则相应地占2/3到3/4。

当观察到老年代频繁增长时，可以考虑增加年轻代的比例。相反，如果Young GC操作非常频繁，则可能需要增大年轻代的空间来减少晋升压力和频率；对于Full GC频繁的情况，则应调整堆内存或优化收集器配置以降低停顿时间。

五、案例3：元空间泄漏，被当成堆内存问题

现象描述

在系统运行几天后出现了java.lang.OutOfMemoryError: Metaspace错误，这表明元空间（Metaspace）已满并且无法自动扩展以满足新的类加载需求。

GC日志分析

从GC日志中可以看出有频繁的Metadata垃圾回收活动：

# 元数据GC阈值触发了Full GC
2024-01-15T10:30:25.123+0800: 120.456: [Full GC (Metadata GC Threshold) 
[PSYoungGen: 1024K-&amp;gt;0K(153600K)]
[ParOldGen: 1024K-&amp;gt;1024K(409600K)]
[Metaspace: 98765K-&amp;gt;98765K(1099776K)], 0.8765432 secs]

问题定位

使用jcmd VM.classloader_stats命令能够帮助查看当前运行的应用程序中的类加载器实例及其相关统计信息。如果发现存在大量的未被卸载的临时或动态生成的类，那么就可能是元空间泄漏的表现形式之一。

根本原因分析

元空间内存泄露通常发生在应用中频繁创建和销毁ClassLoader对象而没有正确清理它们的情况下。例如：

动态脚本语言如Groovy中的脚本执行使用了专用的ClassLoader但未关闭它；
应用程序热部署时未能及时卸载旧版本类加载器导致内存溢出；
某些测试或开发框架（比如Mockito）可能生成大量临时对象。

解决方案

增加元空间大小作为短期应急措施：

-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m

追踪类加载器活动并识别泄漏点 启用以下选项来记录详细的类加载和卸载日志：
```
-XX:+TraceClassLoading -XX:+TraceClassUnloading
```
对于特定场景采取针对性措施，例如Groovy动态脚本使用后关闭groovyClassLoader实例或者改进热部署策略确保旧的类加载器可以被垃圾收集。

六、GC调优常用参数速查

常用GC日志参数设置

参数	作用
`-XX:+PrintGCDetails`	打印详细GC活动信息
`-XX:+PrintGCDateStamps`	在GC输出中包含时间戳
`-Xloggc:/path/gc.log`	将日志写入文件指定路径
`-XX:+PrintHeapAtGC`	GC前后打印堆内存使用情况
`-XX:+PrintTenuringDistribution`	打印对象晋升年龄分布及存活率
`-XX:+PrintReferenceGC`	记录弱引用和虚引用处理日志

场景	推荐GC收集器	参数配置
响应时间优先（4GB以下）	G1GC	`-XX:+UseG1GC`
响应时间优先（4GB以上）	G1GC / ZGC	`-XX:+UseZGC`
吞吐量优化	ParallelGC	`-XX:+UseParallelGC`
大内存低延迟	Shenandoah	`-XX:+UseShenandoahGC`

G1GC常用参数（推荐）

-Xms4g -Xmx4g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100          # 目标停顿时间
-XX:G1HeapRegionSize=16m           # 分区大小
-XX:InitiatingHeapOccupancyPercent=45  # 触发并发GC的堆占用百分比
-XX:G1ReservePercent=10            # 预留空间比例

七、JVM调优的正确流程

准备阶段：开启详细的GC日志记录。
收集数据：让系统运行一段时间，积累充分的日志信息。
分析问题类型：
- 年轻代频繁GC → 考虑增加年轻代大小
- 年轻代耗时过长 → 检查对象存活状况或减少垃圾产生
- 老年代频繁Full GC → 关注内存泄漏或老年代设置不合理
- Full GC时间较长 → 总堆内存过大或者GC策略不合适
实施调整：根据分析结果修改相应的JVM参数。
验证效果：观察系统性能变化，必要时重复步骤2-4直至找到最佳配置。
压力测试：最后进行负载测试以确保调优后的稳定性。

八、一句话避坑口诀

调优前要全面分析GC日志，避免盲目更改参数。
堆内存并非越大越有效率，4GB以上推荐使用G1或ZGC。
Full GC频繁时关注老年代设置，而频繁Young GC则应检查年轻代配置。
元空间溢出问题不要简单地增加其大小，需找出具体的泄漏源。

九、互动一下

你是否有过因为JVM调优而导致系统性能下降的经历？欢迎分享你的故事。

> 🔗 相关阅读：JVM调优

曼波资源站 ManboHub

JVM调优“瞎调”——没分析GC日志，乱改堆内存参数导致OOM

JVM调优实战：正确分析GC日志避免“瞎调”堆内存导致OOM

一、典型“瞎调”场景

场景：感觉系统慢，上来就改堆内存

正确的调优流程

二、第一步：学会看GC日志

2.1 开启GC日志（必做）

2.2 看懂GC日志的关键指标

Young GC 日志示例：

Full GC 日志示例：

三、案例一：堆内存改太大，GC停顿几十秒

现象描述

GC日志分析：

问题定位

根本原因与解决方案

四、案例二：堆内存改太小，频繁Full GC

现象描述

GC日志分析：

五、案例3：元空间泄漏，被当成堆内存问题

现象描述

GC日志分析

问题定位

根本原因分析

解决方案

六、GC调优常用参数速查

常用GC日志参数设置

推荐的GC收集器选择策略

G1GC常用参数（推荐）

七、JVM调优的正确流程

八、一句话避坑口诀

九、互动一下