Go 并发编程中的常见陷阱与 race detector 实战

Go 语言凭借其轻量级 goroutine 和简洁的 channel 机制，成为并发编程领域的热门选择。然而，并发带来的复杂性并未消失，反而以更隐蔽的方式潜伏在代码中。许多开发者在使用 Go 编写并发程序时，常常掉入一些经典陷阱，而 go test -race 或 go run -race 提供的 race detector 正是发现这些问题的利器。本文将梳理常见陷阱，并通过实战演示如何利用 race detector 定位数据竞争。

陷阱一：循环变量捕获

这是 Go 中最经典的并发陷阱之一。在 Go 1.22 之前，for 循环中的迭代变量是所有迭代共享的。当在循环内启动 goroutine 并引用该变量时，所有 goroutine 可能看到相同的最终值。

for i := 0; i < 5; i++ {
    go func() {
        fmt.Println(i) // 可能全部输出 5
    }()
}

修复方式：在循环体内创建局部变量 i := i，或通过参数传递。Go 1.22 已改变循环变量语义，每次迭代创建新变量，但旧代码迁移时仍需注意。

陷阱二：未同步的 map 读写

Go 的内置 map 不是并发安全的。同时读写 map 会直接导致程序崩溃（fatal error: concurrent map writes），而读写竞争则可能产生难以复现的错误。

m := make(map[int]int)
for i := 0; i < 100; i++ {
    go func(n int) {
        m[n] = n // 并发写，可能 panic
    }(i)
}

修复方式：使用 sync.RWMutex 保护，或改用 sync.Map（适用于读多写少场景）。

陷阱三：goroutine 泄漏

goroutine 泄漏是指 goroutine 因阻塞在 channel 发送/接收、锁等待或无限循环中而永远无法退出。泄漏的 goroutine 会占用内存和调度资源，长期运行的服务可能因此耗尽资源。

func leak() {
    ch := make(chan int)
    go func() {
        val := <-ch // 永远阻塞，无人发送
        fmt.Println(val)
    }()
    // ch 未被关闭，goroutine 无法退出
}

修复方式：使用 context.Context 控制生命周期，或确保 channel 有发送方/关闭方。对于超时场景，使用 select 配合 time.After。

陷阱四：WaitGroup 的误用

sync.WaitGroup 的 Add 必须在 Wait 之前调用，且 Add 的计数必须与 Done 匹配。常见错误是在 goroutine 内部调用 Add，导致 Wait 提前返回。

var wg sync.WaitGroup
for i := 0; i < 5; i++ {
    go func() {
        wg.Add(1) // 错误：Add 在 goroutine 内，Wait 可能已返回
        defer wg.Done()
        // ...
    }()
}
wg.Wait()

修复方式：在启动 goroutine 之前调用 wg.Add(1)。

陷阱五：误用 channel 作为锁

有些开发者用容量为 1 的 channel 模拟互斥锁，但忘记在 panic 时释放，或在多个 channel 操作间产生死锁。虽然可行，但 sync.Mutex 语义更清晰、性能更好。

race detector 实战

race detector 基于 ThreadSanitizer 算法，在运行时动态检测对共享内存的未同步访问。启用方式：

go test -race ./...
go run -race main.go
go build -race -o app

实战示例：检测数据竞争

创建 race_demo.go：

package main

import (
    "fmt"
    "sync"
)

func main() {
    var counter int
    var wg sync.WaitGroup

    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter++ // 数据竞争
        }()
    }
    wg.Wait()
    fmt.Println("counter =", counter)
}

运行 go run -race race_demo.go，输出类似：

==================
WARNING: DATA RACE
Write at 0x00c00001c0a8 by goroutine 8:
  main.main.func1()
      /path/race_demo.go:14 +0x44

Previous write at 0x00c00001c0a8 by goroutine 7:
  main.main.func1()
      /path/race_demo.go:14 +0x44

Goroutine 8 (running) created at:
  main.main()
      /path/race_demo.go:12 +0x88
==================
counter = 1000

race detector 精确指出了竞争地址、读写位置和 goroutine 创建栈。注意：即使最终结果看似正确（1000），竞争依然存在，结果不可预测。

修复并验证

使用 sync/atomic 或 sync.Mutex：

var counter int64
// ...
atomic.AddInt64(&counter, 1)

再次运行 -race，无警告输出，问题解决。

race detector 的局限性

• 仅检测实际发生的竞争：未执行的代码路径不会被检测。
• 运行时开销大：CPU 和内存开销约 5-10 倍，不适合生产环境常开。
• 需要触发条件：竞争窗口未命中时可能漏报。

因此，race detector 应作为 CI 流程的常规检查，配合 -count=10 多次运行提高覆盖率。

最佳实践总结

1. 优先使用 channel 通信，而非共享内存；必须共享时用锁保护。
2. 明确 goroutine 生命周期，使用 context 取消和超时。
3. 在 CI 中启用 -race，每次提交都跑一遍竞态检测。
4. 避免在循环中捕获变量，Go 1.22 后仍需注意闭包引用。
5. 使用 go vet 和 staticcheck 补充静态检查，与 race detector 形成互补。

并发编程的难度不在于写出能跑的代码，而在于写出在压力下依然正确的代码。race detector 是 Go 提供的一双“透视眼”，善用它，能让你在问题爆发前将其扼杀。

未经允许不得转载：任鹏个人博客 » Go 并发编程中的常见陷阱与 race detector 实战