17370845950

绝大多数场景应优先使用 sync.Mutex，仅当读写比稳定高于 8:1（如配置缓存）时才考虑 sync.RWMutex；RWMutex 不支持锁升级，须先 RUnlock 再 Lock；切勿复制锁或跨函数传递锁变量。

读多写少？直接用 sync.RWMutex，否则优先 sync.Mutex

绝大多数场景下，sync.Mutex 是更安全、更直观的选择。它只有一种锁状态，没有读/写语义混淆，也不涉及锁升级降级问题。而 sync.RWMutex 的价值只在「读操作远多于写操作」时才真正体现——比如配置缓存、状态快照、只读元数据查询等。

• 如果读写频率接近（比如 3:1 或 2:1），RWMutex 反而可能因内部 reader 计数和 writer 等待逻辑带来额外开销
• 写操作哪怕只占 5%～10%，但若写请求集中爆发（如批量刷新配置），RWMutex 的写优先策略会阻塞新读请求，导致读延迟毛刺
• 实测表明：当读写比低于 8:1 时，sync.Mutex 在多数负载下吞吐更稳、P99 延迟更低

RWMutex 的 RLock/Lock 不能混用或升级

这是最常踩的坑：试图在持有 RLock 的 goroutine 中直接调用 Lock 升级为写锁——Go 不支持锁升级，这会导致死锁或 panic。

• RWMutex 没有 Upgrade() 方法，也没有任何隐式转换机制
• 必须先 RUnlock()，再 Lock()；反过来，也不能在 Lock() 后调用 RLock()
• 更危险的是：在 RLock() 保护的函数里调用另一个也用 RWMutex 的函数，若后者尝试 Lock()，就构成嵌套写锁等待，极易死锁

func badUpgrade() {
    rwMutex.RLock()
    defer rwMutex.RUnlock()
    // ❌ 错误：这里无法“升级”，且下面调用会卡住
    writeSomething() // 内部调用 rwMutex.Lock()
}

func goodSeparate() {
    // 先释放读锁
    rwMutex.RUnlock()
    // 再获取写锁
    rwMutex.Lock()
    defer rwMutex.Unlock()
    writeSomething()
}

忘记 Unlock 或重复 Unlock 会直接 crash

sync.Mutex 和 sync.RWMutex 都不检测锁持有者，所以一旦出错就是运行时 panic，不是静默错误。

• Unlock() 被遗漏 → 其他 goroutine 永久阻塞在 Lock() 或 RLock() 上，程序 hang 死
• Unlock() 被调用两次 → 触发 fatal error: sync: unlock of unlocked mutex 或 sync: RUnlock of unlocked RWMutex
• 正确姿势：所有 Lock() / RLock() 后必须紧跟 defer mu.Unlock() / defer rwmu.RUnlock()
• 切勿把锁变量作为参数传入并期望在别处解锁——锁的状态无法跨函数传递

别复制锁，也别在 struct 里嵌套使用未导出锁字段

Go 的 sync.Mutex 和 sync.RWMutex 都包含不可复制的底层字段（如 state int32），一旦被复制（例如作为 struct 字段值拷贝、或传参时按值传递），就会破坏锁一致性，引发未定义行为。

• 编译器不会报错，但 -race 检测能发现 “copy of unlocked mutex” 类警告
• struct 中应将锁声明为指针字段（*sync.RWMutex）或直接嵌入（sync.RWMutex），但必须确保该 struct 不会被浅拷贝
• 常见反模式：type Config struct { mu sync.RWMutex; data map[string]string } —— 若 Config 被赋值给另一个变量，mu 就被复制了

type SafeConfig struct {
    mu sync.RWMutex // ✅ 嵌入合法，但禁止 copy 整个 struct
    data map[string]string
}

// ❌ 危险
：复制整个 struct 会复制 mu
c1 := SafeConfig{data: make(map[string]string)}
c2 := c1 // mu 被复制！后续 c1.mu 和 c2.mu 完全无关
c1.mu.Lock()
c2.mu.Lock() // 不会阻塞 c1，竞态隐患

真实项目里，锁选型往往不是“理论最优”，而是“最不容易出错+可观测+可调试”。sync.Mutex 的简单性本身就是一种鲁棒性；而 RWMutex 的优势，只在压测确认读写比稳定高于 10:1、且 P99 延迟确实卡在读锁争用上时，才值得引入。