如何在Golang中实现并发控制_Golang sync包互斥锁与WaitGroup方法

必须用 sync.Mutex 的场景是多个 goroutine 同时读写同一内存且含写操作;sync.WaitGroup 用于等待 goroutine 结束,需 Add、Done、Wait 严格配对;二者可安全组合,但职责分离:Mutex 管数据访问,WaitGroup 管生命周期。

Go 里并发控制不是靠“加锁就完事”,而是得看场景选对工具:sync.Mutex 解决数据竞争,sync.WaitGroup 解决 goroutine 生命周期等待,两者混用不当反而引入死锁或 panic。

什么时候必须用 sync.Mutex

当多个 goroutine 同时读写同一块内存(比如全局变量、结构体字段、切片底层数组),且至少有一个是写操作时,sync.Mutex 就不是可选项,而是必需项。不加锁的典型表现是运行时 panic 报 fatal error: concurrent map writes,或者数值计算结果随机出错(如计数器总比预期少)。

实操建议:

  • 锁粒度越小越好:不要在函数入口就 mu.Lock(),而是在真正访问共享数据前才加锁,访问完立刻 mu.Unlock()
  • 避免在锁内做耗时操作:比如调用 HTTP 请求、文件 IO 或长时间循环,否则其他 goroutine 会卡住
  • 别把 sync.Mutex 当成值传递:它不能被复制,必须传指针;如果嵌入结构体,该结构体也不能被赋值或作为 map 的 key
  • defer mu.Unlock() 是安全习惯,但注意它在函数返回时才执行,若锁内有 long-running goroutine,需手动 unlock

sync.WaitGroup 的三个核心方法怎么配对用?

WaitGroup 不是用来保护数据的,它的唯一职责是:让主 goroutine 等待一组子 goroutine 全部结束。它靠三个方法协同工作:Add()Done()Wait(),缺一不可,顺序错一个就会 hang 或 panic。

常见错误现象:

  • Wait() 返回不了 → Add() 没调用,或 Done() 调用次数少于 Add()
  • panic: sync: negative WaitGroup counter → Done() 调用多了,或 Add() 传了负数
  • goroutine 泄漏 → Wait() 在子 goroutine 启动前就返回了,因为 Add()go 语句顺序反了

正确写法必须满足:先 wg.Add(n),再 go func() { ...; wg.Done() }(),最后 wg.Wait()。不能靠 “大概启动了几个” 来估算 n,必须精确。

Mutex 和 WaitGroup 能一起用吗?怎么组合才安全?

能,而且很常见——比如并发更新一个计数器并等待全部完成。但关键在于:WaitGroup 管生命周期,Mutex 管数据访问,二者职责不能交叉。

典型安全组合示例:

var (
    mu    sync.Mutex
    total int
    wg    sync.WaitGroup
)

for i := 0; i < 10; i++ {
    wg.Add(1)
    go func(val int) {
        defer wg.Done()
        mu.Lock()
        total += val
        mu.Unlock()
    }(i)
}
wg.Wait()
// 此时 total 是确定值

容易踩的坑:

  • wg.Done() 放在 mu.Lock() 里面 → 可能导致死锁(如果 Unlock() 永远不执行,Done() 就卡住)
  • Wait() 之后还去读写被锁变量 → 没问题,但前提是没其他 goroutine 在继续跑;如果还有活跃 goroutine,仍需锁保护
  • WaitGroup 等待带锁逻辑时,误以为锁能替代 WaitGroup → 锁只防并发读写,不保证 goroutine 已结束

有没有比 Mutex + Wai

tGroup 更轻量的替代方案?

有,但要看场景。比如只做计数,优先用 sync.Atomic 类型(int64Uint64Pointer),它比 Mutex 快得多,且无锁:

var total int64
for i := 0; i < 10; i++ {
    go func(val int) {
        atomic.AddInt64(&total, int64(val))
        wg.Done()
    }(i)
}
wg.Wait()
fmt.Println(atomic.LoadInt64(&total))

但 Atomic 只支持简单操作(增减、交换、比较并交换),没法封装复杂逻辑(比如“如果余额 > 100 才扣款”这种条件更新)。这时候还是得回到 Mutex

WaitGroup 本身没有轻量替代——context.WithCancelchan struct{} 可用于通知退出,但不提供“等待全部结束”的能力。真要等,WaitGroup 仍是标准解法。

真正容易被忽略的是:WaitGroup 的零值可用,但 Mutex 的零值虽可用,却不能被复制;Atomic 操作要求变量地址稳定(不能是栈上临时变量的地址);所有这些约束不写在文档最上面,而藏在 godoc 示例和 FAQ 里。