Go 语言 channel 底层结构 hchan 解析

本文深入剖析了 Go 语言 channel 的底层核心结构体 hchan，揭示其如何通过 qcount、dataqsiz、buf、sendq、recvq 和 lock 等关键字段精准控制 channel 的行为：从 len/chap 的语义本质、缓冲区的环形内存管理、goroutine 阻塞与唤醒机制，到无缓冲 channel 的零拷贝直接交接原理，再到所有操作强制串行化的锁保护策略——读懂 hchan，就真正理解了 channel 阻塞与否、读写安全边界、close 后行为及性能开销的底层根源。

hchan 是 Go 运行时内部结构，你无法直接声明、访问或修改它；所有 make(chan T, N) 调用背后都由 runtime 分配并初始化一个 hchan 实例，挂载在堆上。

hchan 的关键字段对应哪些运行时行为

看懂这几个字段，就能预判 channel 是否阻塞、len(ch) 为什么不准、close 后还能读到什么：

• qcount 就是 len(ch) 返回的值，表示当前缓冲区中实际存放的元素个数；它不统计正在 sendq/recvq 中等待交接的数据
• dataqsiz 决定 cap(ch)：为 0 → 无缓冲 channel；>0 → 有缓冲，buf 数组长度即为此值
• buf 是 unsafe.Pointer，只在 dataqsiz > 0 时非 nil；它不是 slice，而是原始内存块起始地址，读写靠 sendx/recvx 偏移计算
• sendq 和 recvq 是双向链表，节点是 sudog（封装 goroutine 指针、待传值地址、唤醒状态等），不是数据本身；goroutine 阻塞时挂入对应队列，被唤醒时由 goready 触发，非轮询
• lock 是真实互斥锁，所有收发、close 操作都必须持锁；哪怕无缓冲 channel，也逃不开这把锁 —— 它保护整个 hchan 结构及关联的 sudog 字段

无缓冲 channel 的 buf 为什么是 nil

因为无缓冲 channel 不需要存储中间数据，收发必须同步完成：发送方 goroutine 直接把值交给接收方 goroutine 的栈帧，绕过 buf。此时 dataqsiz == 0，runtime 不分配 buf 内存，buf 恒为 nil。

• 这种“直接交接”不拷贝数据到堆，但会拷贝值本身（如 int 拷 8 字节，*int 拷指针值）
• 若发送方在 ch 后立刻修改 x 所指向的内容（比如是 *int 或 []byte），接收方看到的可能是脏数据 —— 这不是 bug，是值拷贝语义下的正常行为
• len(ch) 在无缓冲 channel 上永远是 0，cap(ch) 也是 0；别用 cap(ch) - len(ch) 算“剩余空间”，它在无缓冲场景下毫无意义

为什么 hchan 必须分配在堆上

channel 变量（如 ch := make(chan int, 10)）本身是个指针，它在栈上，但所指向的 hchan 实例一定在堆上。

• 多个 goroutine 可能同时访问同一个 channel，而 goroutine 栈生命周期不可控；堆分配保证 hchan 生命周期独立于任意单个 goroutine
• sendq/recvq 中挂的 sudog 也要跨 goroutine 存活，它们也分配在堆上
• 即使你把 channel 作为参数传给函数，传的是指针副本，底层仍指向同一块堆内存中的 hchan

真正容易被忽略的是：sendx 和 recvx 是环形偏移索引，不是线性数组下标；当它们走到 dataqsiz 边界时会回绕，但 runtime 不做边界检查 —— 错误的 unsafe 操作可能越界读写 buf 内存，且不会 panic，只会引发静默数据损坏。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Go 语言 channel 底层结构 hchan 解析》文章吧，也可关注golang学习网公众号了解相关技术文章。