java gc日志分析核心是识别停顿过长、回收不力、内存泄漏或分配过快等问题，需结合jdk版本启用详细日志（jdk8用-xx:+printgcdetails等，jdk9+用-xlog:gc*:file=gc.log），重点关注gc类型、停顿时间、内存变化率、晋升与full gc频率，并借助gceasy、gcviewer等工具辅助诊断。
Java 中通过 GC 日志（GC.log）分析内存回收效率，核心是看每次 GC 的耗时、回收量、内存变化及频率。关键不是日志有没有，而是能否从中识别出停顿过长、回收不力、内存泄漏或分配过快等问题。
开启详细 GC 日志
不同 JDK 版本启用方式不同，需匹配实际环境：
- JDK 8：用 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M
- JDK 9+（推荐）：用 -Xlog:gc*:gc.log:time,tags,level -Xlog:safepoint -Xlog:gc+heap=debug，支持结构化输出，更易解析
- 避免只加
-verbose:gc，它信息太少，无法判断晋升失败或元空间压力
关注几类关键指标
打开 gc.log 后，重点扫以下字段（以 G1 或 Parallel GC 为例）：
-
GC 类型与触发原因：如
Allocation Failure（频繁说明对象生命周期短或 Eden 太小）、Metadata GC Threshold（元空间快满）、Humongous Allocation（大对象导致 G1 频繁 Mixed GC） -
停顿时间：看
pause或user/sys/real时间，单次超过 200ms 值得排查；连续多次 >100ms 可能影响响应 -
回收前后内存变化：例如
[PSYoungGen: 1234M->210M(1536M)]，计算回收率（(1234−210)/1234 ≈ 83%），若长期低于 70%，说明对象存活率高或年轻代偏小 - 晋升与 Full GC 频率：老年代持续增长、Full GC 隔几分钟一次，大概率存在内存泄漏或对象过早晋升
用工具辅助解读
纯文本逐行看日志效率低，建议配合工具快速定位问题：
- GCEasy（在线）：上传 gc.log 自动生成报告，标出 GC 耗时趋势、内存分布、推荐参数，适合快速诊断
- GCViewer（本地 GUI）：支持多种日志格式，可画出堆内存变化曲线和 GC 时间分布图
-
命令行简单统计：如
grep "Pause" gc.log | awk '{sum+=$NF} END{print sum/NR}'算平均 pause 时间；grep "Full GC" gc.log | wc -l查 Full GC 次数
结合业务场景做判断
GC 行为是否“低效”，不能只看数字，要联系应用特征：
- 批处理任务允许较长但低频 GC；Web 服务要求低延迟，应避免单次 >50ms 的 Young GC
- 如果日志中大量
Concurrent Mode Failure（CMS）或Evacuation Failure（G1），说明并发阶段跟不上分配速度，需调大堆或增加并发线程数 - 元空间（Metaspace）持续增长且触发 GC，检查是否动态生成大量类（如反复 CGLIB 代理、Groovy 脚本热加载）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
