Golang并发控制：互斥锁与WaitGroup使用技巧

本文深入剖析了 Go 语言中两种核心并发控制工具——sync.Mutex 和 sync.WaitGroup 的本质区别、正确用法与常见陷阱：Mutex 专治数据竞争，必须在多 goroutine 读写共享内存（尤其含写操作）时强制使用，强调小粒度加锁、避免锁内耗时操作及禁止值传递；WaitGroup 则专注 goroutine 生命周期管理，要求 Add、Done、Wait 严格配对，顺序错乱将导致死锁或 panic；二者可安全组合但职责分明——Mutex 守护数据访问，WaitGroup 等待任务结束，混用不当反而引发更隐蔽的并发问题；文末还点明了更轻量的替代方案：简单原子操作首选 sync/atomic，而复杂逻辑或确定等待仍离不开 Mutex 与 WaitGroup 的精准协同——掌握这些，才能真正写出高效、健壮、无竞态的 Go 并发代码。

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 
容易踩的坑：

• 把 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 
但 Atomic 只支持简单操作（增减、交换、比较并交换），没法封装复杂逻辑（比如“如果余额 > 100 才扣款”这种条件更新）。这时候还是得回到 Mutex。
WaitGroup 本身没有轻量替代——context.WithCancel 或 chan struct{} 可用于通知退出，但不提供“等待全部结束”的能力。真要等，WaitGroup 仍是标准解法。
真正容易被忽略的是：WaitGroup 的零值可用，但 Mutex 的零值虽可用，却不能被复制；Atomic 操作要求变量地址稳定（不能是栈上临时变量的地址）；所有这些约束不写在文档最上面，而藏在 godoc 示例和 FAQ 里。
今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~