Go map concurrent 只读 map 和写入 map 的边界怎么定义

Go 里的普通 map 可以被多个 goroutine 同时读取，但前提是这张 map 已经完成初始化，并且整个并发窗口内没有任何 goroutine 写入它。只要出现赋值、delete、clear 或与写入等价的更新，原来的“只读安全”就不成立；读写之间必须用锁、通道、原子快照或明确的所有权模型建立同步关系。

判断边界时不要只问“有没有写入 map 的语句”，还要问 map 的值是否指向可变对象，以及遍历、len 和键更新是否都遵守同一份访问契约。

只读 map 什么时候可以并发访问

“只读”不是指业务上大多数请求都在查，而是指共享 map 的生命周期里没有并发写操作。初始化阶段可以由一个 goroutine 建好数据，之后把引用发布给其他 goroutine；发布完成后，其他 goroutine 只执行键查找、len 或 range，这时普通 map 的访问边界是清楚的。

如果配置刷新会替换某个键，缓存淘汰会调用 delete，或者后台任务会向 map 增加数据，就不能再把它称为只读 map。下面这张结构图把访问者、共享 map 和同步边界放在同一张图里，重点是区分“只读契约”与“发生写入后的保护方式”。

哪些操作会让只读边界失效

最容易漏掉的是不明显的写入：m[key] = value 和 delete(m, key) 很直观，批量清空、延迟初始化、定时刷新和把 map 交给另一个组件修改则更容易藏在调用链里。range 本身是读，但如果遍历期间另一个 goroutine 修改同一张普通 map，仍然属于读写并发。

还有一个常见误解：只要 map 本身没有被写，map 里保存的指针就可以随意修改。实际上，map[string]*Config 的查找只保护了“取指针”这一步；如果多个 goroutine 同时改动同一个 Config，竞争发生在对象内部，仍需单独同步。

用 RWMutex 把读写路径固定下来

共享缓存或运行时状态通常可以先用一个小型包装类型表达契约。读方法只在读取期间持有读锁，写方法持有写锁；不要在解锁后继续使用依赖共享状态的中间引用。

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

func (s *Store) Get(key string) (string, bool) {
	s.mu.RLock()
	defer s.mu.RUnlock() // 读路径结束后释放读锁
	value, ok := s.data[key]
	return value, ok
}

func (s *Store) Set(key, value string) {
	s.mu.Lock()
	defer s.mu.Unlock() // 写入完成前不允许读写者穿过临界区
	s.data[key] = value
}

这段代码的关键不在于把锁放进结构体，而在于让所有访问都经过同一个结构体。若业务代码仍然把 data 暴露出去，调用者就可能绕过锁，包装类型建立的边界会被破坏。读多写少时可以考虑把更新后的完整副本一次性替换出去，但副本里的嵌套对象也要保持不可变或单独同步。

sync.Map 和单 goroutine 所有权怎么选

sync.Map 不是“加速版 map”，它适合两类典型场景：键集合长期稳定而写入很少，或者不同 goroutine 操作的键彼此独立。若数据结构需要多字段一致更新、频繁遍历，或者读写规则本身复杂，普通 map 配合 RWMutex 往往更容易审查。

另一种方案是把 map 的所有操作交给一个 goroutine，其他 goroutine 通过 channel 发送查询或更新请求。它能让所有权非常明确，但请求协议、关闭流程和背压也要设计好；当查询必须同步返回时，调用方还需要等待响应。

可以用下面的判断表先缩小范围：

用 race 检查器验证你写下的契约

设计完成后，让测试故意覆盖并发读写、并发遍历和指向对象的修改，再运行：

# 用竞态检测器检查测试覆盖到的共享访问
go test -race ./...

如果报告竞争，先沿调用栈找出哪一方绕过了访问包装，再决定补锁、改成快照还是收回所有权。没有报告只表示当前测试路径没有观测到竞争，不表示任意输入和任意调度都安全；访问契约仍应写进类型边界和代码评审清单。

常见问题与边界

多个 goroutine 同时读取普通 map 一定安全吗？

在 map 已初始化且没有任何并发写入时，可以并发读取。若值指向可变对象，对象内部仍要按自己的规则同步。

读取和 delete 同时发生可以接受吗？

不可以。delete 是写操作，必须和读取一起纳入同一个锁、通道或快照发布机制。

用了 sync.Map 就不需要 race 检查了吗？

不需要。sync.Map 只覆盖它提供的方法和同步语义，业务对象、组合更新和其他共享字段仍可能存在竞争。

只给 Set 加锁、Get 不加锁行不行？

不行。读写锁的价值在于读路径也参与同步；否则读取仍可能与写入并发，包装类型的契约并没有闭合。

最终可以把判断压缩成一句话：没有写入者时，普通 map 可以作为冻结只读数据共享；有写入者时，先选择谁拥有状态，再让所有读写经过同一条同步边界，最后用 go test -race 检查实际调用路径。