把无界并发改造成带容量限制的工作池

把每条输入都直接交给 go handle(item)，吞吐看似上去了，但输入一多，goroutine、内存和下游连接数会一起膨胀。更稳妥的改法是把“并发多少”和“排队多少”拆开控制：用固定数量的 worker 限制同时执行的任务，用带容量的 jobs channel 限制等待中的任务，再用 context 和 WaitGroup 负责取消与收尾。

固定 worker 和带容量队列如何共同限制并发

工作池的关键不是“多开几个 goroutine”，而是给任务流设置两个边界。下面示例让 3 个 worker 消费最多缓存 6 个任务的队列；第 7 个等待中的任务会让提交方停住，直到有 worker 取走任务。

package main

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

type Job struct {
    ID int
}

func worker(ctx context.Context, id int, jobs 

这里的 3 是活动并发上限，6 是等待区容量。两者都不能随意写成“越大越快”：worker 数受 CPU、下游连接和限流约束，队列容量受内存和可接受延迟约束。

提交策略要先定义队列满时的行为

带缓冲 channel 只能提供边界，不能替你决定背压策略。上面的 submit 在队列暂满时会等待；这适合不能丢任务、且上游可以被反压的批处理。如果接口请求不能长时间等待，可以改成带 default 的快速失败：

func trySubmit(jobs chan

快速失败时不要偷偷丢任务。可以记录拒绝计数、返回明确错误，或者把任务交给更上层的重试队列。若任务必须完成，则优先使用可取消的阻塞提交，并给请求设置超时。

取消、关闭和等待必须分成三个动作

收尾时最容易犯的错是让多个 goroutine 争抢 close(jobs)，或者关闭后仍有生产者发送。建议由唯一的生产者拥有关闭权：先停止生产，再关闭队列，worker 从队列中排空剩余任务后退出；若需要立即终止，则先取消 context，让 worker 放弃未领取的任务。

不要用“再睡一会儿”判断工作池是否结束。WaitGroup 才是退出条件；如果 worker 内部还要调用下游接口，还应让这些调用继承同一个 ctx，否则 goroutine 虽然离开取任务循环，内部请求仍可能悬挂。

上线前用四项检查确认容量边界

• 任务是否可重试：不可重试任务不能用静默丢弃的满队列策略。
• 下游是否有并发限制：worker 数应低于数据库连接池、HTTP 对端或外部 API 的可用额度。
• 队列是否可观测：至少记录当前长度、拒绝次数、处理耗时和取消数量。
• 停机是否可等待：优雅退出给排空留时间，超时后再取消并记录未完成任务。

工作池不是一个固定数字，而是一组可解释的容量契约：用压测得到单任务耗时和下游承载力，再调整 worker、队列和超时。先把无界并发改成有边界，才能继续讨论吞吐优化。

相关问题

worker 数和 channel 容量应该设成一样吗？

不必一样。worker 数控制执行并发，channel 容量控制短时积压；批处理可留出较大的缓冲，交互请求则应让队列较小并尽快反馈。

为什么关闭 jobs 后还要 WaitGroup？

关闭只代表不会再有新任务，已经取出的任务仍需执行。WaitGroup 用来确认所有 worker 都已返回，避免主 goroutine提前退出。

队列满了是否应该直接扩容？

先判断积压来自生产突发还是下游变慢。盲目扩容只会把等待时间和内存占用往后推，无法提高受限下游的真实处理能力。