Go goroutine 泄漏因无界 channel 造成的排查

看到 goroutine 数量持续上涨，同时堆内存也慢慢抬升时，很多人会把问题归结为“无界 channel”。需要先纠正一个关键概念：Go 原生 channel 在创建时容量就是固定的，无缓冲 channel 的容量为 0，有缓冲 channel 的容量由 make(chan T, n) 决定；所谓“无界 channel”，通常是业务代码在 channel 前后又包了一层 goroutine 与可无限增长的 slice，使生产者始终能提交，而下游停止或变慢后，队列 goroutine、等待发送的 goroutine 和被引用的数据都无法退出。

排查时不要只盯着内存。先用 goroutine profile 找到重复堆栈，再确认它们是在 chan send、chan receive 还是 select 上等待，最后沿着 channel 的创建、关闭和取消责任追到所有者。修复目标也不是简单把缓冲区改大，而是同时补齐容量上限、背压策略、取消信号和退出等待。

官方参考：https://go.dev/blog/pipelines、https://go.dev/doc/diagnostics、https://pkg.go.dev/context

先把“无界 channel”还原成真实代码结构

标准库 channel 不会自动扩容。工程里常见的“无界”实现，是一个中转 goroutine 同时维护输入 channel、输出 channel 与内部 slice：输入来了就追加，输出可写时再弹出。只要输入分支长期可用，生产者就很少感受到背压；一旦消费者退出、处理变慢或没有继续读取，slice 会不断增长，中转 goroutine也可能永久停留在 select 中。

func unboundedQueue[T any](in  0 {
			var send chan 0 {
				send = out
				first = pending[0]
			}

			select {
			case v, ok := 

这段代码的风险不只是 slice 变大。如果下游不再接收，send 永远不能完成；如果上游也没有关闭 in，循环没有退出条件。中转 goroutine 会继续持有 pending 中的全部对象。若每次请求又新建一条这样的队列，goroutine 数量和内存会一起增长。

用 goroutine profile 锁定阻塞点

runtime.NumGoroutine 返回当前 goroutine 数量，适合做趋势告警，但单个数值不能证明泄漏：流量上涨、并发任务或后台维护也会让它临时升高。更可靠的做法是，在相近负载下分别采集两次 goroutine profile，比较哪些堆栈的数量只增不减。

package main

import (
	"log"
	"net/http"
	_ "net/http/pprof" // 仅在受控的诊断监听地址注册 pprof 路由。
)

func main() {
	go func() {
		// 生产环境应限制到管理网络，并增加认证或访问控制。
		log.Println(http.ListenAndServe("127.0.0.1:6060", nil))
	}()

	select {} // 示例服务保持运行，便于从管理端采集诊断信息。
}

# 保存完整 goroutine 堆栈，重点搜索 chan send、chan receive 与 select。
curl -sS http://127.0.0.1:6060/debug/pprof/goroutine?debug=2 > goroutine.txt

# 通过 pprof 查看聚合后的 goroutine 创建与阻塞路径。
go tool pprof http://127.0.0.1:6060/debug/pprof/goroutine

Go 官方诊断文档说明，goroutine profile 会报告所有当前 goroutine 的堆栈，block profile 则用于观察在 channel 发送、接收、select 等同步原语上的阻塞时间。block profile 默认不开启，需要设置采样率，因此常规排查先从 goroutine profile 入手，再按需要启用 block profile，避免把诊断开销长期留在生产路径。

从 Go 1.27 开始，运行时还提供 goroutineleak profile，可识别一部分永久阻塞在 channel 或 sync 原语上的泄漏。如果服务已升级，可以通过 /debug/pprof/goroutineleak 或 runtime/pprof 采集；旧版本仍使用普通 goroutine profile 做堆栈趋势比较。它不是所有泄漏的万能检测器，例如仍在循环、I/O 或定时唤醒的 goroutine 还需要结合其他证据分析。

从堆栈回到 channel 的所有权

拿到阻塞堆栈后，按“谁创建、谁发送、谁接收、谁关闭、谁取消”五个问题检查代码。最常见的错误是消费者因错误提前返回，上游发送方却没有收到取消；或者中转 goroutine 只等待输入关闭，但输入的真正所有者永远不会关闭。关闭 channel 也不能随意补在接收端，否则多个发送者仍可能向已关闭的 channel 写入并触发 panic。

下面的静态结构图把泄漏现场拆成生产边界、队列边界与消费边界。生产者写入输入 channel，中转 goroutine 持有 pending slice 并尝试写输出 channel；消费者停止后，如果 context 取消没有覆盖这些节点，中转和发送方就缺少退出条件。

在 profile 里看到 chan send，通常说明发送方没有接收者或缓冲已满；看到 chan receive，通常说明接收方等不到值，也等不到 channel 关闭；停在 select 则要逐个判断每个 case 是否存在永远无法满足的条件。不要因为堆栈显示在运行时函数里就停止追查，向下找到第一个业务函数和源码行，那里才是所有权断裂的位置。

把旧实现迁移为有界队列与可取消发送

修复的第一步是把容量与过载策略写进接口。容量不是越大越好，它表示系统愿意用多少内存吸收短期抖动。队列满时必须选择一种明确行为：等待形成背压、在超时后返回错误、丢弃可牺牲数据，或把任务转移到具备持久化和重试语义的外部队列。不能再用无限 slice 隐藏速度差。

package jobs

import (
	"context"
	"errors"
	"sync"
)

var ErrQueueFull = errors.New("任务队列已满")

type Queue[T any] struct {
	ch chan T
	wg sync.WaitGroup
}

func NewQueue[T any](capacity int) *Queue[T] {
	if capacity 

示例选择了“队列满立即返回 ErrQueueFull”，适合调用方能够重试或降级的场景。如果业务要求等待，可以删除 default，保留 q.ch 与 ctx.Done() 两个 case；这样等待仍然有上限。若任务不能丢失，应使用带确认、持久化和重放能力的消息系统，而不是把进程内存当成无限缓冲。

同时修复取消、关闭与等待边界

有界 channel 只限制内存，并不自动保证 goroutine 退出。发送方、接收方和 worker 的所有阻塞点都需要监听同一个请求级或服务级 context。Go 官方 pipeline 指南的核心规则是：阶段在完成发送后关闭自己拥有的输出 channel；接收阶段持续读取，直到输入关闭或发送方通过取消信号解除阻塞。

静态关系上，有界 channel 负责容量，context.Context 负责取消，sync.WaitGroup 负责确认 worker 已退出，队列所有者 负责关闭输入。四者职责不同，不能用“把 channel close 掉”代替完整的生命周期协调。

还要注意关闭与提交的竞态。上面的简化示例要求外层先停止所有 Submit 调用，再执行 CloseAndWait。如果提交与关闭会并发发生，需要在更高层用状态机、互斥锁或单一协调 goroutine 串行化；仅在 Submit 里 recover 不能修复所有权错误。

回归检查不要只比较一次 goroutine 数量

修复后应重复造成问题的负载：持续提交任务、让消费者提前取消、触发队列满，并等待清理窗口结束。记录测试前、峰值时和结束后的 goroutine 数量，同时保存结束后的 profile。测试通过的标准不是“goroutine 数完全等于起点”，因为测试框架、HTTP 客户端和运行时本身也会创建后台 goroutine；更有价值的标准是业务堆栈不再随轮次线性累积，队列长度能够回落，取消后 worker 能在限定时间内退出。

func TestQueueStopsAfterCancel(t *testing.T) {
	ctx, cancel := context.WithCancel(context.Background())
	q := NewQueue[int](8)
	q.Start(ctx, 2, func(context.Context, int) {})

	for i := 0; i 

这个测试只验证退出契约，没有声称复现生产环境的 profile。更完整的回归还应覆盖队列满策略、处理函数阻塞、关闭前停止提交，以及重复启动和停止后的堆栈数量。若使用 Go 1.27，可把 goroutineleak profile 加入压测后的诊断步骤；较旧版本则对普通 goroutine profile 做前后差异分析。

迁移清单

• 确认所谓“无界”来自哪一层：内部 slice、每任务一个 goroutine，还是缺少接收者。
• 记录 runtime.NumGoroutine 趋势，并采集 goroutine profile 找到重复业务堆栈。
• 逐个标记 channel 的创建者、发送者、接收者、关闭者与取消来源。
• 把无限 slice 改为固定容量 channel，给队列满定义等待、拒绝、丢弃或外部持久化策略。
• 所有可能阻塞的发送和接收都用 select 监听 ctx.Done()。
• 只由拥有发送生命周期的一方关闭 channel；关闭前先停止新的提交。
• 用 WaitGroup 或等价机制确认后台 goroutine 已退出。
• 重复执行取消与过载场景，确认业务堆栈、队列长度和内存都能回落。

常见问题

把 channel 缓冲从 100 改成 10000 能解决泄漏吗？

通常不能。更大的缓冲只扩大可吸收的短期峰值；如果平均生产速率持续高于消费速率，或者消费者已经退出，容量最终仍会耗尽。必须同时定义背压和取消。

goroutine 停在 chan receive 就一定是泄漏吗？

不一定。长期运行的 worker 本来就可能等待任务。只有当解除条件永远不会出现，例如输入不会再发送也不会关闭、context 也无法取消时，才属于泄漏。要结合生命周期与多次 profile 判断。

消费者可以直接关闭输入 channel 吗？

一般不应这样做。关闭 channel 表示不会再有发送，最清楚这个事实的是发送方或协调发送生命周期的所有者。消费者想提前退出时，应发送取消信号，让上游停止发送。