Go语言如何用sync.RWMutex_Go语言读写锁使用教程【实战】-Golang-PHP中文网

sync.RWMutex适用于读多写少场景，如配置缓存、路由表；写频繁时反比Mutex慢；需配对使用RLock/RUnlock，避免死锁与panic，嵌入结构体时必须用指针接收器。

go语言如何用sync.rwmutex_go语言读写锁使用教程【实战】

sync.RWMutex 什么时候该用，而不是 plain sync.Mutex

读多写少的场景下，sync.RWMutex 才有意义；如果写操作频繁（比如每秒几十次以上），它反而比 sync.Mutex 更慢，因为多了读锁计数和唤醒开销。

典型适用场景：配置缓存、路由表、内存索引映射（如 map[string]*User）这类「几乎只读，偶尔更新」的数据结构。

别在单 goroutine 里用 —— 它解决的是并发安全问题，不是线程安全语法糖
别对纯值类型（如 int、string）加读写锁 —— 值拷贝本身是安全的，锁反而拖慢性能
RWMutex 不递归：同一个 goroutine 重复调用 RUnlock() 会 panic，Unlock() 同理

ReadLock 和 WriteLock 的调用顺序和配对规则

RWMutex.RLock() 和 RWMutex.RUnlock() 必须成对出现，且只能在持有读锁的 goroutine 内调用 RUnlock()；RLock() 可以被多个 goroutine 同时调用，但一旦有 goroutine 调用了 Lock()，所有新的 RLock() 会被阻塞，直到写锁释放。

写锁优先级高于读锁：只要有人在等 Lock()，新来的 RLock() 就得排队 —— 这能防饿死，但也可能让读请求堆积
不能在持有读锁时调用 Lock()（会死锁），也不能在持有写锁时调用 RLock()（虽然语法允许，但逻辑错乱）
推荐用 defer mu.RUnlock() 或 defer mu.Unlock()，避免忘记解锁导致整个程序卡住

常见 panic：“sync: RUnlock of unlocked RWMutex” 怎么定位

这个错误通常不是“没加锁”，而是“多解了一次锁”或“在没加锁的上下文中调用了 RUnlock()”。比如把 defer mu.RUnlock() 放在了 if 分支外，但实际只在某个分支里调用了 RLock()。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

检查所有 RUnlock() 是否严格对应一次 RLock()，尤其注意 error early return 路径
不要在循环体里反复 RLock()/RUnlock() —— 锁粒度太细，容易漏配对，也影响性能
用 go build -race 编译运行，race detector 能捕获大部分解锁不匹配和数据竞争

示例错例：

mu.RLock()
if cond {
    return // 忘了 RUnlock！
}
doWork()
mu.RUnlock()

嵌入 RWMutex 到结构体时的零值陷阱

sync.RWMutex 是可直接使用的零值类型，不需要显式初始化；但如果你把它作为结构体字段嵌入，并用指针接收方法操作它，要注意 receiver 是值还是指针。

如果方法签名是 func (s MyStruct) Read() {...}，那 s.mu.RLock() 操作的是 mu 的副本 —— 完全无效，不提供任何保护
必须用指针接收器：func (s *MyStruct) Read() {...}，否则锁根本不起作用
字段名建议用 mu 或 rwmu，避免和业务字段混淆；别叫 lock，容易误以为是 sync.Mutex
嵌入时不用 sync.RWMutex 匿名字段（如 sync.RWMutex），除非你真需要透出全部方法 —— 易误用 Lock() / Unlock() 混淆语义