解读GC日志中的各项指标用法
作者：alden_ygq
这篇文章主要介绍了GC日志中的各项指标用法,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
GC 日志是 JVM 性能调优的重要依据，不同垃圾收集器（如 CMS、G1、ZGC）的日志格式有所差异，但核心指标含义一致。
以下是对 GC 日志中各项指标的详细解读：
一、基础 GC 日志格式（以 G1 为例）
1. Minor GC 日志
[GC pause (G1 Evacuation Pause) (young), 0.0144227 secs] [Parallel Time: 13.0 ms, GC Workers: 8] [Eden: 24.0M(24.0M)->0.0B(20.0M) Survivors: 0.0B->4.0M Heap: 24.0M(256.0M)->20.4M(256.0M)] [Times: user=0.09 sys=0.00, real=0.01 secs]
2. Full GC 日志
[Full GC (Metadata GC Threshold) [PSYoungGen: 512K->0K(9216K)] [ParOldGen: 6336K->6848K(10240K)] 6848K->6848K(19456K), [Metaspace: 2560K->2560K(1056768K)], 0.0254310 secs] [Times: user=0.09 sys=0.00, real=0.03 secs]
二、关键指标解析
1. GC 类型与触发原因
[GC pause (G1 Evacuation Pause) (young) [Full GC (Metadata GC Threshold)
GC 类型：
GC：Minor GC（新生代回收）Full GC：全堆回收（可能包含新生代、老年代、元空间）
触发原因：
Allocation Failure：对象分配失败（Eden 区空间不足）Metadata GC Threshold：元空间达到阈值G1 Humongous Allocation：大对象直接分配到老年代
2. 堆内存变化
[Eden: 24.0M(24.0M)->0.0B(20.0M) Survivors: 0.0B->4.0M Heap: 24.0M(256.0M)->20.4M(256.0M)]
格式：区域名: 回收前使用量(总容量)->回收后使用量(新总容量)
关键指标：
- Eden 区：GC 后通常被清空（0.0B）
- Survivor 区：对象在两个 Survivor 区之间移动
- Heap：整个堆的使用情况（回收前 24.0M → 回收后 20.4M）
3. GC 耗时
0.0144227 secs
STW 时间：应用线程暂停的时间（本例中 14.4ms）
异常情况：
- 单次 GC 时间过长（如超过 500ms）
- 频繁 GC 导致应用响应缓慢
4. 并行 / 并发阶段
[Parallel Time: 13.0 ms, GC Workers: 8] [Concurrent Marking (10.2 ms)]
- Parallel：多线程并行执行的阶段
- Concurrent：与应用线程并发执行的阶段（不产生 STW）
- GC Workers：并行 GC 线程数
5. 对象晋升与年龄分布
[Tenuring Distribution] age 1: 1310720 bytes, 1310720 total age 2: 655360 bytes, 1966080 total
age N：存活了 N 次 GC 的对象大小
异常情况：
- 大量对象在低年龄（如 age 1）就晋升到老年代
- 晋升年龄分布不均匀（如 age 15 突然激增）
6. CPU 时间
[Times: user=0.09 sys=0.00, real=0.01 secs]
- user：所有 GC 线程在用户态消耗的 CPU 时间总和
- sys：GC 线程在内核态消耗的 CPU 时间
- real：实际流逝的时钟时间
- 关系：
user + sys ≈ real × 并行线程数
7. 元空间 / 永久代
[Metaspace: 2560K->2560K(1056768K)]
- 元空间：存储类元数据（JDK 8+）
- 永久代：类似元空间（JDK 7 及以前）
- 异常情况：元空间持续增长，可能触发 Full GC
三、不同收集器的日志差异
1. G1 收集器
[GC pause (G1 Evacuation Pause) (young), 0.0144227 secs] [GC pause (G1 Humongous Allocation), 0.5123456 secs]
关键指标：
- Humongous 对象分配（直接在老年代分配的大对象）
- Mixed GC（同时回收新生代和部分老年代）
2. CMS 收集器
[GC (Allocation Failure) [ParNew: 61440K->61440K(61440K), 0.0000388 secs] [CMS: 0K->20480K(102400K), 0.0123456 secs] 61440K->20480K(163840K), [Metaspace: 2560K->2560K(1056768K)] 0.0123844 secs]
关键阶段：
- Initial Mark（初始标记，STW）
- Concurrent Marking（并发标记）
- Remark（重新标记，STW）
- Concurrent Sweep（并发清除）
3. Parallel 收集器
[GC (Allocation Failure) [PSYoungGen: 8192K->512K(9216K)] 8192K->6848K(19456K), 0.0034949 secs]
特点：
- 仅包含并行阶段
- 重点关注吞吐量（而非低延迟）
四、异常指标与问题定位
1. 频繁 Full GC
日志特征：
[Full GC (Metadata GC Threshold) ... 0.5234120 secs]
可能原因：
- 老年代空间不足
- 元空间持续增长
- 内存泄漏
2. 长时间 STW
日志特征：
[GC pause (G1 Humongous Allocation) ... 1.2345678 secs]
可能原因：
- 堆内存过大
- CMS 并发模式失败
- 大量 Humongous 对象
3. 过早晋升
日志特征：
[Tenuring Distribution] age 1: 104857600 bytes, ...
可能原因：
- Survivor 区空间不足
- 对象分配率过高
-XX:MaxTenuringThreshold设置过小
五、分析工具与实战建议
1. 命令行工具
# 统计GC次数
grep "GC" gc.log | wc -l
# 计算平均GC耗时
awk '/GC.*secs/ {sum+=$NF} END {print "Average GC time: " sum/NR " secs"}' gc.log
# 提取堆使用情况
grep "\[Heap\]" gc.log | awk '{print $6, $8}' > heap_usage.txt
2. 可视化工具
- GCEasy（在线）：上传 GC 日志生成详细报告
- GCViewer（本地）：分析 GC 频率、内存趋势
- Java Mission Control：集成 GC 日志分析和飞行记录器
3. 关键分析步骤
- 确认 GC 类型：区分 Minor GC、Major GC、Full GC
- 计算 GC 频率：每分钟 / 小时发生的 GC 次数
- 分析内存趋势：堆内存使用量是否持续增长
- 检查 GC 耗时：单次 GC 时间是否超过预期
- 定位 GC 原因：Allocation Failure、Metadata Threshold 等
六、优化建议
1. 减少 Full GC
# 增大元空间 java -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m YourApp # 避免大对象直接进入老年代 java -XX:PretenureSizeThreshold=1048576 YourApp
2. 降低 GC 耗时
# 使用G1收集器并限制最大停顿时间 java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 YourApp # 增加并行GC线程数 java -XX:ParallelGCThreads=16 YourApp
3. 优化对象晋升
# 增大Survivor区比例 java -XX:SurvivorRatio=6 YourApp # 提高晋升年龄阈值 java -XX:MaxTenuringThreshold=15 YourApp
通过深入理解 GC 日志中的各项指标，可以精准定位内存泄漏、对象分配不合理、收集器选择不当等问题，从而优化 JVM 配置，提升应用性能。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。