Go中实现生产者-消费者模型应使用channel+goroutine:生产者向chan T发送数据,消费者从中接收,避免共享变量加锁,契合“不通过共享内存通信”原则。
Go 里实现生产者-消费者模型,最直接、最符合语言设计哲学的方式是用 channel + goroutine,而不是加锁或条件变量。它天然支持解耦、背压和优雅退出。
chan 做数据管道,别用共享变量错误做法是让多个 goroutine 读写同一个 slice 或 map 并加 sync.Mutex —— 这违背 Go 的“不要通过共享内存来通信”原则。正确路径是把 channel 当作唯一的数据交接点:
chan T 发送(ch )
chan T 接收(item := )
make(chan int, 100))可缓解瞬时生产过快for item := range ch 自动退出,或用 val, ok := 判断是否已关闭
close() 只能由生产者调用,且只能调一次这是最容易出 panic 的地方。如果多个生产者共用一个 channel,谁关、何时关、关几次,必须明确约定。常见错误:
close(ch) → panic: close of closed channelclose(ch) → 第二次 close 直接 panic推荐方案:用 sync.WaitGroup 等待所有生产者结束,再由主 goroutine 统一 close:
var wg sync.WaitGroup ch := make(chan int, 10)// 启动生产者 for i := 0; i < 3; i++
{ wg.Add(1) go func(id int) { defer wg.Done() for j := 0; j < 5; j++ { ch <- id*10 + j } }(i) }
// 启动消费者 go func() { wg.Wait() close(ch) // 所有生产者完成后再关 }()
// 消费 for val := range ch { fmt.Println("got:", val) }
channel 本身支持多路并发读(只要没缓冲或缓冲未满,发送不会阻塞),无需额外分发逻辑。但要注意:
select 转发到多个下游 channeldefault 分支做非阻塞尝试,或结合 time.After 防止忙等context.Context,别靠 channel 关闭硬等真实场景中,你往往需要“随时中断整个流程”,比如超时、信号中断、上游取消。仅靠 close(ch) 不够灵活 —— 它无法通知正在阻塞在 上的 goroutine “别等了,退出”。这时必须引入 context.Context:
ctx.Done() 检查是否被取消,提前退出循环select { case val := 实现可中断接收
time.Sleep 或空 for {} 等待,那会卡死 goroutine 且无法响应 cancel真正麻烦的是上下文传播和错误归并 —— 比如一个消费者 panic 了,如何让其他 goroutine 也快速退出?这需要组合 errgroup.Group 或手动管理 cancel 函数。