sync.Mutex饥饿模式触发的等待时间阈值是1毫秒，即当goroutine阻塞等待超1ms且锁释放时，直接唤醒队首goroutine并启用饥饿模式，该阈值硬编码为starvationThresholdNs = 1e6纳秒，不可配置。
sync.Mutex 饥饿模式触发的等待时间阈值是 1 毫秒
go 运行时对 sync.mutex 的饥饿模式（starvation mode）切换有明确的硬编码阈值：当一个 goroutine 在互斥锁上**阻塞等待超过 1 毫秒**，且此时锁恰好被释放，该 goroutine 就会“唤醒并抢占”锁，同时促使 mutex 进入饥饿模式。
这个 1ms 是写死在 runtime/sema.go 中的常量 starvationThresholdNs = 1e6（即 1,000,000 纳秒），不是可配置项，也不随系统负载或调度延迟动态调整。
- 仅适用于已进入排队队列（即调用
semacquire1）且尚未被唤醒的 goroutine - 只在锁释放时检查：若发现队首 goroutine 等待 ≥1ms，就跳过正常唤醒逻辑，直接把锁交给它，并设置
mutexStarving标志位 - 饥饿模式一旦开启，后续所有新来的 goroutine 都不会尝试自旋或抢锁，而是直接排队，直到队列清空才退出饥饿模式
为什么是 1 毫秒？这不是太短了吗
1ms 看似很短，但它的设计目标不是“避免任何等待”，而是快速识别出“大概率已发生调度延迟”的场景。在 Go 调度器下，goroutine 被唤醒后通常能在微秒级完成上下文切换；如果等了 1ms 还没拿到锁，说明：
- 当前持有锁的 goroutine 可能被抢占、陷入系统调用，或正在执行长耗时操作
- 继续让新 goroutine 自旋抢锁只会浪费 CPU，还可能加剧尾延迟
- 此时优先保障公平性（FIFO）比吞吐更重要——这也是饥饿模式的核心动机
注意：这个阈值和 GOMAXPROCS、GC 停顿、网络 I/O 等无关，它只反映该 goroutine 在信号量队列里的挂起时长。
如何验证你的 Mutex 是否进入了饥饿模式
Go 标准库不暴露 mutexStarving 字段，也无法通过反射安全读取（结构体字段未导出且含 noescape）。但你可以间接观察行为：
- 用
go tool trace查看锁竞争事件：饥饿模式下，SyncMutexLock事件的“wait duration”会明显拉长，且后续锁获取几乎无自旋痕迹 - 在高争用压测中对比吞吐与 p99 延迟：启用饥饿模式后，吞吐可能略降，但长尾延迟（如 >5ms 的锁等待）会显著收敛
- 查看
runtime/mutex.go中mutex.lockSlow的汇编或调试日志（需编译带 debug info 的 runtime）——但生产环境不推荐
饥饿模式不是性能问题，而是保护机制
看到 “starving=true” 日志（比如某些监控 hook 或自研锁包装器打出的）不用 panic。它说明 Mutex 正在按设计工作：用一点吞吐换确定性延迟。真正要警惕的是：
- 大量 goroutine 长期卡在
semacquire1，且平均等待远超 1ms（比如持续 10ms+）——这往往指向锁持有者执行过久（如未分片的大 map 遍历、同步阻塞 I/O） - 饥饿模式频繁启停（每秒切换数次）——说明争用模式剧烈震荡，可能是临界区大小不稳定或存在隐式锁升级
- 误以为关闭饥饿模式能提升性能，于是用
unsafe强制清除标志位——这会破坏 FIFO 保证，可能引发活锁或不可预测的调度倾斜
1ms 阈值背后没有魔法，只有对调度现实的妥协。它不解决锁设计问题，只防止最坏情况恶化。
