读屏障通过染色指针快速识别转移中对象并原子重写引用。它仅拦截字段读取，检查指针高4位状态位，Marked0时查转发表获取新地址并写回原引用，后续访问直接使用新地址，实现零开销读取。
读屏障如何拦截并修正移动中的对象访问
ZGC 在并发转移阶段会把存活对象从旧地址复制到新地址，但此时 Java 线程仍在运行，随时可能通过某个 Object ref 访问该对象。若不做干预，线程读到的就是已失效的旧地址——这会导致崩溃或数据错乱。读屏障（Load Barrier）正是插在每次对象字段读取前的一段“检查逻辑”，它不改变字节码，而是由 JIT 编译器在生成机器码时自动插入。
关键点在于：
- 读屏障只作用于对象字段加载指令（如
getfield,aload），不介入局部变量或方法参数传递 - 它检查目标指针的染色位（
Marked0/Marked1），若发现该对象正处于转移中（即标记为Remapped → Marked0状态），就触发“自愈”：从转发表（Forwarding Table）查出新地址，并将该地址写回原引用位置（即“重写指针”） - 这个重写是原子的，且仅发生一次；后续再读同一引用，指针已是新地址，不再进屏障
典型伪代码逻辑类似：
if (ptr & 0x08 != 0) { // 检查 Marked0 位
new_ptr = forwarding_table[ptr & ~0xFF];
if (new_ptr == null) {
new_ptr = relocate_object(ptr);
}
store_release(&ptr, new_ptr); // 原子写回
}
为什么必须用染色指针配合读屏障
单纯靠读屏障无法判断“这个指针是否需要处理”，因为 JVM 不可能对每个指针都查转发表（开销爆炸）。ZGC 的解法是把元数据直接塞进指针本身——64 位指针高 4 位被复用为状态位（Marked0、Marked1、Remapped、Finalizable），低 42 位才是真实地址。
这意味着：
- 指针本身自带状态，读屏障只需做位运算即可快速决策，无需额外内存查表
-
Remapped状态表示“已完成转移且引用已更新”，此时读屏障直接放行，零开销 -
Marked0表示“正在转移中”，才触发查表与重写 - 染色指针让读屏障从“保守全拦截”变成“精准按需拦截”，这是吞吐量不崩的关键
注意：染色指针要求禁用压缩指针（-XX:-UseCompressedOops），且只支持 64 位 JVM；32 位或开启压缩指针时，ZGC 直接不可用。
读屏障带来的实际性能影响与可观测线索
读屏障不是免费的——它增加每条对象字段读取的指令数和分支预测压力。但实测表明，其开销集中在以下场景：
- 高频遍历长链表或数组（如
LinkedList、ArrayList的get()） - 反射调用（
Field.get()）或序列化框架（如 Jackson）深度反射读取字段 - JIT 尚未内联的 getter 方法（屏障逻辑无法被优化掉）
可通过 JVM 参数验证其生效：
- 启用
-XX:+PrintGCDetails -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需 hsdis）观察汇编中load barrier stub插入点 - 使用
jstat -gc <pid>查看ZGCTotalPauseTimeMs是否稳定在 sub-millisecond 级别——若突增到毫秒级，大概率是读屏障未被 JIT 充分优化，或存在大量未内联的反射访问
一个容易被忽略的事实：读屏障的“自愈”行为只修正当前读取的指针值，不递归修正该对象内部所有引用字段。ZGC 依赖并发标记阶段已记录的对象图关系，确保转移时一并更新转发表，而非靠屏障逐字段修复。
