goroutine 泄漏不一定忘了 cancel：还要看 sender 和 receiver 谁没回家

Thu, 28 May 2026 15:20:00 +0800

goroutine 泄漏最讨厌的地方，不是它会炸，而是它不炸。

它先是悄悄多几个，再多几十个，最后把内存、延迟、CPU 一起拖下水。你回头看日志，发现代码没报错；你再看监控，发现曲线只是在往上爬。

很多人看到这种情况，第一反应是：是不是忘了 cancel。

有时候是。但不总是。

更常见的真实原因是：channel 这头还在发，那头已经不收了；或者 range 还在等 close，但 close 根本不会来；或者 select 里放了一个 default，把等待变成了空转。

这篇只做一件事：把“goroutine 为什么没退出”拆成四个场景讲清楚，再给你一套能落地的退出规则。

一、先把问题说准：泄漏不是“线程多了”，是“没人回家了”

goroutine 数量上升，不等于一定有 bug。

真正值得警惕的是两种信号：

高峰过去了，goroutine 数量却不回落
pprof 里堆着一批 chan send 或 chan receive

前者说明有生命周期没收住，后者说明你已经碰到阻塞点了。

排查时别先盯业务逻辑。先看两样东西：

1

runtime.NumGoroutine()

和：

1

curl -s http://localhost:6060/debug/pprof/goroutine?debug=1

一个看趋势，一个看栈。趋势告诉你“有事发生了”，栈告诉你“卡在哪”。

二、Goroutine 泄漏，最常见就两种方向

1）sender 还在发，receiver 已经走了

这是最常见的泄漏。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


func leakySender() {
 ch := make(chan int)
 go func() {
 for i := 0; ; i++ {
 ch <- i
 }
 }()

 for i := 0; i < 5; i++ {
 fmt.Println(<-ch)
 }
 // 这里返回后，没人再收 ch
}

表面上看，循环只发了几个值；实际上，后面的 sender goroutine 还在原地等。

channel 最容易翻车的不是发送接收，而是 close

Mon, 25 May 2026 10:28:00 +0800

上一篇讲到最后，其实只把问题说完了一半。

如果你面对的是任务、结果、信号和访问权交接，channel 确实比 mutex 更顺手。它能把 goroutine 之间的关系写出来，让代码不只是在“保护状态”，而是在表达一段通信。

但很多 channel 代码真正翻车的地方，不是发送，也不是接收。

是 close。

线上日志里突然蹦出一行：

1

panic: send on closed channel

通常很难看。因为出问题的那一行，往往只是一个普通到不能再普通的发送：

1

results <- r

真正的问题藏在更早的地方：有人提前把 results 关了。

一个 goroutine 觉得“我不想收了”，顺手 close(results)；另一个 worker 正好处理完任务，准备把结果发回来。于是代码不是优雅退出，而是当场炸掉。

这就是 channel 最容易被低估的地方。

你会写 ch <- v，也会写 <-ch，不代表你已经设计好了这条通信关系。

channel 最难的不是传值，是收尾。

select 解决的是等待，不是公平

先看 select。

Go 没有给 channel 单独设计 TrySend、TryRecv 方法。它把“等哪个 channel、等不等、同时等几个”这件事，统一放进了 select。

非阻塞接收通常长这样：

1
2
3
4
5
6
7
8


select {
case v := <-ch:
 use(v)
case <-ctx.Done():
 return ctx.Err()
default:
 // 现在没有值，先做别的
}