锁粒度拆分是否有效不能靠猜，必须用pprof mutex profile分析真实争用数据：查看contentions与delay比值、计算竞争率变化，并结合哈希分布实测验证，否则易误判优化效果。
锁粒度拆分是否真有提升，不能靠猜，得看 goroutine 等待锁的时间、实际临界区执行耗时、以及竞争分布。pprof 的 mutex profile 是唯一能直接回答这个问题的工具。
用 pprof mutex profile 抓真实锁等待数据
Go 自带的 runtime/pprof 支持采集锁竞争事件，它记录的是 goroutine 在 Mutex.Lock() 上阻塞的真实纳秒数，不是估算值。
启用方式很简单：
- 在程序启动时注册：
import _ "net/http/pprof"，然后起一个 HTTP server（比如http.ListenAndServe("localhost:6060", nil)） - 压测过程中访问
http://localhost:6060/debug/pprof/mutex?debug=1，会输出当前所有锁的阻塞总时间、调用栈和调用次数 - 关键字段是
contentions（争用次数）和delay（总阻塞时间），比值越小说明单次等待越短，拆分才真正起效
注意：必须设置 GODEBUG="mutexprofile=1" 环境变量，否则 /debug/pprof/mutex 返回空。这是最容易漏掉的一步。
立即学习“go语言免费学习笔记（深入）”；
对比拆分前后同一临界区的 contention rate
锁粒度优化的目标不是“让锁变少”，而是降低单位时间内单个锁被争用的概率。所以要算两个数字：
- 拆分前：
total_contentions / (run_time_sec * goroutine_count) - 拆分后：对每个子锁分别采样，取平均或最大值，再做同样计算
如果后者比前者低 3 倍以上，才算有效；如果只是从 1000 次争用降到 900 次，大概率是热点 key 还没打散，或者哈希不均。
示例：你用 32 个分片 map，但 80% 的请求都落在前 3 个桶里——这时看整体 contentions 可能下降了，但那 3 个桶的 delay 会飙升，反而更差。
避免误判：pprof mutex 数据不反映 CPU 占用
/debug/pprof/mutex 只统计阻塞时间，不统计临界区执行时间。如果你把耗时操作（比如 JSON 解析、DB 查询）留在锁内，即使粒度再细，delay 也不会降——因为 goroutine 不是卡在等锁，而是卡在干活。
这时候要配合 /debug/pprof/profile（CPU profile）一起看：
- 如果火焰图里
Mutex.Lock调用栈下面堆着大量json.Unmarshal或database/sql.(*DB).Query，说明锁范围没收缩干净 - 真正该进锁的，只应是读写 map[key] 这类微秒级操作；其他一律移出去
一个常见陷阱：用 sync.RWMutex 替换 sync.Mutex 后看到 contentions 下降，就以为优化成功——其实只是读操作不争写了，但写操作依然串行，写密集场景下吞吐可能没变。
分片 map 的哈希偏斜必须实测验证
分片数量固定（如 16 或 32）只是起点，key 分布是否均匀，得看真实流量。Go 的 map 默认哈希函数对字符串 key 是有效的，但如果你的 key 是递增 ID、时间戳或 UUID 前缀相同，就极易哈希碰撞。
快速验证方法：
- 在分片结构里加一个
stats [32]uint64数组，每次插入/查询时对应桶计数器 +1 - 压测跑完后打印各桶计数，标准差超过均值 50%，说明分布严重不均
- 此时换哈希函数（比如用
xxhash.Sum64）或改分片数（试 64、128）比继续调锁逻辑更有效
别依赖理论上的“平均分配”——线上 key 分布永远比你想的更畸形。
