Go sync.Map 并发读写为什么没有达到预期性能怎样构造最小复现

sync.Map 并发读写没有达到预期性能，通常不是它“不支持并发”，而是实际工作负载没有落在它更擅长的形状上。先不要只改锁或增加 goroutine：把读写比例、键是否重复、写入是否集中在同一批键固定下来，再用 benchmark 对比 sync.Map 和 map + sync.RWMutex，结论才有意义。

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

先把“性能不如预期”拆成三个问题

第一，读是否真的占多数。缓存命中、配置快照这类读多写少场景，Load 能体现 sync.Map 的优势；如果每次读取后都紧跟 Store，它就变成了高频更新测试。第二，键是否分散。不同 goroutine 各自维护独立键集合，竞争更少；所有请求都反复改同一批热点键，结果完全不同。第三，写入临界区里是否还有额外工作。若更新值前还要计算、校验或维护多个字段，单纯替换容器不能解决复合状态竞争。

用固定读写比例构造最小 benchmark

下面的 benchmark 只比较容器访问，不在循环里打印日志，也不混入网络或序列化。为了让每个操作有明确含义，读操作执行 Load，写操作写回预先生成的整数。第二个实现用普通 map 和读写锁，便于观察“并发安全”和“性能更快”并不是同一件事。

package bench

import (
    "strconv"
    "sync"
    "testing"
)

const keyCount = 1024

func BenchmarkSyncMapMixed(b *testing.B) {
    var m sync.Map
    for i := 0; i 

运行时固定参数，例如：

go test -run '^$' -bench 'Mixed$' -benchmem -benchtime=3s -count=5
# -run '^$' 跳过普通测试；-count=5 用于观察波动，不把单次结果当结论

从结果里找出真正的竞争点

先看 ns/op 和 allocs/op，再解释它们。若两种实现差距很小，不要为了“用了并发容器”继续换结构；如果 sync.Map 的分配次数更高，检查键类型和值类型是否导致接口转换，及测试是否频繁产生新字符串。若写入比例从 10% 提升到 50% 后结果反转，说明瓶颈很可能是更新竞争，而不是读取路径。

按工作负载选择实现，而不是按印象选容器

如果数据大多写入一次后被并发读取，或者不同 goroutine 负责互不重叠的键集合，sync.Map 是合理起点。若业务需要同时维护多个字段的不变量，例如修改余额还要同步记录版本号，普通 map 加锁通常更容易把整个状态更新放进一个临界区。若热点键很多但能按租户或哈希分片，也可以继续保留普通 map，使用多把锁降低单锁竞争。

最后把复现条件写进 benchmark 名称或注释：键数量、写入比例、是否热点键、goroutine 数和 Go 版本都要留痕。性能回归时优先复现同一工作负载，再决定是调整数据结构、减少分配，还是缩短锁内操作。

相关问题

sync.Map 是否一定比 RWMutex 快？

不是。它针对特定读多写少或键集合分离模式做了优化，实际吞吐仍取决于访问比例、键分布和值处理成本。

为什么 benchmark 里不能直接用随机字符串做键？

随机键会把字符串生成和分配成本混入容器测试，还可能改变命中率。应先固定键集，再单独测键生成对整体请求的影响。

并发读写结果不稳定时先改什么？

先固定 GOMAXPROCS、-benchtime、-count、键数量和读写比例，确认复现稳定后再比较实现；不要先凭一次耗时改锁。