本文介绍一种基于 sync.waitgroup 和非阻塞通道发送的 go 工作池模式，用于处理可递归生成新任务的场景（如网页爬虫），避免死锁、竞态与过早退出，兼顾简洁性与生产可用性。
在构建异步任务处理系统时（例如 URL 抓取器），一个常见但棘手的需求是：任务本身可能动态产生新任务（即“递归式”任务调度），而工作协程需在无待处理任务时自动终止，且整个池必须整体活跃或整体休眠——不能出现部分协程空转、部分协程阻塞的僵局。
原始方案尝试通过 working 通道统计活跃 worker 数量，并依赖 absent 信号协调启停，但存在逻辑耦合高、状态管理脆弱、难以验证正确性等问题；更关键的是，它隐含了对 select 执行顺序的依赖（虽符合 Go 规范），却未解决核心矛盾：如何安全、无锁地判断“全局无任务且无人将生成新任务”？
✅ 推荐解法：WaitGroup + 非阻塞任务入队（fallback execution）
其核心思想是：用 sync.WaitGroup 原子跟踪“已提交但未完成”的总任务数，而非 worker 状态；当 worker 从通道取到任务后立即 wg.Add(1)（表示该任务及其潜在子任务将被计入总数），执行完毕调用 wg.Done()。入队函数 enqueue 采用非阻塞写入：若通道有空位则直接投递；否则立即在当前 goroutine 中执行该任务（并递归调用 enqueue 处理其子任务）。这彻底规避了“所有 worker 都在等任务，但新任务正试图入队却被阻塞”的死锁。
以下是精简可靠的实现：
package main
import (
"fmt"
"sync"
"time"
)
const workers = 4
type Job struct {
URL string
}
func (j *Job) Do(enqueue func(Job)) {
fmt.Printf("Processing: %s\n", j.URL)
time.Sleep(10 * time.Millisecond) // 模拟网络请求
// 示例：某些 URL 返回新链接（递归生成）
if j.URL == "https://example.com/root" {
enqueue(Job{URL: "https://example.com/page1"})
enqueue(Job{URL: "https://example.com/page2"})
}
}
func main() {
jobs := make(chan Job, 100) // 缓冲通道，缓解突发压力
var wg sync.WaitGroup
var enqueue func(Job)
// 启动 worker
for i := 0; i < workers; i++ {
go func() {
for job := range jobs {
job.Do(enqueue)
wg.Done()
}
}()
}
// 定义线程安全的入队函数（闭包捕获 wg 和 jobs）
enqueue = func(job Job) {
wg.Add(1) // 关键：先声明此任务将被处理（含其子任务）
select {
case jobs <- job:
// 成功入队，由某个 worker 执行
default:
// 通道满或无空闲 worker → 当前 goroutine 直接执行（避免阻塞）
job.Do(enqueue)
wg.Done()
}
}
// 提交初始任务
initialJobs := []Job{
{URL: "https://example.com/root"},
{URL: "https://example.com/seed1"},
{URL: "https://example.com/seed2"},
}
for _, job := range initialJobs {
enqueue(job)
}
// 等待所有任务（含递归生成的）完成
wg.Wait()
close(jobs) // 允许 worker 优雅退出
fmt.Println("All jobs completed.")
}? 关键设计要点说明：
- wg.Add(1) 在 select 前调用：确保即使任务 fallback 到本地执行，wg.Done() 也能匹配，防止 Wait() 永久阻塞。
- 非阻塞 select + default 分支：是打破死锁的“安全阀”，也是支持无限递归深度（无栈溢出风险）的关键——任务树深度由内存而非调用栈决定。
- 通道缓冲区大小为启发式值（如 100）：无需精确预估最大并发任务数，仅作为性能优化；default 分支兜底保障功能不降级。
- close(jobs) 放在 wg.Wait() 后：确保所有 worker 已消费完通道中剩余任务，再关闭以避免 panic。
⚠️ 注意事项：
- 若任务执行时间极长且递归深度极大，需警惕内存累积（所有待处理 Job 实例驻留内存）。生产环境建议增加任务数/内存使用监控，或引入限流（如 semaphore 控制并发子任务数）。
- enqueue 函数必须是闭包或方法，确保能访问 wg 和 jobs；切勿在多个 goroutine 中并发修改同一 sync.WaitGroup 实例（本例中 enqueue 是线程安全的，因 wg.Add/Done 本身是并发安全的）。
- 此模式天然支持“任务优先级”扩展：只需将 chan Job 替换为带优先级的结构（如 heap + chan *PriorityJob），并在 enqueue 中按需插入。
该方案以极少代码达成高鲁棒性，是 Go 生态中处理动态任务图（DAG）的经典范式，适用于爬虫、事件驱动处理、并行树遍历等多种场景。
