90%场景用sync.Map或map+sync.RWMutex已足够快；高频计数统计（>1k/s）且key稳定时，推荐map+sync.RWMutex，因其避免sync.Map的read/dirty切换开销。
直接用 sync.Map 或 map + sync.RWMutex 做统计聚合，90% 的场景已经足够快；真到瓶颈时，再考虑无锁结构或分片设计。别一上来就抄 RocksDB 的内存模型。
什么时候该自己写统计引擎，而不是用 Prometheus 或 statsd？
当你需要：
- 毫秒级低延迟更新（比如实时风控计数），且指标维度多、写入频次高（>10k QPS）
- 统计结果要参与业务逻辑判断（如“过去 60 秒请求超 500 次则熔断”），不能走异步上报+拉取的链路
- 运行环境受限（无网络、容器内存极小、不允许嵌入额外服务）
- 指标语义特殊（如滑动窗口内最大值 + 最小值 + 出现次数，且窗口需支持动态缩放）
这时候外挂式监控系统反而成负担，原生 Go 内存结构更可控。
sync.Map vs 普通 map + sync.RWMutex：选哪个？
sync.Map 不是万能加速器。它适合读多写少、键集变化不大的场景（如缓存配置项）。但做高频计数统计时，它内部的 read map + dirty map 切换反而带来额外指针跳转和内存分配开销。
更推荐：
- 写入频率 > 1k/s 且 key 数量稳定（map[Key]uint64 +
sync.RWMutex，读用RLock()，写用Lock() - 写入极不均匀（少数 key 占 95% 更新量）：对 key 做哈希分片，每个分片配独立
sync.RWMutex，避免锁争用 - 需要原子增减且不关心并发读一致性：直接用
atomic.AddUint64(&counter, 1)，但注意这只能用于单值计数，不适用于结构体字段
示例分片实现：
type CounterShard struct {
m sync.RWMutex
data map[string]uint64
}
type StatsEngine struct {
shards [8]*CounterShard // 8 分片
}
func (e *StatsEngine) Inc(key string) {
idx := int(uint32(hash(key)) % 8)
e.shards[idx].m.Lock()
e.shards[idx].data[key]++
e.shards[idx].m.Unlock()
}
如何安全地暴露统计结果而不阻塞写入？
常见错误是每次 HTTP 接口调用都对整个 map 加读锁并遍历——这会拖慢所有写操作。
- 不要在响应路径中遍历全量数据；改用快照机制：定时（如每秒）生成一次只读副本（
map[string]uint64），接口只读这个副本 - 快照生成时仍需锁，但可错开时间点（比如每秒整点触发），避免与业务写入高峰重叠
- 如果只查个别 key，提供
Get(key string) uint64方法，内部对对应分片加RLock()，不锁全局 - 避免在快照中返回指针或未拷贝的切片——防止外部修改破坏内部状态
关键点：写路径和读路径的锁粒度必须分离，且读路径不能持有锁太久。
内存持续增长却不释放？小心 map 的底层扩容残留
Go 的 map 在删除 key 后不会自动缩容。如果你的统计 key 是带时间戳的（如 "req_20260425_1238"），长期运行后 map 底层数组可能远大于实际 key 数量，造成内存虚高。
- 定期重建 map：当
len(m) < cap(m)*0.25时，新建 map 并迁移数据（注意迁移期间需锁住原 map） - 改用
sync.Map会稍好些，但它也不主动缩容，只是延迟了问题 - 更彻底的方案：用环形缓冲区（ring buffer）管理时效性 key，配合后台 goroutine 清理过期项
这不是 GC 问题，而是 Go map 的设计使然——这点常被忽略，直到 pprof 显示 runtime.mallocgc 耗时突增才去查。
