sync.Mutex 不适合超低延迟场景，因其争用时触发 futex 系统调用进入内核态，上下文切换开销远超用户态自旋，即使仅等待几纳秒。
为什么 sync.Mutex 不适合超低延迟场景
因为 sync.Mutex 在争用时会触发系统调用（如 futex），进入内核态，哪怕只等几纳秒，上下文切换开销也远超用户态自旋。真实业务中，若临界区平均耗时
但要注意：Go 调度器默认不保证 goroutine 在自旋期间不被抢占——这会导致“假长等待”，实际是调度延迟，不是锁本身慢。
- 别在 GC 频繁或 P 数少（
GOMAXPROCS=1）的环境用自旋锁，goroutine 可能被挂起而无法及时释放锁 - 不要用于可能阻塞的操作（如网络 I/O、channel send/recv），否则整个 P 会被卡住
-
runtime.LockOSThread()不解决这个问题，它只绑定 OS 线程，不阻止 goroutine 被调度器抢占
用 atomic.CompareAndSwapUint32 手写最简自旋锁
核心就是用一个 uint32 当锁状态：0 表示空闲，1 表示已锁定。靠原子 CAS 循环尝试获取，失败就 runtime.Gosched() 让出时间片，避免忙等吃满 CPU。
type SpinLock struct {
state uint32
}
func (l *SpinLock) Lock() {
for !atomic.CompareAndSwapUint32(&l.state, 0, 1) {
runtime.Gosched()
}
}
func (l *SpinLock) Unlock() {
atomic.StoreUint32(&l.state, 0)
}
- 必须用
atomic.StoreUint32写解锁，不能用atomic.CompareAndSwapUint32(&l.state, 1, 0)—— 后者在锁已被他人释放时可能失败，导致解锁丢失 - 别加
time.Sleep或runtime.nanosleep做退避：Go 没有用户态高精度 sleep，调用会进内核，失去自旋意义 - 如果临界区可能 panic，记得用
defer l.Unlock()，但要确保Unlock()本身不会 panic（上面实现是安全的）
什么时候该用 sync.Pool 配合自旋锁
当你要频繁分配小对象（如 buffer、request context），又想避免 GC 压力，而这些对象生命周期短、复用率高，此时自旋锁保护 sync.Pool 的本地池（per-P）比全局锁更高效。
立即学习“go语言免费学习笔记（深入）”；
但注意：sync.Pool 本身不是线程安全的——它的 Get/Put 方法内部已用 per-P 缓存+原子操作优化，一般不需要外层再套自旋锁；只有当你在 Pool.New 函数里做共享资源初始化（比如打开一个共用 fd），才需要锁。
- 典型误用：给每个
Get()结果加自旋锁保护——对象本就是 per-Goroutine 复用的，没必要 - 正确场景举例：多个 goroutine 共同初始化一个全局
map[string]*bytes.Buffer，用自旋锁保护 map 的首次写入 - 性能影响：自旋锁在这里只在极少数“首次竞争”时生效，之后全是无锁路径，所以收益明显
Go 1.22+ 中 runtime/internal/atomic 的隐蔽风险
有些同学抄了 Go 运行时源码里的 spinLock 实现（比如 runtime.lock），直接调用 runtime.fastrand() 或 runtime.osyield()。这些函数未导出、无 ABI 保证，Go 1.22 已删掉 osyield，替换成更激进的 procyield 指令。
- 后果：代码在 Go 1.21 下能跑，在 1.22+ 直接编译失败（符号找不到）或运行时 panic
- 替代方案：坚持用
runtime.Gosched()，它在所有版本语义稳定；真要 yield CPU，可用runtime.nanosleep(1)，但记住它仍是系统调用 - 兼容性底线：只要不碰
runtime.下未文档化的符号，你的自旋锁就能跨 Go 版本安全运行
真正难的从来不是写个能跑的自旋锁，而是判断「此刻我是否真的需要它」——多数时候，sync.Mutex 的休眠策略已经足够聪明，强行替换反而暴露调度器不可控的一面。
