Go 标准库 sync.RWMutex 在解锁时遵循写优先原则：若存在等待写锁的 goroutine，新读请求将被阻塞，确保写操作不会因持续读请求而饿死；唤醒顺序取决于阻塞时间而非随机，先阻塞的写锁 goroutine 总是优先于后阻塞的读锁 goroutine。
go 标准库 `sync.rwmutex` 在解锁时遵循写优先原则：若存在等待写锁的 goroutine，新读请求将被阻塞，确保写操作不会因持续读请求而饿死；唤醒顺序取决于阻塞时间而非随机，先阻塞的写锁 goroutine 总是优先于后阻塞的读锁 goroutine。
在 Go 的 sync.RWMutex 实现中，解锁（Unlock）并不会“随机”唤醒某个等待 goroutine，而是依据一套明确的调度策略：写锁（Lock）具有更高优先级，且唤醒严格遵循 FIFO（先进先出）的阻塞顺序。
关键规则如下：
✅ 写锁饥饿防护机制：一旦有 goroutine 调用 Lock 并进入阻塞状态，RWMutex 会立即拒绝后续所有 RLock() 请求（即使当前无持有写锁），直到该写锁获得并释放。这防止了“读者霸占”导致写者永久等待（writer starvation）。
-
✅ 唤醒顺序确定性：
- 若 goroutine 2（Lock）在 goroutine 3（RLock）之前阻塞 → goroutine 2 必然先被唤醒并获取写锁；
- 若 goroutine 3（RLock）在 goroutine 2（Lock）之前阻塞 → 此时 goroutine 3 可能成功获取读锁（前提是无其他写锁等待），但一旦 goroutine 2 后续调用 Lock 并阻塞，后续 RLock 全部被挂起，且 goroutine 2 将在下一个 Unlock 时优先获得锁。
❌ 不存在随机性：Go 运行时调度器本身不保证 goroutine 唤醒顺序的随机性；RWMutex 内部使用 runtime.Semacquire 和队列管理，其等待队列是有序的，唤醒行为由底层信号量和队列头节点决定。
Golang Uber Dig下载使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
以下代码可验证该行为（简化示意）：
package main
import (
"fmt"
"sync"
"time"
)
func main() {
var mu sync.RWMutex
var wg sync.WaitGroup
// goroutine 1: 持有写锁 2 秒
wg.Add(1)
go func() {
defer wg.Done()
mu.Lock()
fmt.Println("G1: acquired write lock")
time.Sleep(2 * time.Second)
mu.Unlock()
fmt.Println("G1: released write lock")
}()
// goroutine 2: 立即尝试写锁（先阻塞）
wg.Add(1)
go func() {
defer wg.Done()
fmt.Println("G2: waiting for write lock...")
mu.Lock()
fmt.Println("G2: acquired write lock")
mu.Unlock()
}()
// goroutine 3: 稍晚（50ms 后）尝试读锁 → 会被写锁阻塞机制拦截
time.Sleep(50 * time.Millisecond)
wg.Add(1)
go func() {
defer wg.Done()
fmt.Println("G3: waiting for read lock...")
mu.RLock()
fmt.Println("G3: acquired read lock")
mu.RUnlock()
}()
wg.Wait()
}输出典型为：
G1: acquired write lock G2: waiting for write lock... G3: waiting for read lock... G1: released write lock G2: acquired write lock // G3 不会在此时唤醒 —— 因 G2 的写锁仍在排队，RWMutex 阻止新读锁获取
⚠️ 注意事项：
- 不应依赖 RWMutex 的唤醒顺序编写业务逻辑（如假设“读一定先于写”）；
- 高频读写混合场景下，若写操作频繁，可能导致读请求长时间延迟，此时需评估是否改用 sync.Mutex 或更高级并发控制（如分片、CAS）；
- RWMutex 的写优先设计是权衡结果：牺牲部分读吞吐，换取写操作的可预期延迟与公平性。
总之，RWMutex.Unlock() 唤醒的是阻塞队列头部、且符合优先级规则（写 > 读）的第一个 goroutine，其行为可预测、非随机，是 Go 并发原语中兼顾安全与性能的重要设计。
