Go Pond WithQueueSize 为零和不设置有什么区别

Go Pond 中，pond.NewPool(4) 不设置 WithQueueSize 时，任务默认进入无界队列；pond.NewPool(4, pond.WithQueueSize(0)) 则完全禁用队列。前者允许任务先排队，后者只接受能立刻交给运行中 worker 的任务。Pond 官方资料可从 https://github.com/alitto/pond 查看。

两者不是“队列大小一个是默认值、一个是零”的简单写法差异：不设置代表可以持续积压，设置为零代表不保留等待中的任务。零队列下，普通提交在满载时会等待；使用 TrySubmit 或 WithNonBlocking(true) 时则可以立即得到失败结果。

• 不设置：默认无界队列，提交通常不会因为队列容量而失败，但积压会继续占用内存。
• WithQueueSize(0)：没有等待队列，只让空闲 worker 接收任务。
• 满载处理：阻塞提交等待 worker；TrySubmit、TrySubmitErr 或非阻塞池可以立即拒绝。

不设置 WithQueueSize 时，任务为什么还能继续提交

Pond v2 默认使用无界任务队列。池的最大并发数限制的是同时运行的 worker 数量，不是已经提交但尚未运行的任务数量。假设池的最大并发为 4，前 4 个任务正在执行，后续任务仍可以先留在等待队列里，等 worker 空闲后再被取出。

这种方式适合任务必须尽量完成、调用方可以接受延迟的场景，例如后台批处理。但“无界”并不等于没有风险：生产者速度长期高于消费者速度时，等待任务会越来越多，内存压力也会随之增加。若只想恢复默认的无界语义但又需要显式写出配置，可以使用官方提供的 pond.Unbounded 常量。

WithQueueSize(0) 满载时到底是等待还是失败

WithQueueSize(0) 关闭的是等待队列，不会把池的最大并发改成零。只要有空闲 worker，任务仍可直接执行；如果所有 worker 都忙，提交动作的结果取决于提交 API 和池选项。

package main

import (
	"fmt"
	"github.com/alitto/pond/v2"
)

func main() {
	// 队列容量为零：任务不能在池内积压，只能直接交给空闲 worker。
	pool := pond.NewPool(4, pond.WithQueueSize(0))
	defer pool.StopAndWait()

	// TrySubmit 不等待空闲 worker，适合把“满载”交给调用方处理。
	_, ok := pool.TrySubmit(func() {
		// 这里放置一项需要受并发上限保护的工作。
		fmt.Println("run task")
	})
	if !ok {
		// 所有 worker 忙时，零队列没有位置接收该任务。
		fmt.Println("queue is full or no worker is available")
	}
}

如果使用普通的提交方法，官方文档描述的默认行为是在队列满时阻塞；对零容量队列来说，就是等待某个 worker 空闲。若配置 pond.WithNonBlocking(true)，满载时会返回 ErrQueueFull；TrySubmit 和 TrySubmitErr 则分别通过布尔值告诉调用方是否提交成功。

按积压策略选择两种配置

可以把问题拆成两个判断：任务是否允许在池内等待，以及生产者是否允许因为满载而停住。允许等待时，不设置队列大小最省事，但应关注等待任务数量和内存压力；需要控制积压时，可设置一个有限的正整数；任务必须“现在执行，否则就不要接收”时，才使用 WithQueueSize(0)。

选择零队列后，不要只看 RunningWorkers()，还要结合 WaitingTasks()、DroppedTasks() 和调用方的失败处理。零队列的价值不是让任务自动变快，而是把“是否等待、是否丢弃”的决策提前暴露给提交方。

常见问题

WithQueueSize(0) 会让 Pond 不创建 worker 吗？

不会。它只关闭任务等待队列，最大并发仍由 NewPool 的参数决定；有任务且存在可用容量时，池仍会按需运行 worker。

不设置和 WithQueueSize(pond.Unbounded) 完全一样吗？

两者都表达无界队列语义。官方文档把 pond.Unbounded 定义为最大支持队列大小的便利常量，适合需要显式配置队列选项的代码；日常使用中不设置就是默认方式。

如何避免零队列让请求 goroutine 长时间阻塞？

把提交改为 TrySubmit 或开启 WithNonBlocking(true)，并在失败时返回降级结果、重试信号或上游背压。不要把“立即失败”误处理成任务已经执行。