本文详解 Go 并发编程中因未同步访问共享变量导致 sync.WaitGroup 表现异常的根本原因，并提供基于 sync.Mutex 的线程安全解决方案，同时强调 race detector 在调试中的关键作用。
本文详解 go 并发编程中因未同步访问共享变量导致 `sync.waitgroup` 表现异常的根本原因，并提供基于 `sync.mutex` 的线程安全解决方案，同时强调 race detector 在调试中的关键作用。
在 Go 中，sync.WaitGroup 是协调多个 goroutine 执行完成的常用工具，但它仅负责等待计数，不提供对共享数据的并发保护。初学者常误以为只要 wg.Wait() 正确阻塞主 goroutine，所有子 goroutine 对变量的修改就一定是安全、有序且完整的——这正是问题所在。
以下代码看似逻辑清晰，实则存在严重竞态条件（race condition）：
package main
import (
"fmt"
"sync"
)
func main() {
n := 100
var wg sync.WaitGroup
wg.Add(n)
x := 0
for i := 0; i < n; i++ {
go func() {
defer wg.Done()
x++ // ⚠️ 危险：非原子操作，多 goroutine 并发读-改-写
}()
}
wg.Wait()
fmt.Println(n, x) // 输出可能为 100 95、100 98 等，x < 100
}x++ 在底层对应三条指令：读取 x 值 → 加 1 → 写回内存。当多个 goroutine 同时执行该操作时，可能出现「两个 goroutine 同时读到 x = 5，各自加 1 后都写回 6」的情况，导致一次自增丢失。这就是典型的 read-modify-write 竞态。
✅ 正确解法：使用 sync.Mutex 保证临界区互斥访问：
package main
import (
"fmt"
"sync"
)
func main() {
n := 100
var wg sync.WaitGroup
var mu sync.Mutex // 声明互斥锁
wg.Add(n)
x := 0
for i := 0; i < n; i++ {
go func() {
defer wg.Done()
mu.Lock() // 进入临界区
x++
mu.Unlock() // 离开临界区
}()
}
wg.Wait()
fmt.Println(n, x) // 总是输出：100 100
}? 更优实践建议：
- 始终启用 race detector：运行 go run -race main.go，它会立即捕获并定位 x++ 处的数据竞争，输出详细栈信息；
- 若仅需原子计数，优先选用 sync/atomic 包（如 atomic.AddInt64(&x, 1)），性能更高且无需锁；
- 避免在闭包中直接捕获循环变量 i（本例虽未使用 i，但若改为 fmt.Println(i) 则会引发另一类常见 bug），应显式传参：go func(id int) { ... }(i)；
- WaitGroup.Add() 应在 goroutine 启动前调用，避免 Add() 和 Done() 时序错乱。
总结：sync.WaitGroup 是“等待同步器”，不是“数据同步器”。任何跨 goroutine 的共享变量读写，都必须通过 mutex、channel 或 atomic 等显式同步机制保护。理解这一点，是写出健壮 Go 并发程序的第一道门槛。
