线上java服务gc日志快速查看分三步：定位日志路径→实时盯jstat指标→扫日志末尾识异常；30秒内可判断内存压力或回收异常，关键看老年代使用率、fgc频次、回收效果及stw时间。
线上 Java 服务 GC 日志要快速查看，核心不是“翻完所有内容”，而是分三步：定位日志文件 → 实时盯关键指标 → 快速识别异常信号。30 秒内就能判断是否存在内存压力或回收异常。
一、确认日志路径并直接读取最新内容
先查 JVM 启动参数，确认 GC 日志实际输出位置：
- 执行 jinfo -flag Xloggc
，返回类似 -XX:Xloggc:/data/logs/app/gc.log，这就是日志路径 - 若未启用，不要重启应用，可临时用 jstat -gcutil
2000 每 2 秒刷新一次，实时看各代使用率（E/O/YGC/FGC） - 已有日志：直接 tail -n 50 /data/logs/app/gc.log 查最后几十行——问题通常集中在最近几次 GC 中
- 若启用了轮转（如
-XX:NumberOfGCLogFiles=5），检查gc.log.0（最新）或gc.log（当前写入）
二、用 jstat 快速抓实时 GC 趋势
比翻日志更快，适合秒级响应：
-
jstat -gcutil
1000 5 ：每秒输出 1 行，共 5 行，重点关注 O（老年代使用率）是否持续 >85%、FGC 是否从 0 突增 -
jstat -gccause
2000 ：每 2 秒显示最近一次 GC 原因（如Allocation Failure或System.gc()），快速定位触发源头 - 看到 FGC 频次 ≥ 1 次/分钟 或 OU（老年代已用）连续上涨不回落，基本可判定存在泄漏或负载突增
三、从日志末尾快速识别三类危险信号
不用通读，只扫最后 10 行，盯住这三点：
-
Full GC 频率飙升：连续出现
Full GC，且时间间隔从小时级缩至分钟甚至秒级（如日志里 02:43、02:44、02:45 各一次） -
回收效果极差：例如
ParOldGen: 1200M->1198M（只回收 2M），说明对象无法释放，大概率是内存泄漏 -
STW 时间过长：看
[Times: real=...]字段，real > 500ms 就需警惕，>1s 说明业务已明显卡顿 - 附带线索：日志中出现
(System)、(Metadata GC Threshold)、(G1 Humongous Allocation)等括号内原因，可反推是主动调用、元空间不足或大对象导致
不复杂但容易忽略：真正影响线上的，往往不是 GC 本身，而是 GC 日志里藏的“时间对齐线索”——把某次 Full GC 的时间戳（如 2026-10-08T22:31:45.123），去应用日志里查前后 30 秒，常能立刻发现慢 SQL、缓存击穿或批量导入任务。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
