stw的根本原因是jvm需获取内存与线程状态的一致性快照，而可达性分析要求所有用户线程暂停以确保引用关系静止；安全点是stw的触发锚点；不止gc，偏向锁撤销、jit反优化等操作也依赖stw；不同收集器通过并发标记等策略缩短stw时间。
STW 的底层触发原因，根本在于 JVM 需要获取一个内存与线程状态的一致性快照，而这种一致性无法在用户线程持续运行时安全达成。
可达性分析必须冻结执行上下文
JVM 使用可达性分析算法判断对象是否存活，它从 GC Roots（如栈帧变量、静态字段、JNI 引用等）出发，沿引用链扫描所有可达对象。这个过程要求整个堆和所有线程的引用关系在扫描期间保持静止：
- 若线程继续执行，可能修改引用（如局部变量赋值、字段更新、对象创建或销毁），导致引用链动态变化；
- 这会引发两类错误：漏标（本该存活的对象被回收）或错标（本该回收的对象被误保留）；
- 只有暂停所有用户线程，才能确保从枚举 GC Roots 到完成标记的全过程基于同一时间点的视图。
安全点（SafePoint）是 STW 的执行锚点
STW 不是任意时刻发生，而是等待所有线程主动运行到预设的安全点位置后才触发：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 安全点通常位于方法调用返回、循环跳转、异常抛出等指令边界处；
- 线程到达安全点后会检查是否需要进入 STW，否则继续执行；
- 长时间运行的原生代码（如 JNI）、或无安全点的循环（未包含方法调用或分支），会导致 STW 延迟，甚至出现“安全点超时”问题。
不止 GC：其他 VM 操作同样依赖全局静止
STW 并非仅由垃圾回收触发，任何需访问全局一致状态的 JVM 内部操作都会要求停顿：
- 偏向锁撤销：需遍历所有线程锁记录，确保无竞争前提下批量取消；
- JIT 反优化：当内联假设失效时，需将已编译代码回退为解释执行，依赖当前栈帧结构稳定；
- 类重定义（如热替换）：必须保证无任何线程正执行待修改类的方法字节码；
- 线程堆栈转储、死锁检测等调试操作：需读取所有线程精确的调用栈和锁持有状态。
不同收集器对 STW 的控制策略差异
虽然 STW 无法完全避免，但现代收集器通过减少停顿频次与缩短单次时长来缓解影响：
- Serial/Parallel 收集器：初始标记、最终标记、整理阶段均需 STW；
- CMS：初始标记和重新标记阶段 STW，其余并发进行；
- G1/ZGC/Shenandoah：将标记拆分为并发阶段，仅极短的初始标记与再标记需 STW（毫秒级）；
- ZGC 和 Shenandoah 还支持并发整理，进一步压缩 STW 时间至几十微秒量级。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
