sync.mutex自旋失败后立即进入阻塞等待，前提是runtime_canspin返回false；该函数要求同时满足：cpu核数>1、当前p本地队列为空、g可抢占，任一不满足即跳过自旋直接阻塞。
sync.mutex 自旋失败后何时进入阻塞等待？
go 的 sync.mutex 不是“要么自旋、要么阻塞”的二选一，而是在加锁失败时先尝试有限自旋，失败后再降级为信号量等待。是否进入阻塞（即所谓“互斥模式”，实际是慢路径的排队等待），取决于三个条件是否**同时不满足**——只要任一条件成立，就跳过自旋，直接走阻塞路径。
-
runtime_canSpin返回 false：这是最核心的判定入口，它检查三项 - CPU 核心数 > 1：单核下自旋无意义（没其他 P 能释放锁）
- 当前 P 的本地运行队列（
runq）为空：若还有待执行的 G，自旋会饿死它们 - 当前 G 已经被调度器标记为“非可抢占”（
g.preemptible == false）：防止自旋期间被强行抢占导致逻辑错乱
为什么自旋只试 4 次？
4 次不是硬编码的魔法数字，而是由 active_spin 常量定义，在 Go 1.21+ 中固定为 4。这不是拍脑袋定的：它在吞吐与公平之间做了权衡。试少于 4 次，可能错过锁刚释放的瞬间；试太多，则浪费 CPU，尤其在高竞争场景下容易推高整体延迟。注意：这 4 次仅发生在 runtime_canSpin 返回 true 的前提下——否则一次都不自旋。
1ms 饥饿阈值和自旋切换无关
常见误解是“自旋超时 1ms 就切阻塞”，其实完全错误。1ms 是判断是否进入**饥饿模式（mutexStarving）** 的阈值，发生在 goroutine 已经排队等待之后，和自旋阶段无关。自旋阶段根本不会计时——它只靠 CAS 循环和固定次数控制。真正开始计时，是在调用 semacquire1 进入信号量等待时才启动的。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操中怎么观察自旋行为？
无法直接观测，但可通过间接方式验证逻辑：
- 在单核 CPU 或
GOMAXPROCS=1环境下压测，go tool trace中几乎看不到自旋相关事件（如ProcStatusGRunning → ProcStatusGRunqueue的快速抖动） - 用
-gcflags="-m"看编译器是否内联了Lock()快速路径（说明编译器认为该调用足够轻量，符合自旋适用场景） - 竞态检测（
go run -race）不会报出自旋问题——它只管内存访问顺序，不管锁内部怎么抢
真正容易被忽略的是：自旋只发生在锁处于 contention 但持有者极可能“马上释放”的乐观预期下；一旦环境不满足（比如单核、P 队列不空），它连一次都不会发生——这时候你看到的“慢”，其实是设计使然，不是 bug。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
