Go 语言实现基于分段锁（Segmented Lock）的高并发缓存-Golang-PHP中文网

直接用sync.RWMutex包map会卡住，因所有读写共用同一把锁，key不重叠也互相阻塞；go-cache采用32分片锁+哈希取模，使不同key落入独立分片并行操作，显著降低争抢、提升吞吐。

为什么直接用 `sync.RWMutex` 包一层 `map` 在高并发下会卡住

因为所有读写操作都串行在同一个锁上，哪怕 key 完全不重叠，set("user:1") 和 set("order:999") 也会互相阻塞。尤其在写多或混合读写场景下，吞吐量会随 goroutine 数增长而急剧下降，不是线性扩展。

典型现象是压测时 CPU 利用率不高，但 QPS 上不去，pprof 显示大量时间花在 runtime.futex 或 sync.runtime_SemacquireRWMutex 上。

根本原因：锁粒度太粗，没利用 key 的离散性
不是代码写错了，是设计上没做分片
sync.Map 虽然并发安全，但它内部没有 TTL、不支持自定义淘汰，且写入路径比分段 map 更重，不适合高频更新缓存

怎么把 `map` 拆成 32 个带独立 `sync.RWMutex` 的分片

核心是哈希后取模，让 key 均匀落到固定数量的 segment 上；每个 segment 是一个 map[string]interface{} 加一把 sync.RWMutex。

示例关键逻辑：

type ShardedCache struct {
    segments []*sync.RWMutex
    data     []map[string]interface{}
}
<p>func NewShardedCache(shards int) <em>ShardedCache {
segs := make([]</em>sync.RWMutex, shards)
data := make([]map[string]interface{}, shards)
for i := range segs {
segs[i] = &sync.RWMutex{}
data[i] = make(map[string]interface{})
}
return &ShardedCache{segments: segs, data: data}
}</p><p>func (c *ShardedCache) Get(key string) interface{} {
idx := fnv32a(key) & (len(c.segments) - 1) // 必须是 2 的幂
c.segments[idx].RLock()
defer c.segments[idx].RUnlock()
return c.data[idx][key]
}
</p>

分片数建议设为 32 或 64——太少起不到分流效果，太多增加哈希计算和内存开销
fnv32a 比 hash/fnv 标准包更快，且避免依赖 unsafe；务必保证 len(c.segments) 是 2 的幂，才能用位与替代取模
不要在 Get 里做 nil 判断并自动初始化 segment map，那会引发竞态（多个 goroutine 同时写同一 slice 元素）