defer mu.unlock() 在高并发下不等于安全，因锁持有时间过长会导致严重争用；临界区应尽量缩小，避免在锁内执行网络请求、sleep等耗时操作，否则即使正确使用defer也会引发性能瓶颈。
defer mu.Unlock() 为什么在高并发下不等于“安全”
它确实能保证解锁，但不等于没风险。关键问题不在 defer 本身，而在于锁的持有时间与竞争强度——defer mu.Unlock() 只是把解锁动作推迟到函数末尾，如果临界区代码很长（比如含网络请求、复杂计算），其他 goroutine 就得排队等这把锁，吞吐量直线下降。
常见错误现象：pprof 显示 sync.Mutex.Lock 占用大量 CPU 时间，或 runtime.semacquire 出现在火焰图顶部。
- 锁持有时间越长，协程阻塞越严重，不是 defer 写得对不对的问题，而是临界区是否该这么宽
- 即使用了
defer mu.Unlock()，若临界区内做http.Get或time.Sleep，照样引发锁争用 - 多个函数嵌套调用且都 defer 同一把锁，容易掩盖真正的锁瓶颈点
读多写少时，RWMutex + defer RUnlock 性能翻倍
当共享数据以读为主（如配置缓存、状态快照），sync.RWMutex 比 sync.Mutex 更合适。但要注意：defer mu.RUnlock() 必须和 mu.RLock() 成对出现在同一作用域，否则 panic。
使用场景：HTTP handler 中读取全局配置、metrics 计数器统计、服务发现列表查询。
-
RLock()允许多个 goroutine 并发读，RUnlock()必须配对 defer，不能漏 - 写操作仍要用
Lock()/Unlock()，且写期间所有读都会被阻塞 - 避免“读写锁饥饿”：如果写请求持续到达，读可能一直等不到机会；可加简单重试或超时控制
defer 在循环里注册锁操作？这是性能陷阱
绝对不要在 for 循环里直接写 mu.Lock(); defer mu.Unlock()。defer 是函数级的，所有 defer 都会等到外层函数 return 才执行，结果就是锁被持有一整个循环结束，完全失去并发意义。
错误示例：
for _, item := range items {
mu.Lock()
defer mu.Unlock() // ❌ 所有 Unlock 都堆到最后才跑
process(item)
}
- 正确做法：把每次锁操作包进独立函数或匿名函数中，让 defer 绑定到本轮作用域
- 例如：
func() { mu.Lock(); defer mu.Unlock(); process(item) }() - 更推荐：只锁真正需要保护的那几行，比如 map 赋值，而不是整个 process 流程
锁释放时机比释放动作更重要
很多人盯着“有没有 defer”，却忽略“什么时候 unlock”。高并发下，早一秒释放锁，就少一堆 goroutine 排队。最有效的优化不是换锁类型，而是缩小临界区。
实操建议：
- 把非共享操作（日志、参数校验、返回值构造）全挪到
mu.Lock()之前或defer mu.Unlock()之后 - 提前算好要写入的值，再进锁赋值；别在锁里调
json.Marshal或查数据库 - 用
atomic.Value替代锁读简单结构体，彻底避开锁开销
真正难的不是写对 defer，而是判断哪段代码“必须”锁、哪段“其实可以不锁”。这点不厘清，再多 defer 也救不了性能。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
