直接用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]
}
- 分片数建议设为 32 或 64——太少起不到分流效果，太多增加哈希计算和内存开销
-
fnv32a比hash/fnv标准包更快，且避免依赖unsafe；务必保证len(c.segments)是 2 的幂，才能用位与替代取模 - 不要在
Get里做nil判断并自动初始化 segment map，那会引发竞态（多个 goroutine 同时写同一 slice 元素）
哈希倾斜导致某段锁过热，该怎么提前发现和缓解
当业务 key 高度集中（比如所有请求都带 tenant_id=1），再均匀的哈希函数也救不了——流量全打到同一个 segments[7]，等于又回到单锁瓶颈。
真实错误现象：go tool pprof 显示某个 segments[i].RLock 占用 90%+ 的锁等待时间，其他 segment 几乎空闲。
- 上线前用线上采样 key 做分布统计：跑一段脚本，对百万级真实 key 计算
fnv32a(k) & 0x1f，看直方图是否平坦 - 如果发现明显倾斜，优先检查 key 构造逻辑——是不是漏拼了 user_id、只用了固定前缀？
- 临时缓解可加二级扰动：比如
fnv32a(key + strconv.Itoa(os.Getpid()))，但治标不治本；长期必须重构 key 设计 - 别迷信“更复杂哈希函数”，
fnv32a在 Go 场景下已足够，问题几乎总出在 key 本身缺乏熵
go-cache 和手写分段锁，什么情况下该选哪个
go-cache 就是封装好的分段锁缓存（默认 32 shard），自带 TTL、LRU 淘汰、容量限制，适合大多数业务场景。
手写分段锁只在以下情况值得投入：
- 需要精确控制过期逻辑（比如按 namespace 分开清理，而非全局 LRU）
- 缓存 value 是固定结构体，想避免
interface{}反射开销 - 已有成熟淘汰策略（如 LFU 或基于访问频次的动态权重），不想被
go-cache的 LRU 绑死 - 对内存布局敏感，需自己做对象池复用或
unsafe优化（比如 BigCache 那种字节切片管理）
绝大多数服务，直接 go get github.com/patrickmn/go-cache 并调用 cache.New(5*time.Minute, 10*time.Minute) 就够了——它省掉的锁误用、内存泄漏、过期漏删风险，远超手写的可控性收益。
