V8写屏障是GC为维护堆内存一致性设计的软件机制，非CPU内存屏障；它在赋值时注入检查逻辑，结合卡表与记忆集，保障并发/增量GC下对象可达性判断正确。

V8 引擎中的写屏障（Write Barrier）不是 ARM 或 CPU 级别的内存屏障指令（如 DMB/DSB），而是垃圾回收器（Garbage Collector）为维护堆内存一致性而设计的软件机制，主要用于增量式或并发式 GC 场景下，确保对象图的可达性判断不被并发修改破坏。

它解决的核心问题是：当 JavaScript 应用线程（Mutator）和 GC 线程（Collector）同时运行时，若对象引用关系被修改，而 GC 正在遍历旧快照，可能导致存活对象被错误回收（漏标）或暂停时间过长。

---

写屏障如何工作？

写屏障是一段插入在“赋值操作”前后的轻量级检查逻辑（通常由 JIT 编译器自动注入），例如：

obj.field = otherObj;  // 这一行会触发写屏障

V8 在执行该赋值时，会额外调用类似 RecordWrite(obj, &obj.field, otherObj) 的函数，根据策略决定是否标记、入队或更新记录。

---

三种常见写屏障策略及其一致性保障方式

• Dijkstra-style（保守标记）

  • 当 obj.field 从 null → non-null，或指向一个老生代对象 → 指向新生代对象时触发
  • 将 obj（源对象）标记为「灰色」并加入标记队列
  • ✅ 保证：所有可能成为新生代对象根的对象都被扫描，避免漏标
  • ❌ 开销：可能重复扫描，但安全

• Steele-style（精确写屏障）

  • 只在 obj.field 从老生代 → 新生代 赋值时触发
  • 将 otherObj（目标对象）所在页或卡表（Card Table）对应区域标记为「脏」
  • GC 后续只扫描这些脏区域，减少遍历范围
  • ✅ 平衡精度与性能，V8 的 Orinoco GC 主要采用此思路配合卡表

• Incremental/Concurrent 标记 + 写屏障组合

  • GC 分多轮标记；Mutator 修改引用时，写屏障确保：
    • 若新引用指向未标记对象，该对象不会被跳过
    • 若旧引用断开，不影响已标记路径的完整性
  • V8 使用「快照算法（Snapshot-at-the-beginning）」+ 写屏障修补，保证最终标记结果与某个一致快照等价

---

关键支撑结构：卡表（Card Table）与记忆集（Remembered Set）

• 卡表：将堆划分为固定大小（如 512B）的“卡”，每卡用 1 字节标记是否被写入

  • 写屏障在赋值时将目标卡设为 dirty
  • GC 增量扫描时只处理 dirty 卡，大幅减少工作量

• 记忆集（用于分代 GC）：记录跨代引用（如老生代对象持有了新生代对象）

  • 写屏障捕获这类引用，并登记到对应老生代页的记忆集中
  • Minor GC 时只需扫描记忆集，无需遍历整个老生代

---

它不解决什么？

• 不控制 CPU 指令重排或缓存可见性（那是硬件内存屏障的事）
• 不替代 std::atomic 或 memory_order 在 C++ 层的同步语义
• 不保证多线程 JS 代码的数据竞争安全——JS 是单线程执行模型，写屏障服务于 GC 线程与 JS 主线程的协作，而非用户级并发

---

总结一句话：

V8 写屏障通过在引用更新点插入轻量检查，动态维护对象图的「逻辑一致性快照」，使并发或增量垃圾回收能正确识别所有存活对象，从而在不停顿全堆的前提下，保障内存管理的正确性与响应性。