Go sync.Map 怎样判断是否适合替代普通 map

我第一次把并发缓存从普通 map 换成 sync.Map 时，关注点只放在“能不能少写几把锁”。真正容易踩坑的是：换完以后类型安全变弱了，原来由一把锁保护的复合更新也不再自动存在。结论先说：sync.Map 适合读多写少的缓存，或不同 goroutine 主要访问互不重叠的键；业务需要强类型、复合不变量和稳定遍历时，普通 map 配合 Mutex 或 RWMutex 往往更合适。

官方文档：https://pkg.go.dev/sync#Map

先按访问模式判断，而不是先看锁少不

sync.Map 的文档把适用场景说得很窄：一个键通常只写一次、之后被大量读取，例如只增长的缓存；或者多个 goroutine 读写不同的键集合。这样的访问模式能减少同一把锁上的竞争。

如果你的代码是“每个请求都更新同一个计数器”“一个键关联多个字段并且必须同时修改”“遍历时要求看到一致快照”，就不能只把类型替换成 sync.Map。这些需求的核心是业务不变量，不是容器有没有内置锁。

sync.Map 的便利来自专用操作

读写入口是 Load、Store、Delete 和 LoadOrStore。其中 LoadOrStore 很适合“缓存没有就放入，有就复用”的一次性初始化，但返回值是 any，调用方必须承担类型断言和类型设计的责任。

package main

import "sync"

type User struct {
	Name string
}

type UserCache struct {
	data sync.Map
}

func (c *UserCache) GetOrLoad(id string, load func() *User) *User {
	// 先读取已有值，命中时避免重复加载。
	if value, ok := c.data.Load(id); ok {
		return value.(*User) // 写入路径统一保存 *User，断言才有稳定前提。
	}

	loaded := load()
	actual, _ := c.data.LoadOrStore(id, loaded)
	// 并发初始化时只认最终存入的对象，避免返回未被缓存的副本。
	return actual.(*User)
}

这段代码的重点不是“少写一个锁”，而是把值类型约束集中到一个包装器里。若项目里到处都出现 value.(具体类型)，说明这个容器的通用性正在转化为维护成本。

复合更新决定了替换成本

普通 map 的锁通常同时保护数据和相关状态。例如“读取旧值、检查条件、更新值、增加版本号”可以放在同一临界区内。sync.Map 的单个方法具备并发语义，但它不会替你组合出业务级事务。

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

func (c *Counter) Add(key string, delta int) int {
	c.mu.Lock()
	defer c.mu.Unlock() // 让所有返回路径都释放写锁。

	c.data[key] += delta
	return c.data[key]
}

这类代码的优势是值类型明确，更新和读取可以连同其它不变量一起保护。反过来，sync.Map 的 Range 也不承诺一致快照：并发存储或删除时，遍历可能看到不同时间点的映射。因此不要把一次 Range 当成事务性导出。

用这张表做最后选择

上线前我会再问三个问题：键是否会被大量覆盖？值是否需要和计数、版本或状态一起变更？团队是否能接受每次读取都做类型断言？只要其中一个答案明显偏向“需要强约束”，就不要为了表面上的无锁 API 强行替换。

相关问题

sync.Map 能不能保存任意类型的键和值？

方法参数是 any，但键最终仍要满足可比较要求，值也需要由调用方管理类型。它不是把类型问题消除了，而是把检查位置从编译期移到了运行时。

sync.Map 的 Range 能否拿到稳定快照？

不能把它当成一致快照。并发修改时，回调可能观察到不同时间点的值；需要稳定导出时，应在普通 map 的锁保护下复制快照，再在锁外处理。

只要并发访问就应该使用 sync.Map 吗？

不是。普通 map 配合合适的锁同样可以安全并发访问，而且通常更容易表达类型和业务不变量。先判断访问模式，再选择容器。