核心是提取gc日志中real字段值作为真实stw时长，按时间序列聚合分析分布、趋势与异常峰值；需区分young/mixed/full gc类型，结合safepoint、metaspace等辅助日志定位停顿根因，并用gcviewer或awk等工具自动化分析。
核心是提取每条 GC 日志里的 real time，它代表真实 STW 时长；再按时间序列聚合，看分布、趋势和异常峰值。
盯住 real 字段，它是唯一可信的 STW 时间
GC 日志中类似这样的行：
[GC (Allocation Failure) ... , 0.0421234 secs] 或
[Times: user=0.042, sys=0.005, real=0.047 secs]
其中 real=0.047 secs 就是本次 GC 导致所有应用线程暂停的真实毫秒数——这是唯一反映业务卡顿的指标。
注意：
- user + sys 是 GC 线程自身消耗的 CPU 时间，不能代替停顿感知；
- real 显著大于 user+sys（比如 real=120ms，user+sys=18ms），说明存在锁竞争、I/O 等待或 OS 调度延迟；
- JDK 8 用 -XX:+PrintGCTimeStamps -XX:+PrintGCDetails，JDK 17+ 推荐 -Xlog:gc*:file=gc.log:time,uptime,pid。
按维度分组统计，识别模式而非单点数值
只看平均值会掩盖问题。应统计以下三类分布：
- 频次分布：把 real 时间分桶（如 0–10ms、10–50ms、50–200ms、>200ms），看各区间发生次数占比。若 >50ms 占比超 5%，就需干预；
- 时间趋势：按分钟/小时绘制 P95 停顿曲线。阶梯式抬升（如从 30ms → 65ms 持续 3 小时）往往指向 Survivor 区过小或对象晋升加速；
- 类型分布：区分 Young GC、Mixed GC、Full GC 的 real 时间。G1 中 Mixed GC 单次 >100ms 且频率上升，大概率是 Humongous 对象堆积或 Remembered Set 更新开销过大。
结合辅助日志，定位 STW 被拉长的真实原因
real 高 ≠ GC 算法不行，可能是非 GC 行为拖慢了安全点同步：
- 开启
-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1，查“safepoint sync time”是否异常高（>10ms）；常见于 JIT 编译阻塞、偏向锁批量撤销； - 加
-Xlog:metaspace*，确认是否因 Metaspace 动态扩容触发类卸载停顿； - 加
-XX:+PrintReferenceGC，看软/弱引用处理是否耗时过长（尤其 ThreadLocal 持有大缓存未清理）。
用工具自动化跑批分析，别靠肉眼 grep
面对 GB 级日志，人工排查效率极低且易漏。推荐组合：
- GCViewer：拖入 gc.log 自动生成 pause 时间热力图、P95 曲线、GC 类型分布饼图；
-
命令行管道：例如用 awk 提取所有 real 值并统计 P95：
awk '/real=/ {gsub(/.*real=| secs.*/, ""); print $1*1000}' gc.log | sort -n | awk 'NR==int(NR*0.95) {print $1 "ms"}'； -
Prometheus + Micrometer：在 Spring Boot 中暴露
jvm_gc_pause_seconds_max和jvm_gc_pause_seconds_count，与 QPS、P95 延迟叠加看因果关系。
