Golang中如何编写无锁（Lock-Free）的数据递增函数

### 聊到 Go 的并发编程，`atomic.AddInt64` 绝对算得上是个高频选手。 它在 Go 标准库中的地位，基本上等同于"无锁递增"的标准答案。直接调用 CPU 的 `XADD`（x86）或 `LDADD`（ARM）等硬件原语，不经过操作系统的互斥量，也不会触发 goroutine 阻塞——性能损耗极低。 但实际用起来，容易栽的几个坑得先说清楚。 **第一，它必须接收一个 `int64` 类型的指针**，不能直接对普通变量或 `int` 类型操作。Go 的 `int` 宽度跟平台有关，而 `atomic` 包不提供 `atomic.AddInt` 这样的函数，所以计数器用 `int64` 是最稳当的。 **第二，确保目标变量的生命周期足够长**。全局变量、结构体字段、或者通过 `new(int64)` 分配出来的内存都没问题，但别对局部变量的指针进行操作——生命周期问题比想象中来得更频繁。 **第三，别试图用 `++` 或 `+=` 替代 `atomic.AddInt64`**。这些操作不是原子的，即便变量是指针传递的，在多 goroutine 并发读写下照样会出现竞态。跑一下 `go run -race`，马上就能看到 `race detected` 的恐慌提示。 ```go var counter int64 // 正确：每次 +1 atomic.AddInt64(&counter, 1) // 错误：非原子操作 counter++ // ⚠️ 竞态风险 ```

## 结构体里藏了个原子计数器，怎么对齐才能不出事？ 实际项目里，计数器往往作为结构体的字段存在。这时候问题来了——`atomic` 操作要求目标地址是自然对齐的，比如 `int64` 需要 8 字节对齐。Go 编译器通常会自动处理，但如果字段前面有小尺寸成员（比如 `bool`、`int8`），就很可能破坏对齐。 通用做法是把 `int64` 字段放在结构体最前面，或者用 `_ padding [7]byte` 手动做一下对齐（后者极少用到）。最好不要用 `unsafe.Offsetof` 计算偏移后再取地址传递给 `atomic`，除非你非常清楚自己在做什么，而且测试覆盖足够充分。 ```go type Stats struct { Hits int64 `json:"hits"` // ✅ 放开头，对齐有保障 Name string } s := &Stats{} atomic.AddInt64(&s.Hits, 1) // 安全 ``` ## 什么时候该放下 `atomic`，换成 `sync.Mutex`？ 原子操作不是万能的。它只适用于有限的场景——整数增减、位运算、指针交换这些。一旦逻辑变成"读-改-写"的复合操作，比如"如果值小于 100 才加 1"，`atomic.AddInt64` 就帮不上忙了。 `atomic.CompareAndSwapInt64` 可以用于简单的条件更新，但失败时要手动重试，很容易写出 bug 或者性能反模式（比如漏了循环终止条件）。更麻烦的是，如果递增逻辑还依赖其他字段的状态，比如"用户登录次数 ≤ 3 才允许再登录"，那就必须用 `sync.Mutex` 或 `sync.RWMutex` 保护整个临界区。 值得注意的是，在高竞争场景下（每秒百万级的 CAS 失败），`atomic` 自旋的开销可能高于锁的系统调用开销。这时候 `Mutex` 反而是更稳妥的选择。 ## 别忘了 `atomic` 不提供执行顺序保证 `atomic.AddInt64` 默认提供的是 sequential consistency 内存序，大多数场景够用。但如果你在递增前后还操作其他非原子变量，比如往 map 或切片里写东西，不能假设其他 goroutine 能看到和代码一致的操作顺序。 举个例子：先 `atomic.AddInt64(&counter, 1)`，再 `log.Printf("count=%d", counter)` —— 日志里看到的 `counter` 值可能滞后于实际执行结果。 最好的做法是：所有共享状态的读写都走 `atomic`，或者统一用 `sync.Mutex`，不要混合使用。如果实在需要混合，就用 `atomic.StorePointer` 和 `atomic.LoadPointer` 来显式同步指针引用，而不是依赖代码执行顺序。 无锁不是银弹——它把复杂性从锁争用转移到了内存模型理解和并发逻辑验证上。写完代码，记得跑一遍 `go test -race`，这比想清楚任何事情都更重要。