你以为 sync.Map 无锁？它的锁藏在三个地方

Mon, 13 Jul 2026 14:30:00 +0800

这套对话，我在 code review 里见过很多次。

A 说：这个 map 读多写少，并发安全得处理一下。 B 说：那把 map + RWMutex 换成 sync.Map 吧，无锁的，更快。

第一句不完全错，第二句基本错了。

sync.Map 不是无锁 map。它内部有一把 Mutex，还有一套 read / dirty 双 map 的调度逻辑。它只是努力让你常见的读路径不走锁，但写、删除、miss、dirty 提升这些路径一个都绕不开锁。

你选 sync.Map，不是因为它在所有场景下都更快，而是因为你的 workload 正好落在它设计的那条窄路径上。

但绝大多数人跳过这个前提。

read 和 dirty：一把锁两个桶

sync.Map 的内部结构（Go 1.25.4）可以浓缩成五样东西：

1
2
3
4
5
6


type Map struct {
 mu Mutex
 read atomic.Pointer[readOnly] // 无锁读的主流路径
 dirty map[any]*entry // 写和 miss 的后备路径
 misses int // 读 miss 计数
}

其中 readOnly 又包了一层：

读多写少就用 sync.Map？先问这 5 个问题

Sat, 04 Jul 2026 13:41:44 +0800

线上有一张设备状态表，用 sync.Map 存着。

读很多，写很少。平时接口很稳，一到定时刷新那几秒，读 p99 就会抖一下。你看代码，第一反应可能不是怀疑 sync.Map，而是怀疑刷新逻辑：是不是批量太大？是不是网络抖了？是不是 GC 刚好撞上？

这种判断很自然。

因为在不少 Go 后端的直觉里，普通 map 并发不安全，sync.Map 并发安全；读多写少，正好该用它。这个链条看起来太顺了，顺到没人再问第二个问题：这张 map 只是在存 key/value，还是还牵着过期队列、计数器、最近更新时间和一组业务不变量？

真正的分岔点在这里：sync.Map 不是普通 map 的并发升级版。它是少数访问模式下的专用优化。

读多写少只是入口，不是结论。

真正该问的是：key 稳不稳定？写入是不是一次性的？不同 goroutine 操作的是不是不相交的 key？这个 map 是否需要和其他状态一起保持一致？你是否需要 Range 得到一个稳定快照？

这些问题不问清楚，把 map+RWMutex 换成 sync.Map，经常不是优化，只是把一把看得见的锁，换成了一套更隐蔽的代价。

官方第一句话就不是“用它”

Go 官方文档对 sync.Map 的态度很克制。

它确实说 Map 像 map[any]any，可以被多个 goroutine 并发使用，Load、Store、Delete 是摊还常数时间。

但紧接着那段话更重要：Map 是 specialized。大多数代码应该使用普通 Go map，再配合单独的锁或协调机制。原因也写得很直：类型安全更好，也更容易维护 map 内容之外的其他不变量。

这句话经常被忽略。

因为我们太容易只记住“并发安全”，忘了官方真正给出的优化场景只有两类：

一个 key 的 entry 只写一次，之后读很多次，比如只增长的缓存；
多个 goroutine 读、写、覆盖的是彼此不相交的 key 集合。

注意，不是“所有读多写少”。

Sync.Map on Zampo Blog

你以为 sync.Map 无锁？它的锁藏在三个地方

read 和 dirty：一把锁两个桶

读多写少就用 sync.Map？先问这 5 个问题

官方第一句话就不是“用它”