RWMutex 一定比 Mutex 快吗，怎样根据临界区做选择

不一定。sync.RWMutex 只有在读操作明显多于写操作、读临界区足够长、并且多个 goroutine 确实会同时竞争同一把锁时，才可能比 sync.Mutex 更合适。若临界区很短、写入不少，读写锁额外的读者计数与等待协调反而可能让它更慢。

先把选择条件说清楚

Mutex 的语义简单：同一时刻只允许一个持有者进入临界区。RWMutex 则允许多个读者同时进入，但写者必须独占。这里的“读”不是函数名里出现了 Get 就算读，而是这段代码是否只观察共享状态、不会修改它。

用一个并发配置缓存看临界区

下面的缓存把“查值”和“更新值”分开。读路径只复制字符串，避免把锁带到调用方；写路径在锁内替换一个键的值。示例使用 RWMutex，改成 Mutex 时只需要把两个读锁方法换成普通锁方法。

package configcache

import "sync"

type Cache struct {
	mu   sync.RWMutex // 保护 items，读多写少时允许多个读者并行
	items map[string]string
}

func New(items map[string]string) *Cache {
	return &Cache{items: items}
}

func (c *Cache) Get(key string) (string, bool) {
	c.mu.RLock()         // 只观察 map，不修改共享状态
	value, ok := c.items[key]
	c.mu.RUnlock()       // 先释放锁，再把结果交给调用方
	return value, ok
}

func (c *Cache) Set(key, value string) {
	c.mu.Lock()          // 写入必须阻挡读者和其他写者
	c.items[key] = value
	c.mu.Unlock()        // 即使后续逻辑失败，也不要把外部调用放在锁内
}

这个例子最重要的不是把 RLock 换成 Lock，而是明确锁的边界：哈希查找和赋值在锁内，格式化、网络请求、日志拼接等与共享 map 无关的工作放在锁外。真实项目里可以先用 Mutex 写对，再用基准证明是否需要拆成读写锁。

待写者出现后，读锁并不是永远并行

Go 官方文档明确说明：当某个 goroutine 调用 RWMutex.Lock 时，如果当前已有读者，后续的 RLock 会等待，直到这个写者获得并释放锁。这样做是为了让写者最终有机会进入，也意味着“读很多”不等于“所有读请求都能一直并行”。

因此，下面两种写法都不可靠：在持有读锁时再次递归 RLock，或者先 RLock 再直接改成 Lock。读锁不能升级，写锁也不能降级；需要改变访问模式时，应先释放旧锁，再按新的顺序获取，并重新确认共享状态是否仍然满足条件。

用基准验证，而不是凭感觉换锁

可以为同一个缓存写两种实现，固定数据规模和临界区工作量，只改变锁类型、读写比例和并发数。下面的基准模板没有假装给出通用数字，运行者应在目标机器和真实数据形态下记录结果。

func BenchmarkCacheReadMostly(b *testing.B) {
	cache := newCache() // 预先准备数据，避免把初始化时间算进锁性能
	b.SetParallelism(4) // 放大并发竞争；实际项目按服务并发模型调整
	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			if rand.Intn(100) 

比较时至少记录 ns/op、B/op 和 allocs/op，并分别试 50/50、90/10、99/1 三种比例。若 RWMutex 只在极端读多且高竞争场景获胜，就不要为了理论上的并行读把所有小对象都改成它。

上线前的四项检查

1. 确认锁保护的是同一份共享状态，defer Unlock 不要掩盖过大的临界区。
2. 确认读路径没有隐藏写入，例如懒加载、缓存刷新或统计计数。
3. 确认锁对象没有在首次使用后被复制；不要把含锁结构体按值传递。
4. 运行 go test -race ./...，再结合基准和 pprof 判断锁竞争，而不是只看单次耗时。

相关问题

RWMutex 读多写少就一定更快吗？

不一定。还要看临界区长度、CPU 核数、竞争强度、写者到达频率和数据是否能复制。短临界区常常让 Mutex 的简单路径更有优势。

可以在 RLock 里面调用 Lock 吗？

不可以把它当作升级操作。先释放读锁会引入状态变化窗口，直接调用则可能等待自己释放读锁，应该重新设计操作顺序。

什么时候考虑 atomic.Value？

当数据适合整体替换、读路径只需要拿到不可变快照时，可以把它作为对照方案；如果需要原地修改多个字段，仍需明确同步边界。