Go协程池需用defer/recover捕获worker内任务panic,通过context控制任务超时与取消,关闭时先停收新任务再WaitGroup等待运行中任务结束,避免goroutine泄漏与状态竞争。
在 Go 中实现协程池(goroutine pool)时,异常处理和安全退出是关键问题。协程池不是 Go 标准库原生支持的模式(不像 Java 的 ThreadPoolExecutor),需自行封装;若不妥善处理 panic、上下文取消、任务超时或池关闭逻辑,容易导致协程泄漏、panic 未捕获崩溃主程序、或关闭时任务被粗暴中断。
协程池中每个 worker 协程通常循环从任务队列取任务执行。若某个任务内部 panic,且未捕获,会导致该 worker 协程退出,池容量永久减少——这是常见隐患。
必须在 worker 执行任务的最外层加 defer/recover:
go func() {
defer func() {
if r := recover(); r != nil {
// 记录 panic 日志,如:log.Printf("worker panic: %v", r)
// 注意:不要在此处重启协程,由池管理器统一调度
}
}()
for task := range taskCh {
task.Run() // 可能 panic 的用户代码
}
}()
⚠️ 关键点:
协程池本身不解决任务超时或中途取消问题。应要求任务函数接收 context.Context,并在阻塞操作(如 HTTP 请求、channel receive、time.Sleep)中响应取消信号。
示例任务签名:
type TaskFunc func(ctx context.Context) error// 提交任务时传入带 timeout 的 ctx pool.Submit(func(ctx context.Context) error { select { case <-time.After(5 * time.Second): return nil case <-ctx.Done(): return ctx.Err() // 返回 context.Canceled 或 DeadlineExceeded } })
worker 执行时需传递 context,并检查 ctx.Err():
ctx.Err() != nil,快速返回http.Client.Do(req.WithContext(ctx)))协程池关闭分两阶段:停止接收新任务(drain),再等待已有任务结束(graceful shutdown)。
典型实现方式
:
sync.Once 保证 Close() 只执行一次close(taskCh)),使 worker 自然退出 for-range 循环sync.WaitGroup 跟踪正在运行的任务数:提交前 wg.Add(1),完成后 wg.Done()
Close() 中先关闭 channel,再调用 wg.Wait() 阻塞等待注意:不可在 Close 中直接 close channel 后立刻 wg.Wait —— 需确保所有 worker 已开始消费“关闭信号”,否则可能死锁。稳妥做法是关闭 channel 后,另起 goroutine 调用 wg.Wait 并通知关闭完成。
协程池的安全退出依赖于“任务不持有跨生命周期资源”。常见陷阱包括:
go http.ListenAndServe(...))建议约束: