Go goroutine 无接收者发送导致泄漏的取消方案

我排查这类问题时，最容易忽略的不是 goroutine 的创建，而是最后一行发送：调用方因为超时或请求取消已经返回，worker 却还在执行 out 。如果这个 channel 没有接收者，发送方会一直等下去，goroutine 数量就会随着取消请求累积。

可行的修复是把发送动作也纳入取消选择：case out 与 case 同时等待。这样只能保证“结果无人接收时 worker 能退出”；如果 work 本身卡在不可取消的网络或磁盘操作，仍然要从底层 API 传入 context，不能只靠外层 select。

先确认 goroutine 卡在发送，而不是卡在工作函数

典型的高风险写法是返回一个无缓冲 channel，worker 完成任务后直接发送：

package main

import "context"

type Result struct {
    Value int
    Err   error
}

func fetchBad(work func() Result) 

这里的泄漏点不在 work 返回之后，而在返回值无人接收时。无缓冲 channel 的发送需要发送方和接收方同时就绪；调用方的 select 选择了取消分支，并不会替 worker 消费结果。

让 worker 在发送结果时也能响应取消

修复时把 ctx 传到 worker，并只在完成计算后竞争两件事：有接收者就交付结果，调用方已经取消就放弃交付并返回。

package main

import "context"

func fetch(ctx context.Context, work func() (Result, error)) 

close(out) 只由唯一发送方执行，避免多方关闭同一个 channel。接收方检查 ok，是为了区分正常结果和 worker 因取消直接关闭 channel 的情况。若业务不需要遍历 channel，也可以改成单次结果对象加错误返回，但取消分支的原则不变。

用固定取消次数看泄漏是否停止增长

“请求返回了”不等于“后台 goroutine 退出了”。我会先固定一组可重复的取消次数，再比较调用前后的 goroutine 数，而不是只看单次请求的延迟。比如发起 100 次会在发送前取消的调用，记录 before、after 和 delta：

package main

import (
    "context"
    "fmt"
    "runtime"
)

func measureCancelledCalls(work func() (Result, error)) {
    before := runtime.NumGoroutine()

    for i := 0; i 

对照时保持 work、取消次数和等待窗口一致。坏实现的 delta 会随取消调用增加而持续偏大，因为每个 worker 都可能停在发送点；修复实现的目标是取消分支可达，delta 在等待调度完成后回到接近基线。这个数字是诊断信号，不应单独当作性能结论；需要结合 goroutine profile 或调用链定位阻塞位置。

另一个实用判断是把发送分支和取消分支分别加计数：发送成功数、取消放弃数和工作错误数之和，应与启动的 worker 数量有清晰对应关系。若取消数为零但调用方大量超时，通常说明取消没有传入 worker，或 worker 仍卡在不可取消的 work()。

缓冲区能缓解什么，不能解决什么

把 channel 改成 make(chan Result, 1) 有时能让一个结果先落入缓冲区，worker 不必立即等待接收者。但它只是改变了发送的暂存容量，不等于完成取消设计。

• 只有一个结果、且结果允许短暂滞留时，容量为 1 可以减少发送方与接收方的耦合。
• 多个 worker 共用一个输出 channel 时，固定容量可能很快耗尽，后续发送仍会阻塞。
• 调用方不再关心结果时，缓冲区可能保留对象和错误信息；如果结果很大，内存占用反而会延后释放。
• 如果 work() 自己不响应 context，worker 可能根本走不到发送选择，缓冲区也救不了它。

因此，缓冲区适合表达“允许暂存几个结果”，取消分支表达的是“调用方放弃后 worker 仍有退出路径”。两者可以同时使用，但语义不要混在一起。

我最后会检查的几个边界

这类修复落地后，我会按下面的顺序复查：

1. 取消是否真的传入 worker：函数签名和调用链中都应携带同一个请求级 context，不能在内部重新用 context.Background() 切断信号。
2. 发送是否有取消出口：所有可能等待接收者的发送点，都要考虑 ctx.Done()；不要只保护其中一个分支。
3. 底层工作是否可取消：HTTP、数据库或其他 I/O 应使用支持 context 的 API；否则只能在工作结束后放弃结果，不能提前终止工作。
4. 关闭责任是否唯一：只有明确的 channel owner 负责关闭，接收方不要为了“结束循环”随手关闭发送方拥有的 channel。
5. 指标是否能对上：启动数、成功发送数、取消放弃数和错误数要能解释同一批请求，goroutine 增量要在合理等待后观察。

结论

Go goroutine 因无接收者发送而泄漏时，核心修复不是盲目加 buffer，而是让发送操作和 ctx.Done() 一起进入 select。这样调用方先取消时，worker 可以放弃无人接收的结果并返回。若任务本身还卡在不可取消的 I/O，则必须继续向下传递 context；外层发送保护只能解决结果交付阶段的阻塞。

相关问题

有缓冲 channel 还需要取消分支吗？

通常仍然需要。缓冲区只提供有限暂存空间，无法保证所有发送都能落入其中，也不能结束已经卡在 work 函数里的 goroutine。

取消后还要接收 channel 吗？

如果发送分支已经用同一个 context 保护，调用方可以直接返回；worker 会在取消分支退出。不要为了“排空”而让另一个 goroutine 无限等待，除非业务明确需要回收结果。

关闭结果 channel 能避免泄漏吗？

关闭只能通知接收方不会再有新值，不能解除一个正在等待接收者的发送。必须先设计发送方的取消出口，再由唯一 owner 负责关闭。