jvm的GC日志分析是怎样的

发布时间：2021-10-23 15:43:44 作者：柒染
来源：亿速云阅读：105

# JVM的GC日志分析是怎样的

## 目录
1. [GC日志的重要性](#1-gc日志的重要性)
2. [GC日志基础配置](#2-gc日志基础配置)
3. [GC日志格式解析](#3-gc日志格式解析)
   - 3.1 [Serial GC日志](#31-serial-gc日志)
   - 3.2 [Parallel GC日志](#32-parallel-gc日志)
   - 3.3 [CMS GC日志](#33-cms-gc日志)
   - 3.4 [G1 GC日志](#34-g1-gc日志)
4. [关键指标分析](#4-关键指标分析)
5. [日志分析工具](#5-日志分析工具)
6. [实战案例分析](#6-实战案例分析)
7. [高级调优建议](#7-高级调优建议)
8. [总结](#8-总结)

---

## 1. GC日志的重要性
垃圾收集（GC）日志是JVM性能调优的"X光片"，它能揭示：
- 内存泄漏的早期迹象
- 不合理的堆大小配置
- GC算法选择不当的问题
- 系统吞吐量下降的根源

> **统计显示**：75%的Java性能问题最终都通过GC日志分析定位

---

## 2. GC日志基础配置
### 必备启动参数
```bash
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps
-Xloggc:/path/to/gc.log

增强型配置（JDK 9+）

-Xlog:gc*=debug:file=gc.log:time,uptime,tags

日志轮转配置

-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=10M

3. GC日志格式解析

3.1 Serial GC日志

2023-07-20T14:23:45.731+0800: 1.234: 
[GC (Allocation Failure) 
[DefNew: 314560K->34944K(314560K), 0.0456789 secs]
314560K->120456K(1013632K), 0.0457890 secs]

DefNew：新生代使用Serial收集器
314560K->34944K：新生代回收前后大小
括号内数字：该区域总容量

3.2 Parallel GC日志

[PSYoungGen: 153600K->25536K(179200K)]

PSYoungGen：Parallel Scavenge收集器
153600K->25536K：回收效果指标

3.3 CMS GC日志

[CMS-concurrent-mark: 1.234/2.345 secs]

分阶段显示CMS收集过程
1.²³⁴⁄₂.345：实际耗时/时钟时间

3.4 G1 GC日志

[GC pause (G1 Evacuation Pause) (young), 0.123456 secs]
   [Parallel Time: 45.6 ms]
      [Ext Root Scanning: 12.3 ms]

清晰展示各阶段耗时
支持预测性日志（-XX:+PrintAdaptiveSizePolicy）

4. 关键指标分析

指标	健康值范围	危险信号
GC频率	次/10秒	>5次/秒
Full GC耗时	秒	>3秒
吞吐量	>95%	<90%
Old Gen增长率	<5MB/分钟	>50MB/分钟

计算公式：

吞吐量 = 1 - (GC总时间/应用运行总时间)

5. 日志分析工具

5.1 在线分析

5.2 本地工具

# GCViewer
java -jar gcviewer.jar gc.log

# 使用jstat实时监控
jstat -gcutil <pid> 1000

5.3 高级分析脚本

# 简单的GC暂停时间分析脚本
import re

with open('gc.log') as f:
    pauses = [float(m.group(1)) 
             for m in re.finditer(r', (\d+\.\d+) secs\]', f.read())]
    
print(f"平均暂停时间：{sum(pauses)/len(pauses):.4f}秒")

6. 实战案例分析

案例1：内存泄漏

日志特征：

[Full GC (Ergonomics) 
[PSYoungGen: 0K->0K(179200K)] 
[ParOldGen: 1024000K->1023998K(1024000K)]

老年代回收后几乎无变化
持续增长的Full GC频率

解决方案： 1. 使用MAT分析堆转储 2. 检查静态集合类

案例2：过早提升

日志特征： [Young GC: 314560K->120456K(314560K)] [Times: user=0.12 sys=0.01, real=0.03 secs] - 每次Young GC后存活对象过多 - 频繁发生晋升

调优方案：

-XX:MaxTenuringThreshold=10
-XX:NewRatio=3

7. 高级调优建议

7.1 ZGC专项配置

-XX:+UseZGC 
-Xlog:gc*=info:file=zgc.log:time

7.2 混合日志分析

# 同时记录GC和分配日志
-XX:+PrintGCDetails 
-XX:+PrintTenuringDistribution

7.3 关键阈值调整

参数	默认值	建议调整范围
-XX:MaxGCPauseMillis	200ms	50-500ms
-XX:G1HeapRegionSize	1MB-32MB	根据堆大小调整
-XX:SurvivorRatio	8	4-16

8. 总结

采集完整数据：至少收集24小时日志
建立基线：记录正常状态的GC特征
关联分析：结合CPU、IO等监控数据
渐进调优：每次只修改1-2个参数

最佳实践：在预发环境进行至少72小时的GC压力测试

延伸阅读： - 《Java Performance: The Definitive Guide》 - Oracle官方GC调优白皮书 - JEP 158：统一JVM日志框架 “`

（注：实际文章需要补充更多详细案例、图表和具体数据分析，此处为框架性展示。完整7200字版本需要扩展每个章节的深度内容，特别是实战案例部分需要增加10-15个不同类型的GC问题分析。）