当多个 goroutine 因争抢 RWMutex 而阻塞时，Unlock() 唤醒的 goroutine 并非随机——写锁（Lock）请求具有调度优先级，会阻断后续新读锁请求，并确保已排队的写锁先于读锁获得锁。
当多个 goroutine 因争抢 rwmutex 而阻塞时，`unlock()` 唤醒的 goroutine 并非随机——写锁（`lock`）请求具有调度优先级，会阻断后续新读锁请求，并确保已排队的写锁先于读锁获得锁。
在 Go 的 sync.RWMutex 实现中，写锁（Lock）享有饥饿保护机制：一旦有 goroutine 调用 Lock 并阻塞，RWMutex 会进入“写优先”模式——此后所有新发起的 RLock() 请求将被挂起，直到当前阻塞的 Lock() 请求被满足并完成。该行为由内部字段 writerSem 和读写等待队列的协同控制实现，目的是防止写操作被大量并发读无限期延迟（即避免写饥饿）。
回到你的示例：
var mu sync.RWMutex
// goroutine 1: 持有写锁
go func() {
mu.Lock()
defer mu.Unlock()
// ...
}()
// goroutine 2: 尝试获取写锁 → 阻塞（入 writerWaiter 队列）
go func() {
mu.Lock() // ⚠️ 先于 goroutine 3/4 阻塞
defer mu.Unlock()
}()
// goroutine 3 & 4: 尝试获取读锁
go func() {
mu.RLock() // ❓ 若此时 goroutine 2 已阻塞，则此调用会被延迟（不立即入 readerWaiter）
defer mu.RUnlock()
}()
go func() {
mu.RLock()
defer mu.RUnlock()
}()关键结论如下：
- ✅ 唤醒顺序确定性前提：若 goroutine 2 的 mu.Lock() 在 goroutine 3/4 的 mu.RLock() 之前完成阻塞（即更早到达临界点并排队），则 goroutine 1 调用 Unlock() 后，goroutine 2 必然被第一个唤醒，执行写操作；之后才轮到所有等待的读 goroutine（按 FIFO 顺序）批量唤醒。
- ⚠️ 顺序未定义的情形：若 goroutine 3 的 RLock() 在 goroutine 2 的 Lock() 完成阻塞前已成功获取锁（例如 goroutine 1 尚未释放、而 goroutine 3 抢先进入且无写等待），则调度行为依赖运行时 goroutine 唤醒时机，Go 不保证具体顺序——但只要存在已排队的 Lock()，后续 RLock() 就不会插队。
- ? 注意：RWMutex 不提供公平锁语义（如严格 FIFO 全局队列），其“写优先”是通过逻辑门控（rwmutex.writerSem 信号量 + rwmutex.readerCount 状态协同）实现的轻量级饥饿防护，而非绝对时间序保证。
✅ 最佳实践建议：
- 若业务对读写响应时序敏感（如强一致性缓存更新），应避免依赖唤醒顺序，改用显式同步原语（如 sync.Mutex + 条件变量）或更高层抽象（如 errgroup + channel 控制流）；
- 读多写少场景下，RWMutex 仍是最优选择；但若写操作频繁，应评估是否需重构为分片锁或使用 sync.Map 等无锁结构。
总之：不是随机，而是写锁优先、读锁让行；唤醒顺序由阻塞发生的相对时间决定，Go 运行时保障该策略的一致性，但不承诺跨平台/跨版本的绝对 FIFO 可重现性。
