本文详解 go 多生产者/多消费者场景中常见的数据竞争问题，揭示全局变量非原子操作的风险，并通过 `atomic` 包和通道协作实现线程安全的序列生成，附可运行示例与调试建议。
在 go 的并发模型中，多生产者-多消费者（MPMC） 是一个经典但极易踩坑的模式。你提供的代码看似能稳定输出 1–1000 的递增序列，实则掩盖了一个严重问题：对全局变量 seq 的非同步读写——这构成了典型的数据竞争（data race）。
? 为什么“看起来正常”？—— 并发的假象
你的代码中，20 个 generateStuff goroutine 共享并修改 seq：
seq = seq + 1 // ❌ 非原子操作：读取 → 计算 → 写入，三步间可被抢占理论上，若两个 goroutine 同时执行该行，可能都读到 seq=5，各自加 1 后都写回 6，导致丢失一次递增。但实际运行中未观察到重复或跳变，原因在于：
- GOMAXPROCS=1（默认）：单 OS 线程调度下，goroutine 协作式让出（如 channel 阻塞），降低了并发抢占概率；
- requestChan 和 generatorChan 均为无缓冲通道：天然形成同步点，使 goroutine 串行化地“排队”访问 seq，偶然掩盖了竞态；
- 竞争窗口极小：在单核上，两次读-改-写操作重叠概率低，但不等于不存在——这是非确定性 bug，而非正确逻辑。
⚠️ 关键认知：“没出错” ≠ “安全”。数据竞争是未定义行为（UB），可能导致静默错误、崩溃、结果错乱，且在高负载、多核或不同 Go 版本下极易复现。
✅ 正确解法：用原子操作替代共享变量
修复核心在于消除对 seq 的竞态访问。推荐使用 sync/atomic 包的原子增操作：
import "sync/atomic" // 替换 seq = seq + 1 为： s := atomic.AddUint64(&seq, 1) // ✅ 原子读-增-写，返回新值atomic.AddUint64 保证整个操作不可分割，无论多少 goroutine 并发调用，seq 的最终值必为准确递增（1000 次调用 → seq==1000），且每个返回值唯一。
? 完整可验证示例（含日志与资源清理）
以下为优化后的生产就绪版本，已移除竞态、增强可观测性，并确保通道优雅关闭：
package main import ( "log" "sync" "sync/atomic" ) var seq uint64 = 0 var generatorChan = make(chan uint64, 10) // 可选：加小缓冲提升吞吐 var requestChan = make(chan uint64, 10) // 同上 func generator(genID int) { for reqID := range requestChan { // 自动退出：当 requestChan 关闭时 s := atomic.AddUint64(&seq, 1) log.Printf("Gen:%2d ← Req:%3d → Seq:%d", genID, reqID, s) generatorChan <- s } } func worker(id int, wg *sync.WaitGroup) { defer wg.Done() for i := 0; i < 5; i++ { requestChan <- uint64(id) result := <-generatorChan log.printf("tworker:%3d → got seq:%d", id, result) } func main() { log.setflags(log.lmicroseconds | log.lshortfile) const ( numgenerators =20 numworkers = 200 ) var wg sync.waitgroup>? 调试与验证技巧
强制多核暴露问题
在程序开头添加：
import "runtime" func main() { runtime.GOMAXPROCS(4) // 强制使用 4 OS 线程，显著提高竞态触发概率 // ... 其余逻辑 }避免 fmt.Println 的干扰
fmt 包内部有锁，可能意外串行化输出，掩盖调度细节；log 包更轻量且行为可预测，适合并发调试。
✅ 总结：MPMC 设计黄金法则
| 原则 | 说明 |
|---|---|
| 永不裸露共享状态 | seq 等跨 goroutine 变量必须通过原子操作（atomic）、互斥锁（sync.Mutex）或通道（channel）保护 |
| 通道是同步原语，不是共享内存 | 利用 channel 实现 goroutine 间通信（CSP 模型），而非争抢同一内存地址 |
| 用工具验证，而非依赖观察 | go run -race 是并发开发的必备步骤，不能仅凭“输出正确”判断逻辑安全 |
| 关闭通道明确生命周期 | 使用 close(ch) 通知接收方停止读取，避免 goroutine 泄漏 |
遵循以上实践，你不仅能写出正确的 MPMC 系统，更能深入理解 Go 并发的本质：通过通信共享内存，而非通过共享内存通信。