Java GC触发Stop The World（STW）是为了确保对象引用关系在回收时不被应用线程修改，避免漏标或误删；关键阶段如G1的根扫描、RSet更新、对象复制等必须暂停所有应用线程。
Java GC 为什么会触发 Stop The World
GC 线程要安全地回收对象，必须确保堆中对象引用关系不被应用线程实时修改，否则可能漏掉存活对象或误删正在使用的对象。所以 JVM 在关键 GC 阶段（比如 CMS 的初始标记、G1 的最终标记、ZGC 的部分标记阶段）会强制暂停所有 Java 应用线程——这就是 STW。
不是所有 GC 都全程 STW：CMS 初始标记和重新标记阶段会 STW，但并发标记阶段不会；G1 的年轻代收集几乎总要 STW；ZGC 和 Shenandoah 把大部分工作挪到并发线程里，STW 时间压到 10ms 内，但依然存在（比如“初始标记”和“转移重映射”前的短暂停顿）。
-
System.gc()显式调用会触发一次 Full GC，大概率引发长时间 STW，生产环境应禁用 - 老年代空间不足、元空间耗尽、CMS 失败（concurrent mode failure）、G1 混合收集失败等都会导致 STW 时间陡增
- STW 时长和堆大小、存活对象数量、GC 算法选择强相关，和 CPU 核数基本无关
G1 GC 中哪些环节最常卡住应用线程
G1 的 STW 主要集中在 Young GC 和 Mixed GC 的根扫描、RSet 更新、对象复制、引用处理等阶段。其中 RSet（Remembered Set）更新是 G1 特有的开销来源：每个 Region 都要检查跨 Region 引用，而这些引用记录在对应 RSet 中，GC 时需遍历并清理脏卡页。
- 年轻代越大，
Young GCSTW 越长——因为要扫描更多对象、复制更多存活对象 - 混合收集时若老年代 Region 过多、且每个 Region 存活率高，
copy阶段会显著拉长 STW -
-XX:G1MixedGCCountTarget=8这类参数控制混合收集次数，设太小会导致单次 STW 更久；设太大则可能拖慢老年代回收节奏，引发更糟的 Full GC - RSet 占用内存高（可达堆的 5%~10%），且写屏障开销持续存在，不是 STW 期间才产生，但会加剧 GC 阶段负担
如何从 GC 日志快速定位 STW 严重问题
关键看日志里的 pause 字样和括号中的时间，例如：[GC pause (G1 Evacuation Pause) (young) 2.452ms] 或 [GC pause (G1 Evacuation Pause) (mixed) 187.321ms]。超过 50ms 就该警惕，超过 200ms 往往已影响接口 SLA。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 用
-Xlog:gc*,gc+phases=debug（JDK 10+）能看到各子阶段耗时，比如[Ext Root Scanning (ms): 2.1]、[Update RS (ms): 12.8] - 如果
[Update RS]占比过高，说明跨 Region 引用太密集，考虑调大-XX:G1RSetUpdatingPauseTimePercent（默认 10）或减少大对象跨 Region 分配 - 出现
to-space exhausted或evacuation failure表示复制失败，会退化为 Full GC，STW 时间飙升到秒级 - JDK 9+ 默认开启
-XX:+UseStringDeduplication，它在 GC 期间做字符串去重，也会延长 STW，需权衡是否关闭
ZGC 在低延迟场景下仍需关注的 STW 隐患
ZGC 承诺亚毫秒级 STW，但它的两次停顿（初始标记和最终标记）虽短，却对系统抖动敏感。尤其在容器环境下，如果 CPU 资源受限或被抢占，Initial Mark 阶段哪怕只多花 0.3ms，也可能让 P99 延迟翻倍。
- ZGC 要求堆大小必须是 2MB 的整数倍，且最小堆不能小于 8MB；若配置
-Xms4g -Xmx4g但实际物理内存碎片化，可能导致 ZGC 初始化失败并回退到 Serial GC -
ZUncommitDelay默认 300 秒，意味着堆内存释放有延迟，在资源紧张的 K8s Pod 里可能造成 OOMKilled - ZGC 不支持类卸载（
-XX:+ClassUnloading实际无效），元空间持续增长最终仍会触发 STW 的 Full GC - 监控必须抓取
ZStatistics输出（用-Xlog:gc+stats），光看pause时间会漏掉并发阶段的 CPU/内存压力累积
STW 不是“有没有”的问题，而是“在哪发生、多久、为什么变长”的问题。很多团队优化到最后才发现，罪魁祸首不是 GC 算法本身，而是某次上线后对象晋升速率翻倍，或是日志框架悄悄缓存了上万条未 flush 的 StringBuilder 实例。
