STW的触发本质是JVM为保障内存一致性和执行安全性而强制应用线程静止，核心在于获取无歧义的堆快照以确保可达性分析准确，避免漏标导致崩溃；其代价包括请求积压、时间敏感逻辑失准、资源调度失效及监控失真。
STW 的触发本质，是 JVM 为保障关键操作的内存一致性和执行安全性，强制所有应用线程进入静止状态。它不是 GC 的“副作用”，而是必要前提——只要操作涉及共享堆内存的全局视图或对象引用关系的精确判定，就必须冻结用户线程。
触发本质：一致性快照与安全边界不可妥协
GC 的核心任务是判断“哪些对象还活着”。这依赖于从 GC Roots 出发的可达性分析。若用户线程在分析过程中修改引用（如赋值、新建、断开），就会破坏分析所依据的瞬时内存状态。STW 就是为捕获一个稳定、无歧义的堆快照：所有对象的引用关系被“定格”，GC 线程可据此得出唯一、确定的存活结论。漏标（把活对象当垃圾回收）会直接导致程序崩溃，这是 JVM 绝不允许的。
同样，JIT 反优化、偏向锁撤销、类重定义等 VM Operation，也都需要线程栈、方法元数据、锁状态等运行时结构处于静止且一致的状态，否则无法安全地变更内部结构。
全线停顿代价：不只是“卡一下”那么简单
STW 的代价远超表面可见的响应延迟。每一次停顿都会带来连锁影响：
- 请求积压与雪崩风险：高并发服务在 STW 期间无法处理新请求，连接队列持续增长，可能触发上游超时、重试、熔断，形成级联故障；
- 时间敏感逻辑失准：定时任务、心跳检测、实时计算窗口等依赖 wall-clock 时间的逻辑，在 STW 后可能批量触发或跳过，造成业务语义错误；
- 资源调度失效：线程池中空闲线程无法被唤醒，数据库连接、HTTP 连接等资源在停顿中悄然超时关闭，恢复后需重建，放大开销；
- 监控指标失真：TP99、QPS、GC 吞吐率等指标在 STW 区间内完全失效，掩盖真实性能瓶颈，误导容量评估。
不同阶段的停顿权重差异巨大
并非所有 STW 都同等沉重。初始标记（Initial Mark）仅扫描 GC Roots，耗时通常低于 1ms；而老年代的完整压缩（如 Serial Old 或 CMS 失败后的 Concurrent Mode Failure）可能长达数百毫秒甚至秒级。ZGC 和 Shenandoah 把 STW 控制在 10ms 内，并非靠“不暂停”，而是将原本需长时间执行的操作（如对象移动、引用更新）拆解为并发阶段，只保留极短的“染色指针切换”或“转发指针安装”作为 STW 点。真正的优化焦点，始终在识别并最小化不可并发化的关键原子操作上。
可观测性是应对停顿的第一步
仅看 GC 日志远远不够。必须启用 -XX:+PrintGCApplicationStoppedTime 获取全部停顿总时长，再叠加 -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 定位每次停顿的具体原因（是 GC？是 biased lock revocation？还是 class redefinition？）。没有精准归因，任何调优都是盲人摸象。
