自旋锁不能用sync.mutex替代，因其底层会主动让出p而非纯自旋；真需自旋须用atomic手写，且仅适用于纳秒级临界区、单核/低并发场景，必须配合runtime.pause()退避、严格使用compareandswapint32获取锁、storeint32释放锁，避免竞态与cpu空转。
自旋锁在 Go 里不能直接用 sync.Mutex 替代
Go 的 sync.Mutex 底层不是纯自旋，它会在尝试几次原子操作失败后主动让出 P（进入休眠），避免空转浪费 CPU。真要“自旋等待”，得自己用 atomic 手搓——但必须清楚：这不是为了替代 sync.Mutex，而是极少数场景下对极短临界区 + 高频争抢的微优化。
常见错误现象：for !atomic.CompareAndSwapInt32(&lock, 0, 1) { } 看似简单，实则危险：没有退避逻辑，可能打满单核；没考虑内存序，编译器或 CPU 重排导致可见性问题；更严重的是，一旦锁被持有时间稍长，线程就卡死在循环里，完全失去响应性。
- 必须用
atomic.LoadInt32和atomic.CompareAndSwapInt32配合，且CompareAndSwapInt32的成功路径才表示真正获取到锁 - 每次失败后应插入
runtime.Gosched()或runtime.pause()（Go 1.19+）让出当前 M，避免饿死其他 goroutine - 务必用
atomic.StoreInt32(&lock, 0)释放，不能直接赋值，否则破坏原子语义和内存屏障
为什么 atomic.CompareAndSwapInt32 是唯一安全的尝试入口
CompareAndSwapInt32 是原子读-改-写操作，它天然带 acquire 语义（获取锁时保证后续读写不被重排到它前面），而 StoreInt32 释放锁时需配合 release 语义（Go 的 atomic.StoreInt32 已内置）。如果用 LoadInt32 判断再 StoreInt32 设置，中间存在竞态窗口：两次原子操作之间，锁状态可能已被别人修改，导致双写或漏释放。
典型误用：if atomic.LoadInt32(&lock) == 0 { atomic.StoreInt32(&lock, 1) } —— 这根本不是锁，是条件竞争放大器。
- 只允许用
CompareAndSwapInt32作为“尝试获取”的唯一手段 - 参数顺序固定：
CompareAndSwapInt32(ptr, old, new)，old必须是期望的当前值（通常是 0），new是新值（通常是 1） - 返回
true表示 CAS 成功且已拿到锁；false表示失败，需重试或放弃
自旋锁实际只适合 纳秒级 操作，且仅限单核或低并发
自旋的本质是“用 CPU 时间换上下文切换开销”，只有当预期等待时间远小于一次系统调用（比如 futex 唤醒）的成本时才划算。在现代 Go 程序中，这个窗口通常小于 50–100 纳秒，且只在无抢占、P 绑定、无 GC STW 干扰的硬实时子模块里存在。拿它保护 HTTP handler 或数据库查询？只会让延迟毛刺更剧烈。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
性能影响很直接：开启自旋锁后，pprof 的 cpu profile 里会看到密集的 runtime.fastrand（如果加了退避）或纯空循环；goroutines 数量不变，但 g0 栈使用率飙升。
- 不要在
http.Handler、database/sql回调、或任何含 I/O 或调度点的路径里用 - 若临界区涉及
map读写、chan操作、或任何可能触发 GC 的动作，立刻弃用 - 启用前先用
go tool trace观察真实锁持有时间分布，>1μs 就不该自旋
Go 1.19+ 推荐用 runtime.pause() 而非 Gosched() 做退避
runtime.Gosched() 会让当前 goroutine 让出 M，但可能立刻又被调度器重新绑定，导致“假让出”；而 runtime.pause() 是 x86/amd64 上的 PAUSE 指令封装，专为自旋等待设计：它降低 CPU 功耗、减少分支预测失败、且不会触发调度决策，比 Gosched() 更轻量、更可控。
兼容性注意：该函数在 Go 1.19 引入，低于此版本需 fallback 到 Gosched() 或空循环（不推荐）。
- 写法统一为：
for !atomic.CompareAndSwapInt32(&lock, 0, 1) { runtime.pause() } - 不要在
pause()前加time.Sleep(1 * time.Nanosecond)—— 它会触发系统调用，彻底失去自旋意义 - 若需多级退避（比如失败 10 次后 sleep），仍建议直接切到
sync.Mutex，别硬撑
自旋锁的边界非常窄：它既不是通用同步原语，也不是性能银弹。最容易被忽略的一点是——你写的那段 for { CAS; pause } 代码，很可能正在把一个本可并行的程序，悄悄变成单核瓶颈。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
