当前位置：首页 > 文章列表 > Golang > Go问答 > Go goroutine 为什么因无人接收而泄漏

Go goroutine 为什么因无人接收而泄漏

来源：17golang原创 2026-10-25 22:19:03 0浏览收藏

如果一个 goroutine 把结果发送到无人接收的无缓冲 channel，它不会“自动结束”，而是停在发送表达式上。最常见的触发方式是：父 goroutine 遇到错误提前返回，接收循环随之结束，剩余 worker 仍执行 ch ，于是它们一直占着栈和引用。修复重点不是盲目增加 goroutine，而是给发送方一条明确的完成、取消或有界缓冲路径。

要点速览

无缓冲 channel 的发送只有在接收方同时就绪时才会完成；接收方提前退出，发送方就可能永久阻塞。
缓冲 channel 只能吸收容量范围内的结果，不能替代取消协议；nil channel 则永远不会就绪。
修复时让发送使用 select 监听 ctx.Done()，并用 goroutineleak 或 pprof 对照阻塞栈。

goroutine 发生泄漏的最常见场景之一，就是往无缓冲或者带缓冲的channel里发送数据时，没有对应的接收方兜底，导致发送方永远阻塞在channel的收发逻辑上，无法退出执行流，这个常驻的goroutine就会一直占用栈内存、调度资源没法被回收。

只要一个goroutine的阻塞逻辑没有外部触发退出的条件，运行时就会一直保留它的执行上下文，哪怕主协程后续执行完退出前都没法回收这类被卡住的协程，这就是无人接收时协程泄漏的核心成因。

先看一个“没人收结果”的最小现场

下面的代码把一个结果通道交给多个 worker。只要其中一个 worker 返回错误，父函数就提前结束接收循环；其他 worker 仍会尝试发送结果。由于 make(chan result) 创建的是无缓冲 channel，发送必须等到对应接收方出现。

package main

import "fmt"

type result struct {
    value int
    err   error
}

func process(items []int) ([]int, error) {
    ch := make(chan result)
    for _, item := range items {
        item := item
        go func() {
            // worker 完成后把结果交给父 goroutine；这里没有取消出口。
            ch

这段最小例子没有错误分支，但它展示了关键契约：接收次数必须覆盖所有发送次数。真实项目里错误通常来自某个 worker 或下游依赖，父函数一旦提前 return，其余发送点就失去接收者。图1把父函数、结果通道和 worker 的静态关系画出来，重点看“接收循环退出”与“发送点仍存在”的边界。

Go worker、父函数、无缓冲结果 channel 与提前返回之间的静态关系说明图 — 图1：结构说明图，展示 worker 发送结果、父函数接收以及提前返回造成的无人接收边界，不是运行截图。

为什么“无人接收”会变成泄漏

Go 语言规范规定，容量为零的 channel 只有发送方和接收方同时准备好时通信才成功；缓冲 channel 也只是在缓冲区未满时允许发送。发送方阻塞本身并不等于泄漏，只有当未来已经不存在能让它继续的接收或取消条件时，阻塞才会永久化。

场景	发送点的状态	判断
无缓冲，接收循环仍在	等待接收方	正常同步，不一定泄漏
无缓冲，父函数提前返回	永久等不到接收	典型 goroutine 泄漏
缓冲未满	写入缓冲后继续	只能暂时解耦
缓冲已满或 nil channel	发送继续阻塞	仍需消费、关闭或取消

因此，单纯把 channel 改成更大的缓冲并不能证明问题消失。如果 worker 数量超过容量、错误路径提前结束，或者 channel 实际上是 nil，发送照样没有终点。排查时应先问“谁负责接收、它在哪些分支会退出、发送方是否能感知退出”，再决定是否需要缓冲。

让发送方拥有可退出的取消路径

更稳妥的修复是让每个发送都同时监听取消信号。父函数返回错误前调用 cancel，已经完成工作的 worker 可以正常交付，尚未交付的 worker 则从 ctx.Done() 分支退出。这里的重点是：取消必须进入发送点，而不是只在父函数里声明一个 context。

func processWithCancel(parent context.Context, items []int) ([]int, error) {
    ctx, cancel := context.WithCancel(parent)
    defer cancel() // 正常返回和错误返回都释放未完成 worker。

    ch := make(chan result)
    for _, item := range items {
        item := item
        go func() {
            r := result{value: item * 2}
            select {
            case ch

示例省略了 worker 内部的真实错误来源，但保留了必须存在的控制关系：发送和接收都能观察取消。若结果允许丢弃，也可以使用容量与 worker 数量匹配的结果 channel 作为兜底；不过这只解决“结果暂存”问题，无法替代对网络、数据库或其他阻塞操作的取消设计。

Go context Done、发送 select、结果 channel 与 worker 退出边界的静态关系说明图 — 图2：边界说明图，展示取消信号如何到达发送 select，以及结果交付与 worker 退出的静态关系，不是运行证据。

用阻塞栈确认泄漏位置

遇到 goroutine 数量持续上涨时，先看阻塞栈是否集中在同一个发送表达式。Go 1.27 的 runtime/pprof 提供了 goroutineleak profile；如果环境或版本不提供该 profile，也可以查看常规 goroutine profile 和阻塞栈。下面是接入 HTTP pprof 的最小片段：

import (
    _ "net/http/pprof"
    "net/http"
)

func startProfileServer() error {
    // 仅示意把标准 pprof 处理器挂到本地调试端口。
    return http.ListenAndServe("127.0.0.1:6060", nil)
}

观察结果时不要只看 goroutine 总数。若大量栈停在 ch ，同时父函数已经走了错误返回，基本可以确认接收生命周期与发送生命周期脱节。修复后再关注同一调用路径的阻塞栈是否回落，并检查取消分支是否真的覆盖所有发送点。