如何利用 SharedArrayBuffer 与 Atomics 实现多 Worker 间高效无锁计数

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《如何利用 SharedArrayBuffer 与 Atomics 实现多 Worker 间高效无锁计数》，聊聊，我们一起来看看吧！

SharedArrayBuffer必须由主进程创建并用transfer list传递给Worker，否则仅复制；须用Int32Array视图配合Atomics原子操作读写，禁用普通赋值；Node.js需启用--experimental-shared-array-buffer标志。

SharedArrayBuffer 必须由主进程创建并分发

Worker 之间无法直接共享内存，SharedArrayBuffer 实例必须在主进程（如 cluster.isMaster）中创建，再通过 worker.postMessage() 传递。如果每个 Worker 自己调用 new SharedArrayBuffer()，得到的是完全独立的内存块，根本达不到“共享”效果。

关键点在于：传递时必须把 buffer 放进 transfer list（第二个参数），否则只是结构化克隆——即复制一份，失去共享意义：

worker.postMessage({ sab }, [sab]); // ✅ 正确：转移所有权
worker.postMessage({ sab });         // ❌ 错误：只传副本

常见错误现象：Atomics.add() 在各 Worker 中看似生效，但主进程读出来仍是初始值，就是因为传的是拷贝。

必须用 Int32Array 视图 + Atomics 原子操作

SharedArrayBuffer 本身不能读写，必须用 Int32Array（或 BigInt64Array）包装成视图；且所有读写都得走 Atomics 方法，普通赋值（如 arr[0] = 1）不是原子的，会引发竞态。

• Atomics.load(arr, 0) 和 Atomics.store(arr, 0, val) 用于安全读写
• Atomics.add(arr, 0, 1) 是无锁递增的标准写法，底层是单条 CPU 指令，天然线程安全
• 别用 arr[0]++ 或 arr[0] += 1 —— 这是“读-改-写”三步，中间可能被其他 Worker 插入

性能影响：Atomics.add() 比普通数组操作略慢，但远快于 IPC 或 Redis 等外部同步方案，适合每秒万级以内的计数场景。

Atomics.wait() / notify() 不适用于计数器，但可用于协调启动

计数器本身不需要阻塞等待，Atomics.wait() 在这里属于过度设计。它只在需要“条件触发”时才有价值，比如等某个标志位变为 1 才开始处理任务。

容易踩的坑：

• 在主线程调用 Atomics.wait() → 直接抛 TypeError: wait not allowed on main thread
• 传入 Float64Array 视图 → RangeError: view is not an Int32Array
• 等待值与当前值不一致 → 函数立刻返回 "not-equal"，不会挂起

所以对纯计数场景，专注用 Atomics.add() 就够了；wait/notify 留给更复杂的协同逻辑（如批量任务分发、屏障同步）。

Node.js 启动需加 --experimental-shared-array-buffer 标志

Node.js 12+ 默认禁用 SharedArrayBuffer，不加标志会报 ReferenceError: SharedArrayBuffer is not defined。

启动命令示例：

node --experimental-shared-array-buffer server.js

注意：该标志仅影响 Node.js 运行时；浏览器端还需满足跨域隔离（Cross-Origin-Embedder-Policy 等响应头），但多 Worker 场景下只需关注 Node.js 侧配置。

容易被忽略的一点：Cluster 模式下，只有主进程需要这个标志；Worker 进程继承主进程的运行时能力，无需单独加——但若 Worker 单独执行（如测试时），也得带上。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~