锁竞争导致goroutine频繁阻塞和调度开销，拉高延迟、降低吞吐；应通过trace定位竞争、细化锁粒度、慎用RWMutex并避免defer误用。
锁竞争会导致 goroutine 频繁阻塞和调度开销
当多个 goroutine 同时争抢同一个 sync.Mutex 或 sync.RWMutex 时，未抢到锁的 goroutine 会从运行态转入等待态，触发 Go runtime 的调度器介入：它需要保存当前栈、切换上下文、查找就绪的 G 并恢复执行。这个过程本身不耗 CPU，但会显著拉高延迟、降低吞吐——尤其在高并发写密集场景下，mutex.Lock() 调用可能成为 P99 延迟毛刺的根源。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go tool trace观察SyncBlock和SyncMutexLock事件频次，确认是否真存在锁竞争（而非误判为 CPU 瓶颈） - 避免在锁内做任何可能阻塞的操作，比如调用
http.Get()、time.Sleep()或 channel 操作（除非你明确知道 channel 是非阻塞且已缓冲） - 若只读多、写少，优先用
sync.RWMutex，但注意RUnlock()必须与RLock()成对，漏调或错序会导致 panic
锁粒度太粗是并发性能下降的常见原因
一个典型反模式是用单个全局 sync.Mutex 保护整个缓存 map，所有读写都串行化。哪怕只是查一个 key，也要排队等锁——这完全抵消了 goroutine 的并发优势。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 按数据访问模式拆分锁：例如对 map 分片，每片配独立
sync.Mutex，哈希 key 决定使用哪把锁（mu := &mutexes[keyHash%numShards]） - 考虑无锁替代方案：读多写少可用
sync.Map；高频计数可用atomic.Int64；简单状态切换可尝试atomic.CompareAndSwapInt32 - 不要过早优化：先用 pprof + trace 定位真实热点，再决定是否分锁；盲目拆锁会增加内存占用和逻辑复杂度
死锁和误用 defer Unlock() 在循环中很隐蔽
在 for 循环里反复 Lock() / Unlock() 时，如果用 defer mu.Unlock()，会导致 unlock 延迟到函数返回，实际形成“锁一直没释放”，后续迭代直接卡死。
func badLoop(data []int) {
mu.Lock()
defer mu.Unlock() // ← 错！只在函数末尾 unlock 一次
for _, v := range data {
// 所有迭代共享同一把锁，且无法中途释放
}
}
正确写法是去掉 defer，手动控制锁生命周期：
func goodLoop(data []int) {
for _, v := range data {
mu.Lock()
// 处理 v
mu.Unlock()
}
}
其他易踩坑点：
- 在 goroutine 中忘记 unlock，或 panic 后没 recover 导致锁永久持有
- 对同一个
sync.Mutex在不同 goroutine 中重复Lock()（Go 不支持重入锁） - 用指针传递 mutex 时，误传值导致每个 goroutine 拿到的是副本锁（锁失效）
sync.Mutex vs sync.RWMutex 的实际开销差异
很多人默认认为 RWMutex 性能一定更好，其实不然。它的读锁实现比普通 mutex 更重：每次 RUnlock() 都要检查是否有 writer 在等，且 writer 等待期间 reader 还能继续进，容易积累大量 reader，导致 writer 饿死。实测中，当读写比低于 10:1，RWMutex 可能比 sync.Mutex 更慢。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 读写比极悬殊（如 > 100:1）且 writer 极少时，
RWMutex才值得引入 - 避免在 hot path 上频繁调用
RWMutex.RLock()/RUnlock()，它们不是零成本 - 若需 writer 优先，可考虑第三方库如
github.com/cespare/xxhash配合自定义锁策略，或改用 channel 控制 writer 排队
