Atomics.wait与notify实现线程互斥锁

本文深入解析了如何利用 Atomics.wait 和 Atomics.notify 结合 SharedArrayBuffer 构建可靠、阻塞式的多线程互斥锁，强调它们并非开箱即用的锁机制，而是需严格遵循状态约定（如 view[0] 表示空闲/占用）、原子操作序列（compareExchange 获取、store+notify 释放）和关键工程约束（强制超时参数、COOP/COEP 响应头启用共享内存）的底层同步原语；同时揭示了常见陷阱——从误将 wait 当作锁、忽略唤醒后状态重检，到忽视浏览器安全策略导致 SharedArrayBuffer 失效——真正挑战在于跨 Worker 对同步语义的精确共识与容错设计。

Atomics.wait 和 Atomics.notify 本身不能直接构成互斥锁，但可以作为底层原语构建一个阻塞式互斥锁——前提是配合 SharedArrayBuffer 和正确的状态约定。

为什么不能直接用 Atomics.wait 当锁？

Atomics.wait 不是锁，它只是「在某个值没变时暂停当前线程」；它不自动修改状态、不保证唤醒顺序、也不自带所有权语义。常见错误是只调用 Atomics.wait(view, 0, 0) 就以为进了临界区，结果多个线程同时通过等待条件（比如都看到初始值为 0），造成竞态。

• 必须搭配一个明确的锁状态变量（如 view[0] === 0 表示空闲，1 表示已占用）
• 获取锁前需用 Atomics.compareExchange 原子地尝试从 0 → 1，失败则再等
• Atomics.wait 只应在 compareExchange 失败后调用，且等待的是「值变为 0」这个信号
• 释放锁必须用 Atomics.store 设为 0，再用 Atomics.notify 唤醒至少一个等待者

Atomics.wait 超时参数不是可选的

省略超时（即只传三个参数）在多数浏览器中会抛出 TypeError: Atomics.wait: timeout argument is required。即使某些环境允许，也不该依赖——因为无限等待会导致线程永久挂起，无法调试或恢复。

• 务必传第四个参数，例如 1e5（100 秒）或更保守的 5000（5 秒）
• 超时后应检查当前状态并决定重试、报错或降级处理，不能假设“等到了”
• 注意单位是毫秒，不是秒；Atomics.wait(view, 0, 0, 1000) 是等 1 秒

Worker 间共享 SharedArrayBuffer 前必须满足 COOP/COEP

即使代码逻辑完全正确，SharedArrayBuffer 在现代浏览器中默认被禁用。若未设置响应头，new SharedArrayBuffer(4) 会返回 undefined 或抛出 TypeError，后续所有 Atomics 操作都会失败。

• 服务端需返回两个关键 header：Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp
• 本地开发时可用 npx serve -l 8080 --cors 启服务，但注意它不设 COOP/COEP，需自行加中间件或改用支持的静态服务器
• Chrome DevTools 的 Application → Frames 面板可查看当前页面是否启用了 shared memory

唤醒数量与实际等待线程数不一致很常见

Atomics.notify(view, 0, 1) 返回的是「成功唤醒的 worker 数量」，但它可能小于你预期的等待线程数——比如返回 0，不代表没人等，而可能是：等待线程还没执行到 wait、已超时退出、或被 GC 掉了。

• 不要用返回值判断“锁已被拿走”，它只反映本次通知动作的结果
• 唤醒后，被通知的线程仍需重新检查状态（再次 compareExchange），不能跳过验证
• 如果需要唤醒全部等待者，传 Infinity 或足够大的数字（如 1e9），但注意性能开销

真正难的不是写对那几行 Atomics 调用，而是让所有 Worker 对「锁变量含义」「状态转换规则」「错误回退路径」达成一致。一旦某处漏掉 compareExchange 或误用 store 替代它，整个同步逻辑就不可靠了。

以上就是《Atomics.wait与notify实现线程互斥锁》的详细内容，更多关于的资料请关注golang学习网公众号！