Go Pond 停止任务池后为什么不能继续提交任务

在 Go Pond v2 中，停止任务池后不能继续提交任务是设计出来的生命周期规则，不是并发池失灵。Stop 会把池标记为已关闭，并等待已经接受的任务完成；关闭标志建立后，新的 Submit、SubmitErr 和 TrySubmit 不再进入队列，等待结果会得到 pond.ErrPoolStopped。如果使用 Go，则可以直接检查它返回的错误。

官方地址：https://github.com/alitto/pond

把 Pond 池看成一次性的任务接收器：停止前提交的任务负责排空，停止后的任务由调用方识别并转交给新建的池。不要把 Stop 当成“暂时暂停”，因为 Pond v2 没有把已停止池重新打开的接口。

先区分停止前后两种提交语义

Pond 的关键变化不是 worker 立刻消失，而是“是否还接受新任务”的入口状态改变。停止前已经被池接受的任务，仍然可以执行并完成；停止后再调用提交方法，任务不会进入原池的队列。

这也是为什么“我已经调用了 Stop，为什么后面的任务没有执行”通常不是任务函数的问题，而是后续提交发生在关闭边界之后。Pond 会把这个结果明确表达为 ErrPoolStopped，调用方应该处理它，而不是继续等待一个永远不会执行的任务。

Stop 和 StopAndWait 分别改变了什么

Stop 返回一个可等待的任务：它负责关闭池、等待当前 worker 把已经接受的任务处理完，再结束停止操作。StopAndWait 则是对这个等待动作的封装，适合程序退出或请求生命周期结束时直接调用。

停止动作是单向的。Stopped 只能告诉你池是否已经停止或上下文是否已经取消，不能把池恢复为可提交状态。若服务还要接收下一轮任务，应创建新的池实例，并把新任务路由到新实例。

用 Wait 识别停止后的 Submit

Submit 返回的是任务句柄，不是“任务一定已经被接受”的成功凭证。提交发生在停止边界之后时，句柄的 Wait 会返回 pond.ErrPoolStopped；因此要把提交错误和任务业务错误放在同一个处理入口。

package main

import (
    "errors"
    "fmt"

    "github.com/alitto/pond/v2"
)

func main() {
    // 创建一个只负责当前批次任务的池。
    pool := pond.NewPool(2)

    // 先提交的任务属于停止前批次，StopAndWait 会等待它完成。
    accepted := pool.Submit(func() {
        fmt.Println("停止前的任务完成")
    })
    if err := accepted.Wait(); err != nil {
        // 任务本身的错误也要在 Wait 处处理，不能只看是否提交过。
        fmt.Printf("已提交任务失败：%v\n", err)
    }

    // 关闭池后，后续任务不会进入这个池的队列。
    pool.StopAndWait()
    rejected := pool.Submit(func() {
        fmt.Println("这行不会被 Pond 执行")
    })
    if err := rejected.Wait(); errors.Is(err, pond.ErrPoolStopped) {
        // ErrPoolStopped 表示生命周期已结束，应转交给新的池或上层调度器。
        fmt.Println("任务池已停止，准备切换到新池")
    }
}

示例中，accepted 和 rejected 都有任务句柄，但它们的生命周期不同。前者是停止前已接受的任务，后者只得到一个已解析为 ErrPoolStopped 的结果。这个差别比“调用了 Submit”更重要。

Go 入口可以直接检查返回错误

如果任务不需要等待结果，可以调用 pool.Go。这个入口在池已经停止时直接返回错误，适合把提交失败交给上层队列、重试策略或新池路由器。

// submitToCurrentPool 只负责提交，不把停止后的任务静默丢掉。
func submitToCurrentPool(pool pond.Pool, job func()) error {
    // Go 的返回值比异步 Wait 更适合在入口处做路由判断。
    if err := pool.Go(job); err != nil {
        if errors.Is(err, pond.ErrPoolStopped) {
            // 原池已结束；这里可以把 job 放入新的池或外部队列。
            return fmt.Errorf("任务池已结束，请切换池实例：%w", err)
        }
        // 其它提交错误也要保留，避免误判成任务执行失败。
        return fmt.Errorf("提交任务失败：%w", err)
    }
    return nil
}

不要只记录“提交函数已调用”。对 Go 来说，真正的接受结果是返回的 error；对 Submit 来说，真正的接受结果要通过任务句柄的 Wait 观察。

并发提交时，Stopped 检查不是提交保证

在一个 goroutine 检查 pool.Stopped()，再由另一个 goroutine 调用 Submit，中间可能正好执行停止操作。因此下面这种“先判断、后提交”的写法不能把两步组成原子操作：

// 错误示例：检查和提交之间存在竞态窗口。
if !pool.Stopped() {
    // 这里执行 Stop 后，Submit 仍然可能返回 ErrPoolStopped。
    pool.Submit(job)
}

更可靠的做法是直接提交，并把 ErrPoolStopped 作为正常的生命周期分支处理。若需要保证一批任务全部属于同一轮，应由上层调度器先停止接收，再等待发送方退出，最后调用 StopAndWait 排空池；不要让生产者在关闭过程中继续盲目提交。

要继续接收任务，创建新的池

停止池后不要尝试修改内部状态或复用旧池。Pond 的设计把池停止视为生命周期结束，最清晰的替代方案是由工厂或调度器创建新的池实例，并把下一批任务送入新实例：

// newPoolForRound 为下一轮任务创建独立池，避免复用已停止实例。
func newPoolForRound() pond.Pool {
    // 新池拥有自己的关闭状态和任务队列。
    return pond.NewPool(8)
}

func runRound(jobs []func()) {
    // 每轮使用一个新池，轮次结束后只关闭这一轮。
    pool := newPoolForRound()
    defer pool.StopAndWait()

    for _, job := range jobs {
        // 生产者应处理提交错误，而不是假设池永远可用。
        if err := pool.Go(job); err != nil {
            fmt.Printf("本轮提交失败：%v\n", err)
        }
    }
}

如果业务是长期运行的服务，通常不需要频繁停止主池，而是让主池持续存在，把“批次结束”交给任务组或上层上下文表达。只有在进程退出、租约到期、配置切换或明确完成一轮资源回收时，才调用 StopAndWait。

常见问题

Stop 会取消已经提交但还在队列中的任务吗？

停止操作会先拒绝新的提交，再等待已接受任务完成；任务本身是否因上下文取消而提前结束，还取决于任务使用的上下文和下游调用。

Submit 返回值为什么看不出是否成功？

Submit 用任务句柄表达异步结果，停止后的拒绝会在 Wait 中体现；若希望入口立即拿到错误，可改用 Go 或 TrySubmit。

停止后的 Pond 池能重新启动吗？

不能把同一个已停止池重新打开。继续处理任务时创建新的 pond.Pool，并让调度器切换到新实例。