如何用SharedArrayBuffer和Atomics.load实现高效多Worker轮询

在 Web Worker 的协作编程中，一种高效、低延迟的通信机制至关重要。你可能首先想到使用 SharedArrayBuffer 配合 Atomics.load 来轮询标志位——听起来直接，实际却是一个典型的性能陷阱。

核心结论是：Atomics.load 本身并不适合用于轮询。强行使用不仅耗尽 CPU、阻塞线程，而且根本谈不上“高效”。它的正确角色，是作为 Atomics.wait 同步链路中的一部分。

为什么不能用 Atomics.load 做轮询

所谓轮询，就是 Worker 反复调用 Atomics.load(view, index) 来检查某个内存位置的值是否发生变化。这种做法隐患重重：

• CPU 空转：每次 Atomics.load 都是一次内存访问，线程不会主动让出或等待。极端情况下，一个 Worker 线程就可能吃满一个 CPU 核心。
• 影响调度：浏览器无法让这种持续活跃的线程进入休眠，它会一直抢占时间片，从而拖慢其他 Worker 甚至主线程的响应速度。
• 延迟不可控：如果为了避免 CPU 满载而加入 setTimeout 或 await 延时，就变成了一种低效的“假轮询”，既无法保证及时唤醒，也引入了不确定的延迟。
• 缺乏协作：Atomics.load 是纯粹的单向读取操作，无法与数据生产者形成有效的通知与协作机制，本质上是在“盲猜”。

真正高效的替代方案：Atomics.wait + notify

高效的跨线程协作，其精髓不在于“不停地查”，而在于“安静地等”。Atomics.wait 正是为此而生：它让线程挂起，直到被明确唤醒，实现零 CPU 开销和毫秒级响应。

• 等待方：Worker 启动后，调用 Atomics.wait(sharedView, 0, 0)。这表示：“在共享视图的索引 0 处等待，直到它的值不再是 0。”
• 通知方：当主线程或其他生产者 Worker 准备好数据后，先执行 Atomics.store(sharedView, 0, 1) 写入新值，紧接着调用 Atomics.notify(sharedView, 0, 1) 来唤醒一个正在等待的线程。
• 处理与重置：被唤醒的 Worker 获得控制权，处理数据。完成后，通常将标志位重置（例如 Atomics.store(sharedView, 0, 0)），然后再次进入 wait 状态，等待下一次任务。
• 重要限制：Atomics.wait 只能在 Worker 线程中安全调用。在主线程中调用会直接抛出 TypeError。

共享内存布局建议（避免踩坑）

把所有的状态和数据胡乱塞进一个 SharedArrayBuffer 是滋生竞态条件的温床。一个清晰的内存布局至关重要：

• 同步标志区

  建议使用前 4 个字节（对应 Int32Array[0]）专门作为同步标志位。例如，0 表示空闲，1 表示数据就绪，2 表示正在处理。

• 元数据区

  接下来的 4 个字节（Int32Array[1]）可以用来存储数据的长度，确保读取时不会越界。

• 数据区

  剩余的空间按需划分。例如，可以用 new Float64Array(sab, 8) 来创建一个从第 8 字节开始的双精度浮点数数组，用于存放计算结果。

• 操作纪律

  所有对共享内存的写入都必须使用 Atomics.store，所有读取都必须使用 Atomics.load。即使是读取一个看似简单的长度值，也不能直接用 view[1]，必须保证操作的原子性。

• 并行写入

  如果需要多个 Worker 并行写入不同的内存区域，必须确保它们操作的索引范围完全没有重叠。否则，仍然需要使用 Atomics.compareExchange 等指令来实现锁机制。

检查环境是否就绪再动手

代码逻辑再完美，如果运行环境不满足条件，一切都会静默失败。在动手之前，请务必确认以下几点：

• 关键 HTTP 头：服务器必须返回两个响应头：Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp。
• 资源加载属性：页面中所有相关的脚本和 Worker 文件，在加载时都必须带上 crossorigin 属性。例如：。
• 开发环境：不要直接双击打开本地 HTML 文件（file:// 协议）。必须通过 HTTP 服务器（如 http://localhost:8080）访问，否则 self.crossOriginIsolated 永远为 false。
• 最终验证：在 Worker 或主线程中，打印 self.crossOriginIsolated 的值。只有它为 true 时，才能安全地使用 SharedArrayBuffer。否则，创建 SharedArrayBuffer 的尝试要么静默失败，要么抛出未定义的错误。

说到底，很多开发者感觉自己在“轮询”，其实是没有意识到 Atomics.wait 才是通往高效协作的唯一正途。而那些看似省事的“手动延时加读取”组合，往往在不知不觉中牺牲了性能，也埋下了维护的隐患。