如何利用 SharedArrayBuffer 在多个 Web Worker 之间直接共享海量原始数据缓冲区

如何利用 SharedArrayBuffer 在多个 Web Worker 之间直接共享海量原始数据缓冲区

当应用需要处理海量原始数据，例如音频采样、图像像素或科学计算中的巨型数组时，传统的消息传递机制常成为性能瓶颈。此时，SharedArrayBuffer 便可发挥作用。它允许主线程与多个 Web Worker 直接读写同一块物理内存，完全避免了序列化与复制的开销，实现了零拷贝共享。然而，这套强大机制的使用有严格前提：它不提供自动同步，必须手动使用 Atomics 进行读写协调，并且在现代浏览器中，默认要求页面处于跨域隔离状态才能启用。

启用 SharedArrayBuffer 的前提条件

从 Chrome 92 和 Firefox 93 等主流版本开始，SharedArrayBuffer 默认处于禁用状态。若页面不满足跨域隔离要求，尝试使用它可能引发 SharedArrayBuffer is not defined 错误或静默失败。如何搭建所需的“隔离环境”？

• 服务器配置是关键：服务器必须返回两个特定的 HTTP 响应头：
  Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
• 处理跨域资源：若页面引用了不同源的资源（如 iframe 或脚本），需为它们显式添加 crossorigin 属性。例如：
  
• 运行时检查：配置完成后，可在 Worker 或主线程中通过 self.crossOriginIsolated 验证环境是否就绪：
  if (crossOriginIsolated) { /* 现在可以安全地使用 SharedArrayBuffer 了 */ }

创建与分发 SharedArrayBuffer

环境准备就绪后，即可创建和共享内存。通常由主线程创建缓冲区，并通过 postMessage 分发给各个 Worker。核心要点是传递内存引用，而非数据副本。

• 主线程侧（以分配 1GB 的 Int32 数组为例）：
  const sab = new SharedArrayBuffer(1024 * 1024 * 1024); // 1GB
const int32View = new Int32Array(sab);
worker.postMessage({ buffer: sab }, [sab]); // 注意：sab 必须置于 transfer list 中
• Worker 侧接收：
  self.onmessage = ({ data }) => {
const { buffer } = data;
if (buffer instanceof SharedArrayBuffer) {
const view = new Float64Array(buffer); // 可根据需要创建不同的类型化数组视图
}
};
• 关键细节：必须将 sab 对象放入 postMessage 的第二个参数（即 transfer list）中。若遗漏此步，它可能被当作普通 ArrayBuffer 传递，导致共享失败。

使用 Atomics 实现线程安全访问

SharedArrayBuffer 仅解决了内存共享问题，未提供线程安全保障。多个 Worker 同时写入同一内存位置会产生竞态条件；同时读写则可能读到不完整的“撕裂值”。因此，必须使用 Atomics 进行显式同步访问。

• 基础原子操作：
  Atomics.add(int32View, 0, 1); // 原子加法，返回操作前的旧值
Atomics.load(int32View, 0); // 原子读取，确保读到完整值
Atomics.store(int32View, 0, 42); // 原子写入，保证写入过程不被中断
• 等待与通知机制（适用于生产者-消费者模式）：
  Atomics.wait(int32View, 0, 0); // 线程将在此阻塞，直到内存位置 0 的值不等于 0
Atomics.notify(int32View, 0, 1); // 唤醒最多 1 个在该位置等待的线程
• 性能提示：尽量使用 Atomics.wait() 这类阻塞原语，而非 while (true) 忙等待，可显著降低 CPU 的无谓消耗。

实用模式与注意事项

直接操作原始的 SharedArrayBuffer 和 Atomics 较为底层。在实际项目中，通常基于它们封装更高级、易用的模式。

• 环形缓冲区：这是处理流式数据（如实时音频）的经典结构。通过两个原子变量分别记录读指针和写指针，生产者 Worker 写入数据，消费者 Worker 读取数据，双方通过 Atomics.compareExchange 等操作协调边界，避免覆盖未读数据。
• 分块工作区：对于超大缓冲区，可将其划分为固定大小的块（例如每块 64KB）。再用一个独立的 Int32Array 作为“管理表”，记录每个块的状态（0 表示空闲，1 表示正在写入，2 表示就绪可读）。Worker 按需申请和释放块，实现精细化的内存管理。
• 警惕“伪共享”：若不同 Worker 频繁访问物理上相邻的内存地址（如同一个缓存行内的多个 int32），即使它们逻辑上无关，也会引发严重的缓存行争用，拖慢性能。解决办法之一是在关键字段之间插入“填充”，实现 64 字节对齐。
• 调试与验证：Chrome DevTools 的 Memory 面板可查看 SharedArrayBuffer 的分配情况。要直观感受其性能优势，可使用 console.time() 进行对比：传输一个几百 MB 的数组，SharedArrayBuffer 与普通 postMessage 的耗时差异会非常明显。