自旋锁仅适用于几十纳秒级无阻塞临界区，如原子计数器增减或单字段CAS更新；超100ns（如map查找、I/O）即导致CPU浪费，争用率超5%会显著降低吞吐。
自旋锁只适合几十纳秒级临界区
Go 的自旋锁不是“快一点的 Mutex”，而是专为极短、确定、无阻塞的临界区设计的。一旦临界区超过 100ns（比如涉及内存分配、系统调用、网络 I/O、甚至一次 map 查找），自旋就立刻变成 CPU 浪费。
常见错误现象：runtime.Gosched() 调用后仍卡住、P99 延迟毛刺陡增、go tool pprof -cpu 显示大量时间花在 runtime.futex 或空循环里。
- 真正适用的场景只有：原子计数器增减、标志位翻转、单字段结构体更新（如
state uint32）、无锁队列头/尾指针 CAS 更新 - 不适用场景：HTTP handler 中加锁、数据库事务封装、任何含
fmt.Sprintf/json.Marshal/time.Now()的逻辑 - 临界区必须不含 panic 可能；若无法保证，必须用
defer l.Unlock()，且确认Unlock()自身不会 panic（如仅用atomic.StoreUint32）
实测对比：Mutex vs 手写 SpinLock（热路径）
在纯内存、无调度干扰的热路径下（例如高频 ticker 更新一个计数器），SpinLock 确实比 sync.Mutex 快 2–5×，但前提是：争用率低于 1%、P 数量稳定、且无其他 goroutine 饥饿。
示例代码片段（注意状态变量必须是 uint32）：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
type SpinLock struct {
state uint32
}
func (l *SpinLock) Lock() {
for !atomic.CompareAndSwapUint32(&l.state, 0, 1) {
runtime.Pause() // Go 1.22+ 推荐，比 Gosched 更轻
}
}
func (l *SpinLock) Unlock() {
atomic.StoreUint32(&l.state, 0)
}
- 争用率 > 5% 时，
runtime.Pause()循环会迅速吃满一个 P，导致其他 goroutine 调度延迟 - 实测中，若加锁失败后不做退避（如直接空循环），
top显示单核 100%，但吞吐反而下降 30% - sync.Mutex 在低争用下内部也自旋约 4 次，所以差距远不如 C/C++ 明显；手动 SpinLock 的收益集中在「已知零争用 + 极端延迟敏感」场景
为什么不能直接用 sync.Mutex 的自旋逻辑？
sync.Mutex 的自旋是隐藏的、有上限的、且与饥饿模式联动的——它不会让你控制自旋次数或退避策略。你看到的「快速路径」只是运行时自动决策的结果，无法复现或保证。
- 它的自旋只发生在
lockSlow()中，且最多尝试约 4 次，之后必然进等待队列 - 一旦有任意 goroutine 等待超 1ms，Mutex 自动切到饥饿模式，彻底关闭自旋
- 你无法通过配置或参数延长这个行为；想“强制自旋”，只能绕过 Mutex 自己实现，但代价是失去运行时调度协同保障
- 官方不提供
sync.SpinLock正是因为它和 Go 的 M:N 调度模型天然冲突：goroutine 自旋时若被抢占，既浪费 CPU，又可能饿死同 P 上其他任务
容易被忽略的兼容性陷阱
最常踩的坑不在逻辑，而在类型和初始化细节：
- 状态字段必须是
uint32——atomic.CompareAndSwapUint32不接受int32或bool，否则编译失败或 panic - 必须显式初始化为 0：
var lock SpinLock是安全的（零值为 0），但lock := &SpinLock{state: 1}会导致第一次Lock()永远失败 - 不能嵌套在 struct 里再取地址传给 CAS，如
type X struct { mu SpinLock }→&x.mu.state可能因内存对齐导致读写越界（尤其在 CGO 边界） - 别在测试中用
time.Sleep(1)模拟临界区耗时——它会触发系统调用，完全破坏自旋语义；应改用for i := 0; i 这类纯计算延时
真正需要自旋锁的地方极少，多数所谓“热路径”其实该优化的是算法或数据结构，而不是换锁。一旦开始考虑 fallback 到 Mutex 或加超时，说明已经不适合用自旋锁了。
