必须STW才能保证可达性分析准确性；初始标记和重新标记阶段需暂停用户线程以获取一致对象图快照，避免漏标或误标，而并发标记阶段允许用户线程与GC线程同时运行。
垃圾回收器在并发可达性分析的标记阶段并不会“强行按下全局刹车”——这个说法容易误解。真实情况是：它必须暂停所有用户线程（即触发 Stop-The-World，STW），才能安全、准确地完成初始标记和重新标记两个关键环节。
为什么标记阶段不能全程并发？
可达性分析依赖一个稳定的对象图快照。如果用户线程持续修改引用关系（比如把某个对象从 A 引用改为指向 B，或断开引用），而 GC 线程同时在遍历，就可能漏标或误标：
- 刚被新引用的对象，可能还没被 GC 扫到，就被当成垃圾清除了（漏标）；
- 正在被断开引用的对象，可能已被 GC 标记为存活，但实际已不可达（误标，虽不致命但影响效率）。
因此，JVM 只允许在“对象图相对静止”的时刻做精确标记，这就需要 STW。
哪些标记阶段必须 STW？
以主流 CMS 和 G1 为例：
- 初始标记（Initial Mark）：从 GC Roots 出发，仅标记直接可达对象。耗时极短，必须 STW；
- 重新标记（Remark）：修正并发标记期间因用户线程运行导致的引用变动（如写屏障记录的“脏卡”）。这是 STW 最长的一环，也是调优重点；
- 而中间的 并发标记（Concurrent Mark） 阶段才是真正并发执行的——此时用户线程照常运行，GC 线程一边遍历一边记录变化。
STW 不是“暴力中断”，而是有节奏的配合
JVM 并不会在任意指令处打断线程。它依靠 SafePoint 和 SafeRegion 机制，在线程执行到安全位置（如方法调用返回、循环边界、无锁代码段）时才发起暂停：
- 用户线程运行中会定期轮询是否需进入 SafePoint；
- 长时间运行的本地方法（Native）或偏向锁重偏向等场景，则需等待进入 SafeRegion；
- 这意味着 STW 延迟可控，并非“瞬间硬刹车”，而是协同式停靠。
有没有完全不 STW 的方案？
目前没有通用、高性能、精确的纯并发可达性分析。ZGC 和 Shenandoah 通过读屏障（Load Barrier）和颜色指针等技术，把 STW 压缩到毫秒级（如 ZGC 初始标记 & 重新标记均
