Shenandoah通过JVM在字节码阶段主动插入读写屏障逻辑，结合Brooks转发指针实现并发GC：读屏障检查fwdptr并重定向引用，写屏障协调写入时机并支持预转发，全程无硬件依赖、无需STW（除根扫描），兼容性强但有轻微CPU开销。

Shenandoah 的读写屏障不是靠硬件指令直接完成的，而是由 JVM 在字节码编译或解释执行阶段，**主动插入特定的屏障逻辑代码**，再配合对象头结构与运行时状态协同工作。它的核心目标是：在不暂停应用线程的前提下，让 Mutator（用户线程）对对象的访问始终看到“正确且一致”的数据，哪怕该对象正在被 GC 线程并发移动。

读屏障：确保读取的是迁移后的新对象

当应用线程执行 getfield、aload 等涉及对象引用读取的操作时，JVM 会在其前后插入读屏障逻辑。典型流程如下：

• 检查当前对象头中是否已设置 Brooks 转发指针（fwdptr），且该指针非空
• 若 fwdptr 存在且指向新位置，直接返回新地址上的对象引用
• 若 fwdptr 尚未设置（对象未开始移动）或仍指向自身，则原样返回原对象
• 整个过程发生在用户线程上下文中，无需锁或系统调用，开销可控

写屏障：控制对象更新时机并辅助转发

写屏障主要作用于 putfield、astore 等修改对象字段或引用的操作。它不只是拦截写入，更承担状态协调职责：

• 先判断当前 GC 是否处于并发转移阶段（通过全局状态标志位）
• 若处于转移中，且待写入的对象已有有效 fwdptr，则将写操作重定向到新对象上
• 若对象尚未转发，但 GC 已标记为“待转移”，部分实现会触发“预转发”——协助 GC 线程完成复制并设置 fwdptr
• 避免出现“旧地址写入后，GC 再移动”的数据错乱问题

Brooks 指针与屏障协同的关键设计

Shenandoah 使用对象头前附加的转发指针（早期版本固定 +8 字节；2.0 版本优化为临时复用 Mark Word），这是所有屏障行为的锚点：

• 读屏障依赖 fwdptr 判断是否需重定向，本质是“懒加载式重映射”
• 写屏障不仅检查 fwdptr，还会在必要时参与 CAS 设置，保证多线程下转发动作原子性
• 屏障只对引用类型字段生效（如 Object、数组引用），基本类型（int、long）不触发，降低开销
• 根集合（GC Roots）扫描仍需短暂 STW，但耗时极短，与堆大小无关

与 ZGC 染色指针的根本区别

ZGC 把元信息（如是否已重定位）编码进 64 位指针的高位，靠硬件支持的内存访问陷阱（trap）触发处理；Shenandoah 则完全走软件路径：

• 不依赖特殊 CPU 指令或操作系统 trap，兼容性更强，可在 JDK 8u 上运行
• 屏障逻辑由 JIT 编译器内联展开，热点路径可高度优化
• 代价是每个对象增加存储开销（早期明显，2.0 已缓解），且屏障本身带来轻微 CPU 周期消耗