ZGC通过读屏障实现并发垃圾回收，将地址校验与指针更新拆解为轻量、原子、线程本地操作；染色指针编码GC状态，读屏障实时解码并修正引用；仅三次固定开销STW，其余工作全由应用线程在运行中完成。
ZGC 实现近乎零停顿，核心不靠“躲开”应用线程，而是让垃圾回收的大部分工作和应用代码**同时跑**——读屏障就是这个并发协作的关键入口点。它不是用来“阻止”访问，而是让每次对象引用操作都自动参与 GC 进程，把原本需要 STW 才能做的地址校验、指针更新，拆成微小、安全、可并行的步骤。
读屏障不是拦截器，是自动协作者
传统 GC（如 G1）用写屏障（Write Barrier）在字段赋值时记录跨区引用；ZGC 的读屏障则发生在每次读取对象引用时（比如 aload、getfield、invokevirtual）。只要 Java 代码拿到一个引用，JVM 就会悄悄插入几条指令：检查指针颜色 → 判断是否指向已转移或待标记的对象 → 如需，就现场解析并原子更新该引用到新地址。
- 这个过程极轻量，现代 CPU 流水线下通常只增加 1–2 个周期开销
- 它不阻塞线程，也不排队等待，每个线程各自处理自己的引用
- 没有全局锁、无需协调多个线程同步更新同一块内存
染色指针 + 读屏障 = 地址状态随用随解码
ZGC 把 GC 状态（Marked0 / Marked1 / Remapped）直接编码进 64 位指针的高位（如第 60–63 位），指针本身就成了“带状态的地址”。读屏障正是解码这个状态的执行单元：
- 若指针标为 Marked：说明对象已被标记，但可能还在旧地址；读屏障触发并发标记流程，并确保后续访问能落到正确视图
- 若指针标为 Remapped：说明对象已完成转移，但部分引用尚未更新；读屏障立即重写该引用为新地址，并保证原子性
- 若指针是 Normal（未染色）：直接使用，无额外动作
所有这些判断和修正都在单次内存加载时完成，用户代码无感知，也无需修改逻辑。
立即学习“Java免费学习笔记（深入）”；
真正停顿的环节被压缩到极致
ZGC 全周期中仍存在三次极短 STW 阶段，但它们只做最轻量的事，且耗时与堆大小无关：
- 初始标记：仅扫描 GC Roots（线程栈、寄存器、全局引用等），数量固定
- 再标记：修正并发标记期间因应用修改产生的少量漏标，增量式处理
- 初始转移：选定待回收区域，准备转移表，不移动对象本身
而对象扫描、标记遍历、内存复制、指针更新——全部由读屏障驱动，在应用线程运行过程中自然完成。不是“暂停世界来清理”，而是“边用边清”。
绕过读屏障的场景必须谨慎对待
JNI 调用、Unsafe 直接内存访问、GetPrimitiveArrayCritical 等操作会跳过 JVM 的引用检查机制，也就无法触发读屏障。此时若 GC 正在转移对象，原生代码可能读到已失效地址，导致崩溃或静默数据错误。
- 避免在关键路径大量使用
Unsafe.allocateMemory或DirectByteBuffer的底层操作 - JNI 回调中如需长期持有 Java 对象引用，应显式调用
NewGlobalRef并管理生命周期 - JDK 15+ 默认启用读屏障，禁用选项（如
-XX:-UseZGCReadBarrier）切勿开启
