Go sync.Map 适合读多写少的什么场景

我第一次把 sync.Map 放进服务代码时，出发点也很简单：多个 goroutine 要同时读写一组缓存数据，又不想在每次读取前后手动加锁。真正用过几次后，我更愿意把它看成一个有明确适用条件的专用容器，而不是“并发 map 的默认答案”。

Go sync.Map 适合的读多写少场景，通常是键对应的值初始化后会被反复读取，例如只增长的缓存、只注册一次的对象表、按名称查找的共享配置。官方文档还列出另一类场景：多个 goroutine 读写并覆盖互不重叠的键集合。如果数据需要强类型、多个字段必须一起维护，或者经常对全表做一致性遍历，普通 map[K]V 加 sync.RWMutex 往往更容易维护。

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

判断重点不是“读操作是不是更多”，而是值的生命周期、键集合是否互相独立，以及调用方是否还要维护 map 之外的不变量。

读多写少时，先看键和值的生命周期

如果一个键只在初始化阶段写入一次，之后被很多请求读取，这正是 sync.Map 文档中明确提到的典型模式。常见例子包括按名称缓存解析后的配置、按 ID 保存只创建一次的客户端、按路由保存已经准备好的处理器。

这里的“写少”不只是写次数少，还意味着写入不会和一堆额外状态绑定在一起。假如写入一个值的同时还要更新计数器、过期时间、索引和审计字段，那么只把其中一张表换成 sync.Map，并不会自动让整组状态具备一致性。

为什么 LoadOrStore 很适合初始化型缓存

初始化型缓存最容易遇到的竞争是：多个 goroutine 同时发现某个键不存在，然后各自创建一份值。LoadOrStore 可以把“读取已有值”和“没有时存入候选值”放在同一个并发操作里。返回值中的 loaded 表示最终拿到的是已有值还是本次传入的值。

package main

import (
    "fmt"
    "sync"
)

type Profile struct {
    Name string
}

type ProfileCache struct {
    values sync.Map // key 是 string，value 约定为 *Profile
}

func (c *ProfileCache) GetOrCreate(name string) *Profile {
    candidate := &Profile{Name: name} // 先准备当前调用想缓存的值
    actual, loaded := c.values.LoadOrStore(name, candidate)
    if loaded {
        // 已有 goroutine 先写入，复用已经发布的值
        return actual.(*Profile)
    }
    // 当前值成功进入缓存，后续读取可直接复用它
    return candidate
}

func main() {
    var cache ProfileCache
    profile := cache.GetOrCreate("reader")
    fmt.Println(profile.Name)
}

这个例子里的类型断言是有前提的：所有写入 values 的路径都必须遵守同一个值类型约定。sync.Map 的键和值是 any，编译器不会像 map[string]*Profile 那样替你检查类型。如果项目中写入入口很多，类型约束的维护成本就会抵消一部分使用便利。

第二类场景：不同 goroutine 管不同的键集合

有些程序并不是严格的“初始化后只读”，而是不同 goroutine 负责不同的键。例如按租户 ID、连接 ID 或分片标识分开管理对象：某个 goroutine 反复更新自己负责的键，其他 goroutine 读取这些键，但写入者之间很少碰同一条记录。

这种场景的关键是键集合之间近似独立，而不是简单地把所有高并发写入都交给 sync.Map。如果所有 goroutine 都频繁更新同一个热点键，或者写入需要和其它共享状态组成事务，仍然应先建模锁的边界，而不是只看容器名字。

type Session struct {
    UserID string
    State  string
}

var sessions sync.Map // key 是 sessionID，value 约定为 *Session

func putSession(id string, userID string) {
    sessions.Store(id, &Session{
        UserID: userID,
        State:  "ready", // 写入时明确对象的初始状态
    })
}

func readSession(id string) (*Session, bool) {
    raw, ok := sessions.Load(id)
    if !ok {
        return nil, false // 不存在时由调用方决定是否创建
    }
    session, ok := raw.(*Session)
    if !ok {
        return nil, false // 防止不符合约定的值继续向下传播
    }
    return session, true
}

还要注意，容器的并发安全不等于值对象内部的并发安全。上面的 Session 指针放进 sync.Map 后，如果多个 goroutine 还会同时修改 State，就需要为字段本身设计同步方式，或采用替换整对象的策略。sync.Map 只负责 map 的键值操作。

sync.Map 和 map + RWMutex 怎么选

我通常先问四个问题：值的类型能否由约定稳定保证？除了 map 内容，是否还有必须一起更新的状态？读取是否远多于写入？遍历是否需要一个一致快照？答案比“哪个更快”更适合作为设计依据。

普通 map 加读写锁并不意味着一定更慢。它的优势是结构清楚：锁保护什么、值是什么类型、哪些字段必须一起变化，都可以直接写在类型和方法里。反过来，只有在访问模式确实符合专用场景时，sync.Map 才可能通过减少锁竞争体现价值。没有压测数据时，不要把这个判断写成无条件的性能结论。

四个 API 边界，决定代码是否容易出错

Load 的 ok 不能省略

Load 返回值和是否找到两个结果。即使业务上暂时没有存入 nil，也建议根据 ok 判断命中，避免把“键不存在”和“值本身为空”混成一个状态。

Range 不是一致快照

Range 会依次调用回调，但并不保证遍历期间所有键值来自同一时刻。遍历过程中如果有并发写入或删除，某个键看到的映射可能来自调用期间的不同时间点。因此它适合做逐项清理、统计或导出尝试，不适合直接当作事务快照。

Map 使用后不能复制

零值 sync.Map 可以直接使用，但第一次使用后不能复制。把它嵌入结构体时，尽量让结构体通过指针传递；不要把包含已使用 sync.Map 的值随意赋值或作为参数按值传递。

值对象仍要有自己的并发策略

map 的存取安全并不覆盖指针指向对象的字段读写。如果缓存值会发生原地修改，需要在值对象内部加锁、使用原子类型，或改成构造新值后整体替换。这个边界经常比 map 本身更容易被忽略。

我的选择结论

对“只注册一次、之后大量查询”的缓存或对象表，我会优先考虑 sync.Map，并把键和值的类型约定封装在少量方法里，避免业务代码到处做类型断言。对需要强类型、批量一致更新、稳定快照遍历的表，我会选择 map[K]V 加 RWMutex。

如果还不能判断，先把访问模式写成一小段接口说明：谁写入、同一键是否会反复覆盖、是否需要联动状态、是否需要一致遍历。这个说明比直接套用“读多写少”四个字更可靠。

常见问题

sync.Map 只能用于读多写少吗？

不是。官方文档还提到多个 goroutine 读写并覆盖互不重叠的键集合这一类场景。读写比例只是线索，键的独立性和业务不变量同样重要。

sync.Map 能替代所有带锁的 map 吗？

不能。它牺牲了一部分编译期类型表达能力，而且不负责维护 map 之外的关联状态。复杂数据模型通常需要显式锁住一组操作。

Range 能拿到完整一致的列表吗？

不能把它当作一致快照。并发存取期间，遍历结果只代表回调执行过程中观察到的一组映射，不保证对应某一个统一时刻。

缓存里的结构体字段变化要不要加锁？

要看字段是否会被并发修改。sync.Map 只保护键值映射；如果多个 goroutine 直接读写同一个结构体字段，还需要对象级同步或整体替换。