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

Web Worker 传输 ArrayBuffer 后主线程为什么不能再读取

来源:17golang原创

时间:2026-09-07 20:00:11 364浏览 收藏

Web Worker 传输 ArrayBuffer 后,主线程不能再读取,通常不是 Worker 把数据“清空”了,而是你在 postMessage() 的第二个参数中转移了这块内存的所有权。转移完成后,主线程里的原 ArrayBuffer 会进入 detached 状态,byteLength 变成 0,关联的 Uint8Array 也失去可用的底层存储。

需要两边都继续读,就不要把 buffer 放进 transfer list;只需要把大块数据交给 Worker 处理,则可以转移,但必须把同一个 buffer 同时放进消息体,并在转移前完成主线程的读取。
要点速览
  • 普通结构化克隆会复制数据,转移则把底层内存的所有权交给接收端。
  • postMessage(message, [buffer]) 中的 buffer 仍要出现在 message 内,否则 Worker 没有可读取的字段。
  • 转移后不要继续使用原对象或它创建的视图;要复用数据就改用复制或发送前复制。

先区分复制和转移两种发送方式

下面两段代码的差异只有第二个参数,但语义完全不同。第一段把 ArrayBuffer 作为消息字段发送,结构化克隆会在 Worker 侧得到一份独立副本,主线程仍可读取原对象。

const buffer = new ArrayBuffer(8);
const view = new Uint8Array(buffer);
view[0] = 7;

// 不传 transfer list:Worker 获得副本,主线程仍保留原内存。
worker.postMessage({ buffer });
console.log(buffer.byteLength); // 8

第二段把同一个对象加入 transfer list。发送端对象的 JavaScript 外壳还在,但它不再拥有底层内存:

const buffer = new ArrayBuffer(8);
const view = new Uint8Array(buffer);
view[0] = 7;

// 先把对象放进消息体,再声明转移所有权。
worker.postMessage({ buffer }, [buffer]);
console.log(buffer.byteLength); // 0
// 这里不要再读取 view[0],也不要继续写入 view。
Web Worker 中 ArrayBuffer 在结构化克隆与所有权转移之间的静态关系
图1:复制路径保留主线程内存,转移路径则让 transfer list 把底层 ArrayBuffer 所有权交给 Worker。

为什么原对象还在,却已经不能读取

ArrayBuffer 是持有原始内存的对象,Uint8Array 只是指向这块内存的视图。转移时,浏览器不会再复制一份数据,而是把底层资源从发送端交给接收端。发送端留下的对象因此成为 detached buffer:它的 byteLength 为零,依附其上的视图也不能再访问原来的字节。

这也是“转移”适合大块二进制数据的原因:内存不必完整复制。但它要求代码遵守单一所有者规则。把 buffer 交给 Worker 后,主线程不应再把旧引用放进缓存、日志格式化函数或下一次消息中。

可以用一个小检查判断发送动作是否已经改变所有权,但不要把它当作发送后的业务读取:

function sendOwnedBuffer(worker, buffer) {
  // 发送前先记录大小;转移后只能检查状态,不再读取内容。
  const sizeBefore = buffer.byteLength;
  worker.postMessage({ buffer }, [buffer]);
  const detached = buffer.byteLength === 0;
  return { sizeBefore, detached };
}

消息体和 transfer list 必须指向同一个对象

transfer list 不是额外的消息字段,它只告诉浏览器哪些可转移资源要移动。下面的写法虽然声明了转移,却没有把 buffer 放入消息体,Worker 收到的对象里没有可用数据:

const buffer = new ArrayBuffer(16);

// 错误边界:transfer list 只声明资源,不能代替消息字段。
worker.postMessage({ kind: "parse" }, [buffer]);

正确写法是让 event.data.buffer 取得那块已经转移到 Worker 的内存:

// worker.js
self.onmessage = (event) => {
  // 消息体中的 buffer 是 Worker 当前拥有的资源。
  const buffer = event.data.buffer;
  const bytes = new Uint8Array(buffer);
  self.postMessage({ firstByte: bytes[0], size: buffer.byteLength });
};

// main.js
const buffer = new ArrayBuffer(16);
new Uint8Array(buffer)[0] = 42;
// 同一个对象同时出现在消息体和 transfer list 中。
worker.postMessage({ buffer }, [buffer]);
Web Worker 消息体、transfer list、detached buffer 与接收端 Uint8Array 的静态关系
图2:消息体负责携带字段,transfer list 负责转移所有权,Worker 侧再用 Uint8Array 视图读取同一块内存。

项目中如何选择复制、转移和发送前复制

场景推荐方式主线程发送后能否继续读原 buffer
数据较小,双方都要保留结构化克隆,不传 transfer list可以
大块数据只交给 Worker 解析消息体加 transfer list不可以
Worker 处理后主线程还要保留快照发送前复制一份,再转移副本可以读取原始副本

如果业务既需要低拷贝,又需要主线程留档,可以在发送前创建一个新的 ArrayBuffer,把副本转移给 Worker,原始数据继续由主线程管理。不要等转移后再调用 slice() 试图补救,因为 detached buffer 上的部分方法会直接抛出 TypeError

常见问题

只写 transfer list,Worker 为什么收不到 ArrayBuffer?

因为 transfer list 只声明要转移的资源,不会自动把资源挂到消息对象上。应使用 { buffer } 作为消息体,并把同一个 buffer 放入数组。

转移后 Uint8Array 的 byteLength 为什么也变了?

视图不拥有独立内存,它引用的是原 ArrayBuffer。底层 buffer detached 后,视图自然失去可访问的字节范围。

不用 transfer list 就一定没有性能问题吗?

不是。结构化克隆需要复制数据,大对象可能带来复制成本。是否转移应结合数据大小、所有权和主线程后续用途判断。

可以把已经转移过的 buffer 再发送一次吗?

不应这样做。转移后原对象已经没有底层资源,应该在发送前创建新对象,或让 Worker 把处理结果通过新 buffer 转回。

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