go 的 sync.mutex 在普通模式下不保证唤醒顺序公平性，因新 goroutine 自旋抢锁成功率高，导致等待者即使排首也可能连续失败；仅当等待超1ms触发饥饿模式时才严格 fifo。
Go 的 sync.Mutex 在高度竞争下默认不保证唤醒顺序公平性，但可通过控制饥饿模式触发条件与避免干扰因素来间接影响实际唤醒行为。
为什么 sync.Mutex 的唤醒顺序不可控
普通模式下，被唤醒的 goroutine 必须和新到达的 goroutine 竞争锁 —— 新 goroutine 占着 CPU，大概率赢；所以即使你排在等待队列头，也可能连续失败、重新插队到队首。这不是 bug，是设计取舍：换来了更低延迟和更高吞吐。只有当某个 goroutine 等待时间超过 1 毫秒，mutex 才自动切到饥饿模式，此时才严格 FIFO 传递锁。
这意味着：Unlock() 时到底唤醒谁，取决于当前是否处于饥饿模式、等待队列长度、以及有没有新 goroutine 正在自旋抢锁。
如何让饥饿模式更早、更稳定地生效
饥饿模式是唯一能强制 FIFO 唤醒的机制，但它不是开关，而是由运行时自动判断。要让它更可靠地介入，需满足以下条件：
- 避免在锁临界区内做耗时操作（如网络调用、大内存拷贝），否则单次持锁时间拉长，导致后续 goroutine 等待更容易超 1ms
- 确保 Goroutine 调度不被长期抢占：比如不要在锁内调用
runtime.Gosched()或阻塞系统调用（如time.Sleep），否则等待者计时器可能误判 - 不要在高竞争路径上频繁创建新 goroutine —— 新 goroutine 到达会打断饥饿模式的“安静交接”，迫使锁退回普通模式
- 如果业务允许，可主动在关键路径加
runtime.LockOSThread()（慎用），减少因 OS 线程切换带来的调度抖动，让等待时间测量更准确
Lock() 自旋对唤醒顺序的实际干扰
自旋只发生在普通模式，且最多 4 次 CAS 尝试。虽然它不直接修改唤醒顺序，但会显著推迟进入等待队列的时间，从而影响“谁先等满 1ms”这个饥饿判定的关键点。
例如：
goroutine A 持锁 800μs → goroutine B/C/D 同时到达 → B 自旋 4 次失败后入队（等待开始计时）→ C 自旋成功抢到锁 → D 紧接着又抢到 → B 实际等待已超 1ms，触发饥饿模式
这时真正被 FIFO 唤醒的是 B，但 C 和 D 已经插队执行了两次。所以自旋越频繁，FIFO 越难生效。
若你观察到唤醒顺序混乱，先检查是否大量 goroutine 在同一时刻密集调用 Lock()，并确认它们是否真正在自旋（可通过 pprof 的 goroutine stack 看是否有大量 lockSlow 中的循环）。
替代方案：不用 sync.Mutex，改用显式队列控制
如果你的场景要求**绝对确定的唤醒顺序**（比如实现一个带优先级的请求分发器），sync.Mutex 不适合。此时应放弃“锁即同步”的思维，改用：
-
chan struct{}实现纯 FIFO 阻塞队列：每个 goroutine 入队后阻塞在 channel 上，由一个中心协程按序转发信号 -
sync.Cond+sync.Mutex+ 切片队列：自己维护等待者列表，Signal()时明确唤醒第一个 - 第三方库如
golang.org/x/sync/semaphore（带上下文取消和排队语义）或自定义带序号的 ticket lock
注意：sync.Cond 的 Signal() 也不保证唤醒顺序，必须配合手动索引管理；而 channel 的 send 操作在有 receiver 时是原子且 FIFO 的 —— 这才是最贴近“可控唤醒”的原语。
真实项目中，绝大多数所谓“唤醒顺序问题”，其实是临界区过长或 goroutine 创建节奏失控导致的，而不是锁本身不够“公平”。先压测定位瓶颈点，再决定要不要绕过 sync.Mutex。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
