Atomics.load 不适合轮询，应使用 Atomics.wait 配合状态位实现零开销等待；需确保状态值一致、视图构造相同，并检查 crossOriginIsolated。
Atomics.load 本身不适合做“轮询”——它只是原子读取，不带等待能力；真要高效协作，得用 Atomics.wait 配合状态位，否则 CPU 空转、功耗高、响应还慢。
为什么不用 setInterval + Atomics.load 做轮询
常见误解是：Worker 启动后每 10ms 调一次 Atomics.load(view, 0) 检查状态。这看似简单，但实际问题很直接：
- 主线程刚写入新状态，Worker 可能要等最多 10ms 才发现，延迟不可控
- 空转期间持续触发 JS 执行，Chrome 下单个 Worker 的 10ms 间隔会快速吃满事件循环，影响其他任务
- 多个 Worker 同时轮询同一地址，会加剧缓存行争用（false sharing），反而拖慢整体吞吐
-
Atomics.load不阻塞线程，你得自己加setTimeout或while循环——后者直接卡死 Worker
正确做法：用 Atomics.wait 实现零开销等待
Atomics.wait 是唯一能真正“挂起线程直到条件满足”的原语，它把轮询逻辑下沉到浏览器内核级，不消耗 JS 执行资源。前提是状态位必须用 Int32Array 单索引承载，且初始值和预期值定义清晰。
- 共享内存前 4 字节固定为状态位：
const state = new Int32Array(sab, 0, 1) - 约定状态值：
const IDLE = 0,RUNNING = 1,DONE = 2 - Worker 启动后立即调用：
Atomics.wait(state, 0, IDLE)—— 这会立刻挂起，不占 CPU - 主线程发令时执行：
Atomics.store(state, 0, RUNNING)→Atomics.notify(state, 0, 1) - Worker 被唤醒后，
Atomics.load(state, 0)读到的就是RUNNING，可安全进入计算逻辑
容易踩的坑：wait 调用时机和视图一致性
两个最常导致 Atomics.wait 静默失败或永不返回的问题：
-
Atomics.wait(state, 0, IDLE)必须在状态确实等于IDLE时调用；如果主线程已提前写成RUNNING，该调用会立即返回"not-equal"，Worker 就跳过等待直接执行——这通常不是你想要的“同步启动”行为 - 主线程和 Worker 必须用完全相同的视图构造方式访问同一块
SharedArrayBuffer；比如主线程用new Int32Array(sab)，Worker 却用new Uint8Array(sab)，会导致字节偏移错乱，Atomics.wait读到的压根不是你写的那个整数 - 忘记检查
self.crossOriginIsolated：如果为false，Atomics.wait会抛出TypeError: Atomics.wait is not supported，而不是静默降级
真正的高效不在于“多快读一次”，而在于“什么时候才读”。Atomics.wait 把决策权交给内核，只要状态位布局合理、通知及时，Worker 就能在毫秒级精度下被唤醒，且全程零 CPU 占用——这才是 SharedArrayBuffer + Atomics 协作的本来面目。
