Channel on Zampo Blog

加 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 数量只升不降，大概率有泄漏。

Go channel 不是高级锁，它是一种组织并发的语言

Thu, 21 May 2026 16:02:00 +0800

有人为了写得“更 Go”，把一个简单 cache 包成了 channel 协议。

每次 Get，先构造 request，发给 owner goroutine，再等 response channel 返回。还要处理 context、close、退出顺序、goroutine 泄漏。

最后代码确实没有显式 sync.RWMutex 了。

但问题也来了：本来一把锁能讲清楚的事，被写成了一套小型 RPC。

这不是优雅。

这是绕远。

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

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

很多人把它理解成：Go 不喜欢锁，channel 更高级，能用 channel 就别用 mutex。

这个理解太粗了。

channel 的价值不是把锁藏起来，而是把通信显式写出来。mutex 也不是“不 Go”，它就是保护共享状态的直接工具。

真正要问的不是：channel 和 mutex 谁更高级？

真正要问的是：你现在到底是在传东西，还是在护东西？

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

Rob Pike 在那场很有名的演讲《Concurrency is not Parallelism》里，一直在压一个区分：concurrency 是 structure，parallelism 是 execution。

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

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

Go channel 源码不是在讲队列，而是在讲 goroutine 怎么排队

Thu, 21 May 2026 15:17:00 +0800

goroutine dump 里满屏 chan send，你知道它卡住了。

但它到底卡在哪里？

是缓冲区满了？没有 receiver？被 select 挂进了等待队列？还是 channel 被 close 之后才醒过来，然后 panic？

如果只停留在“channel 是 goroutine 之间通信的管道”，这些问题永远说不清。

ch <- v 这一行代码，在 Go runtime 里不是一句“把数据塞进队列”。它会走过 hchan、环形缓冲区、sendq / recvq、sudog、gopark、goready，最后决定一个 goroutine 是继续跑，还是挂起来等别人。

Go 的 channel 设计长期受 CSP 思想影响。Rob Pike 在 Go 早期设计和并发模型传播里反复强调：不要通过共享内存来通信，而要通过通信来共享内存。

这句话听起来像哲学，但到了 runtime 里，它会变成很具体的结构：谁在等谁，数据放在哪里，哪个 goroutine 应该被唤醒。

这篇只做一件事：沿着 Go 1.25.4 的 runtime/chan.go 和 runtime/select.go，把 channel 的几条关键路径走一遍。

不是为了背源码。

是为了让你下次看到 chan send、chan receive、close、select 的时候，脑子里有一张清楚的运行时地图。

channel 不是无锁队列，它是带调度语义的协作原语。

hchan：channel 在运行时到底长什么样

Go 代码里你写的是：