StopTheWorld（STW）是JVM执行关键GC操作时强制暂停所有应用线程的行为，源于堆一致性与对象可达性判定的必要性；不同收集器STW时长差异大，G1为毫秒级、ZGC控制在1ms内、Serial/Parallel则全程STW；无法彻底消除，但可通过调优显著压缩。
StopTheWorld 是什么，为什么它必然发生
StopTheWorld（STW）不是某个 API 或配置项，而是 JVM 在执行某些关键操作（主要是部分 GC 阶段）时，**强制暂停所有应用线程**的行为。它不是 bug，也不是可选开关——只要用了分代回收、需要对象图一致性或堆结构变更，JVM 就必须 STW。
根本原因在于：GC 线程和 Java 应用线程并发访问堆内存时，若不冻结应用线程，就无法安全判断哪些对象还被引用、哪些可以回收。比如 CMS 的初始标记、G1 的 Evacuation 阶段、ZGC 的 Relocation 准备阶段，都依赖“那一刻的堆快照”。
不同垃圾收集器的 STW 时长差异极大
STW 时间不是由“是否触发 GC”决定，而是由**收集器类型 + 堆大小 + 存活对象数量 + GC 触发时机**共同决定。以下为典型表现：
-
G1：默认启用-XX:+UseG1GC后，大部分阶段并发，但Initial Mark和Evacuation（即 Mixed GC 中的实际复制）仍需 STW；一次 Mixed GC 的 STW 通常在几毫秒到几十毫秒，但大堆（>32GB）+ 高存活率下可能突破 100ms -
ZGC：设计目标是 STW 不超过 10ms，实际中绝大多数 STW（如Pause GC）控制在1ms内，但前提是堆不超过 16TB 且未开启-XX:+UnlockExperimentalVMOptions下的不稳定选项 -
Serial / Parallel：全程 STW，ParallelGC虽并行处理，但整个 Young GC 或 Full GC 过程仍会停掉所有应用线程；一次 Full GC 在 4GB 堆上可能卡住 500ms 以上
如何定位一次 GC 是否引发了不可接受的 STW
不能只看 GC log 里有没有 pause 字样——所有 GC 日志中的 pause 都代表 STW 发生。关键看时长和频率：
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-Xlog:gc*:file=gc.log:time,tags,level -Xlog:safepoint*:file=safepoint.log:time,tags
重点关注日志中类似这样的行：
[2024-04-10T10:23:45.678+0800][info][gc,phases] GC(123) Pause Young (Normal) (G1 Evacuation Pause) 123M->45M(1024M) 42.323ms
其中 42.323ms 就是本次 STW 持续时间。同时检查 safepoint.log，确认是否因 no vm operation 或 revoke bias 导致额外 safepoint 延迟——这些也会表现为“伪 STW”，让应用线程卡在进入 safepoint 的路上。
能关掉 STW 吗？不能，但可以大幅压缩它
没有收集器能完全消除 STW（ZGC 和 Shenandoah 也只是把 STW 压到亚毫秒级，且仍存在），但你可以通过以下方式显著降低影响：
- 避免
System.gc()或Runtime.getRuntime().gc()——它们会强制触发 Full GC，带来长 STW - 调小
-XX:MaxGCPauseMillis（仅对 G1/ZGC 有效），但不要设得比实际能力低太多，否则 GC 频次会飙升 - 减少大对象直接进入老年代（避免
-XX:PretenureSizeThreshold误配），防止老年代碎片化引发频繁 Full GC - 用
-XX:+UseStringDeduplication（G1）或-XX:+UseShenandoahGC替代 ParallelGC，对字符串多、长生命周期对象多的场景更友好
真正棘手的从来不是“有没有 STW”，而是 STW 发生在请求链路的关键路径上（比如支付扣款接口正在等数据库响应时突然被 GC 卡住 80ms）。这时候光换收集器不够，得结合异步化、缓冲队列、降级策略一起压测验证。
