Atomics.waitAsync实现跨Worker非阻塞同步

Atomics.waitAsync 是浏览器中实现跨 Worker 非阻塞同步的关键新 API，但它绝非开箱即用：它被硬性限制在启用跨源隔离（COOP/COEP）的 Worker 环境中运行，主线程因 Spectre 防御策略彻底禁用 SharedArrayBuffer 而无法调用；正确使用需严格满足三重前提——HTTP 服务下确保响应头配置、Worker 内先 load 再 waitAsync、notify 必须精准匹配索引与时机，稍有偏差就会永久挂起；更关键的是，开发者必须跳出“原子即万能”的误区，通过双状态位设计等工程实践主动规避竞态窗口，让底层原子语义真正服务于可靠的时序逻辑——这是一场对内存模型理解与系统级协作能力的双重考验。

Atomics.waitAsync 不能在主线程使用，这是硬性限制。你必须把它放进 Worker 里，否则直接抛 TypeError: Atomics.waitAsync is not supported —— 这不是兼容性问题，是浏览器策略层面的禁用。

为什么主线程调用 Atomics.waitAsync 一定失败

根本原因不是 API 没实现，而是它依赖 SharedArrayBuffer，而现代浏览器默认禁用 SharedArrayBuffer 防御 Spectre 类攻击。即使你手动 new SharedArrayBuffer(4) 成功了，只要页面没启用跨源隔离（COOP/COEP），Atomics.waitAsync 就不可用，且错误提示非常不友好，只报类型错误，不提隔离策略。

验证是否就绪，得在控制台跑这两句：

typeof SharedArrayBuffer !== 'undefined'
typeof Atomics.waitAsync === 'function'

两者都为 true 才算过关。本地开发时，file:// 协议绝对不行，必须起 HTTP 服务，比如：

python3 -m http.server 8000 --bind 127.0.0.1

同时确保响应头包含：

• Cross-Origin-Opener-Policy: same-origin
• Cross-Origin-Embedder-Policy: require-corp

Worker 中初始化共享内存与等待逻辑的正确写法

主线程负责创建和传递，Worker 负责绑定视图并调用 waitAsync。关键点在于：等待前必须先读一次值，否则可能错过初始状态变化；waitAsync 必须写在 async 函数里，不能裸 await。

主线程示例：

const sab = new SharedArrayBuffer(4);
const iv = new Int32Array(sab);
iv[0] = 0; // 初始值
const worker = new Worker('worker.js');
worker.postMessage({ sab });

Worker 内部（worker.js）：

let iv;
self.onmessage = async (e) => {
  iv = new Int32Array(e.data.sab);
  // 必须先 load 确认当前值，再 wait
  if (Atomics.load(iv, 0) === 0) {
    const { value, asyncId } = await Atomics.waitAsync(iv, 0, 0);
    if (value === 'ok') {
      console.log('被通知，新值：', Atomics.load(iv, 0));
    }
  }
};

注意：iv 必须是 Int32Array，不能是 Uint32Array 或其他类型视图，字节偏移和类型必须严格一致，否则原子操作失效。

Atomics.notify 怎么配才不会让 waitAsync 永远挂起

waitAsync 不是轮询，它交由底层线程调度器挂起等待，唤醒全靠 notify。一旦漏掉、错位或数量不匹配，就会永远 pending。

通知方（通常是主线程或另一个 Worker）必须满足三个条件：

• 在同一个 SharedArrayBuffer 上构造的 Int32Array 视图
• 调用 Atomics.notify(iv, 0, 1) —— 第二个参数是索引（必须和 waitAsync 的位置一致），第三个参数是唤醒数量（1 表示只唤醒一个等待者）
• notify 必须发生在 waitAsync 调用之后、且该等待尚未被 resolve 前；如果先 notify 后 waitAsync，这次通知就丢了

强烈建议加超时保护：

const result = await Promise.race([
  Atomics.waitAsync(iv, 0, 0),
  new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), 5000))
]);

容易被忽略的底层一致性细节

最隐蔽的问题不是语法或配置，而是内存顺序和竞态窗口。比如主线程改值后立刻 notify，但 Worker 还没执行到 Atomics.load(iv, 0)，就可能跳过初始值检查，导致 waitAsync 等待一个永远不会变的旧值。

所以实际工程中，推荐用“双状态”模式：一个位置存数据，另一个位置当信号位。例如：

• 位置 0 存业务值
• 位置 1 当信号（0=未就绪，1=已就绪）
• Worker 先 Atomics.load(iv, 1) === 0，再 waitAsync(iv, 1, 0)，通知方改 iv[1] = 1 后 notify(iv, 1, 1)

这样能彻底规避“先改值后等待”导致的丢失问题。原子操作本身不解决逻辑时序，只保证单次读写不撕裂 —— 时序得靠你设计。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Atomics.waitAsync实现跨Worker非阻塞同步》文章吧，也可关注golang学习网公众号了解相关技术文章。