JVM GC日志分析需结合应用行为、GC策略和系统资源识别真实瓶颈，重点关注分配失败、并发模式失败、元空间阈值等静默异常，并用GCViewer、gceasy.io和Prometheus闭环监控。
JVM GC 日志分析不是“看懂日志就行”，而是要结合应用行为、GC策略和系统资源，快速识别真实瓶颈。很多团队花大量时间解读日志，却漏掉了关键上下文，导致误判或反复调优。
别只盯着“GC次数”和“耗时”
单纯统计 Minor GC 次数多、某次 Full GC 耗时 1.2s，并不能说明问题。真正要问的是：
- 这次 GC 是因为对象分配速率突增？还是内存泄漏缓慢积累？
- 年轻代空间是否长期接近阈值（如 Eden 区每次 GC 后仅回收 5%）？这比单次耗时更能暴露压力趋势
- 老年代使用率是否在缓慢爬升（比如每小时涨 0.3%），且未伴随明显 Full GC？这是典型内存泄漏信号
看日志前，先确认 GC 类型和参数匹配
不同 GC 算法（ZGC/G1/Parallel）日志格式、字段含义差异极大。常见错配：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 用 Parallel GC 的分析经验去读 G1 日志，把 “Mixed GC” 当成 Full GC 处理
- 开启 -XX:+PrintGCDetails 却没加 -XX:+PrintGCTimeStamps，无法对齐业务日志时间点
- 在 JDK 17+ 使用 -XX:+UseG1GC，却仍按 JDK 8 的 Serial GC 日志结构做自动化解析（字段名、缩写、单位全不同）
重点关注三类“静默异常”指标
这些指标不报错、不告警，但持续出现就预示风险：
- Allocation Failure 频繁触发：日志中反复出现 “(Allocation Failure)” —— 表明 Eden 区几乎每次都被填满才触发 GC，说明对象生命周期短但总量大，可能需调大年轻代或检查临时对象滥用
- Concurrent Mode Failure / Evacuation Failure：G1/ZGC 中出现这类提示，代表并发回收跟不上分配速度，已退化为 STW 回收，性能会断崖下跌
- Metaspace OOM 前兆：日志里连续出现 “Metadata GC Threshold” 或 “Metaspace used XMB, committed YMB” 且 committed 值持续逼近 -XX:MaxMetaspaceSize，说明动态类加载（如热部署、Groovy 脚本）正在撑爆元空间
工具链要闭环，不能只靠肉眼扫日志
人工翻日志效率低、易遗漏。建议组合使用：
- 用 GCViewer 快速生成吞吐量、暂停时间分布图，一眼识别毛刺和趋势
- 用 gceasy.io（上传 GC 日志）自动诊断“是否内存泄漏”“是否 GC 配置不当”“是否元空间不足”，附带修复建议
- 在 Prometheus + Grafana 中接入 JVM 的 jvm_gc_collection_seconds_count 和 jvm_memory_used_bytes，让 GC 行为与业务指标（如 HTTP 5xx、P99 延迟）联动观察
