zgc通过写屏障、染色指针与转发表原子操作协同实现并发搬迁下的引用更新：写屏障拦截赋值并依染色位判断是否重定向；染色指针保障状态可见性；cas确保转发表更新无竞争；多视图映射兜底避免崩溃。
ZGC 在并发搬迁阶段面对应用线程对对象指针的并发修改（如 obj.field = newRef），不依赖全局暂停或粗粒度锁，而是通过“写屏障（Store Barrier）+ 染色指针状态 + 转发表原子查写”三者协同完成冲突规避与自动补偿。关键在于：它不阻止修改，而是让每次写入都自带状态校验与自愈能力。
写屏障拦截写操作，实时判断目标对象是否已搬迁
ZGC 启用写屏障（Store Barrier），在每次执行对象字段赋值（如 a.b = c）时插入检查逻辑。该屏障会解析右侧引用 c 所在指针的染色位：
- 若
c指针的 Remapped 位已置位，说明该对象已完成重定位，且新地址已稳定；此时直接允许写入，无需干预 - 若
c指针处于 Marked0/Marked1 状态但 Remapped 未置位，说明对象正被 GC 线程搬迁中（或尚未开始搬迁）；此时屏障会立即查询转发表（Forwarding Table），获取其新地址，并将写入目标自动重定向到新地址 - 若
c是刚分配的新对象（Remapped 位天然有效），或指向未被选入本次搬迁的区域，则跳过处理，走原路径
染色指针保障状态可见性，避免写入旧地址导致“悬垂引用”
传统 GC 中，对象移动后若应用线程仍向旧地址写字段，会造成数据错乱或静默丢弃。ZGC 将状态内嵌于指针本身，使每次解引用前都能快速判定：
- 应用线程写
obj.field时，JVM 实际拿到的是一个带标记的虚拟地址（如 Marked0 视图下的地址） - 写屏障结合该地址的高位染色信息，决定是直接写、还是先重定向再写——整个过程对 Java 代码完全透明
- 即使 GC 线程正在复制对象到新物理页，只要旧页映射仍存在（靠多视图内存映射保障），写屏障就能安全读取原对象头或转发表条目，不会出现访问非法内存
CAS 更新转发表 + 原子写回，确保引用修复不丢失
当多个应用线程几乎同时尝试写入同一个待搬迁对象的引用时，可能触发多次重定向请求。ZGC 用以下机制防止重复搬迁和状态竞争：
- 转发表（Forwarding Table）中每个槽位采用 CAS（Compare-And-Swap）方式初始化：仅首个成功写入新地址的线程能设置成功，其余线程发现已被设置后，直接复用该结果
- 写屏障在完成重定向后，不仅把新地址用于本次写入，还会将更新后的指针（带 Remapped 位）原子写回源位置（如栈帧局部变量、对象字段），避免下次读取再次触发查表
- 对于静态字段等长期存活引用，ZGC 不强制立刻修正；而是等下一次读/写访问时由对应屏障再次介入——把修复压力摊平，不堆积
多视图映射兜底，硬件级保证写入不崩溃
即便写屏障因极罕见时序未能完全覆盖（例如写操作发生在屏障插入前的 JIT 优化窗口），ZGC 的三视图内存映射（Marked0 / Marked1 / Remapped）仍提供最后一层保护：
- 旧地址（Marked0 视图）在搬迁期间仍映射到原物理页，写操作不会段错误
- 而 GC 线程在复制完成后，会原子切换页表项，使后续所有新访问（含写）自然落入 Remapped 视图
- 这种“新旧共存+渐进切换”设计，让写入行为始终落在合法内存页上，只是语义由屏障动态解释
