锁竞争优化需依读写比例、数据结构和操作耗时选择原语：读多写少用sync.rwmutex，纯计数/开关用atomic，高频map用分片锁，锁内仅做内存操作，避免io与长耗时逻辑。
锁竞争不是“加了锁就完事”，而是要根据读写比例、数据结构、操作耗时，选对原语、缩紧临界区、拆开热点——否则 sync.Mutex 会成为你服务吞吐量的隐形天花板。
什么时候该换掉 sync.Mutex？
别等 pprof 显示 runtime.futex 占 CPU 20% 才反应过来。先看场景：
- 读操作远多于写（比如配置、路由表、用户白名单），且读逻辑里不修改共享数据 → 换
sync.RWMutex - 只做计数、开关、指针替换（如
atomic.LoadUint32(&flag)）→ 直接上sync/atomic - 写操作占比超过 15%～20%，或读操作隐含写（比如读完顺手改个字段）→
sync.RWMutex可能比sync.Mutex更慢，别硬换 - 结构体整体只读、偶有更新（如全局
*Config）→ 用atomic.Value存指针，读零成本，写仅一次原子赋值
map 并发访问卡死？别锁整个 map
高频并发读写大容量 map 是锁竞争最典型的温床。一把锁压住所有 key，等于让所有 goroutine 排队过独木桥。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 分片数建议 32 或 64：太少易形成热点，太多增加哈希与内存开销
- 哈希函数别用
len(key) % N，改用fnv32或xxhash.Sum32，避免 key 长度集中导致分片倾斜 - 每个分片必须配独立的
sync.Mutex实例，不能复用同一把锁 -
ShardedMap.Get中的idx计算必须无符号取模（uint32(hash) % uint32(shardCount)），否则负数索引 panic - 分片锁不支持跨分片原子操作（如求全量 sum），这类需求要么退全局锁，要么改用
sync.Map+ 外部迭代器（但注意它不保证遍历顺序）
锁里千万别干这些事
锁本身不慢，慢的是你让它干了调度器不该管的事。
- HTTP 请求、数据库查询、JSON 解析、文件 IO —— 全部移出临界区。锁内只做内存读写
- 如果必须触发异步动作（如发通知），锁内只
select发信号到 channel，由独立 worker 处理 - 定时刷新类写操作（如 token 缓存重载），用双缓冲：新数据加载完成后再
atomic.StorePointer切换指针，避免写过程长期持锁 - 临界区只包真正共享且可变的数据操作。例如“查 DB → 构造 user → 写入
usersMap”，应为“查 DB → 构造 user →mu.Lock()→ 写入 →mu.Unlock()”，而不是把查 DB 也包进去
sync.RWMutex 的死锁和饥饿比性能问题更隐蔽
它看似友好，但几个关键约束不守牢，轻则卡死，重则线上静默故障。
-
RLock()和RUnlock()必须严格成对；漏掉一次RUnlock()，后续所有Lock()就永久阻塞 - 别在
defer中无条件调RUnlock()：如果RLock()因 context 被取消而失败，就不该解锁 - 写操作期间，所有新进来的读请求会被阻塞，直到写完成；若写操作本身耗时长（比如加载大配置文件），读请求会堆积，引发延迟毛刺
- 大量读者存在时，新写请求可能一直抢不到锁（写饥饿），尤其当读者持续不断进入 —— 这时要考虑是否真适合用 RWMutex，或引入写优先策略（需自行实现）
最常被忽略的点是：锁竞争优化不是“换一个更炫的同步原语”就能解决的，而是从数据结构设计开始——比如能否用 channel 替代共享变量？能否把状态下沉到局部 goroutine？能否用 COW 或双缓冲规避写时加锁？这些决策往往比怎么加锁更重要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
