深入解析：Shenandoah 在并发处理上为何比 G1 更加激进
先提出一个核心结论：在 GC 停顿时间的角逐中，Shenandoah 借助 Brooks 转发指针实现了完全并发的 Evacuation（对象复制），配合整堆去分代的前瞻设计，能够将 STW（Stop-the-World）时间稳定控制在 5 毫秒以内；而 G1 虽然持续优化，但由于核心 Evacuation 阶段必须 STW，再加上保留分代模型，其停顿时间波动较大，通常处于 100–200ms 的范围。
Shenandoah 的做法相当激进——它几乎将原本需要 Stop-the-World 的关键阶段全部搬移到与用户线程并发执行的路径上。反观 G1，虽然也支持并发标记等环节，但最棘手的 Evacuation 阶段仍然依赖 STW 来兜底。
关键差异：Evacuation 是否需要 STW
先看 G1 的处境。在 Mixed GC 或 Full GC 过程中，Evacuation 阶段必须 STW——这意味着所有应用线程都需要停下来，等待 G1 将存活对象从源 Region 复制到目标 Region。这部分停顿通常占整个 GC 停顿的 80% 以上，尤其是在老年代回收压力增大时，体验会非常明显。
Shenandoah 则换了一条思路。它通过 Brooks 转发指针（Forwarding Pointer）技术，让对象移动过程完全并发执行。具体如何实现？当用户线程访问某个对象时，如果发现该对象已被标记为“待移动”，它就会自动跳转到新地址，并同步帮助 GC 线程更新引用。这样一来，GC 线程与应用程序线程之间互不阻塞，各自运行，效率自然大不相同。
内存管理模型：更彻底的去分代策略
G1 保留了经典的分代逻辑（Eden/Survivor/Old Region 三个区域划分清晰）。年轻代的回收依然依赖 STW 的 Minor GC；老年代回收虽然引入了并发标记，但到了整理阶段，仍会因区域间引用处理和部分 STW 操作而受到影响。
相比之下，Shenandoah 默认取消了分代设计。整堆被统一视为 Region 的集合，所有回收动作——标记、转移、引用更新、清理——都按照并发策略来调度。这样一来，再也找不到“必须等待用户线程停摆才能开始”的硬性阶段，整个回收流程变得顺畅许多。
屏障机制与开销权衡：将并发优先原则贯彻到底
G1 使用的是 SATB 写屏障，主要用于并发标记的快照一致性。但问题在于，它无法支撑并发转移的实现，因此在 Final Mark 环节仍需一次 STW 来清空缓冲区。
Shenandoah 采用 读写双屏障 + Brooks 指针 的方案。每次对象访问和字段更新时，这个屏障都会介入干预。代价是增加了少量运行时开销，但换来了实实在在的收益：
• 不再需要 Final Mark 阶段的 STW
• 跨 Region 的引用更新可以全程并发完成
• 压缩（Compact）环节也不再依赖停顿窗口
从取舍来看，这种设计思路非常明确：宁可承受日常的微小性能开销，也要将 GC 停顿这个最大痛点彻底解决。
实际效果：STW 时间被大幅压缩
G1 的目标停顿时间通常设定在 100–200ms（可通过 -XX:MaxGCPauseMillis 调整），但实际运行中波动较大，尤其面对大堆或高分配率场景时，很容易突破预期值。
Shenandoah 在 JDK 17 及之后的稳定版本中，典型的 STW 时间可以稳定控制在 5ms 以内，并且这个数字与堆的大小基本无关。这正是其“更激进”并发设计的直接体现——它追求的不是“部分并发”，而是“尽可能消灭 STW”。这才是两个 GC 方案之间最本质的差异所在。
