Go 官方不提供 sync.SpinLock，因其运行时 M:N 调度模型与自旋锁冲突：goroutine 自旋时若被抢占会浪费 CPU 并阻塞其他 goroutine；sync.Mutex 已内置低争用自旋优化，但不暴露纯自旋接口；手动基于 CAS 实现需严格使用 uint32 状态、初始为 0、循环中调用 Gosched 或短暂停顿并设超时 fallback。
为什么 Go 官方不提供 sync.SpinLock
Go 运行时调度器（Goroutine + M:N 调度）天然不适合传统自旋锁：goroutine 在自旋时若被抢占或调度出 CPU，不仅浪费时间，还可能阻塞其他 goroutine。标准库的 sync.Mutex 在争用低时会快速进入自旋（内部已做优化），但不会暴露为用户可控的纯自旋行为。你手动实现 sync/atomic.CompareAndSwapUint32 循环，本质是绕过 runtime 的协作式调度，在高争用或长临界区下极易拖垮整体吞吐。
sync/atomic.CompareAndSwapUint32 是唯一靠谱的原子基元
Go 中实现自旋逻辑必须依赖 CAS，不能用 sync/atomic.AddUint32 或 Store/Load 模拟锁状态——它们无法保证“检查+设置”原子性。状态变量必须是 uint32（CompareAndSwapUint32 只支持该类型），初始值为 0（未锁定），锁定时设为 1。
常见错误现象：
- 用 int32 或 bool 做状态变量 → 编译报错或运行时 panic
- 忘记初始化为 0 → 第一次 CAS 总失败
- 在 for 循环里不加 runtime.Gosched() 或短暂停顿 → 某个 P 长期被占满，其他 goroutine 饿死
实操建议：
- 状态字段定义为
state uint32，别用指针或嵌套结构体（避免误读内存对齐） - 循环内每次 CAS 失败后，加
runtime.Gosched()或time.Sleep(1 * time.Nanosecond)（后者更可控） - 务必配超时机制，比如最多自旋 1000 次后 fallback 到
sync.Mutex或直接阻塞
示例片段：
立即学习“go语言免费学习笔记（深入）”；
for i := 0; i < 1000; i++ {
if atomic.CompareAndSwapUint32(&s.state, 0, 1) {
return
}
runtime.Gosched()
}
// fallback to blocking acquire...
自旋锁只适合极短临界区，且必须控制调用上下文
适用场景非常窄：临界区执行时间稳定在几十纳秒内（如更新一个计数器、翻转一个标志位），且锁争用概率极低（
容易踩的坑：
- 在 HTTP handler 或数据库回调里用自旋锁 → 请求一并发，CPU 瞬间拉满，P99 延迟爆炸
- 把自旋锁当
sync.RWMutex替代品 → 读多写少场景下，CAS 自旋写反而比读锁更重 - 跨 goroutine 生命周期复用同一个自旋锁实例 → 状态残留（如 panic 后未释放）导致永久死锁
- 没考虑 NUMA 架构：跨 socket 自旋会放大 cache line bouncing，性能反不如 mutex
替代方案比手写更可靠
真有低延迟需求，优先考虑：
- 用
sync.Pool减少临界区内存分配 → 间接缩短临界区时间，让默认sync.Mutex自旋更有效 - 把共享状态拆成 per-P 或 per-goroutine 缓存（如用
sync.Map+ 本地 buffer）→ 消除锁争用本身 - 确认是否真的需要锁：很多场景用原子操作（
atomic.AddInt64）或无锁队列（chan配合 select）更合适
手写自旋锁不是“更底层就更高效”，而是把调度责任从 runtime 推给程序员。一旦临界区行为稍有变化，或者部署环境从单核 VM 切到多 NUMA 节点，表现可能天差地别。
