Shenandoah GC的读写屏障并非依赖特殊硬件，而是由JVM在编译或解释字节码时自动插入屏障逻辑。结合对象头中的转发指针（Brooks pointer），构成一套支持并发标记与并发转移的垃圾回收方案。整个过程无需特殊CPU指令，也无需全局Stop-The-World暂停（仅根扫描需要短暂停顿），兼容性极佳，代价是CPU开销略有增加。
该机制的核心思想简洁明了：避免应用线程等待GC，而是让GC与应用线程并行运行，在移动对象的同时确保应用线程始终访问迁移后的最新数据。以下详细解析其实现原理。
读屏障：保证读取操作获取迁移后对象
当应用线程执行getfield、aload等读引用指令时，JVM会在之前插入屏障代码。该屏障执行以下操作：首先检查对象头中Brooks转发指针（fwdptr）是否有效；若指向其他地址，则直接返回新地址的对象引用；若fwdptr未设置（对象未搬迁）或指向自身，则返回原对象。整个过程在用户线程上下文中完成，无需加锁或系统调用，开销完全可控。
写屏障：管理对象更新时机并辅助转发
写屏障挂载在putfield、astore等写引用指令附近。它不仅是拦截写入操作，更重要的是协调状态：首先检查全局标志位，判断GC是否处于并发转移阶段；若在转移中且目标对象已有有效fwdptr，则将写操作重定向到新对象；若对象未转发但GC已标记为“待转移”，部分实现会触发“预转发”——主动完成复制并设置fwdptr。这样避免了“写入旧地址后GC再搬迁导致数据不一致”的问题。
Brooks指针与读写屏障的协同设计
Shenandoah在每个对象头前面附加了一个转发指针（早期版本固定占用8字节，2.0之后临时复用Mark Word，显著节省空间），所有屏障行为都依赖该指针锚定：
- 读屏障通过检查fwdptr决定是否重定向，本质是“懒加载式重映射”——仅在需要时确认地址有效性。
- 写屏障不仅检查fwdptr，还会在必要时通过CAS操作协助设置，确保多线程环境下转发操作的原子性。
- 屏障仅作用于引用类型字段（如Object、数组引用），基本类型（int、long等）不触发，从而进一步降低开销。
- 根集合（GC Roots）扫描仍需短暂STW，但耗时极短且与堆大小无关，不会造成应用整体暂停。
与ZGC染色指针的本质区别
ZGC将元信息（如“对象是否已被重定位”）直接编码到64位指针的高位，通过硬件触发内存访问陷阱通知GC。Shenandoah则采用纯软件路线：
- 不依赖特殊CPU指令或操作系统陷阱，兼容性更强，可在JDK 8上直接运行。
- 屏障逻辑由JIT编译器内联展开，热点路径经深度优化后性能表现优异。
- 代价是每个对象占用额外存储（早期版本明显，2.0后大幅改善），以及屏障消耗少量CPU周期。
