sync.Mutex易成瓶颈主因是高并发下goroutine争抢同一锁，引发排队等待、调度开销上升和伪共享；应改用分片锁、RWMutex（读多写少时）或atomic（简单变量操作）。
为什么 sync.Mutex 一用就成性能瓶颈？
不是锁本身慢，而是多个 goroutine 频繁抢同一把 sync.Mutex，导致大量 goroutine 进入等待队列、调度开销激增、CPU 缓存行频繁失效（false sharing）。常见于全局计数器、共享缓存、日志缓冲区等场景。
典型症状：pprof 显示 sync.runtime_SemacquireMutex 占比高，go tool trace 中看到大量 goroutine 在 semacquire 处阻塞。
- 避免在 hot path 上直接保护大结构体——改用细粒度锁或无锁结构
- 不要用
sync.Mutex保护只读操作；读多写少时优先考虑sync.RWMutex - 注意锁的生命周期：在函数内提前
Unlock()，别等到函数返回才释放
什么时候该换 sync.RWMutex？又何时不该？
sync.RWMutex 对读多写少场景有效，但它的写锁会完全阻塞所有读请求，且读锁之间虽不互斥，但每次加读锁仍需原子操作和内存屏障。
适用场景：map 查找远多于更新（如配置中心本地缓存）、状态快照读取。
立即学习“go语言免费学习笔记（深入）”；
- 写操作占比 > 10% 时，
RWMutex可能比普通Mutex更差——因为写锁饥饿风险升高 - 如果读操作本身很轻（比如只是取一个
int），用atomic.LoadInt64比RWMutex.RLock()更快 -
RWMutex不是可重入的，同一个 goroutine 重复RLock()会导致死锁
如何用 sync.Pool 避免高频锁竞争？
sync.Pool 本质是 per-P 的对象缓存，绕过堆分配与 GC 压力，间接减少因内存分配引发的锁争用（比如 runtime.mheap_.lock）。
但它不能替代业务逻辑锁，只适用于「临时对象复用」场景，例如 JSON 解析缓冲、HTTP header map、小 slice。
var bufPool = sync.Pool{
New: func() interface{} {
return make([]byte, 0, 512)
},
}
func process(data []byte) {
buf := bufPool.Get().([]byte)
buf = append(buf[:0], data...)
// ... use buf
bufPool.Put(buf)
}
- 不要把含指针的长生命周期对象放进去（可能造成内存泄漏或悬垂引用）
- Pool 中的对象可能被任意时间清理，绝不能假设
Get()总返回初始化好的值 - 如果对象构造成本低（如空 struct），用 Pool 反而增加调度开销
哪些地方容易忽略 false sharing 导致锁竞争恶化？
当多个互不相关的 sync.Mutex 字段被编译器排布在同一个 CPU 缓存行（通常 64 字节）中，一个 goroutine 修改其中一个锁，会导致其他锁所在缓存行失效，强制其他 P 重新加载——即使它们锁的是不同资源。
典型例子：结构体里挨着定义多个 sync.Mutex 字段，或把 Mutex 和高频更新的 int64 放一起。
- 用
go vet -shadow或go tool compile -gcflags="-m"检查字段布局 - 手动填充：在
Mutex后加_ [64]byte强制对齐到新缓存行（谨慎使用，会增大内存占用） - 更稳妥的做法是让每个锁独占一个 struct，并确保 struct size ≥ 64 字节
真正难调的锁竞争，往往不在代码显式加锁处，而在内存布局、GC 触发点、甚至 runtime 调度器的交互细节里。动手前先 go tool pprof -http=:8080 binary http://localhost:6060/debug/pprof/mutex 看真实热点，比凭经验猜更可靠。
