Go sync 包实战指南：Mutex、RWMutex 与 WaitGroup 的核心用法与避坑

sync 包提供的正是这些“共享内存”场景下的基础工具。它们不像 channel 那样充满 Go 的哲学美感，但却是构建稳定、高效并发程序的务实选择。今天，我们就聚焦其中最常用、也最容易用错的三个原语：Mutex、RWMutex 和 WaitGroup。

Mutex：最基础的互斥卫士

Mutex，互斥锁，是 sync 包的基石。它的职责非常简单：保证同一时刻只有一个 goroutine 能进入被保护的代码段。

type Counter struct {
    mu    sync.Mutex
    value int
}

func (c *Counter) Increment() {
    c.mu.Lock()
    defer c.mu.Unlock() // 使用 defer 确保锁一定会被释放
    c.value++
}

func (c *Counter) Value() int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.value
}

这段代码展示了一个线程安全的计数器。看起来很简单，但工程中常见的错误往往就藏在这里。

锁的粒度与性能陷阱

一个典型场景是，团队为了快速实现功能，用一个粗粒度的大锁保护整个复杂对象。比如，一个用户服务结构体里包含了用户信息、订单列表和消息记录，所有方法都共用同一把锁。在低并发下相安无事，一旦流量起来，这个锁就成了性能瓶颈，所有 goroutine 都在排队，CPU 闲置，但接口延迟飙升。

更合理的做法是根据数据访问模式拆分锁。如果用户基本信息和订单列表更新频率不同且关联不紧密，就可以用两把独立的锁来保护。这背后的权衡是复杂度：锁越多，死锁的风险越高，代码也越难推理。

Mutex 不可复制：一个静态检查就能发现的错误

sync 包的类型值不应被拷贝。这不仅是文档里的一句话，编译器工具 `go vet` 可以帮你发现这类问题。如果你把包含 Mutex 的结构体作为值传递，或者嵌入了另一个结构体但没使用指针，那么锁的状态就失效了，并发保护形同虚设。

// 错误示例：值传递导致锁复制
func processBad(c Counter) { // 这里复制了整个 Counter，包括 mu
    c.Increment() // 操作的已经是另一个锁了
}

// 正确做法：始终传递指针
func processGood(c *Counter) {
    c.Increment()
}

RWMutex：读多写少时的性能优化器

当你的共享数据读操作远大于写操作时，RWMutex（读写锁）就该登场了。它允许多个 goroutine 同时持有读锁（RLock），但写锁（Lock）是独占的，与所有读锁和其他写锁互斥。

听起来很美，但它可能是 sync 包里最容易被误用的原语。很多团队引入 RWMutex 后，并没有观察到预期的性能提升，甚至更慢了。为什么？

RWMutex 不是免费的

获取读锁 RLock() 并不是无代价的。它内部仍然需要原子操作来更新读者计数，在高并发读的争抢下也有开销。如果每次读操作本身非常快（比如只是读取一个整数），那么 RWMutex 带来的额外开销可能会抵消掉并发读带来的收益。这时，一个简单的 Mutex 可能反而更快。

所以，引入 RWMutex 前先问自己：读操作是否足够“重”（涉及I/O、复杂计算）？读写比例是否真的悬殊（比如 100:1 以上）？一个常见的适用场景是缓存：大量请求并发读取缓存项（重操作），而缓存失效更新（写操作）相对很少。

致命的升级陷阱

绝对不要尝试在持有读锁（RLock）时，再去获取写锁（Lock）。这会导致死锁，因为写锁在等待所有读锁（包括你自己持有的那个）释放，而你的 goroutine 又在等待写锁，形成循环等待。

// 错误！会导致死锁
rw.RLock()
defer rw.RUnlock()

if needUpdate {
    rw.Lock()   // 在这里永远等不到
    defer rw.Unlock()
    // ... 更新操作
}

正确的模式是先释放读锁，再获取写锁。但这中间数据状态可能已经改变，通常需要再次检查条件（类似“双重检查”）。

WaitGroup：优雅的协同等待

WaitGroup 用于等待一组 goroutine 完成任务。它的 API 很简单：Add(delta) 增加计数，Done() 减少计数，Wait() 阻塞直到计数归零。

然而，简单并不意味着不容易出错。WaitGroup 的坑通常很隐蔽，会让程序“安静地”卡住或者崩溃。

Add 的调用时机是核心

最基本的原则是，所有 Add 调用必须在启动新的 goroutine 之前完成，并且最好在调用 Wait 之前。一个经典的错误模式是在 goroutine 内部调用 Add：

// 错误！存在竞态条件，Wait 可能提前返回
var wg sync.WaitGroup
for i := 0; i < 10; i++ {
    go func() {
        wg.Add(1) // 在goroutine内Add，可能执行在Wait之后
        defer wg.Done()
        // ... 工作
    }()
}
wg.Wait() // 可能只等到部分或零个goroutine

正确的做法是在启动 goroutine 的循环之前，一次性或分批设置好计数：

// 正确
var wg sync.WaitGroup
wg.Add(10) // 预先知道数量
for i := 0; i < 10; i++ {
    go func() {
        defer wg.Done()
        // ... 工作
    }()
}
wg.Wait()

// 或者，动态添加（需确保在Wait前）
var wg sync.WaitGroup
for _, task := range tasks {
    wg.Add(1) // 在启动goroutine前立即Add
    go func(t Task) {
        defer wg.Done()
        t.Process()
    }(task)
}
wg.Wait()

负计数器与复用陷阱

调用 Done() 次数超过 Add 增加的总数，会导致计数器为负，从而引发 panic。这通常发生在复杂的控制流中，某个分支漏掉了 Done 调用，或者错误地多次调用了 Done。

另一个问题是 WaitGroup 的“复用”。当一次 Wait() 返回后，计数器归零。如果你想用同一个 WaitGroup 等待另一组任务，必须确保所有前一次的 Wait() 都已经返回，并且新的 Add 调用发生在这之后。否则，新的 Add 可能会唤醒仍在等待旧任务的 goroutine（如果存在），导致混乱。更安全的做法是为每一组独立的任务创建新的 WaitGroup 实例。

组合使用与选型决策

在实际项目中，这些原语经常组合使用。例如，你可能用一个 RWMutex 保护一个缓存映射（map），再用一个 WaitGroup 来等待一批缓存预热 goroutine 完成。

如何选择？可以遵循一个简单的决策流程：

• 需要等待多个 goroutine 完成吗？ -> 使用 WaitGroup。
• 需要保护共享数据免受并发访问吗？ -> 考察访问模式。
  • 读写都很频繁，或操作简单？ -> 首选 Mutex。
  • 读远多于写，且读操作成本较高？ -> 考虑 RWMutex，并通过压测验证收益。
• 注意锁的粒度，避免在锁内执行耗时操作（如 I/O）。
• 始终使用 `defer` 来解锁，以防忘记或因 panic 导致锁无法释放。
• 对于复杂的同步需求（如“等待条件成立”），可以考虑 sync.Cond，但它更底层，使用时要格外小心。

总结：同步原语是工具，理解场景是关键

Mutex、RWMutex 和 WaitGroup 是 Go 并发工具箱里锋利且实用的工具。它们没有 channel 那种声明式的优雅，却提供了 imperative（命令式）编程中不可或缺的控制力。

记住，没有“最好”的同步原语，只有“最适合”当前场景的选择。盲目追求性能使用 RWMutex 可能适得其反；粗心大意地使用 WaitGroup 会导致难以调试的协程泄漏。理解每个工具的工作原理、开销和约束，结合真实的业务数据访问模式进行设计和测试，才能写出既正确又高效的并发 Go 代码。当你对共享数据的访问模式了然于胸时，选择正确的同步原语就会成为一种直觉。