必须用 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。
立即学习“go语言免费学习笔记(深入)”;
常见错误现象:
-
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 + WaitGroup 更轻量的替代方案?
有,但要看场景。比如只做计数,优先用 sync.Atomic 类型(int64、Uint64、Pointer),它比 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.WithCancel 或 chan struct{} 可用于通知退出,但不提供“等待全部结束”的能力。真要等,WaitGroup 仍是标准解法。
真正容易被忽略的是:WaitGroup 的零值可用,但 Mutex 的零值虽可用,却不能被复制;Atomic 操作要求变量地址稳定(不能是栈上临时变量的地址);所有这些约束不写在文档最上面,而藏在 godoc 示例和 FAQ 里。










