https://blog.cpdd.fyi/tags/runtime/Recent content in Runtime on Zampo BlogHugozh-cnThu, 21 May 2026 15:17:00 +0800https://blog.cpdd.fyi/posts/go-channel-hchan-runtime-source/Thu, 21 May 2026 15:17:00 +0800https://blog.cpdd.fyi/posts/go-channel-hchan-runtime-source/<p>goroutine dump 里满屏 <code>chan send</code>，你知道它卡住了。</p> <p>但它到底卡在哪里？</p> <p>是缓冲区满了？没有 receiver？被 <code>select</code> 挂进了等待队列？还是 channel 被 close 之后才醒过来，然后 panic？</p> <p>如果只停留在“channel 是 goroutine 之间通信的管道”，这些问题永远说不清。</p> <p><code>ch &lt;- v</code> 这一行代码，在 Go runtime 里不是一句“把数据塞进队列”。它会走过 <code>hchan</code>、环形缓冲区、<code>sendq</code> / <code>recvq</code>、<code>sudog</code>、<code>gopark</code>、<code>goready</code>，最后决定一个 goroutine 是继续跑，还是挂起来等别人。</p> <p><img src="https://blog.cpdd.fyi/images/go-channel-hchan-runtime-source/cover.png" alt="Go channel hchan 运行时封面"></p> <p>Go 的 channel 设计长期受 CSP 思想影响。Rob Pike 在 Go 早期设计和并发模型传播里反复强调：不要通过共享内存来通信，而要通过通信来共享内存。</p> <p><img src="https://blog.cpdd.fyi/images/go-channel-hchan-runtime-source/rob-pike.jpg" alt="Rob Pike"></p> <p>这句话听起来像哲学，但到了 runtime 里，它会变成很具体的结构：谁在等谁，数据放在哪里，哪个 goroutine 应该被唤醒。</p> <p>这篇只做一件事：沿着 Go 1.25.4 的 <code>runtime/chan.go</code> 和 <code>runtime/select.go</code>，把 channel 的几条关键路径走一遍。</p> <p>不是为了背源码。</p> <p>是为了让你下次看到 <code>chan send</code>、<code>chan receive</code>、<code>close</code>、<code>select</code> 的时候，脑子里有一张清楚的运行时地图。</p> <p>channel 不是无锁队列，它是带调度语义的协作原语。</p> <h2 id="hchanchannel-在运行时到底长什么样">hchan：channel 在运行时到底长什么样</h2> <p>Go 代码里你写的是：</p>