锁竞争导致goroutine大量阻塞；死锁在全goroutine休眠时触发panic；RWMutex在写频次高或读轻量时反而更慢；粗粒度锁引发伪共享与缓存失效；应依访问模式拆分锁或改用原子操作。
锁竞争导致 goroutine 大量阻塞
当多个 goroutine 频繁争抢同一把 sync.Mutex 或 sync.RWMutex 时，调度器会把抢不到锁的 goroutine 挂起，进入等待队列。这不是 CPU 空转，但会显著拉高 goroutine 数量和上下文切换开销。
典型表现是 pprof 中 runtime.futex 或 sync.runtime_SemacquireMutex 占用大量采样时间，goroutine profile 显示数百甚至上千个 goroutine 停留在 semacquire 或 mutex.lock 调用上。
- 避免在 hot path（如循环体、高频 HTTP handler）中持有锁超过必要范围
- 用
defer mu.Unlock()确保释放，但别让它包裹整个函数逻辑 - 考虑用
sync.Pool或无锁结构（如atomic.Value）替代读多写少场景下的互斥锁
死锁：Go runtime 能检测到的部分情况
Go 的 sync 包本身不主动检测死锁，但运行时在特定条件下会 panic —— 比如所有 goroutine 都休眠且无网络 I/O、channel 操作或定时器待触发时，会报 fatal error: all goroutines are asleep - deadlock!。
常见诱因包括：
- 在持有锁期间调用
mu.Lock()再次加同一把锁（非重入） - 两个 goroutine 分别持有一把锁，又尝试获取对方持有的另一把锁（AB-BA 顺序）
- 在锁保护的代码里向无缓冲 channel 发送，而接收方也在持锁状态下等待该 channel
这类问题往往只在压测或特定并发节奏下复现，本地小流量测试几乎不暴露。
误用 sync.RWMutex 反而比 sync.Mutex 更慢
sync.RWMutex 并非“读快写慢”的银弹。它的读锁实现依赖原子计数器 + 排队机制，当存在写请求待处理时，新来的读请求会被阻塞（防止写饥饿），此时读操作延迟可能反超普通互斥锁。
尤其在以下场景，RWMutex 实际性能更
差：
- 写操作频率不低（比如 >5%）
- 读操作本身很轻量（如只读一个 int 字段），加锁开销占比反而上升
- 大量 goroutine 同时尝试读，但写请求偶发插入，引发批量读阻塞
用 go tool trace 观察 runtime.block 事件，能直观看到读 goroutine 在 RWMutex.RLock 上排队的长度。
锁粒度粗导致数据局部性破坏与缓存失效
一把锁保护整张 map 或整个 struct，会让本可并行的独立字段访问被迫串行。更隐蔽的问题是：CPU 缓存行（cache line）通常为 64 字节，若多个高频更新字段落在同一缓存行，即使用不同锁保护，也会因「伪共享（false sharing）」互相干扰。
例如：
type Counter struct {
mu sync.Mutex
hits, misses, timeouts uint64 // 这三个字段很可能挤在同一 cache line
}解决方案不是简单拆锁，而是按访问模式隔离：
- 将冷热字段分离到不同 struct，并各自加锁
- 对计数类字段优先用
atomic.AddUint64替代锁 - 用
go tool pprof --alloc_space结合perf record -e cache-misses辅助定位热点缓存行
锁从来不是并发安全的万能补丁；它是最容易写、也最容易掩盖设计缺陷的捷径。真正难的是判断哪些状态必须同步、哪些可以靠消息传递、哪些压根不该共享。
