应用暂停时间即 GC 日志中“secs”字段的 real time，是 Stop-The-World 的真实停顿长度；如 0.0421234 secs 表示业务请求完全卡住的时长，其值恒 ≥ user + sys，超差说明存在锁竞争或调度延迟。
应用暂停时间就是 GC 耗时中最关键的部分——它等于日志里明确标出的 real time，也就是 Stop-The-World（STW）的真实停顿长度。
看懂日志中那个“秒数”代表什么
典型日志行如：
[GC (Allocation Failure) [PSYoungGen: 123456K→12345K(200704K)] 234567K→134567K(501760K), 0.0421234 secs]
这个 0.0421234 secs 就是应用线程被强制暂停的总时长，业务请求在此期间完全卡住。它和 Linux time 命令输出的 real 时间含义一致。
user 和 sys 是辅助参考：前者是 GC 线程在用户态消耗的 CPU 时间，后者是内核态时间。三者关系恒为：real ≥ user + sys。若 real 明显大于二者之和，说明存在锁竞争、I/O 等待或 OS 调度延迟，不只是 GC 自身开销。
不同 GC 类型下暂停与耗时的对应关系
- Young GC：整行耗时即 STW 时间，一般几毫秒到几十毫秒；若超过 50ms，需检查 Eden 大小、对象分配速率或大对象直接入老年代
-
G1 Mixed GC：日志中标记为
GC pause (G1 Evacuation Pause) (mixed)，其后数值即本次混合回收的 STW 时间；注意to-space exhausted或evacuation failure会触发退化 Full GC，耗时骤增 -
ZGC / Shenandoah：大部分工作并发执行，只有
gc,pause标签的事件（如Pause Initial Mark、Pause Final Update References）才是真正 STW；这些值通常在 1–2ms 量级，是影响 P99 延迟的关键 -
Full GC：含
Full GC字样，整行耗时即全程 STW，常达数百毫秒甚至秒级；一旦出现，应用必然明显卡顿
别把“耗时”和“开销”混为一谈
有些日志行不带 Pause，比如 CMS-concurrent-mark 或 G1-Concurrent-Cycle，它们反映后台线程工作，应用线程仍在运行，不算暂停时间。真正影响接口延迟的，只看所有带 Pause、pause 或明确标注 secs 的 STW 事件。
累计所有这类事件的 real 时间，除以应用总运行时间，就得到 STW 占比——超过 2% 系统已亚健康，单次超 500ms 必然导致 P99 超时。
用工具确认关联性更可靠
- 人工统计易遗漏：旧参数（如
-XX:+PrintGCDetails）可能不记录 ZGC 或元空间回收的完整暂停 - 推荐用
GCViewer或GCeasy解析日志，自动提取全部 STW 事件并计算总暂停时长、占比、趋势图 - 将 GC 暂停时间点（精确到毫秒）与 APM 中的请求延迟尖峰对齐，才能确认是否真由 GC 引起；若延迟升高时无对应暂停，问题大概率在下游或线程阻塞
