Golang 如何限制并发数

Golang 如何限制并发数

用 sync.Semaphore（Go 1.21+）最稳妥

从Go 1.21开始，标准库自带的 sync.Semaphore 就成了生产环境的首选方案。它可不是一个简单的计数器，而是一个功能完备的信号量实现，支持权重、上下文取消，并且是panic安全的。

不过，用起来有几个细节必须注意，否则很容易踩坑：

• 初始化必须传 int64：比如你想限制8个并发，得写成 semaphore.NewWeighted(8)。如果传一个普通的 8（int类型），编译器会直接报错。
• sem.Acquire(ctx, 1) 必须检查返回的 error —— 如果上下文（ctx）已经取消或超时，这个方法会立刻返回 context.Canceled 或 context.DeadlineExceeded。这时候，可千万别再执行业务逻辑了。
• defer sem.Release(1) 要写在 goroutine 的最外层：这个习惯能保证，即使你的 doWork() 函数 panic 了，defer 语句依然会执行，令牌不会泄漏。
• 别把 ctx 只用在 Acquire 上：如果你的业务逻辑本身需要发起 HTTP 请求，记得把同一个 ctx 也传给 http.Client.Do()。否则，可能会出现信号量等到了，但请求却卡死在 TCP 握手阶段的尴尬情况。

用 chan struct{} 模拟信号量（兼容所有 Go 版本）

对于简单的场景，用通道（channel）模拟信号量是个轻量且零依赖的选择，所有 Go 版本都兼容。但这个方法有个致命弱点：极易翻车——只要漏释放一次令牌，后续所有任务就会永久阻塞。

想用对，得盯紧下面几点：

• 声明必须带缓冲：正确写法是 sem := make(chan struct{}, 5)。如果写成无缓冲的 make(chan struct{})，那就完全失去了限流的意义。
• 获取和释放必须严格配对：sem <- struct{}{} 是占位，<-sem 是归还。另外，别用 len(sem) 来判断是否能进入，它返回的是已占用的数量，可用数应该是 cap(sem) - len(sem)。
• 安全写法是 defer func() { <-sem }()：但要注意，闭包捕获的变量需要显式传入。比如在循环里启动 goroutine，应该写成 go func(s chan struct{}) { s <- struct{}{}; defer func() { <-s }(); ... }(sem)，否则闭包捕获的可能是循环的最终值，导致所有任务挤进同一个“槽位”。
• 别在 select 里只写 case <-sem: 就开干：万一任务在注册 defer 之前就 panic 了，令牌可就找不回来了。

HTTP 请求并发限制，关键位置在哪

限制 HTTP 请求并发，关键在于把限流逻辑放在真正发起网络调用的那一刻之前，而不是在启动 goroutine 时，更不是在 for 循环外面。很多人把信号量放错了位置，结果下游服务的 QPS 照样被打满。

• 正确位置：在 http.NewRequest() 之后，client.Do() 之前。这样，即使请求失败、超时、甚至 panic，defer 也能保证令牌被安全归还。
• 错误示范：for range urls { go func() { sem <- struct{}{}; ... }() } —— 这里的 sem <- 虽然在 goroutine 内部，但如果 goroutine 启动过快，实际并发连接数依然不可控。更糟的是把信号量操作放在 for 循环里、goroutine 外部，那只是限制了 goroutine 的启动速度，对网络并发毫无约束。
• http.Transport 的 MaxConnsPerHost 不等于并发请求数：这个参数控制的是 TCP 连接池的复用上限，它和信号量是协作关系，而非替代关系。通常建议将信号量设为你的业务目标并发数（例如10），而将 MaxConnsPerHost 设为一个略大的值（例如15），以允许合理的连接复用。

什么时候该换 worker pool，而不是只靠信号量

信号量只回答了“最多几个任务同时跑”的问题，但它不关心“谁来跑”、“跑几次”以及“任务积压了怎么办”。一旦遇到以下几种情况，就该考虑升级到更复杂的 worker pool 模式了：

• 需要拒绝新任务，而不是无限排队等待：信号量会阻塞等待，而像 ants 这样的 worker pool 库，可以通过配置 ants.WithNonblocking(true) 来直接丢弃无法立即处理的任务。
• 需要统计实时指标：比如当前正在运行的任务数、排队中的任务数量、任务平均耗时等。裸信号量无法提供这些观测维度。
• 任务执行时间差异极大，存在长期挂起的风险：比如调用某个不稳定的第三方接口。worker pool 可以内置超时和熔断机制，而信号量只能被动等待任务自己结束。
• 你已经在使用 ants 或类似库：这类库的 NewPool(n) 本质上封装了信号量、goroutine 预热以及 panic 捕获，比自己手写更稳健。但要注意，如果 worker 数量（n）远小于任务总量，且没有设置合理的任务队列缓冲，可能会导致大量任务被静默丢弃。