atomics.load 不可用于轮询，它仅适用于状态变更后的一次性确定读取；高效跨线程同步应使用 atomics.wait 或 waitasync 主动等待，避免 cpu 空转。
不能用 Atomics.load 实现“轮询”——它本身不是轮询机制，而是原子读取工具；所谓“高效跨线程轮询”，本质是误用概念。真正高效的做法是放弃轮询，改用 Atomics.wait 或 Atomics.waitAsync 主动等待状态变更，避免 CPU 空转、功耗飙升和响应延迟。
为什么轮询 + Atomics.load 是低效且危险的
常见错误写法：
- 在主线程或 Worker 中写一个 while 循环，反复调用
Atomics.load(view, 0)检查某个标志位 - 加
setTimeout或await new Promise(r => setTimeout(r, 1))试图“节流”，仍属忙等变体 - 结果：CPU 占用持续拉高、电池快速耗尽、UI 卡顿、响应延迟不可控
正确替代方案：用 wait 系列实现零空转等待
Atomics.wait 和 Atomics.waitAsync 才是专为跨线程同步设计的原生等待机制，它们让线程真正挂起，不消耗计算资源。
-
Worker 内阻塞等待（适合后台计算任务）：
调用Atomics.wait(view, 0, 0)—— 表示“当view[0]的值等于 0 时，挂起当前线程”，直到主线程调用Atomics.notify(view, 0) -
主线程异步等待（不卡 UI）：
调用Atomics.waitAsync(view, 0, 0)返回 Promise，resolve 后拿到新值，可直接更新 DOM 或触发下一步逻辑 - 两者都要求：共享内存是
SharedArrayBuffer、视图是Int32Array、且已满足跨域隔离（COOP/COEP）
典型协作流程（以主线程控制 Worker 计算为例）
共享内存布局：前 4 字节为状态码（0=待命，1=运行中，2=完成），后续区域存输入/输出数据。
- 主线程初始化：
Atomics.store(stateView, 0, 0)，再启动 Worker - Worker 启动后：
Atomics.wait(stateView, 0, 0)进入休眠，等待指令 - 主线程下发任务：
Atomics.store(dataView, 1, inputVal)→Atomics.store(stateView, 0, 1)→Atomics.notify(stateView, 0) - Worker 被唤醒，执行计算，完成后：
Atomics.store(resultView, 2, result)→Atomics.store(stateView, 0, 2)→Atomics.notify(stateView, 0) - 主线程用
waitAsync响应式接收结果，无需任何循环或定时器
如果真要“读取最新值”，Atomics.load 该这么用
Atomics.load 的唯一正当用途，是在已知状态变化发生后，**一次性、确定性地读取当前值**，例如：
- Worker 完成计算并
notify后，主线程立即调用Atomics.load(resultView, 2)获取结果 - 状态机中判断当前状态：
const s = Atomics.load(stateView, 0)，然后用compareExchange尝试跃迁 - 永远不要把它放进循环里反复调用——这不是“高效”，是反模式
