17370845950

当读写频率接近（如6:4或5:5）、写操作频繁（>20%）、临界区极短、需锁升级或强一致性保障时，应选sync.Mutex；它更简单可靠，避免写饥饿与死锁风险。

什么时候该用 sync.Mutex，而不是 sync.RWMutex

当读写操作频率接近（比如 6:4 或 5:5），或者写操作逻辑复杂、需强一致性保障时，sync.Mutex 更简单可靠。它不区分读写，所有操作都排队，避免了锁升级/降级、写饥饿等隐含风险。

• 写操作频繁（>20% 的并发请求是写）：用 RWMutex 反而会让写 goroutine 长时间等待，因为新读请求会不断插队（Go 的 RWMutex 是写优先但「读不阻塞读」，导致写被持续延迟）
• 临界区极短（如只改一个字段、查一个 map key）：加锁开销本身已占主导，RWMutex 多出的状态管理反而略慢
• 需要在持有读锁期间“升级”为写锁：这是禁止的——RWMutex 不支持锁升级，强行 RLock() 后再 Lock() 会导致死锁

sync.RWMutex 真正发挥优势的场景

典型读多写少：读操作占比 ≥ 80%，且读逻辑耗时明显（如遍历 map、序列化结构体、计算聚合值）。这时多个 goroutine 并发 RLock() 不互斥，吞吐量能线性提升。

• 配置缓存：配置只在后台定时更新（写少），但每个 HTTP 请求都要读取（读多）
• 状态快照：服务暴露 /health 或 /metrics 接口，需读取大量只读指标
• 内存索引：如倒排索引、路由表，查询远多于重建

注意：RWMutex 的 Lock() 会阻塞后续所有 RLock()，所以写操作一旦变慢（比如触发磁盘 IO 或网络调用），读请求就会集体卡住——这不是 bug，是设计使然。

常见误用与 panic 原因

两类锁都要求「谁 Lock 谁 Unlock」不是硬性限制（Go 允许跨 goroutine 解锁），但实际中极易出错。真正会 panic 的是以下操作：

• 对未加锁的 sync.Mutex 或 sync.RWMutex 调用 Unlock() → panic: "sync: unlock of unlocked mutex"
• 对未加读锁的 RWMutex 调用 RUnlock() → panic: "sync: RUnlock of unlocked RWMutex"
• 拷贝已使用的锁变量（如结构体赋值、map value 传递）→ 锁状态丢失，出现竞态或静默失效

正确姿势：始终用 defer mu.Unlock() 或 defer rw.RUnlock()；锁变量必须是地址传递或全局/成员变量，禁止值拷贝。

性能差异到底有多大？别猜，看实测倾向

小并发（≤10 goroutines）下，两者差距微乎其微；但高并发读场景（100+ goroutines 持续 RLock()），RWMutex 的读吞吐可比 Mutex 高 3–5 倍。不过写性能更差——因为每次 Lock() 都要等所有现存读锁释放，且新读请求会被挂起。

简单验证逻辑：

var m sync.Mutex
var rw sync.RWMutex
var data = make(map[string]int)

// 写操作（两者共用）
func write(k string, v int) {
    m.Lock()
    data[k] = v
    m.Unlock()
    // 或用 rw.Lock() / rw.Unlock()
}

// 读操作（关键区别）
func readMutex(k string) int {
    m.Lock()
    defer m.Unlock()
    return data[k]
}

func readRWMutex(k string) int {
    rw.RLock()
    defer rw.RUnlock()
    return data[k]
}

真实压测前，先问自己：你的读写比例是多少？写操作是否可能阻塞？有没有 goroutine 在锁内做网络/IO？这些比选哪个锁更重要。