Go 语言中 channel 实现任务同步在高并发任务流中应用

Go 中多生产者任务同步需用 sync.WaitGroup 配合 channel 关闭，因多生产者无法协调 close 时机，易 panic 或死锁；WaitGroup 确保主 goroutine 唯一、终局性关闭通道，消费者可安全 range；缓冲大小仅控制积压边界，不提升吞吐。

直接说结论：Go 里用 channel 做任务同步，真正的精髓不是“怎么把数据从一个地方搬到另一个地方”，而是“怎么用一根无形的指挥棒，让大家步调一致”。它的场景特别清晰：要么是“等你给我一个信号，我再继续”，要么是“等所有人都收工了，我们再来个总结”。很多新手一上来就 chan struct{} 堆砌 select，结果不是死锁就是漏信号。说实话，真正稳如老狗的方案，几乎离不开 sync.WaitGroup 和关闭 channel 这“黄金搭档”。

为什么不能只靠 channel 关闭来判断所有 goroutine 完成

一个常见的误区是：只要所有生产者都调了 close(ch)，消费者用 for range ch 就能安全退出。想法是好的，但现实很骨感——close() 这个操作，每个 channel 一辈子只能被调用一次，而且必须是发送方来调。多个生产者 goroutine 同时干活，谁来调？什么时候调？这就成了一个死结。

• 如果多个生产者都抢着 close(ch)，第二次调用会直接 panic，报错消息就是 "close of closed channel"。
• 如果让主 goroutine 自己等着所有生产者结束再去关，又得额外写一套计数器或别的同步机制来“打报告”，那还不如直接用现成的 sync.WaitGroup，省心又省力。
• range 只有在 channel 被关闭，并且其缓冲区/队列里所有数据都被读完时才会退出。万一某个生产者卡住了没发完，或者它退出了但缓冲区里还有数据没被读完，range 就可能提前退出或者延迟退出，逻辑上很容易出问题。

WaitGroup + channel 关闭才是多生产者同步的标准解法

正确的模式其实很清晰，很多走弯路的朋友都倒在这点上：主 goroutine 先用 wg.Add(n) 声明要等 n 个生产者；每个生产者干完活后调用 wg.Done() 报个到；然后主 goroutine 在 wg.Wait() 返回后，唯一一次、终局性地调用 close(ch)。这就是那把“指挥棒”。

• 发送方（生产者）：只负责把数据扔进 channel，关不关 channel 跟它没关系。
• 接收方（消费者）：只负责从 channel 里读数据，不需要关心是谁发的、发了多少。
• 主 goroutine：扮演“调度员”角色，等所有生产者都“打卡下班”了，再关闭通道。这个关闭动作是单点的、原子的、不可逆的，彻底避免了竞争条件。
• 消费者可以安心地用 for result := range results 来读，因为关闭的时机是确定且安全的。

关键代码片段是这样的：

results := make(chan Result, 100)
var wg sync.WaitGroup

// 启动 5 个生产者
for i := 0; i < 5; i++ {
    wg.Add(1)
    go func(id int) {
        defer wg.Done()
        for _, task := range getTasks(id) {
            results <- process(task)
        }
    }(i)
}

// 主 goroutine 等全部完成，再关通道
go func() {
    wg.Wait()
    close(results)
}()

// 消费者安全读取
for r := range results {
    handle(r)
}

缓冲大小不是性能万能药，而是阻塞边界的显式声明

make(chan T, N) 里的缓冲大小 N，说白了就是一个“我最多能容忍多少任务积压”的声明。它并不会让系统跑得更快，只是把阻塞的时机和位置从“生产者写入时”挪到了“缓冲区满时”。

• N=0（无缓冲）：每次 ch <- data 都像一次握手，必须等别人来取走才能继续。适合强依赖、低延迟的同步场景。
• N=1：至少能缓存一个结果，让生产者不会因为消费者一时半会的卡顿就立刻停摆。常用于轻量级工作池。
• N 过大（比如 10000）：内存占用直接起飞，而且还可能把消费者处理慢的问题掩盖起来。等到任务堆积如山、延迟大到不可控时，才发现解决问题的钥匙根本不在 channel 上。
• 真正的瓶颈往往在消费者那边，比如写数据库、调 HTTP 接口。增大缓冲只是把压力从 channel 转移到了下游，不解决根本问题。

select + done channel 是取消与超时的标配，但别滥用 default

当任务需要响应中断或限时时，select 配合 ctx.Done() 或 time.After() 是标准操作。但很多人顺手就加个 default 分支，这很容易导致忙轮询，甚至把关键信号给“吞掉”。

• 如果写 select { case <-done: return; default: doWork() }，那 doWork() 就会不受控制地循环执行，即使 done 已经发出了退出信号。
• 正确的做法是把 default 去掉，让 goroutine 在没有信号来时优雅地挂起。或者用 time.AfterFunc 实现一次性超时触发。
• 多个 channel 同时就绪时，select 会随机挑选一个执行。不要依赖 case 的书写顺序来做逻辑控制，那是不可靠的。
• 如果真想非阻塞地探测某个 channel 是否就绪，可以用 select { case x := <-ch: ... default: ... }，但仅限于明确需要“试探”的场景。

最后提醒一个最容易忽略的点：channel 的生命周期管理必须和 goroutine 的启动/退出严格对齐。一个没被消费的 channel，或者一个永远不退出的生产者 goroutine，都会导致程序无法正常终止。这种泄漏不会报任何错误，只会让程序“看起来还活着”，实际上已经卡死在某条 ch <- 或 <-ch 上不动了。