如何利用 SharedArrayBuffer 在 Web Worker 之间共享海量原始像素数据缓冲区

本文深入解析了如何在 Web Worker 之间高效共享海量像素数据，明确指出 SharedArrayBuffer 无法直接复用 ImageData.data（因其底层为普通 ArrayBuffer），必须显式创建并严格统一视图类型与字节长度；强调了原子操作（Atomics）的合理使用场景——仅用于轻量控制变量同步，而非高频像素读写，并警示常见错误如类型不匹配导致的像素混乱；同时划清关键边界：SharedArrayBuffer 要求严格的跨域隔离策略（COEP/COOP 响应头），且 Safari 尚不支持，而 Transferable 则更适合一次性零拷贝传输——二者并非替代关系，而是针对“共享内存”与“移动内存”两类根本不同的需求。

SharedArrayBuffer 能否直接传递 ImageData.data？

不能。ImageImageData.data 返回的是 Uint8ClampedArray，底层绑定的是普通 ArrayBuffer，无法跨 Worker 共享。必须显式创建 SharedArrayBuffer，再用 Uint8ClampedArray 或 Uint32Array 等视图包装它——且所有 Worker 必须使用**相同字节长度和相同视图类型**访问同一块内存，否则读写错位。

常见错误现象：RangeError: byte length of source array is not divisible by the element size，或像素颜色完全混乱，本质是主线程与 Worker 对同一段内存用了不同 TypedArray 构造方式。

• 主线程创建：const sab = new SharedArrayBuffer(width * height * 4);
• 主线程视图：const pixels = new Uint32Array(sab);
• Worker 内必须用完全一致的方式：const pixels = new Uint32Array(sab); ——不能用 Uint8Array 去读同一个 sab，除非你手动按字节偏移计算 RGBA 分量

如何安全地在主线程与多个 Worker 间同步像素写入？

SharedArrayBuffer 本身不提供锁，但可配合 Atomics.wait() / Atomics.notify() 实现轻量级协调。典型场景是“一写多读”：主线程生成帧数据后通知所有 Worker 开始处理；或“轮转写入”：多个 Worker 各自负责图像某一块区域，需避免同时写同一行。

性能影响：频繁调用 Atomics.wait() 会阻塞 Worker 线程，不如用 postMessage 传递轻量信号（如帧序号 + 偏移范围），再由 Worker 自行读取对应 sab 区域。真正需要原子操作的，仅限极少数共享控制变量，比如：

• 用 Int32Array(sab, 0, 1) 存一个帧计数器，主线程写完调 Atomics.store()，Worker 用 Atomics.load() 检查是否新帧
• 用 Int32Array(sab, 4, 1) 做状态标志（0=空闲，1=写入中，2=就绪），配合 Atomics.compareExchange() 实现无锁状态切换

Chrome/Firefox 中启用 SharedArrayBuffer 的必要条件

现代浏览器默认禁用 SharedArrayBuffer，除非页面满足跨域隔离（Cross-Origin Isolation）。否则构造时直接抛 ReferenceError: SharedArrayBuffer is not defined。

必须同时满足两个响应头：

• Cross-Origin-Embedder-Policy: require-corp
• Cross-Origin-Opener-Policy: same-origin

本地开发时 file:// 协议或未配 header 的 localhost 服务均无效。可用 http-server -p 8080 --cors 启服务并手动加 header，或改用 localhost:8080 并在 Node/Express 中设置上述 header。Safari 目前仍不支持 SharedArrayBuffer，这点容易被忽略。

替代方案：Transferable 是不是更简单？

如果只是单次、大批量传输像素数据（如 Canvas getImageData() 结果），用 postMessage(data, [data.buffer]) 转移 ArrayBuffer 更快、更安全，无需处理原子性或跨域隔离。但 Transferable 是“移动”而非“共享”：发送后原视图立即失效，无法反复读写。

所以真实选择逻辑很直接：

• 需要**低延迟、高频次、多方向读写同一缓冲区** → 必须用 SharedArrayBuffer + 跨域隔离 + 原子协调
• 只需**一次性把整帧传给 Worker 做离屏处理，再传回结果** → 用 transferable，省事且兼容性好

很多人卡在以为 “SharedArrayBuffer 是 transferable 的升级版”，其实二者解决的是根本不同的问题：一个是共享内存，一个是零拷贝移动内存。

本篇关于《如何利用 SharedArrayBuffer 在 Web Worker 之间共享海量原始像素数据缓冲区》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！