Go goroutine 为什么泄漏后无法回收

Go 的 goroutine 泄漏，通常不是“垃圾回收失效”，而是某个 goroutine 仍然处于运行时管理的阻塞状态，等待一个永远不会发生的事件。常见触发点包括：发送方提前返回后仍向无缓冲 channel 发送、接收方退出却没有取消通知、生产者没有关闭 channel，以及 WaitGroup 的计数没有归零。

判断标准可以先记住一句话：临时阻塞不等于泄漏，永远没有解除条件的阻塞才是泄漏。修复的核心也不是手动“回收” goroutine，而是给它一条确定的退出路径。

goroutine 只有在函数返回、阻塞操作被解除，或收到明确的取消信号后才会结束。GC 可以回收不再被引用的堆对象，但不会替业务猜测一个被阻塞的 goroutine 什么时候应该退出。

先看一个提前返回留下的发送方

下面这个例子里，worker 负责把结果送回调用方。调用方遇到错误后直接返回，worker 却还在等待接收者；因为 channel 没有缓冲，这次发送永远找不到配对的接收操作。

package main

import "errors"

func loadValue(failed bool) error {
	result := make(chan string)

	go func() {
		// 无缓冲 channel 的发送必须等到接收者出现。
		// 调用方提前返回后，这个 goroutine 会永久卡在这里。
		result 

这段代码的问题不是 worker 做了太多工作，而是它的生命周期依赖调用方继续接收。只要某个错误分支跳过接收，worker 就停留在发送指令上。服务反复进入这条路径时，泄漏数量会随请求次数增长。

为什么垃圾回收不会把它自动清掉

goroutine 不是普通的临时对象。启动后，它有自己的栈、调度状态和等待的同步原语，运行时需要保留这些状态，才能在条件满足时恢复执行。对上面的 worker 来说，发送操作仍然是一个合法的等待状态，运行时无法仅凭“现在没有接收者”就断定以后永远没有接收者。

同时，goroutine 的栈还可能持有结果缓冲区、请求对象或闭包变量。只要 goroutine 没有退出，这些引用就可能继续保持堆对象存活。因此，看到进程内存上涨时，不要把希望寄托在下一轮 GC 上；先找出是谁让 goroutine 一直活着。

这里要区分两个概念：

• 暂时阻塞：例如队列正在等待下一条消息，生产者稍后会继续发送，这是设计中的等待。
• 永久阻塞：接收者已经返回、channel 永不关闭，或者取消后仍没有可达的唤醒路径，这才是泄漏。

用数量和栈信息确认是不是同一种泄漏

runtime.NumGoroutine() 适合观察趋势，但单次读数不能直接证明泄漏。排查时应该在相同负载下重复采样，并把增长的 goroutine 栈与业务路径对应起来。Go 官方的诊断说明把 goroutine profile 定义为当前全部 goroutine 的栈快照，它能帮助你看到大量 goroutine 是否停在同一个发送、接收、锁或 I/O 位置。

package main

import (
	"os"
	"runtime"
	"runtime/pprof"
)

func writeGoroutineSnapshot() error {
	// 数量只用于观察趋势，不能替代栈信息。
	count := runtime.NumGoroutine()
	_ = count

	// goroutine profile 会输出当前 goroutine 的阻塞栈。
	// 文件句柄必须关闭，避免诊断代码本身留下资源问题。
	file, err := os.Create("goroutines.txt")
	if err != nil {
		return err
	}
	defer file.Close()

	profile := pprof.Lookup("goroutine")
	if profile == nil {
		return os.ErrNotExist
	}
	return profile.WriteTo(file, 2)
}

如果多次快照都显示相同的业务函数停在 ch 、 或 Wait()，就应该沿着这条路径检查退出条件。相反，短时间内数量升高、请求完成后又下降，往往只是正常的并发波动。

修复发送方：让发送也能响应取消

对于请求级任务，最稳妥的方式是把 context.Context 传进 worker，并把可能永久等待的发送包在 select 中。调用方取消时，worker 能从 ctx.Done() 分支返回，而不是继续等一个不存在的接收者。

package main

import "context"

func loadValue(ctx context.Context) error {
	result := make(chan string)

	go func() {
		// 取消信号和发送竞争，避免错误分支留下发送方。
		select {
		case result 

调用方通常用 context.WithCancel 或 context.WithTimeout 创建子上下文，并在所有返回路径执行取消函数。Context 的价值在于：同一个取消信号可以沿调用链传给多个 worker，而不是为每个 goroutine 设计一套互不相干的停止标志。

缓冲 channel 只能解决特定的“一次性交付”

如果 worker 只需要交付一个结果，调用方允许提前离开，而且这个结果不需要在取消后继续处理，可以使用容量为 1 的 channel：

result := make(chan string, 1)
go func() {
	// 容量为 1 时，worker 能完成一次交付，不必等待接收者同时到场。
	result 

但缓冲不是通用的泄漏修复。它只把“发送等待”改成“最多缓存一个结果”；如果 worker 可能发送多个值、生产者数量不确定，或者结果包含需要及时释放的资源，仍然需要取消、关闭 channel 和等待收尾。

修复生产者：明确谁负责关闭和等待

多个 worker 从 channel 接收时，生产者必须在所有发送结束后关闭 channel；worker 则应在 channel 关闭或取消时退出。若需要确认已经启动的 worker 全部结束，再用 sync.WaitGroup 做收尾，而不是用一个可能永远等不到的计数。

package main

import (
	"context"
	"sync"
)

func runWorkers(ctx context.Context, input 

这段结构里有三个静态契约：输入 channel 的所有者负责关闭输入；每个 worker 都在输入关闭和 context 取消时返回；统一的收尾 goroutine 在 Wait 完成后关闭输出。任何一个契约缺失，都可能让某一侧永远等待。

Go 1.27 的 goroutineleak profile 能帮你缩小范围

Go 1.27 已提供名为 goroutineleak 的 profile 类型，并可通过 net/http/pprof 的 /debug/pprof/goroutineleak 获取。它针对一部分永久阻塞在 channel 或 sync 原语上的 goroutine，由运行时结合垃圾回收后的可达性判断是否不可能再被唤醒。

这个 profile 不是“所有泄漏的万能扫描器”。官方说明也限定了范围：依赖全局变量或仍被可运行 goroutine 持有的同步原语，可能无法被识别；网络读、外部系统调用等阻塞也不都属于它能精确判断的类型。旧版本没有这个 profile 时，仍然可以使用普通 goroutine profile、数量趋势和测试中的生命周期检查来定位问题。

实践中建议先用普通 profile 找到重复栈，再用新 profile 缩小永久阻塞的范围，最后回到代码补齐取消、关闭和等待契约。工具负责提供证据，退出设计仍然需要由业务代码完成。

排查时按这张清单收尾

1. 记录相同负载下的 goroutine 数量趋势，不用单次数量下结论。
2. 抓取 goroutine 栈，确认增长项是否停在相同的 channel、锁、WaitGroup 或 I/O 调用。
3. 检查每个 go 语句对应的退出条件：谁取消、谁关闭、谁接收、谁等待。
4. 让发送和接收都能响应 ctx.Done()，并为所有错误返回路径执行取消。
5. 只有在“一次结果、容量明确、结果可丢弃或可延后处理”的场景使用小容量缓冲。
6. 明确 channel 所有权，所有 worker 都 Done，由一个确定的收尾方关闭输出。

所以，Go goroutine 泄漏后无法回收的根因，是它仍被运行时视为一个可能继续执行的并发实体，而代码没有提供让它结束的条件。把“启动 goroutine”与“如何停止 goroutine”放在同一处设计，通常比事后增加 GC 或内存参数更有效。

相关问题

goroutine 数量高就一定是泄漏吗？ 不一定。高并发、长轮询、连接池和队列消费者都可能产生大量暂时存活的 goroutine，关键是观察趋势、阻塞栈和请求结束后的回落情况。

关闭 channel 能结束所有 goroutine 吗？ 只能唤醒正在接收该 channel 的 goroutine。阻塞在发送、锁、网络读或另一个 channel 上的 goroutine，仍需要对应的取消或关闭路径。

为什么不用直接杀掉 goroutine？ Go 没有安全的通用强杀接口。强行打断会留下锁、文件、连接和共享状态的清理问题，应该通过协作式取消让函数自己返回。