Go worker pool 的优雅停止与任务回收方案

Go worker pool 要想停得干净，关键不是“把所有 goroutine 一起关掉”，而是把停止过程拆成两个入口：正常收尾时先停止接收新任务，再让已入队任务自然排空；超时或故障时取消 context，让 worker 和正在执行的任务尽快退出。两条路径都要由一个明确的协调方负责，不能让每个 worker 随意关闭共享 channel。

下面用 jobs、results、sync.WaitGroup 和可取消的 context 组织一个最小模型。示例重点是关闭入口、等待完成与任务回收，不依赖第三方 worker-pool 库。

官方资料：https://pkg.go.dev/context、https://pkg.go.dev/sync、https://go.dev/blog/pipelines

先把优雅关闭和强制取消分开

worker pool 通常有三类状态：仍然接收任务、停止接收但继续处理队列、取消当前批次并尽快退出。把第二种和第三种都叫“关闭”，调用方就很容易误判任务是否已经完成。

这里有一个必须先约定的所有权规则：只有提交协调方可以关闭 jobs，worker 不关闭它；调用方在进入 Close 前不能再并发调用 Submit。如果业务要求两者并发安全，就要额外加状态锁或串行化提交，这已经是生命周期协议的一部分。

让 worker 同时观察任务队列和取消信号

worker 的主循环至少要处理两件事：从 jobs 取任务，以及在取消后停止等待新任务。任务处理函数本身也要接收 context.Context，否则外层取消了，内部的网络请求、数据库调用或长循环仍可能继续运行。

package pool

import (
    "context"
    "sync"
)

type Job struct { ID int }
type Result struct { JobID int; Err error }

type Pool struct {
    ctx    context.Context
    cancel context.CancelFunc
    jobs   chan Job
    result chan Result
    wg     sync.WaitGroup
}

func New(parent context.Context, workers, queueSize int) *Pool {
    // 派生一个共享取消信号，所有 worker 都观察同一个生命周期。
    ctx, cancel := context.WithCancel(parent)
    p := &Pool{ctx: ctx, cancel: cancel, jobs: make(chan Job, queueSize), result: make(chan Result, workers)}
    for i := 0; i 

这个循环的重点是两个 select。第一个保证 worker 不会在取消后永久阻塞于取任务；第二个避免结果没人接收时拖住 worker。context 只是发出取消信号，不会替你强行终止正在执行的 Go 函数，所以 handle 以及它调用的下层 API 必须合作式地检查取消状态。

优雅停止时先关入口，再等 worker 归零

优雅停止的顺序是固定的：调用方先停止继续提交，然后关闭 jobs；worker 读取完缓冲区和已发送的任务后自然退出；最后等待 WaitGroup 归零，再关闭 result。这样结果消费者可以安全地用 range 读到结束。

func (p *Pool) Submit(ctx context.Context, job Job) error {
    // 提交方的上下文控制“等队列空位多久”，不是任务自身的执行上下文。
    select {
    case 

Close 不是“立即清空队列”。只要任务已经进入 jobs，worker 就会继续领取；如果任务执行时间很长，Wait 也会跟着等待。生产代码通常会让调用方在外层加一个下线期限，超过期限就转入取消路径。

取消时怎样回收执行中和排队中的任务

取消的语义要写在接口契约里。调用 cancel 后，已经开始执行的任务只有在底层操作支持 ctx 时才能尽快返回；还留在 jobs 中的任务不会自动变成“成功”，通常应由上层记录为未处理、重新入队或交给下一批处理。

func (p *Pool) Cancel() {
    // 取消只发信号，不等待；真正的退出确认仍由 Wait 完成。
    p.cancel()
}

func (p *Pool) WaitAndCloseResults() {
    // 调用方在 Cancel 后调用此方法，统一等待 worker 并关闭结果通道。
    p.wg.Wait()
    close(p.result)
}

func consume(ctx context.Context, p *Pool) error {
    for {
        select {
        case 

示例中的 Cancel 和 WaitAndCloseResults 展示了取消路径的核心边界。实际项目应当用 sync.Once 或状态机保证结果通道只关闭一次，并把“取消后是否允许继续读取结果”写清楚，避免 Close 与 Cancel 被不同调用方同时执行。

用调用顺序避免关闭竞争

最稳妥的外层编排是：先停止生产者，再决定是优雅排空还是取消退出，最后等待并回收结果。不要让某个 worker 发现错误后直接关闭 jobs，因为此时可能还有其它生产者在发送。

func shutdown(ctx context.Context, p *Pool, graceful bool) {
    // 这里先让生产者停止调用 Submit，避免 close(jobs) 与发送并发发生。
    if graceful {
        p.Close()
        return
    }

    // 取消路径不承诺处理完队列中的所有任务，超时由调用方记录和补偿。
    p.Cancel()
    done := make(chan struct{})
    go func() {
        p.WaitAndCloseResults()
        close(done)
    }()

    select {
    case 

如果需要让关闭操作自身可重复调用，可以把生命周期封装成一个拥有 sync.Once 的控制对象；如果需要支持“先优雅等待，超时后取消”，则应让同一个控制对象协调两个阶段，而不是把两个导出方法交给不同 goroutine 各自处理。

worker pool 关闭方式速查

可以把它浓缩成一句调用规则：优雅停止关闭任务入口，强制停止取消执行上下文；两条路径都要等待 worker 退出，结果通道只能由生命周期协调方关闭。

常见问题

关闭 jobs 后还能继续 Submit 吗？

不能。向已关闭的 channel 发送会触发 panic，所以要先停止生产者，再由唯一协调方关闭 jobs。

调用 cancel 后任务一定马上停止吗？

不一定。取消是协作式信号，任务必须把 context 传给可取消的操作，并在长循环或阻塞点观察 Done。

为什么不能只调用 WaitGroup.Wait？

Wait 只等待已有 goroutine 结束，不会阻止新的任务提交，也不会自动关闭 jobs 或 results；它需要和 channel 关闭及取消协议配合。