因为 atomic.CompareAndSwapUint32 不记录持有者ID、不支持重入计数，同一线程重复加锁必死锁；它仅比对数值，无法区分“谁设置”，且无退避机制易致CPU空转100%。
为什么不能直接用 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)
}- 不要用
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()
}
}- 上线前务必删掉日志，否则 I/O 会彻底毁掉自旋意义
- 观察
spin值是否稳定在个位数 —— 若常达千级以上，说明竞争严重，该换sync.RWMutex或分段锁 -
go build -gcflags="-m"可确认state字段是否逃逸到堆，影响 CAS 性能（应保持在栈上）
自旋锁的“简单”是假象，真正难的是界定它适用的边界：临界区必须极短、锁持有时间远小于调度延迟、且 goroutine 数不超过 P 数。多数时候，你不是在优化，是在给自己埋调度雷。
