Go 的 sync.Mutex 饥饿模式由运行时自动触发，非手动配置；当 goroutine 在队列中等待 ≥1ms 时启用，此时禁用自旋、严格 FIFO 调度，Unlock() 直接交锁给队头；退出条件为队列仅剩最后一个等待者或其等待时间不足 1ms。
Go 的 sync.Mutex 不是“可选模式”的锁，它没有暴露 API 让你手动切到饥饿模式；它的两种行为是运行时自动切换的底层策略，不是配置项。你写代码时不需要、也不能显式启用或禁用饥饿模式——它只在锁竞争激烈且等待超时（≥1ms）时由 runtime 暗中触发。
为什么 Lock() 有时快有时慢，还出现顺序异常？
这是正常模式的典型表现：新来的 goroutine 会自旋抢锁，刚被唤醒的 goroutine 反而容易竞争失败，导致它重新排队甚至插到队头（因 state 更新和唤醒时机交错）。这不是 bug，而是设计取舍。
- 自旋只发生在锁即将释放的极短时间内（通常 ≤4 次 CAS 尝试），CPU 利用率低但延迟敏感场景收益明显
- 等待队列确实是 FIFO，但“唤醒后立刻拿到锁”不成立——它要和所有新调用
Lock()的 goroutine 公平竞争 - 如果你观察到某 goroutine 连续多次抢不到锁、等待时间不断累积，它大概率已在下一次
Unlock()时触发饥饿模式切换
饥饿模式真能保证“先到先得”吗？
能，但仅限于已入队的 goroutine。饥饿模式一旦激活，Lock() 的行为就变了：不再自旋，不参与竞争，直接进等待队列尾部；而每次 Unlock() 都会把锁直接交给队头 goroutine，跳过所有新请求。
- 触发条件严格：必须有 goroutine 在队列中等待 ≥1ms（注意：是“在队列中等待”，不是从第一次调用
Lock()开始计时） - 退出条件有两个满足其一即可：
Unlock()时发现当前持有锁的 goroutine 是队列里最后一个，或它本次等待时间 - 饥饿模式下
tryLock()总是返回false，因为新请求一律不许插队
state 字段的 mutexStarving 位到底怎么用？
state 是 int32，其中第 2 位（bit 2）就是 mutexStarving。它不是开关，而是状态快照：runtime 在每次 Unlock() 前检查等待队列头 goroutine 的等待时长，若超阈值，就原子设置该位；下次加锁/解锁流程会据此分支处理。
- 不要尝试用
atomic手动修改它——这会破坏内部状态机，导致死锁或 panic - 调试时可通过
unsafe读取mu.state观察该位是否为 1，但生产环境无意义 - 该位清零时机很关键：不是“锁一释放就清”，而是等到队头 goroutine 成功获取并开始执行后，在它下一次
Unlock()时才可能重置
真正影响性能的从来不是“模式叫什么”，而是你是否让一个 Lock() 持有锁的时间远超 1ms——比如在临界区做 HTTP 调用、磁盘 I/O 或复杂计算。这时候无论模式如何，都会推高尾延迟。饥饿模式只是兜底机制，不是性能优化手段。
