RWMutex 解锁时的唤醒顺序：写锁优先与公平性保障-Golang-PHP中文网

RWMutex 解锁时的唤醒顺序：写锁优先与公平性保障

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 阻止新读锁获取

⚠️ 注意事项：