STW停顿时间是Java GC日志中最关键性能指标，需聚焦其发生位置、持续时间、频率及与业务表现的关联；仅识别gc,pause或Pause Young/Full等明确标记行，区分并发阶段与真实STW，并结合safepoint日志分析叠加延迟。
Stop-The-World（STW）停顿时间是 Java GC 日志分析中最关键的性能指标之一，它直接反映业务线程被强制暂停的时长。评估和优化不能只看“有没有停顿”，而要聚焦停顿发生的位置、持续时间、触发频率及其与业务表现的关联。
看懂日志里真正的 STW 事件
不是所有 GC 日志行都代表 STW。必须识别带 gc,pause 或明确标注 Pause Young/Pause Full 的条目。ZGC 日志中常见 pauseStartinitialmark、pauseDonefinalmark；G1 日志中则是 Pause Young (Normal) 或 Pause Full。注意区分：
– 并发阶段（如 G1 的 Concurrent Mark、ZGC 的 Concurrent Relocate）不计入 STW；
– Safepoint 等待时间虽非 GC 本身，但会叠加到 STW 总耗时中，需结合 safepoint=info 日志交叉分析。
分层评估停顿质量
单看一次停顿毫秒数意义有限，应从三个维度建立基线：
– 平均暂停时间：反映日常负载下的稳定水平，ZGC 通常 – P99 / 最大暂停时间：决定尾延迟体验，金融或实时系统需压到 10ms 以内；
– 暂停频率：每分钟超过 5 次 Young GC 可能说明新生代过小，频繁晋升又可能抬高 Full GC 概率。
针对性优化路径
停顿长 ≠ 一定要换回收器，先排查是否可避免：
– 减少触发条件：避免 System.gc()、显式调用 RMI 或 JMX 导致的意外 Full GC；
– 调优内存结构：增大 Eden 区降低 Minor GC 频次；合理设置 -XX:MaxGCPauseMillis（G1/ZGC 会据此动态调整并发线程数和工作粒度）；
– 升级回收器：JDK 11+ 且堆 ≥ 4GB 时，ZGC 或 Shenandoah 显著压缩 STW；64GB 堆下 ZGC 平均停顿常低于 1ms；
– 规避隐性开销：检查 JNI 临界区过长、编译线程阻塞、大量 finalizer 对象——这些都会拖长 safepoint 进入时间，间接拉长 STW。
立即学习“Java免费学习笔记（深入）”；
验证优化是否生效
改完参数后不能只盯平均值：
– 用脚本提取全部 gc,pause 事件，统计 P95/P99 分布；
– 将 GC 暂停时间戳与 APM 工具（如 SkyWalking、Pinpoint）中的请求 RT 曲线对齐，确认毛刺是否消失；
– 观察 pause 后是否紧随 gc,move 或 gc,relate，判断重定位压力是否转移为新瓶颈。
