乐闻世界logo
5月31日 20:28

WebAssembly 多线程怎么做？共享内存和 Worker 有哪些坑？

WebAssembly 多线程在浏览器里主要靠 Web Worker、SharedArrayBuffer 和 Atomics，不是给 wasm 模块加一个开关就能自动并行。主线程负责 UI 和任务分发，Worker 里实例化 wasm 模块，多个 Worker 通过共享内存读写同一块 WebAssembly.Memory。如果使用 Emscripten pthreads 或 Rust rayon，工具链能包掉一部分细节，但浏览器安全头、内存布局和同步成本仍然要自己理解。判断是否值得上多线程时，先看任务能不能切分、计算量够不够大，否则通信和同步开销会比单线程更慢。

追问

WebAssembly 多线程依赖哪些浏览器条件？

共享内存依赖 SharedArrayBuffer，现代浏览器通常要求页面处于 cross-origin isolated 状态。服务端要配置 Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp，否则代码没错也拿不到共享内存能力。踩坑点是第三方脚本、图片或 CDN 资源没带正确响应头，会破坏隔离，线上才突然降级。上线前要检查 crossOriginIsolated，并准备单线程路径。

js
if (!crossOriginIsolated) console.warn('降级到单线程');
const memory = new WebAssembly.Memory({
  initial: 256, maximum: 256, shared: true
});

Worker 和共享内存应该怎么配合？

常见做法是主线程创建 Worker 池，把 wasm 模块和共享内存发给 Worker，每个 Worker 只处理自己的数据区间。共享内存适合大数组、图像块、矩阵分片，能减少 postMessage 复制成本。边界是共享内存不会自动保证一致性，谁写哪段、什么时候读结果、失败后怎么回收，都要约定清楚。任务不要拆太细，几十微秒的计算扔进 Worker，排队和通知成本就可能把收益吃掉。

Atomics 什么时候必须用，什么时候该避免？

多个线程会读写同一个状态位、计数器或队列指针时，就需要 Atomics 保证可见性和顺序。任务队列的 head/tail、完成计数、锁状态都不能用普通赋值糊弄，否则偶发脏数据很难复现。踩坑点是 Atomics.wait 不能在浏览器主线程使用，锁粒度太大也会让并行计算退化成排队。更稳的取舍是按数据分片减少共享写入，只在开始、结束和少量状态同步时使用原子操作。

js
const state = new Int32Array(memory.buffer, 0, 4);
Atomics.add(state, 0, 1);
Atomics.notify(state, 0, 1);

Emscripten pthreads 和 Rust rayon 怎么选？

迁移 C/C++ 项目时，Emscripten pthreads 是最直接的路线，编译时打开 -pthread，并设置 Worker 池大小。它的优势是复用原有线程模型，代价是包体、启动和浏览器部署条件都更重。Rust 侧可以用 wasm-bindgen-rayon 初始化线程池，写法更贴近 Rust 生态，但第三方 crate 是否支持 wasm 多线程要逐个确认。无论选哪条路，都要先用性能面板证明瓶颈在 CPU 计算，而不是网络、DOM 或 JS 与 wasm 的频繁边界调用。

bash
emcc src.c -O3 -pthread -sPTHREAD_POOL_SIZE=4 -o app.js

WebAssembly 多线程适合图像处理、音视频、压缩、科学计算、模型推理这类可切分的 CPU 密集任务。它不适合普通页面交互优化，也不能绕开浏览器安全模型。先确认隔离头、降级方案和内存布局，再决定 Worker 池大小，通常比盲目增加线程数更可靠。

标签：WebAssembly