本文介绍在 go 中等待缓冲通道达到容量上限的两种方法：使用 sync.waitgroup 确保所有 goroutine 完成写入，或通过 len(ch) 轮询检查通道长度；重点推荐 waitgroup 方案，因其线程安全、语义清晰且无需忙等待。
本文介绍在 go 中等待缓冲通道达到容量上限的两种方法：使用 sync.waitgroup 确保所有 goroutine 完成写入，或通过 len(ch) 轮询检查通道长度；重点推荐 waitgroup 方案，因其线程安全、语义清晰且无需忙等待。
在 Go 并发编程中，常需协调多个 goroutine 向同一缓冲通道写入数据，并在所有数据就绪后统一处理——例如等待一个容量为 3 的 chan int 被完全填满（即 len(difs) == cap(difs)），再执行后续逻辑。虽然 len(difs) 可实时获取当前队列长度，但它不能直接用于阻塞等待，因为 Go 不支持基于通道长度的原生同步原语。
✅ 推荐方案：使用 sync.WaitGroup
sync.WaitGroup 是最符合 Go 习惯、高效且线程安全的解决方案。它不依赖轮询，避免了 CPU 空转，语义明确表达“等待 N 个任务完成”。
以下是重构后的完整示例：
package main
import (
"fmt"
"sync"
)
func main() {
// 假设 a 已初始化，且满足 0 < n < len(a)-1
a := []int{1, 2, 3, 4, 5}
n := 2
var wg sync.WaitGroup
wg.Add(3) // 预期启动 3 个 goroutine
difs := make(chan int, 3)
go routine(a[:n], difs, &wg)
go routine(a[n+1:], difs, &wg)
go routine(a[n-1:n+1], difs, &wg)
wg.Wait() // 阻塞直到所有 goroutine 调用 wg.Done()
// 此时通道中已存入全部 3 个结果（按发送顺序）
results := make([]int, 3)
for i := range results {
results[i] = <-difs
}
fmt.Println("All results:", results) // 输出: All results: [result1 result2 result3]
}
func routine(a []int, out chan<- int, wg *sync.WaitGroup) {
defer wg.Done() // 确保无论函数如何退出都调用 Done()
// 模拟耗时计算（实际中可替换为复杂逻辑）
var result int
for _, v := range a {
result += v
}
out <- result
}⚠️ 关键注意事项：
- WaitGroup 必须传指针（*sync.WaitGroup），否则复制会导致计数器失效；
- wg.Add() 必须在 goroutine 启动前调用，避免竞态；
- defer wg.Done() 应置于 goroutine 函数开头，确保异常退出时仍能正确计数。
❌ 不推荐方案：轮询 len(ch)（仅作技术参考）
虽然 len(difs) 可返回当前未读元素数量，但若用于等待，需配合循环与 time.Sleep，既低效又易出错：
// ❌ 不推荐：忙等待 + 睡眠，破坏响应性与资源效率
for len(difs) < cap(difs) {
time.Sleep(1 * time.Millisecond) // 不精确、浪费 CPU、不可靠
}
// ... then read该方式违背 Go “不要通过共享内存来通信”的哲学，且无法保证原子性——即使 len(ch) 返回 3，也可能因并发读取导致瞬间变化。
✅ 总结
- 优先使用 sync.WaitGroup：清晰表达协作意图，零开销，天然适配“N 个任务完成后统一消费”的场景；
- 避免对 len(ch) 做同步假设：它反映瞬时状态，不是同步原语；
- 若需进一步解耦“生产”与“消费”，可结合 close(ch) + range，但本例中因需保留所有结果，WaitGroup + 手动接收 更直接可控。
最终，WaitGroup 不仅解决了“等待通道填满”的表层需求，更体现了 Go 并发模型中“显式协作优于隐式轮询”的设计哲学。
