万字详解｜Go 进阶（四）：channel 底层与泄漏排查：5000 个 goroutine 睡死，发送方挂起后谁来唤醒

万字详解｜Go 进阶（四）：channel 底层与泄漏排查：5000 个 goroutine 卡死不退出，发送方挂起后到底谁来唤醒

你好，我是利威尔xu。

这是《Go 进阶》系列的第四篇。前三篇我们把 GMP 调度器、GC 三色标记、内存分配器挨个拆了一遍——这篇轮到并发编程里使用频率最高、踩坑姿势最固定的角色：channel。

这篇文章适合谁：

• 写了两年 Go，make(chan int)用得飞起，但没读过runtime/chan.go一行源码的；
• 线上遇到过 goroutine 只涨不降、pprof 拉起来一片 channel 阻塞，却看不出该唤醒谁的；
• 正在准备 Go 后端面试，被问「channel 底层是什么结构」只会背「hchan」两个字母的。

先把结论放在这，后文逐个给源码和案例验证：

channel 的阻塞和唤醒，从来不是「谁喊一嗓子全体起床」，而是一条精确到 goroutine 的队列操作。理解了 sendq/recvq 两条队列，90% 的 channel 死锁问题看一眼 pprof 就能定位。

本文所有源码基于Go 1.25.4（runtime/chan.go、runtime/select.go），不同版本行号会有漂移，但结构和流程自 Go 1.6 重写后基本没动过大手术。文中涉及的性能数字来自本机实测（Apple M2 / Go 1.25.4 / linux/arm64），文末会附上测试代码的跑法。

一、先说结论：channel 不是「管道」，是一张等待者名单

很多教程把 channel 比作水管：一头灌、一头接。这个比喻在你能跑通 demo 的阶段够用，但一到排查死锁就全废——因为真实的水管会堵，而 channel 的「堵」是有精确账本的。

更贴切的比喻是食堂的取号窗口：

• 窗口（channel）没人的时候，你来了就把餐盘放上传送带（缓冲区），直接走人；
• 传送带满了，你拿着号码牌去旁边坐下（sendq挂起），睡着；
• 取餐的人（接收方）从传送带拿走一份，按叫号机把你摇醒（goready），你才把餐盘递过去；
• 没人取餐、窗口也关门了（close），你会收到一张「关门通知」（panic 或零值），而不是永久坐下。

对应到 runtime，channel 的本质就是hchan这个结构体，加两条 goroutine 等待队列。发送方永远只睡sendq，接收方永远只睡recvq，谁该被谁唤醒，队列里写得明明白白。排查死锁，就是把这两条队列对上账。

先贴结构体（src/runtime/chan.go，Go 1.25.4）：

typehchanstruct{qcountuint// 队列中当前元素个数dataqsizuint// 环形队列容量（make 时的第二个参数）buf unsafe.Pointer// 指向环形队列数组（有缓冲区时非 nil）elemsizeuint16// 单个元素大小closeduint32// 是否已关闭elemtype*_type// 元素类型sendxuint// 发送位置下标（环形队列写入点）recvxuint// 接收位置下标（环形队列读出点）recvq waitq// 等待接收的 goroutine 队列sendq waitq// 等待发送的 goroutine 队列lock mutex// 保护上述所有字段}

面试追问 Q&A

Q：为什么 channel 一定要带一把锁，不能做成无锁的吗？
A：无锁的 MPMC 队列在学术界和工业界都有实现（比如 Lamport 队列、基于 CAS 的环形缓冲），但 channel 的语义比「队列」复杂得多：close 要让所有等待者收到「关闭」事件、select 要同时挂到多个 channel 上、len()/cap()要可读。无锁结构要同时满足这些语义，复杂度会失控。Go 团队的选择是「一把细粒度锁 + 精确的睡眠/唤醒」，实测大部分场景瓶颈不在锁本身，而在 goroutine 挂起唤醒的调度开销。

Q：无缓冲 channel 和有缓冲 channel，在 runtime 里是两套代码吗？
A：不是。buf == nil（无缓冲）时，runtime 把dataqsiz记为 0，所有「入队」分支天然跳过，直接走「发送方把值拷给接收方」的快路径。是同一套代码的两种数据状态，不是两套实现。这个细节很多人答反，值得记一句。

二、发送的源码之路：一次ch <- v到底发生什么

chansend是整个 channel 最容易出问题的一半源码。把主干拆成四步，每一步对应一类线上故障：

第一步：判空和关闭。ch == nil→ 当前 goroutine 永久睡死，而且没有任何人能唤醒它（nil channel 不在任何队列里）。ch.closed != 0→ 直接 panic：send on closed channel。

第二步：加锁，走快路径。如果recvq非空（有接收方在等）——注意，是有等待者优先，而不是缓冲区优先——runtime 会把发送方的值直接 memmove 给第一个等待的接收方，然后goready把它唤醒，自己继续跑，缓冲区动都不动。

第三步：缓冲区路径。recvq空但qcount < dataqsiz，值进环形队列，发送方不阻塞，sendx前移。

第四步：慢路径挂起。缓冲区也满了，把自己包成sudog挂到sendq尾部，gopark睡死。此后它的生死完全交给别人：要么被chanrecv取出值后唤醒，要么被closechan唤醒收到 panic。

这四步对应四类高频故障，先给你一张速查表，建议直接收藏，排查时对着翻：

这张表的用法：把 pprof goroutine dump 里阻塞最多的那个 channel 的内存地址拿出来，和上面四行对号入座，10 分钟内定位。下文第三、四节会把两个典型行展开成完整案例。

三、案例一：5000 个 goroutine 卡死，「发送方挂起后谁来唤醒」

这是一个我处理过的真实形态（脱敏后复现）的故障：一个任务分发服务，启动半小时后 goroutine 数从 200 涨到 5200+，CPU 反而在降，接口超时率飙升。

pprof 拉出来，goroutine profile 的阻塞榜首是这样的：

goroutine 3129 [chan send, 3 hours]: main.(*WorkerPool).dispatch(0xc0001a4000, ...) /app/pool.go:87 +0x1a4

pool.go:87是taskCh <- task。通道是无缓冲 channel，容量 0。设计意图是「发一个、worker 取一个，天然背压」。听起来很美好——直到那个 worker 处理任务时调了一个下游 RPC，下游抖动 3 秒，分发 goroutine 就睡在sendq上 3 秒；worker 恢复后继续取，本来相安无事。

真正致命的是第二处代码：worker 里有个if err != nil { return }——worker 直接退出了，没关 channel、也没通知池子。发送方对此一无所知，继续往sendq尾部挂人。5000 个任务进来，5000 个 goroutine 在sendq里睡成了「永久居民」：它们的 sudog 挂在 hchan 上，但没有 worker 会再来chanrecv，没有任何事件会唤醒它们。

谁来唤醒？答案是：只有三种事件能唤醒 sendq 上的 goroutine——有人 recv、有人 close、进程退出。三者都没有，就是永久泄漏。

修复后的关键代码（这是可复用资产，建议对着改自己的池子）：

// Go 1.25+，worker 退出必须让发送方有感知，三条纪律缺一不可func(p*WorkerPool)dispatch(ctx context.Context,task Task)error{select{casep.taskCh<-task:// 快路径：有 worker 接returnnilcase<-p.done:// 纪律①：池子关闭时发送方必须能退出，而不是永久睡 sendqreturnErrPoolClosedcase<-ctx.Done():// 纪律②：上游取消时同步退出，防雪崩叠加returnctx.Err()case<-time.After(5*time.Second):// 纪律③：兜底超时，睡死也不超过 5 秒returnErrDispatchTimeout}}

三条纪律的源码依据：select在select.go里会给每个 case 注册 sudog，任何一个 case 触发（包括done的 close）都会把其余 sudog 从各自队列里摘掉（sellock/sgunlock全套撤销）。这就是「发送方挂起后谁唤醒」的完整答案——唤醒者是 select 注册的所有 channel，不是主 channel 一个。

面试追问 Q&A

Q：sendq里的 goroutine 是被 FIFO 唤醒的吗？
A：是。chanrecv从sendq头部摘 sudog，chansend挂尾部，严格 FIFO。但要注意：FIFO 不等于公平——如果一个接收方 goroutine 在 recv 后立刻又来 recv，它可能反复抢在刚被唤醒的发送方前面，造成「饿死」假象。所以看到唤醒顺序「不对劲」时，先数接收方的 recv 次数，别先怀疑队列。

Q：怎么在 pprof 里确认泄漏的 channel 是同一个？
A：goroutine?debug=1或pprof.Lookup("goroutine").WriteTo(w, 1)的 dump 里，阻塞在chan send的栈会带0x开头的 channel 地址。写个 5 行脚本聚合地址计数，同一个地址出现 100+ 次，就是它没跑了。别靠肉眼翻栈。

四、案例二：nil channel 与关闭顺序，两行代码两种死法

比案例一更隐蔽的是「nil channel 死锁」。var ch chan int之后直接ch <- 1，runtime 的判断路径是：ch == nil→gopark(neverReady)，参数名就叫永不就绪。这个 goroutine 的栈上看不到任何 channel 地址，pprof 里显示[chan receive(nil), 2 hours]这种字样。典型触发场景：结构体字段是 channel，new 出来忘了初始化，某个错误分支提前发了货。

第二种死法是 close 顺序错。规则只有一句，但值得刻在脑子里：close 只由发送方做，且只做一次。接收方 close，会让正常发送方 panic；双方都 close，第二次直接 panic；close(nil channel)同样 panic。

关闭的安全形态永远是单向的：

// 正确姿势：发送方独占 close 权，用 defer 保证退出路径必达funcproducer(ctx context.Context)<-chanint{ch:=make(chanint,64)gofunc(){deferclose(ch)// 纪律：发送方 return/panic 都会关，接收方永不被挂起fori:=0;;i++{select{casech<-i:case<-ctx.Done():return}}}()returnch// 返回只读方向的 channel，把发送权锁死在函数内}

注意<-chan int这个返回类型——把 channel 的方向写进函数签名，是编译期防呆，调用方想 close 都编译不过。这是 Go 里少见的「类型系统帮你防线上故障」的设计，面试提一句很加分。

面试追问 Q&A

Q：close 一个 channel，runtime 具体做什么？
A：closechan加锁后置closed=1，然后把recvq 里所有等待者全部唤醒，收到零值 +received=false；sendq 里的全部唤醒，收到的是 panic（send on closed channel）。所以 close 是「群发事件」，这也是为什么 close 不能重复做——第二次closed已是 1，直接 panic。

Q：往关闭的 channel 发数据一定 panic 吗？有没有「优雅失败」的写法？
A：一定 panic，没有开关。优雅做法是发送前用select带default/done探活，或者干脆用上面的「发送方独占 close」模式从源头消灭竞态。别指望 recoversend on closed channel后继续用这个 channel——队列状态已经不可信了。

五、select 底层：为什么「随机」是特性不是 bug

select在runtime/select.go，主干三步：

第一步，注册。每个 case 的 channel 加锁，生成scase，非 default 的全部把 sudog 挂到对应 hchan 的 sendq/recvq，记住「我从哪来」。

第二步，排序洗牌。这一步是精髓：runtime 把所有就绪的 case（能立即收发的）收集起来，用fastrandn随机选一个执行。没就绪的才去睡。

第三步，唤醒撤销。选中的 case 执行，其余 sudog 从队列里原样摘除（sgunlock），自己继续跑。

为什么就绪多个时要随机？官方注释写得很直白：防止「饿死」。设想一个读两个 channel 的循环，如果 select 永远优先选第一个，第一个 channel 的生产者永远不被消费，第二个饿死。随机性是公平的代价，不是实现的偷懒。

但随机性也有坑：新手写「超时控制」时爱用select { case v := <-ch: ... case <-time.After(time.Second): ... }，如果ch长期就绪、time.After也到点了，两个 case 都就绪——随机选，可能选到超时分支把有效数据丢了。正确做法是超时判断放业务层，或者就绪优先级手工保证（先非阻塞试一次 ch，再走带超时的 select）。

一个高频追问的边界情况：所有 case 都不就绪、又没有 default，select 才会阻塞；有 default 则永不阻塞。这就是「select+default 做非阻塞探测」的源码依据。

面试追问 Q&A

Q：select 里同时监听同一个 channel 的收发会怎样？
A：编译层面就过不了——同一个 channel 同时出现在两个 case，go vet/编译器会提示，运行时行为是「两个 case 共享同一把锁」，会出现递归加锁风险。这是编译器直接拒绝的少数组合之一。

Q：time.After在 select 里有什么坑？
A：time.After的定时器直到超时才回收，select 每秒执行一次、超时设一分钟，积压的定时器要一分钟后才批量释放，高频循环里是真实的内存泄漏源。Go 1.23 之后time.After改成了「超时后即回收」的新实现（runtime/time.go里when+1触发后 channel 关闭并让 timer 可回收），这个历史坑在新版本已经修了大半，但老项目停留在 1.21 以前的仍要小心——版本升级本身就是修复手段，这就是我强调「注 Go 1.25+」的原因。

六、可复用资产：channel 问题 30 秒定位清单

把全文的排查动作压缩成一张表。这张表建议收藏，下次线上 goroutine 只涨不降、或接口偶发卡死，按顺序走一遍：

配套一个 20 行的自查脚本，压测时挂着，曲线不对就报警：

// Go 1.25+：泄漏哨兵，每 10s 采一次，超过水位打日志funcwatchGoroutines(watermarkint){last:=0forrangetime.Tick(10*time.Second){n:=runtime.NumGoroutine()ifn>watermark&&n>last{log.Printf("goroutine leak suspect: %d (last %d)",n,last)buf:=make([]byte,1<<16)buf=buf[:runtime.Stack(buf,true)]_=os.WriteFile(fmt.Sprintf("/tmp/gr-%d.txt",time.Now().Unix()),buf,0o644)}last=n}}

这张清单 + 这段哨兵代码，就是这篇文章最值得收藏的部分——channel 的源码会随版本微调，但「地址聚合 → 对号队列 → 验证生产者」这套排查方法论不会过时。

面试追问 Q&A

Q：goroutine 泄漏和内存泄漏什么关系？
A：每个 goroutine 最少 2KB 栈（Go 1.25 起初始栈 2KB，可扩到 1GB 上限），5200 个泄漏 goroutine 就是 10MB+ 起步，但它们持有的中间变量、channel 引用、锁才是大头——一个 goroutine 拽着整个请求上下文不撒手，才是内存曲线跟着 goroutine 曲线一起涨的原因。

Q：为什么debug=1的 dump 比debug=2更适合排查 channel 阻塞？
A：debug=1输出全部 goroutine 的完整栈，channel 阻塞栈会带chan send/chan receive字样和地址；debug=2会额外 dump 每个 goroutine 栈帧里的局部变量，信息全但体积大 5-10 倍，curl 容易超时。先 1 定位、必要时再 2。

七、本章小结：三句话带走

1. channel 的本质是 hchan + 两条等待队列：发送方睡 sendq、接收方睡 recvq，唤醒事件只有三个——有人 recv、有人 close、进程退出；
2. nil channel 永不就绪、closed channel 群发事件：发送方独占 close 权、返回<-chan锁死方向，是编译期防呆；
3. select 的随机性是公平机制，select+default才是非阻塞探测的唯一正确形态，超时兜底要显式写。

💡本章面试要点（高频追问一句话版）：

• hchan 的 recvq/sendq 分别挂谁？→ 接收方/发送方，FIFO；
• 无缓冲 channel 发送时，接收方在等会怎样？→ 直接拷贝不给缓冲区，缓冲动都不动；
• close 时 sendq 里的 goroutine 收到什么？→ panic，不是零值；
• 为什么 select 多个就绪 case 要随机？→ 防饿死，公平优先；
• goroutine 泄漏排查三步？→ NumGoroutine 看趋势 → pprof 找阻塞栈 → 聚合 channel 地址。

如果这篇文章帮你把「channel 就是一根管道」的旧认知换成了「两条队列一本账」，建议收藏——第三节的四类故障速查表和第六节的 30 秒定位清单，排查时直接翻，不用再从原理开始推。

一个问题留给你，一句话就能答：你手里的服务，如果现在debug=1拉一份 goroutine dump，阻塞榜首会是chan send还是chan receive？欢迎评论区报一下你的答案，我看看有多少人的 channel 其实一直在「带病工作」。

下一篇预告：《Go 进阶（五）》——sync.Mutex的四种状态与饥饿模式：自旋 4 次就让权，10000 个 goroutine 抢一把锁时谁在吃亏。老规矩，源码 + 线上案例 + 排查清单三件套。

系列导航：

1. 《万字详解｜Go 进阶（一）GMP 调度器》 https://blog.csdn.net/2604_97047541/article/details/168453593
2. 《万字详解｜Go 进阶（二）GC 三色标记》 https://blog.csdn.net/2604_97047541/article/details/168771937
3. 《万字详解｜Go 进阶（三）内存分配器》 https://blog.csdn.net/2604_97047541/article/details/169167664
4. 面试向追问合集：《GMP 调度器 10 个高频追问》 https://blog.csdn.net/2604_97047541/article/details/168559644

作者：利威尔xu | CSDN 专栏《GO保姆级万字详解》