sync.Mutex无竞争时开销约10ns，但多goroutine争抢时延迟跃升至1μs+；需先用pprof和trace确认锁是否真瓶颈，避免误判DB或序列化等临界区耗时为锁问题。
sync.Mutex 在无竞争时加锁开销仅约 10ns，但一旦多个 goroutine 同时争抢，延迟会跳到 1μs+ 甚至更高——性能断崖不是线性的，而是由竞争密度和临界区耗时共同决定的。别急着换锁类型，先看锁是不是真瓶颈。
锁竞争是否真实存在？先用 pprof 和 trace 定位
很多人一看到 QPS 下降就怀疑是锁拖慢了，结果发现是 DB 查询或 JSON 序列化卡在临界区内，锁只是背锅侠。
- 用
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2查看阻塞在sync.runtime_SemacquireMutex的 goroutine 数量 - 跑
go tool trace，过滤关键词SyncMutex，看 Lock/Unlock 是否密集扎堆、持续时间是否 >100μs - 如果锁等待时间占总执行时间 http.Do()、
db.QueryRow()、json.Marshal()
读多写少时，RWMutex 不一定更快
sync.RWMutex 只在读操作占比 ≥90% 且临界区极轻（纯 map[key] 查找）时，吞吐才比 sync.Mutex 高 2–5 倍；读 ≤40% 时，sync.Mutex 反而更稳、延迟低 20%～35%。
- 读 70%–85%：必须确保
RLock()内不做任何 IO、不调用阻塞函数，否则写请求会被长期卡住 - 读写比接近 50/50？直接用
sync.Mutex，逻辑简单、死锁风险低、调度更可预测 -
RLock()后调Lock()是硬性死锁，defer救不了——Go 不支持读锁升级
比换锁更重要的三件事
锁类型只是表象，真正影响并发性能的是临界区设计和数据访问模式。
- 把整个
for range map包进RLock()？并发读毫无意义，改用sync.Map或分片加锁 - 只读/只写一个
int64？用atomic.LoadInt64/atomic.AddInt64，比RWMutex快 10 倍以上 - 热配置类场景（写极少、读极频）？用
atomic.Value+ 不可变结构体，彻底避开锁
最容易被忽略的两个硬指标
写操作实际占比、临界区平均耗时——它们无法靠理论估算，必须压测实测。比如你以为配置加载是“只读”，但后台有定时 Refresh() 写入，实际读写比可能只有 80/20；又或者你用了 RWMutex，但 RLock() 里做了 time.Sleep(10ms)，所有写 goroutine 就全堵死了。
立即学习“go语言免费学习笔记（深入）”；
锁本身很轻，但人写的代码让它变重。
