为什么 Go 的 sync.Map 适合读多写少的场景-Golang-PHP中文网

read map能无锁读取是因为其字段为atomic.Value，存储只读readOnly结构，Load操作仅原子读取内存；若key存在且未标记expunged，则全程无锁、无竞争、纳秒级延迟。

sync.Map 的 read map 为什么能无锁读取

因为 read 字段是 atomic.value，底层存储的是一个只读的 readonly 结构（含 map[interface{}]*entry），所有 load 操作都直接原子读取这个结构，不涉及任何锁。只要 key 在 read.m 中存在且未被标记为 expunged，整个读过程就是纯内存访问，没有竞争、没有调度开销。

常见错误现象：Load 耗时突然升高、pprof 显示 sync.(*Mutex).Lock 占比上升——大概率是 read 频繁 miss，被迫 fallback 到加锁读 dirty。

使用场景：HTTP handler 中查用户 session（key 是 requestID）、配置中心热加载后的只读查询。

性能影响：90%+ 的 Load 走这条路径，延迟稳定在纳秒级；但一旦 miss，就得锁住 mu 去查 dirty，延迟跳到微秒甚至毫秒级。

Store 新 key 为什么会触发锁和晋升开销

当写入一个 read 中完全不存在的 key 时，sync.Map 必须把数据写进 dirty，而 dirty 是受 mu Mutex 保护的。更关键的是，如果此时 amended == false（即 read 和 dirty 不一致），就得先加锁、重建 read，再写入——这是一次全量复制操作。

容易踩的坑：

misses 计数器达到 len(dirty) 时，会强制执行 dirty → read 晋升，这是一个 O(N) 阻塞操作，期间所有读写都被卡住
高频写相同 key（比如计数器）会让 dirty 持续膨胀，misses 累积更快，晋升更频繁
写入后立刻 Load，不一定能读到：新 key 只在 dirty，read 还没同步，得等下次晋升或显式触发

参数差异：Store("k", v) 总是写 dirty；LoadOrStore("k", v) 如果 key 在 read 中已存在（哪怕 value 是 nil），就只读不写，避免锁。

为什么 Range 不是“遍历”，而是“快照 + 复制”

Range 内部会先锁住整个 mu，把当前 read.m 和非删除态的 dirty 条目全部拷贝到一个临时 slice，再解锁，最后逐个回调。这意味着：

使用Go语言搭建家庭相册系统-相关课件

下载

你无法在回调里调用 Delete 或 Store，否则 panic
看不到刚写入 dirty 但尚未晋升的 key
如果 dirty 很大，拷贝本身就会卡顿，且占用额外内存

典型误用：用 Range 清理过期 session——每次调用都锁全表，还可能漏掉刚写入的 dirty key。正确做法是用 sync.RWMutex + map 配合定时 goroutine 扫描。

兼容性注意：Range 回调函数签名是 func(key, value interface{}) bool，返回 false 不能中断遍历，它只是“建议停止”，实际仍会跑完全部快照。

LoadOrStore 的“存在性判断”为什么不可靠

LoadOrStore 只有在 key **完全不在 read 中**（包括未被标记为 expunged）时才写入。如果之前调过 Delete("k")，该 key 在 read 中会被标记为 expunged，后续 LoadOrStore("k", v) 就直接返回 nil, false，不会重建 entry。

容易踩的坑：