stw（stop-the-world）是jvm垃圾回收中必须暂停所有java应用线程以保障内存回收准确性的机制，发生在根节点枚举、重新标记和对象转移等关键阶段，不同收集器将其压缩至毫秒级甚至亚毫秒级，但无法完全消除，因其本质依赖冻结引用图以确保可达性分析一致性。
STW（Stop-The-World）是 JVM 垃圾回收中无法绕开的核心机制：在 GC 的关键阶段，JVM 会强制暂停所有 Java 应用线程，仅保留 GC 线程运行。这不是故障，而是为保障内存回收准确与安全所必需的“冻结时刻”。停顿期间，程序完全不响应请求，用户感知为卡顿或延迟——因此 STW 时间长短，直接决定系统实时性与用户体验。
STW 发生在哪几个关键环节
并非整个 GC 过程都 STW，但以下阶段必须暂停用户线程：
- 根节点枚举（Root Scanning）：GC 需从 GC Roots（如栈帧局部变量、静态变量、JNI 引用等）出发遍历对象图。若线程正在修改栈或堆引用，根集合就可能漏项或错项，导致存活对象被误回收（对象消失）或垃圾对象被漏标（浮动垃圾）。
- 重新标记（Remark）：在并发标记阶段（如 CMS、G1、ZGC），用户线程持续运行，可能改变对象引用关系。重新标记阶段需再次扫描并修正这些变动，必须 STW 以获得一致快照。
- 对象转移（Evacuation）：使用复制或整理算法时（如 G1 的 Mixed GC、ZGC 的重定位），存活对象需从源 Region 搬到目标 Region。搬移过程中旧地址失效，若用户线程仍通过原引用访问，将引发错误。因此转移动作需在 STW 下原子完成（ZGC 通过读屏障+染色指针大幅压缩该阶段耗时）。
不同收集器的 STW 特点对比
STW 不可避免，但各收集器将其压缩在不同阶段、不同时长：
- Serial / Parallel：全程 STW。Serial 单线程扫描整堆；Parallel 多线程但仍是独占式——吞吐量高，单次停顿长（百毫秒级），适合后台批处理。
- CMS（已废弃）：仅初始标记、重新标记两个短 STW；并发标记与清除与用户线程并行。但因不整理内存，易碎片化，最终触发 Full GC 时仍会 STW 很久。
- G1：初始标记、最终标记、Evacuation（Young/Mixed）阶段 STW。通过 Region 分区和预测式停顿控制（-XX:MaxGCPauseMillis），把 STW 控制在几十毫秒内，兼顾吞吐与响应。
- ZGC / Shenandoah：仅根扫描与极少量重定位相关操作 STW，其余标记、转移全部并发。ZGC 典型 STW 小于 10ms，且与堆大小基本无关，适用于 TB 级堆与超低延迟场景。
为什么不能彻底消除 STW
当前技术下，完全无 STW 的通用 GC 尚未落地（2026 年 6 月官方消息仍称“完全无 STW 的 GC 尚在演进中”）。根本原因在于：
- 一致性不可妥协：可达性分析依赖“冻结的引用图”。只要用户线程能任意修改引用，就无法保证标记结果正确——这是语义正确性的底线。
- 硬件与模型限制：即使采用三色标记+写屏障，写屏障本身有开销，且某些底层操作（如栈帧结构变更、类卸载、JIT 代码替换）仍需线程同步协调，客观需要安全点（SafePoint）介入。
- 权衡取舍：现代设计思路不是消灭 STW，而是将其拆解为多个极短、可预测的暂停，并尽量推后或并发化其余工作。ZGC 的“亚毫秒 STW”已是工程极限的体现。
如何有效降低 STW 影响
调优重点不在规避 STW，而在缩短其时间、减少其频率：
- 选对收集器：低延迟服务用 ZGC 或 Shenandoah；大堆均衡场景首选 G1；吞吐优先且允许百毫秒停顿可用 Parallel。
- 合理设堆参数：避免堆过大（延长扫描时间）、过小（频繁 Young GC）；G1 中适当调大 -XX:G1HeapRegionSize 可减少 Region 数量，降低元数据开销。
- 减少根集合压力：避免全局静态集合无节制增长；慎用 ThreadLocal，防止栈深度过大拖慢根扫描。
- 监控与诊断：通过 -Xlog:gc*,safepoint 查看 STW 实际耗时与触发原因，区分是 GC 导致还是安全点轮询等待（如长时间 JNI 调用阻塞线程进入 SafePoint）。
