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）」+ 写屏障修补，保证最终标记结果与某个一致快照等价
- GC 分多轮标记；Mutator 修改引用时，写屏障确保：
关键支撑结构：卡表（Card Table）与记忆集（Remembered Set）
-
卡表：将堆划分为固定大小（如 512B）的“卡”，每卡用 1 字节标记是否被写入
- 写屏障在赋值时将目标卡设为 dirty
- GC 增量扫描时只处理 dirty 卡，大幅减少工作量
-
记忆集（用于分代 GC）：记录跨代引用（如老生代对象持有了新生代对象）
- 写屏障捕获这类引用，并登记到对应老生代页的记忆集中
- Minor GC 时只需扫描记忆集，无需遍历整个老生代
它不解决什么？
- 不控制 CPU 指令重排或缓存可见性（那是硬件内存屏障的事）
- 不替代
std::atomic或memory_order在 C++ 层的同步语义 - 不保证多线程 JS 代码的数据竞争安全——JS 是单线程执行模型，写屏障服务于 GC 线程与 JS 主线程的协作，而非用户级并发
总结一句话：
V8 写屏障通过在引用更新点插入轻量检查，动态维护对象图的「逻辑一致性快照」，使并发或增量垃圾回收能正确识别所有存活对象，从而在不停顿全堆的前提下，保障内存管理的正确性与响应性。
