Atomics.waitAsync：跨Worker原子同步不阻塞主线程

跨 Worker 原子同步的正确打开方式：Atomics.waitAsync 实战要点

在跨 Worker 共享内存同步场景中，Atomics.waitAsync 是一个兼具优势与门槛的工具。它允许在不阻塞主线程的前提下等待共享状态变化，但正确使用需要掌握若干关键前提与注意事项。以下内容围绕核心概念与典型实践展开，帮助开发者规避常见问题。

核心前提：Atomics.waitAsync 不能在主线程直接调用，必须依赖 SharedArrayBuffer 和跨源隔离环境，否则会抛出 TypeError: Atomics.waitAsync is not supported。

为什么主线程无法调用 waitAsync？

这源于浏览器的安全策略。浏览器默认禁用 SharedArrayBuffer，而 Atomics.waitAsync 依赖该机制。即使手动创建了 SharedArrayBuffer，若页面未启用跨源隔离（即未正确设置 COOP 和 COEP 响应头），Atomics.waitAsync 仍会抛出类型错误。这与“浏览器不支持”不同，开发者需区分这两个概念。

• 检查环境：运行 typeof SharedArrayBuffer !== 'undefined'，并确认 Atomics.waitAsync 确为函数。
• 前置条件：服务器响应头必须包含 Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp。
• 本地调试时，避免使用 file:// 协议，应启动 HTTP 服务，例如 python3 -m http.server 8000 --bind 127.0.0.1。

Worker 中如何正确初始化共享内存与原子等待？

主线程负责分配共享内存并传递给 Worker。Worker 接收后，通过 Int32Array 视图绑定内存，然后使用 Atomics.waitAsync 监听变化。一个易被忽略的步骤：等待前需用 Atomics.load 确认当前值，否则可能错过初始状态，导致等待永不触发。

• 主线程创建缓冲区：const sab = new SharedArrayBuffer(4); const iv = new Int32Array(sab); iv[0] = 0;
• 将共享内存传递给 Worker：const worker = new Worker('worker.js'); worker.postMessage({ sab });
• Worker 内部接收并建立视图：const iv = new Int32Array(e.data.sab);
• 等待逻辑必须置于 async 函数中：const { value, asyncId } = await Atomics.waitAsync(iv, 0, 0);（表示等待位置 0 的值从 0 改变为其他值）。

如何避免 waitAsync 永久挂起或误触发？

Atomics.waitAsync 并非轮询机制，它依赖底层线程调度器的唤醒。通知方若未使用 Atomics.notify，或通知的位置与数量不匹配，等待将一直挂起。更隐蔽的问题是：notify 必须在 waitAsync 被调用之后执行，并且操作的是同一块共享内存视图。

• 通知方应使用 Atomics.notify(iv, 0, 1)——第三个参数指定唤醒等待者的数量，1 表示仅唤醒一个（即使多个 await 同时挂起）。
• 不可混用不同的内存视图（例如主线程用 Uint32Array，Worker 用 Int32Array），字节偏移和类型必须完全一致。
• 等待前建议添加超时保护：Promise.race([Atomics.waitAsync(iv, 0, 0), new Promise((_, r) => setTimeout(r, 5000))])。
• waitAsync 返回的 value 是当前内存值，而非通知值；asyncId 是内部标识，仅用于调试，不可用于业务判断。

实际跨 Worker 同步场景的典型结构

例如：主线程启动一个计算型 Worker，等待其完成后渲染结果。与其通过 postMessage 回传数据再处理，不如让主线程借助 Atomics.waitAsync 等待 Worker 写入完成标记。这样可节省序列化与反序列化开销，并避免消息队列堆积。

• Worker 完成后执行：Atomics.store(iv, 0, 1); Atomics.notify(iv, 0, 1);
• 需注意：主线程自身不能直接 await waitAsync（因主线程禁止调用），因此必须将等待逻辑置于另一个 Worker 中。或退而使用 Atomics.wait 加 setTimeout 模拟，但此方法不推荐。
• 可行模式为：主线程下发任务 → Worker A 执行 → Worker A 通知 Worker B → Worker B 调用 Atomics.waitAsync 并触发后续逻辑 → Worker B 通过 postMessage 通知主线程。
• 换言之，Atomics.waitAsync 的使用者只能是 Worker，且通常不适合由发起同步请求的 Worker 直接调用——它更适合构建“监听型中间层”。

最后提醒：Atomics.waitAsync 的等待行为受浏览器线程调度策略影响，在低功耗设备或后台标签页中，响应延迟可能达到数秒。生产环境务必搭配超时与 fallback 机制，避免依赖即时响应。