17370845950

竞态条件必须显式检测和修复，go test -race 是唯一可靠的运行时探测手段；它基于TSAN动态插桩，捕获无同步的并发读写，仅用于测试环境，启用后性能下降2–5倍，需用WaitGroup或channel确保goroutine完成后再断言。

Go测试中竞态条件不会自动消失，必须显式检测 + 显式修复；go test -race 是唯一可靠的运行时探测手段，不加它就等于没测并发安全。

用 go test -race 启动竞态检测器

Go 内置的 race detector 是基于动态插桩的 C++ 工具（tsan），它会在编译时注入内存访问跟踪逻辑，运行时捕获“同一地址被不同 goroutine 无同步地读+写”这类冲突。

• 必须加 -race 标志，go test 默认完全不启用 —— 这不是可选功能，是开关
• 只对 go test 生效，go run 或 go build 加 -race 会报错（需用 go run -race）
• 启用后二进制体积增大、性能下降 2–5 倍，**仅用于测试环境**，严禁上线
• 检测到竞态时输出含：冲突变量名、读/写 goroutine 的完整调用栈、发生位置（文件:行号）

go test -race -v ./...  
# 或针对单个测试文件  
go test -race -run=TestCounterConcurrent counter_test.go

写并发测试时必须控制 goroutine 生命周期

常见错误是启动 goroutine 后没等它们结束就断言结果，导致 counter 还在被修改，测试结果随机波动，且 -race 可能漏报 —— 因为竞态发生在断言之后。

• 必须用 sync.WaitGroup 或 channel 确保所有并发操作完成后再检查状态
• 避免用 time.Sleep 等待，它不可靠、慢、且掩盖真正问题
• 测试应可重复：每次跑都该得到相同结果（比如 1000 次 increment → 结果必须是 1000）
• 如果测试本身 panic 或死锁，-race 不会触发，要先保证测试能跑完

func TestCounterConcurrent(t *testing.T) {
    var c Counter
    var wg sync.WaitGroup
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            c.Inc()
        }()
    }
    wg.Wait() // 关键：必须等完再断言
    if got := c.Load(); got != 1000 {
        t.Errorf("expected 1000, got %d", got)
    }
}

修复竞态不能只靠加锁，得看场景选对原语

加 sync.M

utex 是最直觉的做法，但不是万能解。锁太重、粒度错、或根本不需要锁，都会引入新问题。

• 纯计数器类整型操作：优先用 sync/atomic，如 atomic.AddInt64(&c.val, 1) —— 无锁、快、安全
• 读多写少结构体（如配置缓存）：用 sync.RWMutex，读不用互斥，写才锁
• 复杂状态机或需要串行化逻辑（如订单状态流转）：用 channel 把操作委托给单个 goroutine，天然隔离
• 锁必须和数据绑定封装，别让调用方自己记着要 Lock/Unlock —— 容易漏、难维护

type Counter struct {
    mu  sync.RWMutex
    val int64
}
func (c *Counter) Inc() { c.mu.Lock(); defer c.mu.Unlock(); c.val++ }
func (c *Counter) Load() int64 { c.mu.RLock(); defer c.mu.RUnlock(); return c.val }

最容易被忽略的一点：竞态检测器只能发现「已执行到的」竞争路径。如果某个临界区在测试中从未被两个 goroutine 同时命中（比如因调度巧合或数据分支未覆盖），-race 就不会报警 —— 所以测试用例要足够“狠”，比如开 100+ goroutine、混入读写、打乱执行节奏，才能把隐藏的竞态逼出来。