sync.Mutex 是默认首选，因其开销最低、语义最直白、出错路径最少；在读写混杂、临界区短、写占比超15%的多数业务场景中反而更稳更快。
sync.Mutex 是默认首选，不是因为它“高级”，而是它开销最低、语义最直白、出错路径最少。别一上来就换 sync.RWMutex 或塞 channel，多数真实业务场景里——读写混杂、临界区短、写占比超 15%——sync.Mutex 反而更稳更快。
为什么 sync.Mutex 比 RWMutex 在某些高并发场景下更合适
很多人看到“读多写少”就条件反射切 sync.RWMutex，但实际压测常发现吞吐不升反降。关键原因有三个：
- 写操作占比超过 15%～20% 时，
sync.RWMutex内部状态切换（如从 reader 状态切到 writer 状态）开销已高于sync.Mutex的纯 CAS + futex 路径 - 读逻辑里隐含写（比如
RLock()后顺手改了lastAccess字段），会触发锁升级失败或死锁 - 写饥饿：当一批 goroutine 持续
RLock()并快速释放，新来的Lock()可能永远抢不到，尤其写操作本身耗时（如加载配置文件）
用 go tool pprof 看到 runtime.futex 占 CPU 超过 10%，先别急着换原语——先确认是不是写太频繁，或者读函数偷偷写了共享字段。
分片锁（ShardedMap）怎么避免 map 并发卡死
一把 sync.Mutex 锁整个 map，等于让所有 goroutine 排队过独木桥。真正要拆的是数据访问维度，不是锁本身。
- 哈希函数选
fnv32或xxhash.Sum32，避免标准库 map 自带哈希的随机性导致热点倾斜 -
GetShardIndex必须用无符号取模：uint32(hash) % uint32(shardCount)，否则负数哈希值会导致 panic - 每个分片配独立
sync.RWMutex（读多）或sync.Mutex（读写均衡），但注意：跨分片原子操作（如全量Sum()）无法保证一致性，得退回到全局锁或双缓冲
示例伪代码：
type ShardedMap struct {
shards []shard
shardCount int
}
func (m *ShardedMap) Get(key string) interface{} {
idx := uint32(fnv32(key)) % uint32(m.shardCount)
m.shards[idx].mu.RLock()
defer m.shards[idx].mu.RUnlock()
return m.shards[idx].data[key]
}
锁里绝对不能干的三件事
锁慢不是锁的问题，是你让它干了调度器不该管的事。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 请求、数据库查询、JSON 解析、文件 IO —— 全部移出临界区。锁内只做内存读写
- 必须触发异步动作？锁内只
select发信号到chan，由独立 worker 处理 - 定时刷新类写操作（如 token 缓存重载）？用双缓冲：
atomic.StorePointer切换指针，新数据加载完成后再替换，避免写过程长期持锁
一个典型错误：mu.Lock(); data = loadFromDB(); parseJSON(data); cache[key] = data; mu.Unlock() —— 这里 90% 时间花在 IO 和解析上，锁只是背锅。
atomic.Value 和 sync/atomic 该用哪个
atomic.Value 不是“无锁对象”，它只保证“整体赋值”原子。适合存不可变结构体、缓存对象指针这类“整块换”的场景。
- 计数器、开关标志、单次初始化指针 → 直接用
sync/atomic（如atomic.LoadUint64），比atomic.Value快一个数量级且无分配 - 误用
atomic.LoadPointer去读一个没用atomic.StorePointer写入的地址 →-race直接报 Data race - 涉及多个字段联动更新？老老实实用
sync.Mutex，别硬套 CAS；atomic.Value存的是指针，解引用后字段仍需额外同步
真正难的从来不是“怎么加锁”，而是判断“哪段代码属于临界区”——这需要你对数据生命周期、读写比例、操作耗时有持续观察，而不是堆砌原语。
