并发编程 on Zampo Blog

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 还在原地等。

goroutine 涨了为什么别先加 buffer：chan send 和 chan receive 不是一类问题

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

goroutine 从 200 慢慢涨到 2 万，线上服务还没挂，但你知道它不对劲。

监控图上那条线不陡，甚至有点温和。它不像事故，更像一个迟早会来的事故。

这时候很多人的第一反应是：把 channel buffer 调大一点。

make(chan int, 100) 改成 make(chan int, 1000)。重启。观察。曲线好像平了。

三天后，又涨回来了。

这不是 buffer 还不够大，而是你修错了地方。

channel 阻塞最麻烦的地方在于，它经常不是立刻炸。它会把 goroutine 悄悄挂在那里，让你以为系统只是“有点忙”。等到 goroutine 越积越多、内存跟着涨、延迟开始抖，你才发现：问题早就发生了。

加 buffer 最多只能买时间，不能改变通信关系。

真正要问的是三件事：谁在发？谁在收？谁负责退出？

这篇只讲上半段：怎么发现 channel 卡住了，以及三个最容易被误判的问题：nil channel、closed channel panic、buffer 当创可贴。

先别看代码，先看 goroutine 有没有在涨

排查 channel 阻塞，不要一上来就钻进业务代码。

业务代码太会骗人了。每一行看起来都有理由，每个分支看起来都能跑通。尤其是线上问题，代码里往往没有一个醒目的“这里会死锁”。真正先露馅的，通常是数字。

最简单的基线是 runtime.NumGoroutine()。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import "runtime"

func init() {
 go func() {
 ticker := time.NewTicker(30 * time.Second)
 defer ticker.Stop()
 for range ticker.C {
 log.Printf("goroutines: %d", runtime.NumGoroutine())
 }
 }()
}

这段代码很粗糙，但有用。

同步原语到底同步了什么：Go 为什么要用 happens-before 解释 channel 和 Mutex

Thu, 28 May 2026 14:52:00 +0800

代码评审里经常出现这种争论：一个 goroutine 写完结果，close(done)；另一个 goroutine 等 <-done 再读结果。有人看着觉得多此一举：这不就是通知一下吗？换成一个 bool，或者 sleep 一小会儿，不也一样？

不一样。

上篇我们说过，ready=true 不是发布。普通变量上的“先写后读”，不会自动变成 goroutine 之间的可见性保证。

这一篇往下走一步：Go 里那些我们天天用的同步原语，到底分别保证了什么？

答案比“channel 是队列，Mutex 是锁”要深一点。

同步原语传递的，不只是控制权，还有可见性。

如果你只把 channel 当队列，只把 Mutex 当门闩，只把 atomic 当“无锁版 Mutex”，并发代码迟早会写得很玄学：能跑，但说不清为什么安全；出事，也说不清哪里断了链。

channel：它不是队列，是一次交接

很多人喜欢把 channel 理解成队列。这个理解不算错，但太窄。

在 Go 内存模型里，channel 真正重要的是几条同步规则：

1
2
3
4


send happens-before 对应 receive 完成
close happens-before 因关闭而返回零值的 receive
无缓冲 channel 上，receive happens-before 对应 send 完成
容量为 C 的 buffered channel 上，第 k 次 receive happens-before 第 k+C 次 send 完成

先看最常见的一种写法：

Go 为什么不承认 ready=true 就是发布：happens-before 才是并发安全的证据

Thu, 28 May 2026 14:40:00 +0800

线上最烦的并发 bug，往往不是崩得轰轰烈烈，而是偶尔读到一个不该出现的旧值。

配置已经加载了，日志也打了“ready”，另一个 goroutine 却像没看见一样，读到的还是旧数据。你盯着代码看半天，越看越觉得冤：明明是先写数据，再把 ready 置成 true。读的一侧也是先等 ready，再读数据。

人脑看这段逻辑，会自然补上一句：既然 ready 已经是 true，前面的数据当然也准备好了。

问题就出在这个“当然”。

在 Go 里，ready=true 不等于发布。普通变量上的“先写后读”，也不等于 goroutine 之间有可见性保证。

并发安全不是看起来有顺序，而是规范承认它有顺序。

这篇只讲 Go 内存模型里最该先吃透的一层：goroutine A 写了变量，goroutine B 什么时候保证能看到？答案不是“代码写在前面”，也不是“机器上跑过没问题”，而是两边有没有一条 happens-before 关系。

最危险的代码，通常看起来最顺

先看这段很多人都写过、也很容易在 review 里漏掉的代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


var data string
var ready bool

go func() {
 data = "payload"
 ready = true
}()

for !ready {
}
fmt.Println(data)

直觉上，它顺得不能再顺。

Go 为什么不让 selectgo 做 O(1) 抽奖：case 越多，runtime 付出的账越多

Wed, 27 May 2026 10:35:00 +0800

很多人写 select，脑子里都有一个抽奖箱。

几个 case 往里一扔，runtime 随机摸一个。哪个 channel 先 ready，哪个就中；都没 ready，就看 default；没有 default，就等。

这个理解不能说全错，但太轻了。

select 不是把 case 丢给调度器随便挑一个。它要先整理 case，跳过 nil channel，生成随机轮询顺序，再按 channel 地址排出加锁顺序。没有任何 case 立即可走时，它还要把当前 goroutine 同时注册到多个 channel 的等待队列里。醒来之后，还得把没选中的那些等待记录清掉。

所以别把 select 想成一次 O(1) 抽奖。

它更像一次小型调度：先洗牌，再排锁，再扫描，必要时多点挂号，最后清场。

这篇接着前两篇，把 selectgo 单独拆开。不是为了劝你少用 select。恰恰相反，select 很好用，但你最好知道它到底帮你付了哪些成本。

nil channel 不是“暂时不可用”，而是直接出局

先从一个最常见的写法说起。

很多代码会用 nil channel 动态关闭某个 select 分支：

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


var ch <-chan int

if enabled {
 ch = realCh
}

select {
case v := <-ch:
 handle(v)
case <-ctx.Done():
 return
}

如果 enabled == false，ch 是 nil。这个接收 case 会怎么样？

Go 为什么让 close(ch) 批量唤醒等待者，而不是只给 channel 关个门

Wed, 27 May 2026 10:21:00 +0800

线上最烦的 channel 问题，往往不是“发不出去”。

而是你以为自己在等一个值，结果等来的是零值；你以为 close(ch) 只是关门，结果它把一批阻塞的 goroutine 全部叫醒；你以为 nil channel 和 closed channel 都是“不能用了”，结果一个永远没人理你，一个立刻给你结果。

上一篇讲 ch <- v，核心是五条发送路径。这一篇换到接收和关闭。

<-ch 看起来只是从队列里拿一个值。但在 runtime 里，它要判断：channel 是不是 nil？是不是已经 close？buffer 里还有没有旧值？有没有 sender 正卡在 sendq？这次接收该不该阻塞？

真正容易讲错的地方在这里：接收不是发送的镜像。

尤其是有缓冲 channel 满的时候，receiver 碰到等待中的 sender，不是简单“从 sender 手里拿值”。它先拿 buffer 头部的旧值，再把 sender 的新值补进 buffer 尾部。

这一个细节没想明白，后面 close、零值、ok、goroutine 唤醒，全都会变成一团雾。

chanrecv：接收不是 chansend 的镜像

接收入口是 chanrecv(c, ep, block)。

你在业务代码里看到的是：

1
2


v := <-ch
v, ok := <-ch

runtime 看到的不是“取一个值”，而是一组分叉：

Go 为什么宁可让 chansend 卡住，也不让你误以为 ch <- v 发成功了

Tue, 26 May 2026 17:40:00 +0800

goroutine dump 里刷出一排 [chan send]，你知道它卡住了。

但更麻烦的问题是：它到底卡在哪？

是 channel 本身是 nil？是已经有人在等接收，只差一次交付？是 buffer 满了？还是它已经被 runtime 挂进 sendq，等下一次接收或关闭来唤醒？

如果你脑子里只有一句“channel 是队列”，排查到这里基本就停了。你会本能地看 buffer 多大，然后想：要不要从 100 改成 1000？

这往往不是修 bug，只是把 bug 往后推。

ch <- v 在 Go runtime 里不是一句“把数据塞进队列”。它会先经过 hchan，再根据当前状态走不同路径：nil channel、等待中的 receiver、可写 buffer、非阻塞失败、真正挂起。

同样是 [chan send]，背后的命运可能完全不同。

很多线上排查就是死在这里。

日志里只剩一行栈：

1
2
3


goroutine 18423 [chan send]:
main.(*Worker).emit(...)
 /app/worker.go:87

你顺着代码点进去，只看到一行很普通的发送：

1

w.results <- result

这行代码不会告诉你 receiver 是不是已经退出了，不会告诉你 buffer 里是不是堆满了旧结果，也不会告诉你这个 channel 是不是在某个分支里被置成了 nil。

业务代码给你的信息太少，runtime 路径才是地图。

超时到了，goroutine 还在涨：context 到底背不背这个锅？

Mon, 25 May 2026 17:46:00 +0800

接口超时了，goroutine 曲线还在往上爬。

日志里已经打出 context deadline exceeded，调用方也早就不等了。你盯着监控看了十分钟，心里开始冒出那个判断：是不是 context.WithTimeout 没生效？

大多数时候，不是。

timeout 可能已经生效了。只是你的 goroutine 没听见，或者听见了也没有退出。

这就是 Go context 最容易被误会的地方：很多人把它当成清洁工，以为只要传下去、超时一到，它就会替你把现场收拾干净。

但 context 没有这么大的权力。

它不会杀 goroutine，不会强制打断你的业务逻辑，不会替你关闭 channel，也不会把一个卡住的 worker 从阻塞点里拽出来。

它只负责把一句话传下去：该停了。

听不听，是你的代码的事。

context 不是清洁工，是通知协议

先把这个判断钉牢：

context 不是清洁工，它只是通知协议。

这句话听起来简单，但很多线上问题正是卡在这里。

你创建了一个带超时的 context：

1
2


ctx, cancel := context.WithTimeout(parent, 200*time.Millisecond)
defer cancel()

这段代码表达的是：这条调用链最多等 200 毫秒，时间到了就发出取消信号；函数提前结束时，也把相关资源释放掉。

注意，是“发出取消信号”，不是“停止所有工作”。

如果下游代码根本不看这个信号，它就会继续跑。比如这样的 worker：

1
2
3
4


func worker(ctx context.Context) {
 ch := make(chan struct{})
 <-ch // 永远等不到
}

你把 ctx 传进来了，但它没有用。timeout 到了，ctx.Done() 会被关闭，ctx.Err() 会变成 context deadline exceeded。可这个 goroutine 仍然卡在 <-ch，它根本没有机会知道外面已经不等了。

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:
 // 现在没有值，先做别的
}

非阻塞发送也一样：

channel 还是 mutex？先回答这五个问题

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

上一篇说到一个很典型的场景：为了写得“更 Go”，有人把一个普通 cache 写成了小型 RPC。

锁确实没了。

但你多了 request、reply channel、owner goroutine、退出顺序、取消处理。读一个 map，本来是一眼能看懂的临界区，最后变成了一套本地协议。

很多人看完这类代码，第一反应还是那个老问题：那到底该用 channel，还是 mutex？

这个问题本身就有点偏。

真正要问的不是“哪个更 Go”，也不是“哪个更高级”。真正要问的是：你现在面对的，到底是哪一种问题。

mutex 保护状态。

channel 描述关系。

这句话很短，但够用。下面这五个问题，就是把它拆开，变成你下次写代码前可以直接拿走的判断流程。

第一个问题：你是在传东西，还是在护东西？

先别看工具，先看问题形状。

如果你处理的是任务、事件、结果、错误、取消信号，它们本来就在 goroutine 之间移动，有明确的方向，有生产者和消费者，有交接关系，那 channel 往往更自然。

比如 worker pool：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


jobs := make(chan Job)
results := make(chan Result)

for i := 0; i < workerCount; i++ {
 go func() {
 for job := range jobs {
 results <- process(job)
 }
 }()
}

这里的 jobs 不是为了显得高级。它表达的是：任务从一个地方流向 worker；worker 处理完，再把结果交回 results。

为了写得“更 Go”，他把一个 cache 写成了小型 RPC

Mon, 25 May 2026 09:53:00 +0800

有些 Go 代码，一看就知道作者很努力。

为了让一个普通 cache 看起来“更 Go”，他把 sync.RWMutex 拿掉了，换成一个专门的 goroutine 来“拥有”这份状态。每次 Get，调用方先构造 request，发进 channel，再等另一个 channel 把结果送回来。Set 也是一样。再往后，还要处理取消、退出顺序、后台 goroutine 什么时候停。

最后代码里确实看不见那把锁了。

但你多了一套协议。

本来 map + RWMutex 三十行能讲清楚的事，被写成了一个本地小型 RPC：请求结构、响应通道、owner goroutine、生命周期管理，一个都不少。

这不是优雅。

这是绕远。

Go 社区有一句被反复引用的话：

Do not communicate by sharing memory; instead, share memory by communicating.

很多人把它念成了另一句话：Go 不喜欢锁，channel 才高级，能用 channel 就别用 mutex。

这个理解太粗，也很容易害人。

channel 的价值不是藏锁，而是写关系。mutex 也不是“不 Go”，它就是保护共享状态的直接工具。真正要问的不是“哪个更有 Go 味”，而是：你现在到底是在传东西，还是在护东西？

channel 首先讲的是结构，不是性能

Rob Pike 在《Concurrency is not Parallelism》里一直在压一个区分：concurrency 是 structure，parallelism 是 execution。

并发不是“同时跑得更快”的同义词。

并发先是一种组织程序的方式：把一件事拆成几个可以独立推进的单元，再让它们通过通信协调。

ready=true 不是发布：Go 内存模型真正要你保证什么

Fri, 22 May 2026 16:40:00 +0800

线上偶现一个很烦的 bug：配置已经加载了，日志也打印了“ready”，但另一个 goroutine 读到的还是旧值。

代码看起来没什么毛病：先写数据，再把 ready 置成 true。读的一侧先等 ready，再读数据。人脑看这段逻辑，很容易得出一个结论：既然 ready 已经是 true，前面的数据当然也该准备好了。

问题就在这里。

在 Go 里，ready=true 不等于发布。普通变量上的“先写后读”，也不等于 goroutine 之间有可见性保证。

并发安全不是让代码看起来有先后，而是让规范承认它有先后。

这篇是 Go 内存模型系列的第一篇。它不打算把你拖进 CPU 指令、缓存一致性协议和汇编细节里。我们先解决一个更常见、更工程化的问题：goroutine A 写了变量，goroutine B 什么时候保证能看到？

答案只有一个：两边要存在 happens-before 关系。

最危险的代码，通常看起来最顺

先看这段很多人都写过的代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


var data string
var ready bool

go func() {
 data = "payload"
 ready = true
}()

for !ready {
}
fmt.Println(data)

直觉上，写入顺序很清楚：data 先被赋值，ready 后变成 true。读的一侧又是看到 ready 才打印 data，似乎不会出错。

加 buffer 不是修 bug：Go channel 阻塞排查实战

Thu, 21 May 2026 18:30:00 +0800

goroutine 数量从 200 慢慢涨到 2 万。

监控图上那条线，不陡，但一直在爬。就像水龙头没拧紧——不喷，但也不会停。

你的第一反应是什么？

加大 buffer。

make(chan int, 100) 改成 make(chan int, 1000)。重启。观察。好像好了。

三天后，又涨回来了。

这不是运气差。这是 Go 服务最常见的线上问题之一：channel 阻塞导致 goroutine 泄漏。而"加 buffer"是社区里最流行、也最没用的解法。

buffer 只是把崩溃推迟了。问题的根因——谁在等谁、谁该退出、谁该 close——一个都没解决。

这篇文章做一件事：从"goroutine 涨了"这个信号出发，走一遍完整的排查路径，把 channel 的六个最常见陷阱逐个拆开。

不是背 API。

是下次线上出问题的时候，你知道先看什么。

发现：怎么知道 channel 卡住了

排查 channel 阻塞的第一步不是看代码，是看数字。

runtime.NumGoroutine()：最简单的基线

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import "runtime"

func init() {
 go func() {
 ticker := time.NewTicker(30 * time.Second)
 defer ticker.Stop()
 for range ticker.C {
 log.Printf("goroutines: %d", runtime.NumGoroutine())
 }
 }()
}

这段代码放到任何 Go 服务的 init() 里，每 30 秒打一行日志。goroutine 数量只升不降，大概率有泄漏。