pprof显示runtime.futex占比超10%即需警觉，主因是goroutine争抢同一把锁且持有者执行耗时操作（如HTTP、JSON、DB），而非锁本身慢；RWMutex仅在读占比≥70%时显著优于Mutex，写超20%或含隐式写操作时反更慢且易死锁。
别一上来就加 sync.Mutex，锁竞争不是靠“加得勤”解决的，而是靠“加得准”——多数性能卡点根本不在锁本身，而在临界区干了不该干的事。
为什么 pprof 显示 runtime.futex 占 CPU 超过 10% 就该警觉
这不是“锁慢”，是 goroutine 在等锁时频繁陷入内核态调度。一旦 runtime.futex 占比持续高于 10%，说明：多个 goroutine 正在反复争抢同一把锁，而持有者可能正在做耗时操作。
- 常见诱因：
Lock()后立刻发起 HTTP 请求、解析 JSON、查数据库、读文件——这些全在临界区内 - 更隐蔽的问题：锁内调用了一个看似无害的函数，但它内部又触发了另一个锁（比如日志库的全局格式化锁）
- 真实案例：某服务缓存刷新逻辑在
mu.Lock()后加载 YAML 配置，单次耗时 80ms，导致平均排队 23 个 goroutine
sync.RWMutex 在什么情况下反而比 sync.Mutex 更慢
读多写少才用 RWMutex，但“读多”不等于“所有读都安全”。它比 Mutex 多一层状态管理开销，且极易因误用拖垮性能。
- 写占比超过 15%～20% 时，
RWMutex的读写模式切换成本 >Mutex的简单互斥 - 读逻辑里隐含写操作（例如
Get(key)中顺手更新lastAccess字段），会强制升级为写锁，破坏并发读优势 -
RLock()漏掉RUnlock()→ 后续所有Lock()永久阻塞；在defer里无条件调RUnlock()→ 若RLock()因 context 取消失败，会 panic 或解锁未持有的锁 - 大量读者活跃时，新写请求可能饿死（尤其写操作本身耗时），此时
RWMutex的吞吐反而低于Mutex
map 并发访问卡死？别锁整个 map，分片才是正解
一把 sync.Mutex 锁住整个 map，等于让所有 goroutine 排队过独木桥。高频写场景下，锁竞争直接线性恶化。
立即学习“go语言免费学习笔记（深入）”；
- 分片数建议取 64 或 128（2 的幂），哈希取模必须用无符号类型：
uint32(hash) % uint32(shardCount)，否则负数索引 panic - 哈希函数选
fnv32或xxhash.Sum32，避免标准库map自带哈希的随机性导致分布不均 - 切忌把
map字段设为 exported（大写开头），必须封装成 unexported 字段 + 带锁的Get/Set方法 - 如果只是读多写少且 key 稳定，考虑
sync.Map；但它不适合高频删除或需要遍历的场景
哪些操作根本不需要 sync.Mutex
锁不是银弹。很多场景用错原语，既没提升安全性，还引入额外开销。
- 单变量计数器、开关标志、初始化指针 → 优先用
atomic.Int64、atomic.Bool、sync.Once - 只读配置对象、缓存结构体 → 用
atomic.Value存整块替换，但注意：它只保证赋值原子，内部字段仍需同步 - 任务分发、状态流转、生产者-消费者 → 用
channel更自然，避免人为制造共享状态 - 误用
atomic.LoadPointer去读一个未用atomic.StorePointer写入的地址 →go run -race直接报 Data race
最常被忽略的一点：锁竞争优化不是堆砌原语，而是对读写比例、数据生命周期、操作耗时的持续判断。pprof 是起点，不是终点；真正关键的是看懂「谁在等」和「谁在占」——等锁的 goroutine 在做什么，持锁的 goroutine 又在干什么。
