Swoole中Atomic原子计数器的应用场景

SwooleAtomic 适合做高频整数计数与轻量状态同步，比如请求计数、滑动窗口限流、一次性初始化标记；但别指望它存状态、传结构、做分支判断或持久化。而且原子性只保障单个操作，复合逻辑还得上 Lock 或 Table。

先说清楚：Atomic 就是用来计数的，别妄想拿它存状态、传结构、当判断分支的凭据。它不是万能共享变量，用错地方比加锁还难排查。

请求计数与限流阈值统计

高频写入、只读当前值的场景，Atomic 是最趁手的工具。比如每个 HTTP 请求进来就调一次 incr()，监控程序定时 get() 上报；或者实现滑动窗口限流时，用多个 Atomic 实例分别记录不同时间片的请求数。

• 必须在 onWorkerStart 或主进程里初始化，别让每个 Worker 各自 new 一个
• 别拿 get() 的结果做 if 判断再调 incr() —— 中间有竞态，直接 incr() 并信任返回值就好
• 超过 2^63-1 会溢出回绕，限流逻辑得自己兜底（比如达到阈值后改用 Table 记录详情）

服务启动后的一次性标记

多个 Worker 同时启动时，只允许第一个完成某项初始化（比如加载配置、连接 Redis），其余跳过 —— 这是 cmpset() 的典型用法，不是 set() 或 add() 的。

• 写法必须是 if ($atomic->cmpset(0, 1) === 1) { /* 成功者执行 */ }，不能只看返回真假
• $cmp_value 和 $new_value 都得 ≤ 4294967295，超了会被截断，而且不报错
• 千万别和 get() 组合使用：if ($atomic->get() === 0) { $atomic->cmpset(0, 1); } 是错的，两步之间存在竞争窗口

连接数/任务数等轻量状态同步

当只需要一个数字代表“当前有多少个活跃连接”或“还剩多少任务待处理”，而且不依赖这个数字做复杂决策时，Atomic 比 Table 更快、内存更省。

• 它只支持 int64，不能存字符串、数组、JSON 或浮点数
• 没有 TTL、没有自动清理，进程退出后值就丢失，别把它当持久化存储
• 如果后续要基于这个数查关联数据（比如“谁建立了这第 100 个连接”），说明已经超出 Atomic 的能力边界，该换 Table 或外部存储了

真正容易被忽略的是：Atomic 的「原子性」仅限单个操作本身。一旦你开始写 if (x > y) { z = x + 1; } 这类逻辑，就已经不在它的保障范围内了——这时候要么上 Lock，要么换 Table 加行锁，别硬扛。