如何利用 SharedArrayBuffer 在多个 Web Worker 之间直接共享海量原始数据缓冲区
当您的 Web 应用需要处理海量原始数据——例如音频采样、图像像素或科学计算中的巨型数组时，传统的 Web Worker 消息传递机制往往会因序列化和复制开销而成为性能瓶颈。此时，SharedArrayBuffer 便成为关键解决方案。它允许主线程与多个 Web Worker 直接读写同一块物理内存，彻底避免了数据复制，实现了真正意义上的零拷贝共享。然而，这套强大的机制也伴随着严格的使用前提：它不提供任何自动的线程同步，您必须手动使用 Atomics API 来协调并发访问。此外，在现代浏览器安全策略下，它默认要求页面必须处于跨域隔离状态才能启用。
启用 SharedArrayBuffer 的前提条件
自 Chrome 92 和 Firefox 93 等主流版本起，SharedArrayBuffer 默认处于禁用状态。若页面不满足跨域隔离要求，尝试使用它将导致 SharedArrayBuffer is not defined 错误或静默失败。那么，如何正确配置这个“隔离环境”呢？
- 服务器配置是关键：您的服务器必须返回两个特定的 HTTP 安全响应头：
Cross-Origin-Embedder-Policy: require-corpCross-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); // 1GBconst 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 的值不等于 0Atomics.notify(int32View, 0, 1); // 唤醒最多 1 个在该位置等待的线程 - 性能提示：尽量使用
Atomics.wait()这类阻塞原语，而非使用while (true)进行忙等待，这能显著降低 CPU 的无谓消耗，提升多线程应用整体性能。
实用模式与注意事项
直接操作底层的 SharedArrayBuffer 和 Atomics 较为复杂，在实际项目中，我们通常基于它们封装更高级、更易用的并发模式。
- 环形缓冲区：这是处理流式数据（如实时音频、视频帧）的经典结构。通过两个原子变量分别记录读指针和写指针，生产者 Worker 写入数据，消费者 Worker 读取数据，双方通过
Atomics.compareExchange等操作协调边界，有效避免数据覆盖或读取冲突。 - 分块工作区：对于超大型缓冲区，可将其划分为固定大小的块（例如每块 64KB）。再利用一个独立的
Int32Array作为“管理表”，记录每个块的状态（0表示空闲，1表示正在写入，2表示就绪可读）。Worker 按需申请和释放块，实现精细化的内存管理与任务调度。 - 警惕“伪共享”：如果不同 Worker 频繁访问物理上相邻的内存地址（例如位于同一 CPU 缓存行内的多个 int32），即使它们逻辑上无关，也会引发严重的缓存行争用，显著拖慢性能。一个有效的解决办法是在关键字段之间插入“填充字节”，实现 64 字节对齐，隔离缓存行。
- 调试与验证：Chrome DevTools 的 Memory 面板可以查看
SharedArrayBuffer的分配情况。要直观感受其性能优势，可以使用console.time()进行对比测试：传输一个几百 MB 的数组，使用SharedArrayBuffer与使用普通postMessage的耗时差异将非常显著，充分体现零拷贝共享的价值。
