Go map 加锁保护时读方法为什么也要使用同一把锁

如果一个结构体同时保存 map 和 sync.Mutex，读方法也必须使用保护这张 map 的同一个锁。最容易踩坑的写法是把方法接收者写成值：每次调用都会复制 wrapper，map 字段仍指向同一份底层数据，但 mutex 已经变成另一份副本。这样读写方法看似都调用了 Lock，实际却没有互斥。

先分清 map 引用复制和 mutex 锁复制

看下面这个故意有问题的例子：

package main

import "sync"

type Cache struct {
	mu sync.Mutex // 保护 data 的读写
	data map[string]string
}

func (c Cache) Set(key, value string) {
	c.mu.Lock()         // 锁住的是值接收者 c 的副本
	defer c.mu.Unlock() // 解锁同一个副本，语法上没有问题
	c.data[key] = value // data 仍指向原来的底层 map
}

func (c Cache) Get(key string) (string, bool) {
	c.mu.Lock()         // 读方法也加锁，但锁可能是另一份副本
	defer c.mu.Unlock()
	value, ok := c.data[key]
	return value, ok
}

调用 cache.Set 或 cache.Get 时，值接收者会复制 Cache。复制后的 data 仍然指向同一个 map，所以写入似乎“生效”；而 mu 是结构体字段，会随 wrapper 一起复制。两个 goroutine 可能分别拿到不同的 mutex，最终在同一张 map 上并发操作。

这也是“map 像引用”不能推广到所有字段的原因。Go 规范描述的是 map 值包含对底层数据的引用，不是说包含 map 的结构体会按引用传递。sync 包中的同步对象在首次使用后也不应复制。

用指针接收者让读写方法锁住同一对象

修复重点不是“给读方法额外加一行 Lock”，而是让方法操作同一个 Cache 实例：

type Cache struct {
	mu   sync.Mutex
	data map[string]string
}

func NewCache() *Cache {
	return &Cache{data: make(map[string]string)} // 返回可共享的单一对象
}

func (c *Cache) Set(key, value string) {
	c.mu.Lock()         // 读写方法都访问 c.mu
	defer c.mu.Unlock() // 即使中途 return，也能释放同一把锁
	c.data[key] = value
}

func (c *Cache) Get(key string) (string, bool) {
	c.mu.Lock()         // 只要可能与 Set 并发，就不能省略保护
	defer c.mu.Unlock()
	value, ok := c.data[key]
	return value, ok
}

这里的 *Cache 让编译器把方法绑定到原对象，c.mu 只有一份。调用方也应避免复制已经使用过的 Cache，例如不要把它按值放进返回值、参数或另一个结构体中。

如果读操作很多，可以把锁换成 sync.RWMutex，但协议必须整体一致：

type Cache struct {
	mu   sync.RWMutex
	data map[string]string
}

func (c *Cache) Get(key string) (string, bool) {
	c.mu.RLock()         // 允许多个读者并发进入
	defer c.mu.RUnlock() // 与 RLock 成对出现
	value, ok := c.data[key]
	return value, ok
}

func (c *Cache) Set(key, value string) {
	c.mu.Lock()         // 写入仍需要排斥读者和其他写者
	defer c.mu.Unlock()
	c.data[key] = value
}

RWMutex 不是“读方法可以不用锁”，而是把读锁和写锁纳入同一个同步对象。若 Get 使用 RLock，Set 就要使用同一个 wrapper 里的 Lock；不要在读方法里新建锁，也不要让某个方法退回到无锁访问。

选择 Mutex 或 RWMutex 的一致协议

这不是单纯的性能竞赛，先看临界区。若读写都很短，sync.Mutex 更容易审查；只有在读操作确实占比高、且读之间不需要互相排斥时，才考虑 sync.RWMutex。无论选哪一个，锁的所有权都应属于 wrapper，而不是散落在调用方。

最后一行很重要：即使每个单独方法都加锁，if !exists { Set(...) } 仍可能被两个调用者同时执行。需要“读取并决定是否写入”时，应在 wrapper 内提供一个完成整个复合动作的方法，让检查和修改使用同一次加锁。

用检查清单排除复制和解锁误区

1. 查看所有方法签名：包含 sync.Mutex 或 sync.RWMutex 的类型，优先统一使用指针接收者。
2. 搜索复制路径：不要按值传递已使用的 wrapper，也不要把它赋值给另一个同类型变量后继续并发使用。
3. 检查锁配对：Lock/Unlock、RLock/RUnlock 必须在同一个对象上成对出现，推荐用 defer 收口。
4. 用 go vet 看复制锁提示，再用 go test -race ./... 检查真实并发路径；竞态检测通过也不能替代对 API 复合操作边界的审查。

go vet ./...                 # 检查可疑的复制锁等静态问题
go test -race ./...          # 运行测试并报告数据竞争

如果类型只负责保存一个 map、没有额外状态，也可以重新评估是否需要自定义 wrapper；但一旦 wrapper 同时维护计数、过期时间或复合状态，统一封装锁通常比要求每个调用者自行加锁更稳妥。

Go map 加锁保护时读方法常见问题

只读方法为什么也会触发并发问题？

单纯的并发只读在没有写入时通常可以工作，但只要另一条 goroutine 可能同时修改 map，读操作也必须被同一同步协议保护。

把 mutex 改成指针字段能解决复制吗？

不建议把解决方案建立在指向 mutex 的额外指针上。更直接的做法是让包含锁的 wrapper 使用指针接收者，并避免复制整个 wrapper，结构和生命周期更清楚。

Get 和 Set 都加锁了，为什么还会数据竞争？

最常见原因是 value receiver 复制了锁，或者还有一条路径直接访问内部 map。应检查方法签名、字段是否暴露以及所有访问路径是否使用同一个对象。

什么时候可以不加锁读 map？

只有在 map 已经完成初始化并且之后不再有任何写入时，才适合以只读状态共享；只要存在并发更新，就应继续使用锁或其他同步机制。