17370845950

Go并发安全必须通过-go test -race测试暴露竞态，结合WaitGroup高概率触发竞争、atomic/Mutex修复后确保-race静默，并用goleak检查goroutine泄漏。

Go语言的并发安全性不能靠肉眼判断，必须通过有针对性的单元测试来暴露竞态条件。核心方法是结合 -race 竞态检测器 + 可重复触发的并发操作 + 显式同步控制。

用 -race 启动竞态检测是前提

Go 自带的 race detector 是发现数据竞争最直接有效的工具。它不是可选插件，而是必须开启的测试基础：

• 运行测试时加上 go test -race，所有 go run 或 go build 也应加 -race 做临时验证
• 注意：开启后程序会变慢、内存占用升高，仅用于测试环境，不可用于生产构建
• 一旦检测到竞争，会打印出读/写发生在哪一行、哪个 goroutine，信息非常具体，直接定位问题源头

构造高概率触发竞争的并发测试场景

单纯起几个 goroutine 调用函数往往不够。要让竞争“大概率发生”，需主动制造临界区压力：

• 用 sync.WaitGroup 控制多个 goroutine 同时（或快速连续）访问共享变量或方法
• 循环多次（比如 100–1000 次），增加调度不确定性带来的碰撞机会
• 避免在 goroutine 内部加 sleep 或 channel 等人为同步——这反而会掩盖问题
• 示例：测试一个计数器 Inc() 方法，启动 10 个 goroutine 各自调用 100 次，最后检查总数是否为 1000

用 sync/atomic 或 sync.Mutex 修复后，测试必须能通过 -race

修复不等于“看起来不 panic”——必须确保 -race 完全静默：

• 优先用 atomic（如 atomic.AddInt64）处理简单数值操作，性能好且无锁
• 涉及多字段更新、条件判断或复杂逻辑时，用 sync.Mutex 或 sync.RWMutex 包裹临界区
• 切忌只加锁但没覆盖全部读写路径（比如忘了对读操作加锁），测试会再次报 race
• 修复后重新跑 go test -race，零警告才算真正安全

补充：用 go.uber.org/goleak 检查 goroutine 泄漏

并发测试常伴随 goroutine 忘记结束，导致资源堆积。这不是数据竞争，但属于并发缺陷：

• 在测试函数前后调用 goleak.VerifyNone(t)，自动检查是否有意外存活的 goroutine
• 特别适合测试含 channel、timer、后台 worker 的代码
• 和 -race 配合使用，构成并发健壮性的双重保障

基本上就这些。不复杂但容易忽略的是：别只写“能跑通”的测试，要写“能让 race detector 报警”的测试——那才是并发安全的试金石。