读屏障通过拦截对象引用读取操作，防止并发标记漏标、支持zgc等收集器的对象并发转移与指针自愈，并避免写屏障的高频开销，从而实现全程并发标记与转移，保障毫秒级确定性停顿。
读屏障（Read Barrier）本身不直接“提升并发”，而是让并发标记更安全、更可靠，从而支撑更高吞吐的并发 GC 场景。它解决的是并发 GC 中最底层的正确性问题——漏标。没有它，JVM 就不敢放心地让业务线程和 GC 线程长时间并行执行。
读屏障保障三色标记不漏标
在 ZGC、Shenandoah 这类低延迟收集器中，GC 线程扫描对象图时，业务线程仍在修改引用。如果某个白色对象（尚未标记）被黑色对象（已标记完）悄悄引用，而灰色对象（正在处理）又断开了对它的引用，这个对象就可能永远不被扫到，最终被错误回收。
读屏障在每次读取对象引用前插入检查逻辑，一旦发现目标对象处于“转移中”或“未标记但可达”，就主动触发标记或重定向，把漏标风险拦截在读取瞬间。
支持对象并发转移与指针重映射
ZGC 的核心能力是“几乎不停顿地移动对象”，靠的就是读屏障配合染色指针（Colored Pointers）：
- 对象被选中转移时，原地址保留一个转发指针（forwarding pointer）；
- 业务线程下次读该引用时，读屏障自动捕获并跳转到新地址，同时把旧引用更新为新地址（即“自愈”）；
- 整个过程对应用透明，无需 stop-the-world 修正所有引用。
避免写屏障的性能开销扩散
G1、CMS 用写屏障，意味着每次赋值（a.field = b）都要进一次屏障逻辑，高频写场景下开销明显。而读屏障只在真正读引用时触发，且现代实现（如 ZGC）做了高度优化：
- 多数读操作走快速路径，仅检查指针颜色位，无分支预测失败；
- 只有遇到“正在转移”的对象才走慢路径，属于稀疏事件；
- 不依赖卡表（Card Table）或记忆集（Remembered Set）维护，减少写放大。
让 GC 更激进地并发执行
因为读屏障兜底了漏标和指针失效，ZGC 可以做到：
- 标记阶段全程并发，不设 STW 的“重新标记”阶段；
- 转移阶段也全程并发，连“初始转移”都可并发启动；
- 单次 GC 停顿稳定控制在毫秒级，不受堆大小影响。
这种确定性低延迟，本质是读屏障赋予 GC 策略更大的并发自由度。
