直接用 sync.Mutex 包裹全局 int64 会成为高并发写瓶颈，因所有 goroutine 争抢同一锁，导致缓存行失效、锁排队和调度开销激增；分片计数器通过预分配 [N]atomic.Int64 数组、哈希映射写入桶、遍历求和读取，可提升吞吐至千万级。
为什么直接用 sync.Mutex 包裹一个全局 int64 会成为瓶颈
高并发写场景下，所有 goroutine 都在争抢同一把锁，哪怕只是做 counter++，CPU 缓存行频繁失效、锁排队、调度开销都会指数级上升。实测在 32 核机器上，纯 sync.Mutex 计数器吞吐常卡在 100 万 ops/s 以下，而分片后轻松破千万。
分片本质是用空间换时间：把一个热点变量拆成 N 个冷变量，让 goroutine 尽量各写各的桶，只在读总数时聚合。
- 桶数不是越多越好——通常取 CPU 核心数的 2–4 倍（如 16–32），再大容易因 cache line false sharing 反而拖慢
- 每个桶必须独立对齐到缓存行边界（64 字节），否则相邻桶落在同一 cache line，仍会互相干扰
- 别用
map[int64]int64存桶——map 非并发安全，且哈希冲突+扩容会引入隐式锁
用 atomic.Int64 + 固定大小数组实现无锁分片计数器
核心思路：预分配一个 [N]atomic.Int64 数组，写操作通过 goroutine ID 或 key 的哈希值映射到某个桶，用 atomic.AddInt64 无锁更新；读操作遍历所有桶求和。
示例关键片段：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
type ShardedCounter struct {
buckets [32]atomic.Int64
}
<p>func (c *ShardedCounter) Inc() {
// 简单哈希：用 goroutine ID 不现实，改用 runtime.Gopark 的伪随机偏移（生产建议用更均匀的 hash）
idx := int(uintptr(unsafe.Pointer(&c.buckets))>>3) & 0x1F // 32 桶，掩码 0x1F
c.buckets[idx].Add(1)
}</p><p>func (c *ShardedCounter) Sum() int64 {
var total int64
for i := range c.buckets {
total += c.buckets[i].Load()
}
return total
}- 避免用
goroutine id分桶——Go 不暴露稳定 goroutine ID，且 worker pool 场景下 goroutine 复用会导致倾斜 - 哈希函数要快且分布均匀；简单位运算（如
key & (N-1)）比hash/fnv更合适，前提是 N 是 2 的幂 - 注意
Sum()是最终一致性读：不保证原子快照，但对监控类计数器完全够用
当需要精确快照或带标签维度时，用 sync.Map 还是自定义结构
如果计数器要按路径、用户 ID、状态码等多维 key 统计，sync.Map 表面看方便，但实际踩坑多：它为读优化，写性能差（尤其高频写相同 key），且内存占用不可控，GC 压力大。
- 高频写+固定维度（如 HTTP 状态码共 10 个）：直接用
[10]atomic.Int64，key 转成索引（status/100 - 1） - 动态 key + 低频写（如每秒百次）：用
sync.Map加一层字符串 key 到*atomic.Int64的映射，但需预分配 bucket 结构体避免反复 new - 绝对避免：
sync.Map直接存int64——每次Store都触发 interface{} 装箱，GC 雪崩
分片计数器在 Prometheus 中暴露时的聚合陷阱
用 prometheus.GaugeVec 或 CounterVec 暴露分片数据时，别把每个桶都注册成独立指标——这会导致指标 cardinality 爆炸，Prometheus server 内存暴涨甚至 OOM。
- 只暴露聚合后的
Sum()值，桶内部分布属于调试信息，可通过 pprof 或自定义 /debug/metrics 接口临时查看 - 若真需观察分桶偏差（比如排查哈希不均），用
prometheus.NewGauge单指标 + labelbucket="0"~"31"，但 label 值必须静态预设，禁止动态生成 - 注意
Sum()调用时机：在Collect()方法里调用，而非初始化时缓存，否则无法反映实时值
分片本身不难，难的是哈希是否均匀、缓存行是否对齐、以及读写语义是否匹配业务场景——尤其当计数器要参与熔断或限流决策时，最终一致性和延迟波动就得实测校准。
