Go 标准库没有 sync.SpinLock，需手动用 atomic.CompareAndSwapInt32 实现；sync.Mutex 已含自适应自旋优化，多数场景应优先使用它而非手写自旋锁。
Go 里没有内置 sync.SpinLock，别直接 import
Go 标准库压根没提供 sync.SpinLock 类型。你搜到的很多“Go 自旋锁实现”，其实是自己用 atomic.CompareAndSwapInt32 或 atomic.LoadInt32/atomic.StoreInt32 手搓的。标准库的 sync.Mutex 在争抢激烈时底层会短暂自旋（约几十纳秒），但不是纯自旋锁——它最终会进系统调度，避免空转耗尽 CPU。
所以，如果你真需要纯用户态自旋（比如内核模块风格、极短临界区、禁用调度的场景），就得自己写；否则，sync.Mutex 或 sync.RWMutex 是更安全、更符合 Go 习惯的选择。
手写自旋锁：用 atomic.CompareAndSwapInt32 控制状态位
核心思路是用一个 int32 变量表示锁状态：0 表示空闲，1 表示已占用。靠 atomic.CompareAndSwapInt32 原子地尝试从 0 改成 1，成功即获得锁。
- 必须用
int32（不能是bool或int），因为atomic包只对固定大小整型提供 CAS 操作 - 获取锁要循环重试，但得加
runtime.Gosched()或runtime.pause()（Go 1.19+）避免死占 P，否则可能饿死其他 goroutine - 释放锁只需
atomic.StoreInt32(&l.state, 0)，无需 CAS——只要确保只有持锁者能调用Unlock - 不支持递归锁，重复
Lock()会导致死锁
type SpinLock struct {
state int32
}
func (l *SpinLock) Lock() {
for !atomic.CompareAndSwapInt32(&l.state, 0, 1) {
runtime.Gosched() // 让出 P，避免完全空转
}
}
func (l *SpinLock) Unlock() {
atomic.StoreInt32(&l.state, 0)
}
什么时候不该用自旋锁？看这三类典型翻车场景
自旋锁在 Go 中属于“高风险高收益”工具，多数业务代码反而更慢、更不稳定。
立即学习“go语言免费学习笔记（深入）”；
- 临界区稍长（> 100ns）：比如涉及内存分配、函数调用、接口方法，自旋期间 CPU 白白空跑，延迟飙升
- goroutine 数远超 OS 线程数（
GOMAXPROCS）：自旋会卡住 P，导致其他 goroutine 长时间得不到调度，表现为整体吞吐骤降 - 运行在容器或云环境（尤其是被限制 CPU 的 cgroup）：自旋会快速触达 CPU 配额上限，被内核 throttle，响应毛刺明显
常见错误现象：pprof 显示大量时间花在 runtime.futex 或 runtime.usleep，但 CPU 使用率却不高——说明你在无效自旋，而系统已在强制限频。
sync.Mutex 的自旋优化是隐式的，别试图绕过它
sync.Mutex 在 Go 1.8+ 中默认开启自适应自旋：当发现锁刚被释放、且当前 goroutine 很可能马上拿到时，会先自旋几十次（非固定次数，取决于竞争历史），失败后再挂起。这个逻辑由 runtime 内部控制，你无法配置或关闭。
- 它和手写自旋锁的关键区别在于：自旋有上限，且一旦失败立即转入 sleep + futex wait，不卡 P
- 参数上无开关，
sync.Mutex就是 Go 官方推荐的“默认正确解”，别为微小性能差异提前优化 - 想观察它的行为？可设置
GODEBUG=mutexprofile=1，然后看go tool trace中的 mutex 事件分布
真正要注意的，不是“怎么写自旋锁”，而是“为什么我的临界区这么慢”——往往问题出在锁内做了不该做的事，比如调用了 fmt.Println、触发了 GC、或访问了未预热的 map。
