短超时压测后 Goroutine 数量不回落：区分工作未取消与结果发送阻塞

短超时压测里，Goroutine 数量一直不回落，先别急着把锅甩给 context.WithTimeout。一个 worker 可能卡在两处：工作函数根本没有响应取消，或者工作已经做完，却在结果发送处等不到接收者。排查时把这两个等待点拆开，通常比盯着总数更快。

本文用一个小型 worker pool 说明判断方法。目标不是让超时“杀死”协程，而是让每个可能阻塞的阶段都有退出路径。

先把“数量不回落”拆成两个等待点

先画出一条最短生命周期：取任务 → 执行工作/I/O → 发送结果 → WaitGroup.Done。压测结束后抓一次 Goroutine profile，若堆栈停在 HTTP、数据库或队列调用里，优先怀疑工作未取消；若停在 results ，则是结果发送阻塞。两者的修复位置完全不同。

为了复现，可以让调用方只等一个很短的 deadline，然后提前返回。此时 worker 仍可能继续向一个没有接收者的无缓冲通道发送。数量不回落不是“超时没触发”，而是仍有一条没有被覆盖的等待路径。

给工作函数和 I/O 同一条取消链

入口创建派生 Context 后，要把它作为参数一路传下去，不能只在最外层用 select 放弃等待。官方 Context 约定也强调：Context 应显式作为函数的第一个参数，派生 Context 被取消后，其子 Context 也会收到信号。

func worker(ctx context.Context, jobs 

doIO 应继续把 ctx 交给支持取消的客户端，例如 http.NewRequestWithContext 或数据库驱动的 QueryContext。如果底层库不支持取消，只能在调用前后检查 ctx.Err()；这能避免继续派生工作，却不能强行中断一个已经进入的不可取消调用。

让结果发送也能响应超时

最容易漏掉的是发送分支。调用方超时后不再读取 results，直接写入就会把 worker 永久留在发送点。上面第二个 select 同时等待“有人接收”与“Context 已取消”，这样调用方退出时 worker 可以走安全返回。

结果通道的所有权也要明确：由创建方决定何时关闭，由发送方保证不再发送。不要让每个 worker 竞争关闭同一个通道，否则泄漏还没解决，先出现 send on closed channel。如果需要收集首个错误，可以让错误触发取消，再由统一的收尾方等待全部 worker 退出。

用压测和 pprof 区分两类泄漏

修复后不要只看一次数量。先记录基线：并发量、deadline、worker 数和压测结束后的等待时间；再把 deadline 从 500ms、100ms 缩短，重复三轮。期望是请求结束后数量回到稳定基线，而不是瞬间归零。

go test -run TestPool -count=1 -timeout=30s
go tool pprof http://127.0.0.1:6060/debug/pprof/goroutine

profile 里重点看阻塞栈：I/O 调用说明取消链没有到达底层，通道发送说明发送分支缺少取消，等待组说明某个 worker 没有执行到 Done。同时给每次派生的 Context 调用配对 defer cancel()，避免计时器和子节点因为遗漏而延迟释放。

结论：短超时只负责发出取消信号；能否收敛取决于工作函数、底层 I/O 和结果发送是否都承认这条信号。把堆栈位置和生命周期阶段对应起来，才能判断是“工作未取消”还是“结果发送阻塞”。

相关问题

为什么调用方已经返回，worker 还在跑？因为外层等待被取消不等于内部工作自动停止，Context 必须传到实际阻塞调用。

有缓冲 Channel 就不会泄漏吗？不能保证。缓冲区填满后仍会阻塞，而且无接收者时结果可能丢失；是否可收敛仍要由取消分支决定。