17370845950

必须用 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，仍需锁保护
• 用 WaitGro

  

  up 等待带锁逻辑时，误以为锁能替代 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 里。