Golang 中 sync.RWMutex 的写锁抢占与读锁共享机制-Golang-PHP中文网

写锁能立刻阻塞新来的读锁，因为RWMutex用readerCount的正负号标记状态：读时为正值（读协程数），Lock()原子减去rwmutexMaxReaders使其变负，后续RLock检测到负值即阻塞等待。

golang 中 sync.rwmutex 的写锁抢占与读锁共享机制

写锁为什么能立刻阻塞新来的读锁

因为 RWMutex 用 readerCount 的正负号做状态标记：正常读时为正值（当前读协程数），一旦有协程调用 Lock()，就会原子地给 readerCount 减去 rwmutexMaxReaders（即 1 ），使其瞬间变负。后续任何 RLock() 都会先执行 atomic.AddInt32(&rw.readerCount, 1)，结果仍小于 0，于是直接进入 readerSem 等待队列挂起。

这一步不依赖额外标志位，纯靠整数溢出语义实现——既节省内存，又避免 CAS 竞争。但要注意：这个负值不是错误，而是设计好的“写锁已就绪”信号。

多个读锁共存时，写锁如何知道该等谁

readerWait 字段才是关键：当写锁调用 Lock() 时，它先拿到底层 w 互斥锁（防多个写者竞争），再把当前 readerCount 的绝对值（即正在读的 goroutine 数）拷贝到 readerWait。之后每有一个 RUnlock()，就原子减一 readerWait；直到归零，才通过 writerSem 唤醒等待的写者。

这意味着：

写锁不关心具体是哪些读协程，只计数
中途新进的读协程会被 RLock() 拦在 readerSem 外，不影响 readerWait 的倒计时
如果写锁持有期间又有新读请求，它们会排队等 readerSem，而不是加入 readerWait

读优先策略的真实表现与陷阱

Go 的 RWMutex 默认是读优先，但不是无条件的：它只在“没有写者等待”时允许新读锁立即进入；一旦有写者在 writerSem 上排队，后续所有读锁都会被挡在 readerSem 外，直到该写者完成。

这种机制防止了写饥饿，但容易被误读为“完全公平”。实际中常见问题包括：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

高频写场景下，RLock() 可能长时间阻塞，表现像普通 mutex
若写操作本身耗时（比如序列化大结构体），会拖慢所有等待的读请求
无法通过 API 查询当前是否有写者在等，调试时只能靠日志或 pprof 观察阻塞点

RLock 和 Lock 不能混用升级降级

RWMutex 不支持在持有 RLock() 时直接调用 Lock() 升级，也不支持持 Lock() 后调用 RLock() 降级——两者会互相死锁。

例如：

mu.RLock()
// ... 中间想改数据
mu.Lock() // 死锁：自己占着读锁，又想拿写锁

正确做法是先 RUnlock()，再 Lock()，但中间存在竞态窗口。若业务逻辑要求“读-判-写”，应直接上 Lock()，别贪读锁并发。

真正容易被忽略的是：哪怕只是临时想“看看要不要写”，只要用了 RLock()，后面所有升级路径都得重入锁逻辑，没法绕开。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！