GC日志是JVM内存行为的“实时录像”，关键看四类字段：时间戳（区分系统时间与JVM启动后秒数）、GC类型与触发原因（如Allocation Failure或Metadata GC Threshold）、内存变化快照（如A→B(C)）、停顿耗时（real时间即STW真实延迟）。
GC 日志不是一串乱码，而是 JVM 内存行为的“实时录像”。读懂它，关键在于抓住四类基础字段：时间戳、GC 类型与原因、内存变化快照、停顿耗时。不需要背全格式，盯住这几处就能快速判断回收是否健康。
看时间戳：区分系统时间和 JVM 运行时长
日志里常出现两类时间：
-
日期时间戳（如 2026-09-25T14:22:18.345+0800）：由
-XX:+PrintGCDateStamps或-Xlog:...:time输出，反映真实发生时刻，适合关联业务日志排障 -
相对时间戳（如 47.713:）：从 JVM 启动起算的秒数，由
-XX:+PrintGCTimeStamps或-Xlog:...:uptime输出，用于分析 GC 频率和间隔稳定性
生产环境建议两者都开，避免因服务器时钟漂移导致误判。
辨 GC 类型与触发原因：一眼识别压力来源
每条日志开头会标明 GC 性质和动机，这是定位问题的第一线索：
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
[GC (Allocation Failure)]：最常见，说明 Eden 区填满，正常 Young GC；若高频出现，可能是对象创建太快或 Eden 太小 -
[Full GC (Ergonomics)]：非预期路径，通常暗示元空间不足、老年代碎片严重或 G1 无法满足停顿目标 -
[GC pause (G1 Evacuation Pause) (young)]：G1 的 Young GC；(mixed)表示已开始清理部分老年代 Region -
[Metadata GC Threshold]：元空间快满，需检查-XX:MaxMetaspaceSize是否合理或存在类加载泄漏
读内存变化：关注“前→后(总)”三组数字
典型结构如：[PSYoungGen: 1280509K->89599K(1308160K)]，拆解为：
- 1280509K：GC 前年轻代已用内存
- 89599K：GC 后年轻代剩余内存
- (1308160K)：年轻代总容量
同理，整行末尾的 1396384K->217194K(1509376K) 是整个堆的变化。计算回收率（如 (1280509−89599)/1280509 ≈ 93%）比单纯看数字更有意义——长期低于 70% 就要怀疑对象存活率异常高。
查停顿耗时：real 时间才是 STW 真实代价
结尾的 [Times: user=0.08s, sys=0.01s, real=0.02s] 中：
- real（又称 elapsed）是用户感知的停顿时间，即 STW 时长，必须重点关注
- user 是所有 CPU 核心累计工作时间，多核下可能大于 real，不能代表延迟
- 单次 Young GC > 50ms（Web 服务）、Full GC > 200ms 就应介入排查
不复杂但容易忽略
