Go 信号量 + WaitGroup 控制并发数

如果只用信号量，主协程在 for 循环结束后就会直接退出 main，新启动的协程还没来得及执行。wg.Wait() 确保 main 等所有子协程完成后才退出。

1

sem := make(chan struct{}, 3)

• make 在内存中开辟了一块空间，最多存放 3 个 struct{}
• 初始状态是空的，已占用 0，剩余容量 3
• struct{} 是 Go 中占用 0 字节的类型，只用来”占位置”，不传递数据

类比： 建了一个停车场，里面有 3 个车位，当前全是空的。

1
2
3
4

for i := 0; i < 10; i++ {
    wg.Add(1)
    ...
}

• wg 内部有一个计数器，Add(1) 让计数器 +1
• 必须有对应次数的 wg.Done() 把计数器减回 0，wg.Wait() 才会放行

类比： 停车场门口有个登记本，每派一辆车出去就划一笔，等 10 笔都勾掉才说明活干完了。

1

sem <- struct{}{}

两种情况：

类比： 车开到停车场门口 — 有空位直接开进去，没空位在门口排队等。

1

go func(id int) { ... }(i)

• go 关键字后面的函数会放到后台异步执行
• 主循环不会等它，继续下一次循环
• (i) 把当前 i 的值复制一份传给 id，每个协程拿到的是独立的值

类比： 车进了停车场后各自去干活，停车场管理员（主循环）继续放行下一辆车。

1
2
3
4

defer func() {
    <-sem
    wg.Done()
}()

不管任务执行成功还是中途崩溃，信号量必须被释放、WaitGroup 必须被通知，否则其他协程会永远阻塞、主协程永远等不到完成。

注意顺序： <-sem 必须在 wg.Done() 前面 — 先释放信号量让排队的循环继续，再通知 WaitGroup。

1
2

fmt.Printf("任务 %d 执行\n", id)
time.Sleep(time.Second)

打印任务编号，time.Sleep(1秒) 模拟耗时操作。这 1 秒内协程占着信号量的一个名额。

1
2
3
4

defer func() {
    <-sem     // 1. 从通道取出一个值 → 腾出空位
    wg.Done() // 2. WaitGroup 计数器 -1
}()

• <-sem — 通道已占用容量 -1。如果有循环正阻塞在 sem <- struct{}{} 上，那个发送操作会立即成功
• wg.Done() — 计数器 -1，从 10 减到 0 时 wg.Wait() 放行

1

wg.Wait()

主协程在这里阻塞，直到 WaitGroup 计数器归零。

如果不写这行： for 循环跑完后 main 函数直接结束，程序退出，已启动的协程还没执行完就被强制终止，你可能只能看到 2~3 个任务的输出。

在 Go 1.22 之前，for 循环变量在所有迭代间共享。如果直接写 go func() { fmt.Println(i) }()，所有协程可能打印同一个值。传参 (i) 可以把当前值复制一份传入，确保每个协程拿到独立的值。

Go 1.22+ 已经修复了这个问题，循环变量每次迭代都是新的，但传参写法仍然是好习惯。

取决于任务类型：

• CPU 密集型 — 设为 runtime.NumCPU()，不超过 CPU 核心数
• I/O 密集型（网络请求、数据库查询）— 可以设得大一些（如 50~100），因为 I/O 等待时不占 CPU
• 不确定 — 从 3~10 开始，根据实际压测调整

不建议换。先 <-sem 释放信号量让后续循环继续，再 wg.Done() 通知完成。如果反过来：

1
2
3
4

defer func() {
    wg.Done()   // 先通知完成
    <-sem       // 再释放信号量
}()

极端情况下，如果最后一个协程执行 wg.Done() 后还没来得及 <-sem，主协程在 wg.Wait() 返回后继续执行后续代码，而信号量还占着没释放（虽然程序快退出了通常没问题，但逻辑上不严谨）。

Go 标准库 golang.org/x/sync/semaphore 提供了 sync.Semaphore，但它需要配合 context 使用，且性能不如通道。通道作为信号量是 Go 社区推荐的做法，语义清晰且性能更好。