分段锁在 Go 里怎么写才不白忙活
Go 没有内置的 SegmentedLock 类型，得靠自己拆——核心是把一个大资源（比如 map）按 key 哈希后映射到多个独立锁上，让并发读写分散到不同锁实例，避免全量互斥。但直接用 sync.Mutex 数组 + 取模哈希很容易翻车。
- 别用
len(mutexes) % hash(key)：取模不是均匀分布，尤其当锁数量是 2 的幂时，低位哈希碰撞高；改用hash(key) & (N-1)（N 是 2 的幂）更稳 - 哈希函数别手写：用
hash/fnv或runtime.fastrand()配合位运算，避免字符串 key 的bytes.Equal引入隐式锁 - 每个锁只保护局部数据，不能跨段操作：比如“遍历所有段”必须依次加锁再释放，不能 hold 住全部锁——否则退化成全局锁
map 分段锁最简可靠实现长啥样
常见错误是把 map 和锁混在一起管理，导致扩容、迭代、删除时 panic 或数据错乱。真正轻量又安全的做法，是让每段自己管自己的 map + sync.RWMutex。
type SegmentedMap struct {
segments []*segment
mask uint64 // 例如 0x3ff，对应 1024 段
}
type segment struct {
m sync.RWMutex
d map[string]int
}
func (s *SegmentedMap) Get(key string) int {
idx := fnv32(key) & s.mask
seg := s.segments[idx]
seg.m.RLock()
defer seg.m.RUnlock()
return seg.d[key]
}
注意：fnv32 返回 uint32，和 mask 位宽要对齐；sync.RWMutex 比 sync.Mutex 更适合读多写少场景，但写操作仍需独占锁段。
为什么用了分段锁还是卡在 runtime.semacquire
pprof 显示大量 goroutine 卡在 runtime.semacquire，说明锁竞争没真降下去——大概率是段数设少了，或 key 分布严重倾斜。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 段数不是越多越好：超过 CPU 核心数太多会增加调度开销和 cache line false sharing；建议从 64 或 256 起调，压测时观察
GOMAXPROCS和mutexprof输出 - 检查 key 是否集中：比如用户 ID 全是
"user_1"、"user_2"这种递增字符串，fnv 哈希低位几乎不变，导致 90% 请求打到同一段；可改用hash/maphash（Go 1.19+）或对 key 做随机 salt - 避免锁内做耗时操作：比如在
seg.m.Lock()里调用 HTTP 请求或数据库查询，会把整段锁住很久，其他 goroutine 只能干等
替代方案比硬写分段锁更省心？
如果只是想降低 map 并发冲突，sync.Map 往往比手写分段锁更合适——它内部就用了类似分段 + read-copy-update 的混合策略，且对读性能做了深度优化。
-
sync.Map适合「读远多于写」且 key 不频繁变更的场景；写多时会退化为 mutex + map，性能反不如分段锁 - 若需要原子性跨 key 操作（如转账：A 减、B 加），
sync.Map无法保证，必须回归分段锁或更高阶协调机制（如 channel 控制权流转） - 第三方库如
github.com/orcaman/concurrent-map提供了带 GC 和统计的分段 map，但引入依赖前先确认是否真比sync.Map或自定义段锁带来可观收益
分段锁真正的不可替代场景，是你要精确控制锁粒度、配合业务语义做段级隔离（比如按 tenant id 分段），或者底层需要对接 C 代码共享内存——这时候，哈希函数选型、段数调优、panic 边界处理，一个都不能含糊。
