SharedArrayBuffer 是唯一支持多 Worker 共享内存的机制,但需跨域隔离、transfer 传递、Atomics 同步,否则必现竞态或损坏。
SharedArrayBuffer 是唯一能让多个 Worker 真正共享同一块内存地址的机制,但默认被禁用,且必须配合 Atomics 才能安全读写——不加同步直接读写必然出现竞态或静默数据损坏。
现代浏览器强制要求跨域隔离(Cross-Origin Isolation)才能启用 SharedArrayBuffer,否则构造函数抛出 TypeError: SharedArrayBuffer is not enabled。这不是配置问题,而是安全策略硬限制。
Cross-Origin-Embedder-Policy: require-corp 和 Cross-Origin-Opener-Policy: same-origin
crossorigin 属性,否则加载失败file:// 协议完全不可用,必须走 http:// 或 https://(推荐用 npx serve 或 VS Code Live Server)不能把 SharedArrayBuffer 当普通对象序列化传递,必须通过 postMessage() 的 transfer 机制移交所有权——否则接收端拿到的是空 buffer,且原 Worker 失去访问权。
worker.postMessage({ buffer: sab }, [sab]); —— 第二个参数是 transfer list,sab 必须显式列出onmessage = ({ data }) => { const sab = data.buffer; },此时 sab 可直接用于 Int32Array 等视图SharedArrayBuffer,若需多 Worker 共享,主页面应生成后分别 transfer 给每个 Worker即使有了 SharedArrayBuffer,直接对 Int32Array 索引赋值(如 view[0] = 42)在多线程下不保证原子性,尤其在不同 CPU 核心上运行时,可能读到撕裂值(torn read)或丢失更新。
Atomics.store(view, index, value),读取优先用 Atomics.load(view, index)
Atomics.wait(view, index, expectedValue) + Atomics.notify(view, index, count)
++view[i] 这类复合操作,它等价于读-改-写三步,必须拆成 Atomics.add(view, i, 1)
Atomics.wait() 在非 SharedArrayBuffer 视图上的使用,务必确认视图绑定的是 SAB初始化百 MB 级 SharedArrayBuffer 很快,但后续按需填充、分片管理比一次性全写更可控;结构设计直接影响缓存行竞争和 Atomics 开销。
Int32Array 元素后插入 12 字节空隙,防止 false sharingnew Uint8Array(sab) 做底层搬运,再用 new Float32Array(sab, offset, length) 构建逻辑视图,避免重复分配ArrayBuffer.slice() 分割 SAB——它返回普通 ArrayBuffer,失去共享能力;应统一用偏移量 + 长度构造视图真正麻烦的从来不是怎么创建 SAB,而是确定哪些字段需要原子操作、哪些区域可以无锁只读、以及如何让 notify/wait 的等待逻辑不卡死——这些必须结合具体数据流来设计,没法套模板。