GC停顿时间需聚焦“pause”行real值，结合P99/Max分析长尾；分阶段定位根因，排除Safepoint、元空间等非GC干扰。
GC日志里的停顿时间不是一眼扫过去就能下结论的，关键得拆开看“谁在停、停多久、为什么停”。真实STW时长藏在特定字段里，而且容易被日志表象误导。
盯住带“pause”的那行，real 时间才是真停顿
启用详细GC日志（如 -Xlog:gc*:file=gc.log:time,uptime,level,tags 或旧版 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps）后，重点找含 “pause” 的日志行：
- [GC pause (G1 Evacuation Pause) (young), 0.0245678 secs] —— 括号末尾的秒数就是本次STW真实时长，不是GC总耗时
- 再往下看 [Times: user=0.018 sys=0.002, real=0.024 secs] —— real 值必须和上面的 pause 秒数基本一致；若 real 远大于 user+sys，说明线程卡在OS调度、IO或native调用中，不是GC本身慢
- 触发原因要同步看：比如 Allocation Failure 是正常分配失败触发；System.gc() 就得立刻查代码，生产环境应禁用
别只看单次，P99停顿才反映用户真实卡顿
平均停顿会掩盖长尾问题。100次GC里99次是5ms，1次是300ms，平均才8ms，但那1%的用户已经超时了。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 把所有 pause 时间提取出来排序，重点关注 P99（99%的GC停顿 ≤ 该值） 和 Max Pause（历史最长单次）
- 生产健康标准参考：核心业务 P99 < 20ms，P999 < 50ms；超过 200ms 已影响 SLA，超过 1s 属于故障级
- 用脚本或日志分析工具（如 gcviewer、gceasy）自动统计分位值，避免人工翻日志漏掉长停顿
结合阶段耗时定位瓶颈环节
现代GC（如G1、ZGC）的STW不是“一整块”，而是由多个子阶段组成。JDK 10+ 可用 -Xlog:gc+phases=debug 查看各环节耗时：
- [Ext Root Scanning (ms): 1.2] —— 根节点扫描慢？检查 GC Roots 是否膨胀（如大量 ThreadLocal、MDC、ClassLoader）
- [Update RS (ms): 15.6] —— G1 的 Remembered Set 更新占比高？说明跨 Region 引用太密集，考虑调大 -XX:G1RSetUpdatingPauseTimePercent 或减少大对象跨代引用
- [Evacuation (ms): 82.3] —— 对象复制耗时长？可能 Survivor 区过小导致隐式晋升，或老年代 Region 存活率高拖慢 Mixed GC
确认是不是真由GC引起，先排除干扰项
很多“GC停顿”其实是假象。需交叉验证是否真由收集器主导：
- 启用 -XX:+PrintGCApplicationStoppedTime，它会单独打印每次应用线程被阻塞的起止时间。如果某次 STW 时间远长于 GC 日志里的 pause，大概率是 Safepoint 卡住（比如线程在 long loop 或 native 调用中无法到达安全点）
- 检查元空间和 CodeCache：日志中出现 Metadata GC Threshold 或 CodeCache is full，说明是类卸载或 JIT 编译器触发的 STW，和堆回收无关
- 用 jstat -gc -h3 <pid> 1000 实时观察 GCT/GC 次数比值是否异常升高；若 YGC 频繁但 YGCT 不涨，可能是对象存活率高，正悄悄触发更多 Mixed GC
