sync.Mutex根据等待超时（≥1ms）且有goroutine阻塞在sema上自动切换至饥饿模式，否则为正常模式；无法手动控制，仅能通过优化临界区缩短锁持有时间来缓解。
sync.Mutex 是怎么决定用正常模式还是饥饿模式的
Go 的 sync.Mutex 在内部会根据等待者的行为自动切换两种模式：正常模式（Normal）和饥饿模式（Starvation）。它不是靠配置开关，而是运行时根据锁的竞争情况动态判断——核心依据是：是否有 goroutine 等待超过 1ms，且等待队列里至少有 1 个 goroutine。
具体逻辑在 mutex.lockSlow 中：当发现当前 goroutine 等待时间 ≥ 1ms，且 mutex.sema 上已有其他 goroutine 阻塞（即信号量已被争抢），就触发切换到饥饿模式。这个 1ms 是硬编码的阈值（starvationThresholdNs = 1e6），不可调。
- 正常模式下，新来的 goroutine 会尝试直接抢占（CAS 获取锁），失败才入队；刚释放锁的 goroutine 也可能把锁“让”给队首，但不保证
- 饥饿模式下，锁释放后**必须**交给等待队列头的 goroutine，新来的 goroutine 不得插队，也不允许自旋，全部老老实实排队
- 一旦进入饥饿模式，只有当队列空了（最后一个等待者拿到锁并退出等待），才会切回正常模式
为什么有时候看到 Lock/Unlock 变慢，怀疑是饥饿模式导致的
饥饿模式本身不是性能问题，而是对公平性的补救；但它会暴露底层调度或锁竞争的真实压力。如果你观察到 mutex.Lock 平均耗时明显上升（比如从几十纳秒跳到几微秒以上），且 go tool trace 显示大量 goroutine 在 sync runtime_SemacquireMutex 处阻塞，那大概率已进入饥饿模式。
- 饥饿模式下每次解锁都要唤醒队首 goroutine，涉及调度器介入、上下文切换，开销比正常模式下的 CAS 自旋高一个数量级
- 如果锁持有时间长（比如在临界区做了 I/O 或复杂计算），会加剧队列堆积，进一步固化饥饿状态
-
runtime.SetMutexProfileFraction(1)后查/debug/pprof/mutex能看到锁竞争次数，但无法直接区分模式；需结合 trace 或源码断点确认
能手动控制 sync.Mutex 进入或退出饥饿模式吗
不能。Go 标准库没有暴露任何接口用于干预 sync.Mutex 的模式切换逻辑。所有行为都是运行时自动完成的，包括：何时判定饥饿、何时恢复、如何管理等待队列。
- 试图通过频繁调用
Lock/Unlock“刷掉”饥饿状态无效——只要还有 goroutine 在等，且上次等待超时，下次仍会触发 - 不要用
unsafe或反射去修改mutex.state字段：该字段布局未文档化，且 Go 1.22+ 已调整位域定义，极易崩溃 - 真正可控的是你的使用方式：缩短临界区、避免在锁内做网络/磁盘操作、用读写锁（
sync.RWMutex）替代纯互斥锁
饥饿模式下 WaitGroup 或 channel 会受影响吗
不会。饥饿模式只影响 sync.Mutex 和 sync.RWMutex（后者底层复用 mutex 的饥饿逻辑）的实现细节，与 sync.WaitGroup、channel、atomic 等机制完全无关。
-
WaitGroup基于原子计数 + 信号量，无队列概念，也无“等待超时”判定逻辑 -
channel的阻塞由 goroutine 状态机和 runtime 的 goroutine 队列管理，其公平性策略独立于 mutex - 混淆点常来自 trace 中都出现 “semacquire”：那是 runtime 底层信号量原语，不同上层结构共用同一套基元，但语义和调度逻辑各自实现
真正需要警惕的是：当多个组件（比如 HTTP handler + 日志 Mutex + DB 连接池）共同导致 goroutine 大量阻塞时，mutex 饥饿只是表象，根源往往在资源瓶颈或设计耦合。盯着模式切换不如先看 pprof 的 block profile 和 trace 的 goroutine wall duration。
