sync.Mutex在高并发下变慢是因为争抢导致退化为系统级阻塞，goroutine堆积在sema上，CPU耗于调度而非计算；应减小锁粒度、避免锁内耗时操作、优先用atomic，并依实际读写频率谨慎选用RWMutex。
为什么 sync.Mutex 在高并发下突然变慢？
不是锁本身坏了，而是你用它的方式触发了它的“压力模式”——当多个 goroutine 频繁争抢同一把 sync.Mutex，它会从轻量级的原子操作退化为系统级阻塞，大量 goroutine 堆在 sema 信号量上排队，CPU 花在调度和唤醒上，而不是干活。
典型症状：QPS 上不去、P99 延迟飙升、go tool trace 里看到大量 goroutine 卡在 sync.(*Mutex).Lock 的阻塞态，且 runtime.semasleep 占比异常高。
- 别在锁里做
time.Sleep、HTTP 调用、数据库查询等耗时操作 - 避免“一把锁护全局”，比如用一个
sync.Mutex保护整个 map，而不是按 key 分片加锁 - 确认是否真需要互斥——简单计数器优先用
atomic.AddInt64，flag 位用atomic.OrUint64
什么时候该换 sync.RWMutex？别只看文档说“读多写少”
“读多写少”是门槛，但不是充分条件。真正该切的信号是：读操作不修改结构体字段，且写操作频率远低于读（比如写每秒 ≤10 次，读每秒 ≥1000 次）。否则 RWMutex 的写锁升级开销（需等待所有读锁释放）反而更伤。
-
RWMutex.RLock()和RUnlock()开销略高于Mutex.Lock()，但可并发；写锁仍是排他+阻塞 - 注意：RWMutex 不支持递归读锁，同一个 goroutine 多次
RLock()会导致死锁 - 若读操作内部隐含写（比如 lazy-init 字段），RWMutex 就不安全，必须回退到 Mutex 或拆分逻辑
sync.Mutex 的饥饿模式不是“开关”，而是自动触发的保底机制
Go 1.9+ 的 sync.Mutex 默认走“正常模式”（新 goroutine 可插队），只有当某个 goroutine 等锁超过 1ms，它才自动切到“饥饿模式”——这时释放锁会直接唤醒队首 goroutine，禁止插队。你无法手动开启/关闭，但能感知它是否被激活。
立即学习“go语言免费学习笔记（深入）”；
- 用
go run -race无法检测饥饿，但可通过go tool trace观察 goroutine 在sync.Mutex上的等待时长分布 - 如果 trace 显示大量 goroutine 等待 >1ms，说明业务节奏已超出正常模式承载力，得优化锁粒度或改用无锁结构
- 别指望靠“让 goroutine 睡 1ms 再抢锁”来强制进饥饿模式——这是反模式，只会放大延迟
最容易被忽略的性能黑洞：伪共享（False Sharing）
两个高频更新的 int64 字段，哪怕逻辑完全独立，只要落在同一 CPU 缓存行（通常 64 字节），就会因缓存一致性协议频繁失效彼此的 cache line，导致性能断崖式下跌。Mutex 自身状态字段也受此影响。
- 对高频计数器结构体，用填充字段隔离：
type PaddedCounter struct { v int64; _ [7]uint64 } - 不要把多个
sync.Mutex成员挤在同一个 struct 前后——它们的状态字段（state）也会互相干扰 - 用
go tool pprof -http=:8080 binary -mutexprofile=mutex.out查看锁竞争热点，再结合perf record -e cache-misses验证是否存在缓存层瓶颈
锁优化不是调参游戏，而是对数据访问模式的诚实回应。很多团队花一周压测 sync.Mutex 参数，不如花半天把大 map 拆成 32 个分片 + 独立 Mutex——后者见效快、可验证、无副作用。真正的瓶颈，往往藏在“大家都觉得这里必须加锁”的地方。
