当前位置：首页 > 文章列表 > Golang > Go教程 > Go中atomic.CAS实现自旋锁全解析

Go中atomic.CAS实现自旋锁全解析

2026-05-29 10:21:48 0浏览收藏

本文深入剖析了在 Go 中直接使用 atomic.CompareAndSwapUint32 实现自旋锁的致命缺陷：它不记录持有者 goroutine ID、不支持重入、无退避机制，极易导致同线程死锁或高竞争下 CPU 100% 空转；文章不仅给出了最小可行的非重入自旋锁实现（强调用 runtime.Gosched() 合理退避、StoreUint32 安全解锁及内存屏障必要性），更一针见血地指出——生产环境几乎不该手写自旋锁，因为 sync.Mutex 已智能融合自旋与休眠、具备公平性与饥饿保护，而盲目替换反而会引发调度失衡、goroutine 积压甚至 P 被拖垮；真正的挑战从来不是“怎么写”，而是精准判断“该不该用”：临界区必须极短、竞争极轻、且严格满足调度边界，否则你优化的不是性能，而是埋向系统的深层雷区。

如何在 Go 中利用 atomic.CompareAndSwap 实现自旋锁

为什么不能直接用 `atomic.CompareAndSwapUint32` 实现可重入自旋锁

因为 atomic.CompareAndSwapUint32 本身不记录持有者 goroutine ID，也不支持计数，一旦被同一线程重复加锁，就会死锁——它只认“值是否匹配”，不区分“谁设的”。真实场景里，除非你明确约束单线程调用（比如初始化阶段），否则裸用 CAS 做锁极易陷入无限自旋。

常见错误现象：goroutine 看似卡住、CPU 占用 100%、pprof 显示大量 time.Sleep(0) 或 runtime.futex，本质是多个 goroutine 在争抢同一个 uint32 标志位，而失败方没退避策略，纯忙等。

必须用 uintptr 或 unsafe.Pointer 存储 goroutine ID（通过 gopark 相关运行时符号获取）才能做所有权判断
若只需“一次加锁、一次解锁”，可用 uint32（0 表示未锁，1 表示已锁），但必须配合理性的退避逻辑
CompareAndSwapUint64 和 Uint32 在 32 位系统上行为不同，跨平台需统一用 Uint64 或检查 unsafe.Sizeof(uintptr(0))

如何写一个最小可行的非重入自旋锁

核心是：用 uint32 当锁状态，0 → 1 表示加锁成功，1 → 0 表示解锁；失败时不阻塞，而是循环 + 轻量退避。

type SpinLock struct {
    state uint32
}
<p>func (s *SpinLock) Lock() {
for !atomic.CompareAndSwapUint32(&s.state, 0, 1) {
// 退避：避免总线争抢，给其他 goroutine 让出时间片
runtime.Gosched()
// 或更激进一点：runtime.osyield()（Linux 上映射为 sched_yield）
// 但注意：Go 1.14+ 中 Gosched 已足够，osyield 不再推荐
}
}</p><p>func (s *SpinLock) Unlock() {
atomic.StoreUint32(&s.state, 0)
}</p>

不要用 time.Sleep(1 * time.Nanosecond) —— 它会触发调度器介入，开销远大于 runtime.Gosched()
Unlock() 必须用 StoreUint32，不能用 CompareAndSwapUint32(..., 1, 0)，否则在未加锁时调用会导致意外失败且无提示
该锁不保证内存顺序，若临界区涉及非原子变量读写，需额外加 atomic.Load/Store 或 sync/atomic 的屏障语义（如 atomic.AddUint64(&dummy, 0)）

为什么生产环境几乎不该手写自旋锁

Go 运行时的 sync.Mutex 在轻竞争时就是自旋锁（默认自旋 30 次），且自动降级为休眠锁；它还做了公平性控制、饥饿模式切换、协程队列管理。你手写的版本缺失这些，反而更容易引发调度失衡。

典型误用场景：

在 HTTP handler 中用自旋锁保护 map —— 并发高时 goroutine 积压，Gosched 频繁导致调度器过载
锁内调用 fmt.Println 或任何可能阻塞的函数 —— 自旋锁必须要求临界区绝对不阻塞，否则整个 P 会被拖住
忘记 defer mu.Unlock() 导致 panic 后锁未释放 —— 自旋锁没有 panic 恢复机制，不像 sync.Mutex 可配合 recover 做兜底

如果真要调试或学习 CAS 锁行为，怎么观察它是否生效

最直接方式：用 go tool trace 查看 goroutine 是否长期处于 Runnable 状态，同时 CPU profile 看是否集中在 runtime.futex 或 runtime.osyield；也可以在 Lock() 循环里加计数器和日志（仅调试）：

func (s *SpinLock) Lock() {
    spin := 0
    for !atomic.CompareAndSwapUint32(&s.state, 0, 1) {
        spin++
        if spin&0xff == 0 { // 每 256 次打印一次，避免刷屏
            log.Printf("spin %d times for lock %p", spin, s)
        }
        runtime.Gosched()
    }
}