登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  前端

Web Worker用 Transferable 转移二进制数据的实现方法

来源:17golang原创

时间:2026-09-20 01:11:43 249浏览 收藏

处理文件切片、音频帧或大块二进制数据时,直接调用 postMessage 可能触发结构化克隆。需要把 ArrayBuffer 放进消息,同时把同一个 buffer 放入第二个参数的 transfer 列表:接收方获得内存所有权,发送方的原对象进入 detached 状态。这样可以减少一次大块内存复制,但也意味着发送方不能再继续使用它。

要点速览
  • 转移对象必须既能从消息中到达接收方,又出现在 transfer 列表中。
  • ArrayBuffer 转移后,发送端通常可通过 byteLength === 0 观察到已失去所有权。
  • TypedArray 本身不是 Transferable;真正转移的是它的 buffer,转移后视图也不能继续读写。

先区分结构化克隆与 Transferable 转移

结构化克隆会在另一侧建立一份数据副本,原对象仍可使用;Transferable 则把资源所有权交给目标上下文。对 ArrayBuffer 来说,后者更适合大块数据,但必须接受“同一时刻只有一侧能使用”的约束。

方式发送端状态适用场景
普通 postMessage保留原数据,接收侧得到副本小消息、发送后还要继续读取
postMessage + transfer原 ArrayBuffer 被 detach大块二进制、单向交接所有权
SharedArrayBuffer多个上下文共同访问需要共享内存且能处理同步与隔离要求
Web Worker 中 ArrayBuffer 从主线程转移到 Worker 的所有权关系说明图
图1:ArrayBuffer 所有权转移说明图,展示发送前、Worker 接收后和发送端 detached 的关系。

在主线程把 ArrayBuffer 连同所有权交给 Worker

核心写法只有一个原则:消息里要带上 buffer,transfer 列表里也要列出同一个对象。下面的示例把 Uint8Array 的底层内存交给 Worker,发送完成后不再把原视图当作可写缓存。

const worker = new Worker("worker.js", { type: "module" });

// 创建待处理的二进制块,视图只是访问底层 ArrayBuffer 的窗口
const bytes = new Uint8Array(1024 * 1024);
bytes[0] = 42;
const buffer = bytes.buffer;

// 消息引用和 transfer 列表必须指向同一个 ArrayBuffer
worker.postMessage({ kind: "decode", buffer }, [buffer]);

// 转移后发送端失去内存所有权,不能再把 bytes 当作有效缓存复用
console.log(buffer.byteLength); // 通常为 0

这里传入的是 buffer 而不是 bytes 的原因是:TypedArray 是可序列化的视图,但底层 ArrayBuffer 才是可转移资源。如果业务还需要保留原数据,应在发送前显式复制一份,而不是发送后尝试从 detached 视图恢复。

在 Worker 中处理并回传结果

Worker 收到消息后,event.data.buffer 已经属于 Worker,可以创建新的视图进行解析。处理完成后,如果结果仍是一个独立的 ArrayBuffer,可以再次转移回主线程,形成清晰的“主线程交出、Worker 处理、主线程接回”生命周期。

self.onmessage = (event) => {
  const { kind, buffer } = event.data;

  // 先确认消息类型和资源尺寸,避免把无关对象当成二进制输入
  if (kind !== "decode" || !(buffer instanceof ArrayBuffer)) {
    self.postMessage({ kind: "error", message: "invalid transferable payload" });
    return;
  }

  const input = new Uint8Array(buffer);
  const result = new Uint8Array(input.length);

  // 示例处理:复制并做一个可观察的字节变换,实际项目替换为解码逻辑
  for (let i = 0; i 

输入 buffer 在 Worker 内被使用期间仍然有效;当 Worker 把结果 buffer 转回去后,Worker 也不应继续读取 result。如果要让两侧同时访问同一内存,Transferable 并不是正确模型,需要另行评估共享内存与同步机制。

Worker 处理 Uint8Array 后把结果 ArrayBuffer 转回主线程的关系说明图
图2:Worker 结果回传结构图,展示输入视图、处理结果和第二次所有权交接。

围绕 detached 状态设计二进制生命周期

转移不是“复制后再通知对方”,而是所有权交接。因此最好在代码结构上把发送动作当作资源生命周期的分界线。发送前完成校验、切片和元数据整理;发送后只保留任务编号,不保留继续操作该 buffer 的路径。

检查点建议做法错误信号
发送前确认消息引用与 transfer 列表使用同一个 ArrayBuffer接收端没有资源或触发克隆异常
发送后把原视图标记为不可用,必要时记录 byteLengthbyteLength 变为 0,读写视图抛出异常
回传后只使用主线程收到的新 bufferWorker 仍访问已转出的 result

队列场景尤其要注意:不要把同一个 buffer 同时交给两个 Worker,也不要在转移后把旧视图放回对象池。更稳妥的做法是让任务对象携带状态,例如 createdtransferredreturned,每次状态变化只允许一次。

常见问题

只把 ArrayBuffer 放进 transfer 列表可以吗?

不可以。transfer 列表只声明哪些资源要转移,资源本身仍要通过消息对象可达,例如 { buffer } 配合 [buffer]

Uint8Array 能直接作为 Transferable 传入吗?

不能把 TypedArray 视图直接放进 transfer 列表。应传递它的 buffer,接收端再按需要建立新的 Uint8Array 视图。

转移后为什么原来的 byteLength 变成 0?

这是发送端已经失去 ArrayBuffer 所有权的表现,不是数据被清空后还能继续使用。需要复用数据时,应在转移前复制,或让 Worker 在处理结束后把结果转回。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>