Go 并发任务怎样用带缓冲 channel 限制同时执行数

要限制 Go 并发任务的同时执行数，可以把一个带缓冲的 channel 当作“槽位池”：创建容量为 limit 的 channel，任务开始前发送一个令牌，任务结束时接收令牌。缓冲区满了，新的发送就会阻塞，因此真正进入受限资源的任务数不会超过 limit。关键不在“启动了多少个 goroutine”，而在“有多少个任务拿到了槽位”。

为什么 channel 容量可以表示并发上限

Go 规范规定，带缓冲 channel 在缓冲区未满时发送不会阻塞，缓冲区满后发送才会等待；接收会移走一个已排队元素。把每个元素看作一个“已占用槽位”，容量为 3 就意味着最多有 3 个任务同时持有令牌。len(ch) 可以看到当前缓冲区中的元素数量，cap(ch) 表示容量，但生产代码不应把读取 len 当成“先判断再发送”的并发控制，因为检查和发送之间可能已有其他 goroutine 改变状态。

在任务入口获取槽位，在退出路径释放

最小写法是让发送操作承担等待：发送成功表示任务已经取得一个槽位，任务结束后接收令牌表示归还。释放动作紧跟在成功获取之后用 defer 注册，这样函数从正常返回、错误返回到中途 return 都不会漏掉槽位。

package main

import (
	"fmt"
	"sync"
	"time"
)

func runAll(ids []int, limit int) {
	sem := make(chan struct{}, limit) // 每个元素代表一个正在使用的并发槽位
	var wg sync.WaitGroup

	for _, id := range ids {
		id := id // 让闭包持有本轮任务的值
		wg.Add(1)
		go func() {
			defer wg.Done() // 无论任务怎样返回，都要通知等待方
			sem 

这个模式允许提前创建很多 goroutine，但只有取得槽位的任务会进入受限区域。若输入量可能持续增长，仍要注意“每个输入创建一个 goroutine”会把等待压力转移到 goroutine 数量上；这时应改用固定 worker，让队列长度和 worker 数量一起受控。

释放必须覆盖错误、取消和提前返回

最常见的故障是只在成功分支释放令牌，或者把释放写在某个业务分支的末尾。一次异常返回就会永久占住一个槽位，最终所有新任务都阻塞，看起来像 channel “死锁”。正确顺序是：先成功获取，再立即注册释放；不要在发送前注册接收，也不要把释放交给调用者猜测。

func doOne(ctx context.Context, sem chan struct{}, id int) error {
	select {
	case sem 

示例中的 callRemote 代表业务依赖，重点是等待槽位本身也应可取消。若直接写成 sem ，调用方取消时，正在等槽位的 goroutine 仍会继续等待，直到前面的任务释放位置。

带缓冲 channel 和固定 worker 怎么选

还要区分并发与并行：容量限制的是同时处于受限区域的任务数，不保证 CPU 上一定有同样数量的线程并行执行。limit 应按数据库连接、对端配额、文件句柄或内存预算来定，而不是机械地取 CPU 核数。

排查并发数不受控的几个信号

1. 确认槽位发送发生在真正的受限调用之前，而不是任务全部做完才发送。
2. 确认每次成功发送都一定有一次接收，且接收放在 defer 中。
3. 确认 limit 是正数；容量为 0 的 channel 是无缓冲同步点，不是可积累的槽位池。
4. 确认没有把同一个槽位 channel 在多个批次之间错误关闭；信号量通常不需要关闭。
5. 确认 WaitGroup.Add、Done 和任务启动路径成对出现，避免主 goroutine 提前退出。

常见问题

channel 容量是 10，是否代表最多创建 10 个 goroutine？

不是。它只限制同时持有令牌、进入受限区域的任务数；如果每个输入都单独启动 goroutine，等待槽位的 goroutine 仍可能超过 10 个。

为什么任务报错后，后面的任务一直卡住？

通常是错误路径没有归还令牌。把释放动作放在成功获取后的 defer 中，并让等待槽位使用可取消的 select。