首页 > 文章 > 前端

Web Worker 配合 SharedArrayBuffer 共享高频数据

来源：17golang原创

时间：2026-10-10 14:21:05 301浏览收藏

先判断负载是否真的需要共享内存

Worker 与主线程交换数据有三种常见模型。它们没有绝对优劣，关键是所有权和更新频率。

方案	数据语义	适合负载	主要代价
结构化克隆	接收端得到副本	低频配置、结果对象、控制消息	大对象频繁复制和分配
转移 ArrayBuffer	底层资源移交，发送端缓冲区失效	一批数据只交给一方继续处理	不能由双方同时访问
SharedArrayBuffer	对象各自独立，底层数据块共享	高频数值流、持续生产消费	跨源隔离、并发协议和背压

Worker 结构化克隆、转移 ArrayBuffer 和 SharedArrayBuffer 三种数据交换模型 — 说明图：复制、转移与共享的差别首先是所有权模型，其次才是性能。

一个容易误解的点是：SharedArrayBuffer 不是 transferable。通过 postMessage() 发送后，Worker 会得到新的 SharedArrayBuffer 对象，但它引用的底层共享数据块和主线程相同。任何一方写入后，另一方最终都能看到变化；要建立可靠的先后关系，必须用 Atomics。

跨源隔离是第一条部署约束

浏览器把 SharedArrayBuffer 视为需要额外安全边界的能力。页面通常要同时返回 COOP 和 COEP 响应头，使 crossOriginIsolated 为 true。常见配置如下：

# 将顶层页面放入同源浏览上下文组
add_header Cross-Origin-Opener-Policy "same-origin" always;

# 只允许明确授权的跨源资源进入页面
add_header Cross-Origin-Embedder-Policy "require-corp" always;

require-corp 会影响跨域脚本、图片、字体、iframe 和 Worker 脚本。第三方资源需要正确的 CORS 或 Cross-Origin-Resource-Policy 响应头，否则可能被浏览器阻止。依赖 OAuth、支付弹窗或广告脚本的页面，更应该先评估隔离对 window.opener 和跨域资源的影响。

初始化时不要只判断构造函数是否存在，而要检查隔离状态并准备降级：

// 只有隔离成功时才启用共享内存通道
const canShare = self.crossOriginIsolated &&
  typeof SharedArrayBuffer === "function";

if (!canShare) {
  // 降级为普通消息批处理，避免页面直接崩溃
  console.info("共享内存不可用，改用 postMessage 批处理");
}

共享布局比 API 本身更重要

我更愿意从最简单的单生产者、单消费者模型开始：Worker 只写，主线程只读。共享区分成两部分：

控制区使用 Int32Array，保存 writeIndex、readIndex 和丢弃计数。
数据区使用 Float64Array，保存循环复用的数值样本。
索引通过 Atomics.load/store/add 访问，样本槽位只由其当前所有者读写。
缓冲区满时不覆盖未读数据，而是增加 dropped 计数。

SharedArrayBuffer 控制区和环形数据区的静态关系 — 结构图：原子索引建立发布与消费边界，Float64 数据槽循环复用。

下面把控制区固定为 16 字节，使 Float64 数据区从 16 字节偏移开始，保持 8 字节对齐：

// main.js：创建共享区并把同一数据块交给 Worker
const CAPACITY = 1024;
const CONTROL_BYTES = 16;
const sab = new SharedArrayBuffer(
  CONTROL_BYTES + CAPACITY * Float64Array.BYTES_PER_ELEMENT,
);

const control = new Int32Array(sab, 0, 4);
const samples = new Float64Array(sab, CONTROL_BYTES, CAPACITY);
const worker = new Worker(new URL("./producer.js", import.meta.url), {
  type: "module",
});

// SharedArrayBuffer 不放入 transfer 列表，双方继续共享底层数据块
worker.postMessage({ sab, capacity: CAPACITY, controlBytes: CONTROL_BYTES });

function consumeFrame() {
  let read = Atomics.load(control, 1);
  const write = Atomics.load(control, 0);

  // 只消费已由 Worker 发布的槽位，避免读到半写入样本
  while (read !== write) {
    drawSample(samples[read]);
    read = (read + 1) % CAPACITY;
  }

  // 发布新的读位置，让生产者知道哪些槽位可以复用
  Atomics.store(control, 1, read);
  requestAnimationFrame(consumeFrame);
}

requestAnimationFrame(consumeFrame);

Worker 写入时明确过载策略

Worker 写样本时先计算下一个写位置。如果它追上 readIndex，说明环形缓冲区已满。实时图表通常更关心主线程保持响应，因此我选择丢弃新样本并记数；遥测归档则可能要改成扩大批次、落盘或让生产者等待。

// producer.js：Worker 是唯一生产者，避免多个写方争抢同一槽位
self.onmessage = ({ data }) => {
  const { sab, capacity, controlBytes } = data;
  const control = new Int32Array(sab, 0, 4);
  const samples = new Float64Array(sab, controlBytes, capacity);

  setInterval(() => {
    const write = Atomics.load(control, 0);
    const read = Atomics.load(control, 1);
    const next = (write + 1) % capacity;

    if (next === read) {
      // 缓冲区满时记录丢弃数，不覆盖主线程尚未读取的数据
      Atomics.add(control, 2, 1);
      return;
    }

    // 先写数据，再用原子 store 发布新索引
    samples[write] = collectSample();
    Atomics.store(control, 0, next);
  }, 2);
};

这个例子故意没有在主线程使用 Atomics.wait()。多数浏览器不允许在主线程阻塞等待，而且即使允许，阻塞 UI 也违背使用 Worker 的初衷。主线程按动画帧消费即可；如果消费者也在 Worker 中，可以再评估 Atomics.wait()、notify() 或 waitAsync()。