sync.rwmutex的四个方法必须严格配对：rlock与runlock成对、lock与unlock成对，且两组不可混用；锁不支持升级或降级；仅读多写少场景才具性能优势；值传递会导致锁失效。
sync.RWMutex的四个方法怎么配对用
读写锁不是“加一次锁、解一次锁”那么简单。RLock() 和 RUnlock() 必须成对出现，Lock() 和 Unlock() 也必须成对出现——但这两组**不能混用**。常见错误是：在 RLock() 后调用 Unlock()，或在 Lock() 后调用 RUnlock()，这会直接 panic，报错信息类似 sync: RUnlock of unlocked RWMutex 或 sync: Unlock of unlocked RWMutex。
实际编码中建议始终用 defer 配对：
-
RLock()→defer RUnlock() -
Lock()→defer Unlock()
不要试图省略 defer 或手动控制解锁顺序——哪怕只有一条 return 路径，漏掉一次 RUnlock() 就会让后续所有 RLock() 卡住（因为 readerCount 不归零）。
读锁能升级成写锁吗
不能。Go 的 sync.RWMutex 明确不支持锁升级。下面这段代码会死锁：
rwmu.RLock() // ... 读完发现要改 rwmu.Lock() // 死在这里：当前 goroutine 已持读锁，再请求写锁 → 自己等自己
原因在于：写锁要求所有读锁已释放，而当前 goroutine 持有读锁却还在等待写锁，形成循环依赖。同样，写锁也不能降级为读锁（Unlock() 后再 RLock() 是允许的，但那不是“降级”，而是完全释放后重新获取）。
正确做法只有两种：
- 先
RUnlock()，再Lock()（注意中间可能被其他 goroutine 修改数据） - 干脆一开始就用
Lock()，避免读-写决策延迟
为什么读多写少才值得用 RWMutex
读写锁不是“比 Mutex 更高级”，它只是在特定场景下更高效。它的开销比 sync.Mutex 明显更高：内部维护 readerCount、readerWait、两个信号量（readerSem、writerSem），还要处理写优先策略（有写等待时，新来的读请求会被阻塞）。
所以只有当满足以下条件时，sync.RWMutex 才有优势：
- 读操作占比 > 80%，且单次读逻辑轻量（比如只取一个字段）
- 写操作极少（如配置热更新、缓存淘汰），且写入耗时短
- 实测对比显示并发读吞吐提升明显（别凭感觉，用
go test -bench验证）
如果读写比例接近 1:1，或者写操作本身很重（比如序列化+落盘），用 sync.RWMutex 反而可能因锁管理开销拖慢整体性能。
copy 值传递 RWMutex 会导致什么问题
和 sync.Mutex 一样，sync.RWMutex 是不可复制类型。一旦你把它作为结构体字段或函数参数按值传递，就等于复制了一份锁状态——而原始锁和副本锁完全独立，互不影响。
典型翻车场景：
- 结构体方法接收者用了值类型：
func (d Dictionary) Get() {...}，里面调用d.m.RLock()锁的是副本，对原锁毫无作用 - 把
sync.RWMutex字段直接赋值给另一个变量：mu2 := mu1，之后对mu2加锁完全无效
Go 编译器不会报错，但运行时会出现数据竞争（race detector 会报警）。正确做法永远是传指针：func (d *Dictionary) Get()，或确保锁字段在结构体中以指针形式持有。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
