WebWorker并发冲突怎么处理？

本文深入剖析了 Web Worker 中并发竞争问题的解决方案边界，指出 Atomics API 虽能通过 SharedArrayBuffer 实现整数/浮点数级别的原子操作（如计数器递增或单字段 CAS），但其能力严格受限——不支持对象、字符串等复杂类型，无法替代锁或消息机制处理多字段约束、状态一致性或副作用逻辑；文章用大量典型错误示例和正确实践揭示了 SharedArrayBuffer 传输、视图对齐、跨域隔离等关键陷阱，并强调：真正健壮的并发协作并非依赖底层原子操作堆砌，而是应结合 postMessage 消息传递与主线程协调，将复杂逻辑收口，仅用 Atomics 做轻量标记与简单同步，让开发者避开高危误区，写出可维护、可预测的多线程 Web 应用。

Atomics API 能解决 Web Worker 里的简单共享内存竞争，但仅限于 SharedArrayBuffer 上的整数/浮点数原子操作；它不能替代锁或消息机制来处理复杂状态同步。

SharedArrayBuffer 是 Atomics 的前提条件

Atomics 操作的对象必须是 SharedArrayBuffer 背后的 Int32Array、Float64Array 等视图。普通数组（包括 ArrayBuffer）不支持原子操作，直接传入会报 TypeError: expected a shared array buffer view。

常见错误现象：

• 误用 new ArrayBuffer() 创建缓冲区 → Atomics.add() 报错
• Worker 内未显式传递 SharedArrayBuffer 引用，只传普通数组 → 数据不共享，更谈不上原子性
• 主线程和 Worker 对同一 SharedArrayBuffer 使用不同长度的视图（如主线程用 Int32Array，Worker 用 Uint8Array）→ 内存重叠读写，结果不可预测

正确做法：

• 主线程创建 const sab = new SharedArrayBuffer(1024)
• 用相同构造方式生成视图：const ia = new Int32Array(sab)，再将 sab 通过 postMessage(sab, [sab]) 传输给 Worker
• Worker 中接收：self.onmessage = ({data, ports}) => { const ia = new Int32Array(ports[0]); }

Atomics.add() 和 Atomics.compareExchange() 的适用边界

Atomics.add() 适合计数器类场景，比如统计某类事件发生次数；Atomics.compareExchange() 可模拟“检查-设置”逻辑，但仅限单个整数位的 CAS（Compare-And-Swap），无法安全更新多个字段组成的结构体。

使用场景限制：

• 只能用于 Int8Array / Int16Array / Int32Array / Uint8Array / Uint16Array / Uint32Array / Float32Array / Float64Array
• 不支持字符串、对象、布尔值等任意类型；想存 flag？只能映射为 0/1 整数
• 所有操作都要求内存地址对齐（例如 Int32Array 必须从 4 字节边界开始）

示例（安全递增计数器）：

const sab = new SharedArrayBuffer(4);
const counter = new Int32Array(sab);

// 主线程
Atomics.add(counter, 0, 1); // 原子加 1，返回旧值

// Worker 中同样调用
Atomics.add(counter, 0, 1);

注意：Atomics.add(counter, 0, 1) 的第二个参数是索引（不是值），别写成 Atomics.add(counter, 1, 1) —— 那是在改第 2 个元素。

Atomics.wait() / Atomics.notify() 不等于 condition variable

Atomics.wait() 会让当前 Worker 线程挂起，直到另一线程在相同位置调用 Atomics.notify()，但它依赖底层操作系统线程调度，且有严格前置条件：等待前必须确保该位置当前值等于预期值，否则立即返回 "not-equal"。

容易踩的坑：

• 在非 Int32Array 视图上调用 → 报错
• 等待时传入的 value 与当前值不一致 → 不阻塞，直接返回，容易漏掉唤醒信号
• 主线程不能调用 Atomics.wait()（浏览器禁止阻塞主线程），只能在 Worker 内使用
• 没有超时参数（Atomics.wait() 第四个参数是 timeout in ms，但部分旧版 Chrome 不支持）

典型误用：

// ❌ 错误：没检查当前值就 wait，可能永远等不到
Atomics.wait(counter, 0, 0);

// ✅ 正确：先确认值为 0，再等它变
if (Atomics.load(counter, 0) === 0) {
  Atomics.wait(counter, 0, 0, 1000); // 最多等 1s
}

复杂状态同步仍需消息 + 外部协调

Atomics 解决不了对象字段组合更新、跨字段约束（如“余额 ≥ 扣款金额”）、或需要执行副作用（如触发 DOM 更新、发网络请求）的场景。这时候强行用多个 Atomics 操作拼凑，反而更容易出竞态。

真实项目中更可行的做法：

• 把状态变更封装成纯数据指令（如 {type: "UPDATE_BALANCE", delta: -100}），通过 postMessage() 发给主线程统一处理
• Worker 内部用 Atomics 做轻量标记（如 isProcessing = 1），避免重复启动任务
• 需要等待结果时，不用 Atomics.wait()，改用 Promise + onmessage 回调

最常被忽略的一点：SharedArrayBuffer 在跨域 iframe 或某些隐私模式下默认禁用，需检查 self.crossOriginIsolated 是否为 true，否则 SharedArrayBuffer 构造失败，后续所有 Atomics 调用都会失效。

理论要掌握，实操不能落！以上关于《WebWorker并发冲突怎么处理？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！