Go 语言中 channel 的底层结构 hchan 是怎样的-Golang-PHP中文网

hchan是go运行时管理channel的内部结构体，无法直接声明或访问；qcount对应len(ch)，dataqsiz决定cap(ch)，buf为环形缓冲区起始地址（仅dataqsiz>0时非nil），sendq/recvq挂阻塞goroutine，lock保证所有操作串行化。

go 语言中 channel 的底层结构 hchan 是怎样的

hchan 是 Go 运行时内部结构，你无法直接声明、访问或修改它；所有 make(chan T, N) 调用背后都由 runtime 分配并初始化一个 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 不需要存储中间数据，收发必须同步完成：发送方 goroutine 直接把值交给接收方 goroutine 的栈帧，绕过 buf。此时 dataqsiz == 0，runtime 不分配 buf 内存，buf 恒为 nil。

下载

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

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，只会引发静默数据损坏。