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

数码系统

相机 win10

测评 win11

手机智车

华为 Tesla

小米理想

苹果蔚来

游戏软件

LOL 抖音

原神微信

当前位置：首页

前端开发

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

热心网友时间：2026-04-17

转载

如何利用 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-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 频繁访问物理上相邻的内存地址（例如位于同一 CPU 缓存行内的多个 int32），即使它们逻辑上无关，也会引发严重的缓存行争用，显著拖慢性能。一个有效的解决办法是在关键字段之间插入“填充字节”，实现 64 字节对齐，隔离缓存行。
调试与验证：Chrome DevTools 的 Memory 面板可以查看 SharedArrayBuffer 的分配情况。要直观感受其性能优势，可以使用 console.time() 进行对比测试：传输一个几百 MB 的数组，使用 SharedArrayBuffer 与使用普通 postMessage 的耗时差异将非常显著，充分体现零拷贝共享的价值。