内部是两张表#

sync.Map 里有一个只读的 read 和一个可写的 dirty。读操作走 read，大部分时候只需要一次原子加载；写入发现键不在 read 里，才会加锁去 dirty 里找或插入。

当 dirty 的写入积累到一定程度，它会被提升为新的 read，旧的 read 里被删除的键这时才真正消失。这解释了它的几个行为：

• 读路径几乎没有锁，所以读多写少时很快；
• 写入要维护两张表，写多时不如普通 map 加锁；
• 已删除的键在被提升之前仍然占着位置，键空间反复变化时内存不会立刻下降。

它没有的东西#

1
var m sync.Map
2
m.Store("a", 1)
3
v, ok := m.Load("a")
4
m.Range(func(k, v any) bool {
5
    // 遍历不保证是某一时刻的一致快照
6
    return true
7
})

• 没有 len：想知道大小只能 Range 数一遍，而 Range 期间可能有并发写入。
• 没有类型安全：键值都是 any，每次存取都有装箱和类型断言。
• 没有原子批量操作：需要“读-改-写”时，仍然要自己用 LoadOrStore 或 CompareAndSwap 拼逻辑。
• Range 不是快照：它不阻塞写入，遍历结果可能包含已经被删除的键，也可能漏掉遍历开始后才插入的键。

什么时候值得用#

典型场景是“进程级缓存，键在启动或首次访问时写入，之后几乎只读”：

1
var routes sync.Map // path -> handler，启动期写入，运行期只读
2

3
func lookup(path string) (Handler, bool) {
4
    v, ok := routes.Load(path)
5
    if !ok {
6
        return nil, false
7
    }
8
    return v.(Handler), true
9
}

反过来，如果键会频繁增删，或者需要遍历、计数、批量更新，sync.RWMutex + map 通常更简单也更快。另一个常见选择是分片锁：把键哈希到 N 个桶，每个桶一把锁，冲突概率随 N 下降。

1
type sharded[K comparable, V any] struct {
2
    shards [16]struct {
3
        mu sync.RWMutex
4
        m  map[K]V
5
    }
6
}

一个容易忽略的坑#

sync.Map 的零值可用，但不要复制它。它内部包含互斥锁和状态字段，复制之后两份状态各自独立，行为会变得不可预测。作为结构体字段时，用指针或者确保结构体本身不被复制。

结论#

sync.Map 是一个针对特定访问模式的优化结构，不是“并发 map”的同义词。选它之前先确认：键集合稳定吗？读远多于写吗？需要长度和一致性遍历吗？三个问题里有一个答不上来，普通 map 加锁往往更合适。