ZGC选择读屏障而非写屏障，核心是为实现并发对象移动下的“指针自愈”：每次读取时检查染色指针状态，查转发表并原地更新引用至新地址，确保访问正确性且无需STW修正。
ZGC 选择在读操作时插入 Load Barrier，核心原因在于它要解决的根本问题是并发对象移动下的引用一致性，而不是防止漏标——这和 G1 的写屏障目标完全不同。
读屏障服务于“指针自愈”而非“记录变更”
当 ZGC 并发转移一个对象时，旧地址上的对象已被复制到新位置，但大量引用仍指向旧地址。ZGC 不强求所有引用立刻更新（那需要 STW），而是让每次读取该引用时自动完成三件事：
- 检查指针是否带 Marked 位但未带 Remapped 位（说明对象已转移但指针未更新）
- 查转发表（Forwarding Table）拿到新地址
- 把字段值当场更新为新地址，并返回新对象
这个过程叫“指针自愈”（self-healing）。它只在首次读取时触发一次，后续访问就是纯内存读——没有额外开销。而写屏障做不到这点：写操作不涉及旧引用的修正，无法修复散落在各处的陈旧指针。
写屏障无法支撑“无停顿重映射”
G1 的写屏障主要用于并发标记阶段，记录跨区域引用变化，防止漏标。但它不处理对象移动后的引用更新问题。一旦对象被搬走，G1 必须在某个 STW 阶段（如 Evacuation Pause）统一修正所有引用，这部分时间随堆中存活对象数量线性增长。
ZGC 要消除这个 STW，就必须把引用更新动作下沉到访问路径上。而读操作才是引用真正“生效”的时刻——只有读取时才知道这个指针是否还有效、是否需要跳转。写操作只是修改引用值，不触发对目标对象的实际访问，自然也无法触发重定向逻辑。
染色指针让读屏障轻量可行
读屏障开销能否接受，取决于状态判断是否足够快。ZGC 的染色指针把 GC 状态直接编码在指针高位，判断只需一次位运算（如 ptr & 0x3），无需访存、无分支预测失败风险。这种纳秒级判断，才让“每次读都检查”变得可行。
反观写屏障，哪怕逻辑简单，也会拖慢所有对象字段赋值、数组元素写入、局部变量存储等高频操作。ZGC 明确禁用压缩指针（-XX:+UseCompressedOops），就是为了保住高位空间来放颜色位——这是读屏障能落地的前提。
不是“读比写少”，而是“读才是引用落地点”
有人误以为选读屏障是因为读多写少。实际上，在交易、风控等场景中，字段读取频次可能远高于写入，但关键不在频率，而在语义：
- 写操作定义的是“我打算让这个引用指向谁”，不保证马上用
- 读操作定义的是“我现在就要访问这个对象”，必须确保地址正确
ZGC 把修正时机锚定在真正需要对象内容的那一刻，既保证了正确性，又把开销压到最低。这不是权衡取舍，而是由“并发转移 + 染色指针”这套设计决定的必然路径。
