SharedArrayBuffer 与 Atomics.add 实现高效计数

本文深入解析了如何利用 SharedArrayBuffer 与 Atomics.add 实现高效、线程安全的多 Worker 并发计数——无需锁机制、零内存拷贝、无中间协调，所有 Worker 直接对同一块共享内存执行原子加法，完美适用于高并发实时统计场景（如请求计数、点击追踪）；同时详述了共享内存的正确创建与转移、原子操作的必要性、结果读取的可靠性保障，以及跨域隔离、运行环境配置和类型一致性等关键实践陷阱，为开发者提供了一套开箱即用、稳定可靠的高性能并发计数方案。

用 SharedArrayBuffer 配合 Atomics.add 实现多 Worker 计数，核心是让所有 Worker 操作同一块内存里的整数，并靠原子加法避免覆盖。它不需要锁、不依赖主进程中转，天然适合高并发累加场景（比如请求计数、实时点击统计）。

共享内存的创建与分发

主线程创建一块固定大小的 SharedArrayBuffer（例如 4 字节），再用 Int32Array 绑定为可操作视图：

• 缓冲区长度必须是整数，推荐 4 的倍数；计数器只需 4 字节，所以 new SharedArrayBuffer(4) 就够
• 必须通过 postMessage(buffer, [buffer]) 的 transfer list 显式传递，否则 Worker 收到的是 null 或拷贝，起不到共享作用
• Worker 接收后，要用相同类型视图重建访问入口：const view = new Int32Array(msg.data)，类型和长度需严格一致

用 Atomics.add 替代普通递增

每个 Worker 在循环中执行计数时，不能写 view[0]++ 或 view[0] += 1 —— 这些是非原子操作，会引发竞态，导致最终值小于预期。

• 正确写法是 Atomics.add(view, 0, 1)：它把“读取旧值→加1→写回→返回旧值”整个过程打包成不可分割的操作
• 该调用天然线程安全，多个 Worker 同时执行不会丢失任何一次加法
• 不需要初始化锁变量、也不用轮询等待，零额外开销

读取最终结果的时机与方式

所有 Worker 完成任务后，主线程才能读取准确总数。直接访问 view[0] 不可靠，必须用 Atomics.load：

• Atomics.load(view, 0) 确保读取的是最新写入且对所有线程可见的值
• 如果想在 Worker 运行中动态查看，可由某个 Worker 定期调用 Atomics.load 并 postMessage 回主线程（注意这只是只读观察，不影响计数逻辑）
• 无需 notify/wait 协作，因为累加本身无依赖顺序，纯并行即可

常见陷阱与规避方法

看似简单，但几个细节出错就会导致计数异常或报错：

• 浏览器环境必须启用跨域隔离：服务端响应头需含 Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp
• 本地开发别用 file:// 打开，得跑在 localhost 或 127.0.0.1 上的服务（如 npx serve）
• Node.js 中需启动时加 --experimental-shared-array-buffer 参数（v12+ 支持）
• 别在同一个 SharedArrayBuffer 上混用不同视图（比如主线程用 Int32Array，Worker 用 Float64Array），会破坏数据解释

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。