GC停顿本质是为保证内存一致性而强制STW的底层约束，源于可达性分析需冻结应用线程以避免漏标误标；不同算法通过分摊STW阶段（如CMS、G1）或并发化（ZGC/Shenandoah）优化停顿。
GC停顿本质是Stop-The-World（STW）行为，不是“卡一下”那么简单——它源于垃圾回收必须保证内存状态一致性的底层约束。理解这点，才能从算法层面真正定位和优化停顿问题。
可达性分析强制暂停应用线程
JVM采用可达性分析判定对象是否存活，即从GC Roots出发遍历引用链。这个过程要求对象图在扫描期间不能被修改，否则可能漏标或误标。
- 如果应用线程同时修改引用（比如将A对象的字段指向B，又马上改为C），标记线程可能看到不一致的中间状态
- 为避免错误回收或内存泄漏，JVM必须冻结所有Java线程，确保引用关系静止
- 初始标记（Initial Mark）和重新标记（Remark）阶段都依赖这一机制，哪怕只持续几毫秒，也属于STW
不同算法对停顿的分摊策略差异明显
停顿长短和分布方式，直接由GC算法的设计目标决定：
- Serial/Parallel GC：全程STW，所有工作串行或并行执行，但无法与用户线程并发，Young GC尚可接受，Full GC极易造成秒级卡顿
- CMS：把标记和清除尽量并发化，仅初始标记和重新标记需STW；但并发失败（Concurrent Mode Failure）会退化为Serial Old，触发长时间Full GC
- G1：通过Region划分和预测模型控制停顿，Mixed GC只处理部分老年代Region，停顿可控；但Remembered Set维护开销大，写屏障影响吞吐
- ZGC/Shenandoah：使用读屏障+染色指针（ZGC）或转发指针（Shenandoah），标记、转移、重映射全部并发执行，STW仅限于极短的初始标记和最终更新阶段（通常
晋升与跨代引用加剧停顿复杂度
分代回收本为提升效率，却也引入额外同步成本：
- 年轻代对象晋升到老年代时，若老年代空间不足，直接触发Full GC，停顿不可控
- 跨代引用（如老年代对象持有新生代对象引用）必须被追踪，否则Minor GC可能误回收存活对象
- CMS/G1通过卡表（Card Table）或记忆集（Remembered Set）记录跨代引用，但写屏障操作本身带来CPU开销，且重新标记阶段需扫描这些结构，延长STW时间
元空间与直接内存未被忽略的停顿源
停顿不仅来自堆回收，方法区（元空间）和直接内存管理同样触发STW：
- Metaspace动态扩容失败时，会触发Full GC来尝试释放无用类加载器及其类元数据
- 显式调用System.gc()或JNI代码触发Native内存清理，也可能导致意外Full GC
- DirectByteBuffer的清理依赖Cleaner机制，若Finalizer队列积压，会拖慢Reference Handler线程，间接拉长STW等待
