本文主要是介绍解读GC日志中的各项指标用法,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
《解读GC日志中的各项指标用法》:本文主要介绍GC日志中的各项指标用法,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教...
GC 日志是 JVM 性能调优的重要依据,不同垃圾收集器(如 CMS、G1、ZGC)的日志格式有所差异,但核心指标含义一致。
以下是对 GC 日志中各项指标的详细解读:
一、基础 GC 日志格式(以 G1 为例China编程)
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(10567编程China编程68K)], 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.http://www.chinasem.cn0144227 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 HandroidumChina编程ongous 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 配置,提升应用性能。
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持China编程(www.chinasem.cn)。
这篇关于解读GC日志中的各项指标用法的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!