Atomics.waitAsync 必须在 Worker 中使用且需跨源隔离,因主线程禁用 SharedArrayBuffer 防御 Spectre;验证需 typeof SharedArrayBuffer 和 Atomics.waitAsync 均为 true;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-originCross-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):
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序,基于浩创云、ThinkPHP(PHP)开发,支持微信服务号与 H5 端,适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
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)
这样能彻底规避“先改值后等待”导致的丢失问题。原子操作本身不解决逻辑时序,只保证单次读写不撕裂 —— 时序得靠你设计。










