sync.WaitGroup 的作用，说白了就是把多个协程的执行节奏“对齐”：主协程先通过 Add(n) 把任务数量设好，每个协程处理完自己的工作后调用 Done()，而主协程再用 Wait() 挂起等待，直到所有任务都结束；这里有两个关键点不能含糊——Add 必须放在 goroutine 启动之前调用，Done 也必须确保一定会执行，不能只想着依赖 defer 了事。

怎么用 sync.WaitGroup 控制多协程批量执行队列

直接用 sync.WaitGroup 是最轻量、最可控的方式，不用引入第三方库也能精准等所有任务结束。它不负责调度或限流，只做“计数+阻塞等待”，适合你明确知道任务总数、且希望主协程同步收尾的场景。

常见错误是 Add() 调用时机不对：必须在启动 goroutine 之前调用，否则可能漏计数或 panic；另外 Done() 必须在每个 goroutine 结束前调用，不能靠 defer（万一 panic 没触发 defer 就漏了）。

• WaitGroup.Add(n) 要在 for 循环外或循环开始前一次性加总数量，别在 goroutine 里加
• 每个 goroutine 执行完逻辑后，立刻调用 wg.Done()，不要依赖 defer（尤其当有 recover 或提前 return 时）
• 主 goroutine 中用 wg.Wait() 阻塞，不是轮询或 sleep

var wg sync.WaitGroup
tasks := []string{"task1", "task2", "task3"}
wg.Add(len(tasks))
for _, t := range tasks {
go func(task string) {
defer wg.Done() // 这里用 defer 是安全的，因为函数体简单无 panic 风险；但复杂逻辑建议显式调用
process(task)
}(t)
}
wg.Wait() // 主协程卡在这里，直到全部完成

怎么用 chan + select 实现带缓冲的批量任务队列

当任务源源不断地涌来时，比如来自 HTTP 请求、文件读取或者消息队列，如果还想把并发数牢牢控制住，比如始终限制在最多 5 个 goroutine 同时运行，那就需要借助 channel 来做任务分发。思路其实很清楚：先用一个输入 channel 接住任务，再由固定数量的 worker 去取任务处理，最后配合 sync.WaitGroup 等待所有 worker 全部退出。

容易踩的坑是 channel 关闭时机不对：必须由生产者关闭，且要在所有任务发送完之后；worker 不能用 range 遍历未关闭的 channel，会永久阻塞。

• worker 数量 = 并发上限，硬编码或配置化都行，别动态伸缩（除非你真需要）
• 任务 channel 类型要具体，比如 chan string，别用 interface{} 增加类型断言开销
• worker 内部用 select + default 可做非阻塞尝试，但批量队列一般不需要；重点是用 <-ch 阻塞取任务

tasks := make(chan string, 100)
wg.Add(5) // 5 个 worker
for i := 0; i < 5; i++ {
go func() {
defer wg.Done()
for task := range tasks { // channel 关闭后自动退出
process(task)
}
}()
}
// 发送任务
for _, t := range allTasks {
tasks <- t
}
close(tasks) // 必须关闭，否则 worker 永远卡在 range
wg.Wait()

为什么别直接用 runtime.GOMAXPROCS 控制并发数

runtime.GOMAXPROCS 控制的是 OS 线程数上限，不是 goroutine 并发数。设成 1 不会让 goroutine 串行执行，只是限制了能并行运行的 OS 线程数——goroutine 调度仍由 Go runtime 自动管理，大量 goroutine 还是会并发抢占。想限流，得靠 channel 缓冲或信号量。

典型误用是看到 CPU 占用高就调小 GOMAXPROCS，结果发现任务延迟反而更大，因为调度器被迫更频繁切换，且 IO 密集型任务根本不受它影响。

• GOMAXPROCS 默认等于 CPU 核心数，多数情况不用改
• IO 密集任务（HTTP、DB）完全不依赖它，goroutine 会在等待时自动让出
• 真要压测或调试调度行为才临时调整，上线环境别碰

怎么用 semaphore（信号量）做细粒度并发控制

Go 标准库没提供信号量，但用 chan struct{} 一行就能实现。它比 channel 分发更轻，适合“每次只允许 N 个 goroutine 进入临界区”的场景，比如限制数据库连接、API 调用频次、文件句柄占用。

注意别把信号量 channel 当任务队列用：它不存数据，只做通行许可；而且必须确保每个 <-sem 都配对 sem <- struct{}{}，漏了就会死锁。

• 初始化：sem := make(chan struct{}, 3) 表示最多 3 个并发
• 进入前：sem <- struct{}{}（阻塞直到有空位）
• 退出后：<-sem（释放一个位置，必须执行）
• 别用 len(sem) 判断剩余容量，它是瞬时值，不可靠

sem := make(chan struct{}, 5)
for _, task := range tasks {
go func(t string) {
sem <- struct{}{} // 获取许可
defer func() { <-sem }() // 保证释放，defer 在这里比显式调用更稳妥
process(t)
}(task)
}

实际写的时候，WaitGroup 和 chan 组合最常用；信号量只在需要精确控制资源占用时才上。别为了“看起来高级”而套模板，先想清楚你要控的是“任务总数”“并发数”还是“资源配额”。

《夸克》非常好用的免费AI浏览器

下载APP查看