本文详解 go 语言中多生产者（20 goroutines）与多消费者（200 goroutines）共用共享状态（如全局计数器 `seq`）时的典型竞态问题，揭示为何看似“并发安全”的 channel 协调仍无法避免数据竞争，并提供基于 `atomic` 和 channel 的正确同步方案。
在 Go 的并发模型中，channel 是协调 goroutine 的核心机制，但它仅保证通信同步，不自动保护共享内存。你的原始代码中，requestChan 和 generatorChan 均为无缓冲 channel，这确实强制了生产者（generateStuff）与消费者（concurrentPrint）之间的请求-响应配对同步——即每个 全局变量 seq 的非原子读写引发的数据竞争（data race）。
尽管 channel 协调了“谁来处理请求”，但一旦多个 generateStuff goroutine 同时从 requestChan 接收请求并执行 seq = seq + 1，就进入了临界区。由于该操作包含“读取 seq → 加 1 → 写回 seq”三步，且无任何互斥保护，在多核环境下（尤其启用 GOMAXPROCS > 1 时），极可能出现两个 goroutine 读到相同旧值、各自加 1 后写回，最终 seq 仅增加 1 而非 2——导致重复序号或跳号。即使当前输出看似有序，也仅是单核调度下的偶然现象，而非线程安全保证。
要彻底解决此问题，必须对共享状态 seq 的访问进行显式同步。推荐使用 sync/atomic 包提供的原子操作，它比 sync.Mutex 更轻量且无锁：
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
import "sync/atomic" // 安全递增并返回新值 s := atomic.AddUint64(&seq, 1)
以下是重构后的健壮实现（已移除竞态、增强可读性与可观测性）：
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 {
s := atomic.AddUint64(&seq, 1) // ✅ 原子递增，线程安全
log.Printf("Gen:%2d ← Req:%3d | Seq:%d", genID, reqID, s)
generatorChan <- s
}
}
func worker(id int, work *sync.WaitGroup) {
defer work.Done()
for i := 0; i < 5; i++ {
requestChan <- uint64(id)
resp := <-generatorChan
log.Printf("\tWorker:%3d → Seq:%4d", id, resp)
}
}
func main() {
log.SetFlags(log.Lmicroseconds | log.Lshortfile)
const (
numGen = 20
numWorker = 200
)
var wg sync.WaitGroup
// 启动生产者
for i := 0; i < numGen; i++ {
go generator(i)
}
// 启动消费者
wg.Add(numWorker)
for i := 0; i < numWorker; i++ {
go worker(i, &wg)
}
wg.Wait()
close(requestChan) // 优雅关闭生产者
}关键改进说明：
- ✅ 消除数据竞争：用 atomic.AddUint64 替代 seq++，确保计数器操作绝对原子化；
- ✅ 提升可观测性：采用 log（线程安全）替代 fmt.Println，避免日志交错；
- ✅ 增强鲁棒性：为 channels 添加小缓冲（如 make(chan uint64, 10)），缓解突发请求压力；
- ✅ 保障终止：close(requestChan) 通知所有 generator 退出循环，避免 goroutine 泄漏；
- ⚠️ 调试建议：开发阶段务必启用竞态检测器：go run -race your_program.go，它会精准定位所有共享变量冲突点。
总结：Go 的 channel 是“通信”工具，不是“同步”银弹。多生产者/多消费者场景下，channel 解决任务分发与结果传递，而 atomic 或 mutex 解决状态一致性。二者协同，方能构建真正可靠的并发系统。切勿依赖调度巧合——用工具验证，用原子操作加固，才是工程实践的正道。
