17370845950

sync.RWMutex 仅在读多写少（写

用 sync.RWMutex 替代 sync.Mutex 前先确认读写比例

读多写少是 sync.RWMutex 发挥优势的前提。如果写操作占比超过 15%～20%，它反而可能比 sync.Mutex 更慢——因为读锁的升级/降级开销、goroutine 唤醒调度成本会上升。

实操建议：

• 用 pprof 的 mutex profile（go tool pprof http://localhost:6060/debug/pprof/mutex）看锁等待总时长和争用次数，再结合日志统计读写频次
• 对高频读场景（如配置缓存、状态快照），优先用 RWMutex；但若写操作常伴随批量更新或条件重置（比如定时刷新 token map），sync.Map 或分片锁更稳妥
• RWMutex 的 RLock 不可嵌套，且不能在持有 RLock 时调用 Lock（会死锁），必须显式 RUnlock 后再 Lock

避免在锁内做 IO、网络调用或长耗时计算

这是锁竞争恶化最常见原因：一个 goroutine 持有锁执行 HTTP 请求或 JSON 解析，其他 goroutine 全部排队阻塞。

实操建议：

• 把锁范围缩到最小——只包裹真正需要保护的共享数据读写，IO 和计算提到锁外
• 例如：从数据库查数据 → 解析成 struct → 加锁写入全局 map，而不是加锁后才发起查询
• 若必须在临界区内触发异步动作（如发通知），改用 channel 或 worker pool 转移出去，锁内只做 select 发送信号

用分片锁（sharded mutex）降低单点争用

当热点数据是大容量 map 或 slice，且 key 可哈希时，用分片锁能将锁竞争分散到多个 sync.Mutex 实例上，吞吐量常提升 3–10 倍。

实操示例（简易分片 map）：

type ShardedMap struct {
    mu     [32]*sync.Mutex
    data   [32]map[string]int
}

func (m *ShardedMap) Get(key string) int {
    idx := int(uint32(hash(key)) % 32)
    m.mu[idx].Lock()
    defer m.mu[idx].Unlock()
    return m.data[idx][key]
}

注意点：

• 分片数不宜过小（易热点）或过大（内存/CPU 开销上升），32 或 64 是较安全起点
• hash 函数要均匀，避免某些 shard 长期空闲、某些持续争抢；fnv 或 xxhash 比 string 直接取模更稳
• 无法支持跨分片原子操作（如“所有 key 的 sum”），这类需求得退回到全局锁或用 sync.Map + 迭代器

sync.Map 不是万能替代，它只适合特定读写模式

sync.Map 对“一次写、多次读”的场景做了优化（读走无锁 fast path），但写操作代价高、不支持遍历、无 CAS 原语，且 key 类型必须是可比较的（不能是 slice/map/func）。

适用边界很明确：

• ✅ 适合：map[string]*User 类型的注册表，用户上线写一次、后续大量读取
• ❌ 不适合：频繁更新同一 key（如计数器自增）、需要按顺序遍历、或 key 是 []byte 等不可比较类型
• ⚠️ 注意：sync.Map.LoadOrStore 在 key 不存在时才写，看似原子，但内部仍可能触发内存分配和锁，高并发下不如预分配 + 分片锁稳定

分片策略和锁粒度选择，往往比换用什么锁类型更重要。很多“锁竞争高”的问题，根源其实是数据结构没按访问模式拆分，或者锁被无意中拖进了非必要路径。