Go 如何用 channel 信号量限制批量推理并发：排队、取消与结果回收

批量推理入口最容易踩的坑，是把每条输入都直接交给一个新的 goroutine。请求一多，等待中的任务、下游连接和结果对象会一起堆起来；真正需要控制的不是“能不能并发”，而是同时进入推理阶段的任务数。用一个带容量的 channel 作为信号量，任务先获取名额、完成或取消后释放，排队压力就能被放在一个清楚的边界里。

把并发上限放在进入推理调用之前，并让获取名额、取消退出、结果回收和释放名额都走同一个控制路径，批量任务才不会越积越多。

先把并发边界放在推理调用前

假设上游已经把待处理输入送进 jobs，每个元素都需要调用一次 infer。如果在循环里无条件启动 goroutine，系统只能在下游变慢后被动积压。信号量的关键不是让队列消失，而是把“允许进入推理”的数量固定下来。

type Job struct {
    ID    string
    Input []float32
}

func runBatch(ctx context.Context, jobs 

这里的顺序很重要：sem 的写入发生在 goroutine 启动之前，所以等待名额的任务不会先把大量 goroutine 撒出去。拿到名额后才进入 infer；如果 ctx.Done 先到，任务直接退出。图中只画这条控制流，便于检查并发上限究竟卡在哪里。

比较三种常见写法，选择能被取消的一种

最直接的写法是固定 worker 数量：worker 从 jobs 取任务并调用 infer，天然限制并发，适合任务持续流入的服务。另一种是无界 goroutine，代码短但没有明确背压。带 channel 信号量的写法保留了按任务启动的灵活性，同时把名额控制显式放在调用前，适合需要独立回收结果的批处理。

• 固定 worker：模型调用耗时差异大时，worker 之间可能出现空闲与拥塞，需要额外的批量策略。
• 无界 goroutine：取消和过载时最难收口，不能把“goroutine 很轻”当成容量规划。
• channel 信号量：limit 是清楚的硬边界，但必须保证每个已取得的名额都能释放。

不要把 limit 写成来自请求参数的任意值。生产代码至少应在构造入口处校验它大于零，并根据下游能承受的并发设置上限；这篇示例把容量控制留在调用方，避免把模型服务的内部容量假设写死。

结果回收要和名额释放成对出现

调用方消费 results 时，要区分“任务失败”和“整个批次取消”。单个 infer 错误应进入 Result.Err，而不是让一个 goroutine 直接退出后无人知道；批次取消则应停止继续发送结果，并让上层通过 context 结束等待。

for result := range runBatch(ctx, jobs, 4) {
    if result.Err != nil {
        errors = append(errors, result.Err)
        continue
    }
    values[result.ID] = result.Value
}

worker 里用 defer 释放 sem，即使 infer 返回错误也不会遗留名额。外层用 wg.Wait() 后关闭 results，调用方的 range 才有确定终点。反过来，如果发送结果只写 results 而调用方已经因取消停止消费，worker 可能卡在发送处；示例中的发送也监听了 ctx.Done。

这张图对应的验收顺序是：results 能收到成功或错误结果，errors 能保留失败信息，defer 一定执行并释放 sem，最后由 wg.Wait 之后的关闭动作结束消费。缺任一环节，下一批任务都可能表现为假性“没有并发名额”。

取消、错误和背压的边界

取消发生在拿到 sem 之前

select 的两个分支都可能就绪，取消与名额同时到达时，代码不能承诺固定的选择顺序。重要的是：无论选择结果如何，拿到名额的 goroutine 必须走释放路径；没有拿到名额的任务不能进入 infer。

取消发生在 infer 进行中

context 只能把取消信号传给支持它的下游调用。若 infer 内部没有检查 ctx，外层只能停止等待结果，不能凭空中断正在运行的计算。因此，取消后的资源释放还要依赖 infer 自己的实现。

jobs 本身也需要背压

信号量限制的是活动任务，不等于 jobs 是无界的。jobs 如果来自一次性切片，仍可能在进入信号量前占用大量内存。更稳妥的做法是让生产者按批次写入、在取消时停止生产，并把 jobs 的容量也纳入验收。

上线前用一组小检查确认路径闭合

1. 把 limit 设为一个很小的值，确认同时进入 infer 的任务数不会超过它。
2. 在 jobs 仍有待处理项时取消 ctx，确认后续任务不会继续获取 sem。
3. 让 infer 返回错误，确认结果仍能到达调用方，且后续任务仍能取得释放出的名额。
4. 让调用方提前停止消费，确认 worker 的结果发送有 ctx.Done 分支，不会永久阻塞。
5. 确认 wg.Wait() 之后才关闭 results，避免发送方与关闭方竞争。

相关问题

channel 信号量和固定 worker 该怎么选？

任务数量持续、处理逻辑相近时固定 worker 更简单；需要按任务携带上下文、独立收集结果或动态启动任务时，channel 信号量更直观。两者都要配合有界输入和取消路径。

为什么不能只在 infer 返回后释放名额？

释放动作应该由 defer 绑定到“已经取得名额的 goroutine”，这样错误返回、提前取消和未来新增分支都不容易漏掉清理。

并发上限越大，批量推理一定越快吗？

不一定。上限只控制同时活动的任务数，真正吞吐还受下游容量、输入大小、排队时间和结果消费速度影响。先用小 limit 验证稳定性，再用真实负载调整。

这条实现的核心不是某个固定数字，而是控制路径闭合：jobs 负责排队，sem 负责名额，infer 执行实际推理，ctx.Done 负责退出，results 和 errors 负责把结果带回调用方，defer 与 wg.Wait 负责收尾。把这些边界写进测试后，批量推理服务才有可观察、可回滚的并发行为。