---
tags: [go/lang, channel, hchan, ring-buffer, deadlock, synchronization]
create time: 2026-08-08 19:00
update time: 2026-08-08 19:00
---
# Channel 底层实现
## 概述
Channel 是 Go 语言中唯一的 IPC（进程间通信）机制，也是 goroutine 之间传递数据、同步信号的核心原语。它封装了互斥锁、条件变量和环形缓冲区的复杂性，对外暴露简洁的 `send / recv / close` 语义。理解 channel 的底层结构，能帮你回答「无缓冲 vs 有缓冲怎么选」「什么时候会死锁」「close 到底谁该调」这些高频面试问题。
> [!TIP] 核心心法
> Channel 不是消息队列，它是 goroutine 之间的同步通道。不要把 Channel 当作通用数据结构来用，它的正确姿态是协调并发的节奏。
## 核心原理
### hchan 数据结构
Go runtime 中 channel 对应的内部结构体为 `hchan`，关键成员如下：
```go
type hchan struct {
qcount uint // 队列中剩余元素个数
dataqsiz uint // 环形缓冲区容量（cap）
buf unsafe.Pointer // 指向长度为 dataqsiz 的环形缓冲区
elemsize uint16 // 每个元素的字节大小
closed uint16 // 是否已关闭
elemtype *etype // 元素类型信息
sendx uint // 发送索引（当前可写入的位置）
recvx uint // 接收索引（当前可读到的位置）
waitq waitq // 阻塞等待队列（sudog链表）
lock mutex // 保护上述所有字段
}
```
其中 `waitq` 包含两个 `sudog` 链表：
- `recvq` — 在 channel 上等待接收数据的 goroutine 队列
- `sendq` — 在 channel 上等待发送数据的 goroutine 队列
> [!NOTE]
> 对于无缓冲 channel（`dataqsiz == 0`），`buf == nil`，此时每次 send 都必须与 recv 直接配对完成手递手交接。
### 环形缓冲区原理
有缓冲 channel 的 `buf` 是一个循环数组，通过 `sendx` 和 `recvx` 两个指针控制读写位置：
```mermaid
graph LR
A["buf[0]
已读取"] --> B["buf[1]
待写 ← sendx"]
B --> C["buf[2]
待读 ← recvx"]
C --> D["buf[3]
空位"]
D --> E["buf[N-1]
空位"]
E --> A
style A fill:#ffcdd2
style B fill:#c8e6c9
style C fill:#c8e6c9
style D fill:#e3f2fd
style E fill:#e3f2fd
```
- `sendx`：下一个可写入位置的索引，写入后 `sendx = (sendx + 1) % dataqsiz`
- `recvx`：下一个可读位置的索引，读出后 `recvx = (recvx + 1) % dataqsiz`
- 当 `qcount == dataqsiz` 时缓冲区满，写操作阻塞；当 `qcount == 0` 时缓冲区空，读操作阻塞
> [!TIP]
> `sendx` 和 `recvx` 相等时并不一定代表空或满，需要结合 `qcount` 判断：`qcount == 0` 为空，`qcount == dataqsiz` 为满。
### 发送流程（send）完整链路
channel 的 `send` 操作用于向 channel 写入数据。整个流程分为三个阶段：
```mermaid
flowchart TD
A["goroutine 调用 ch <- val"] --> B["获取 &ch.lock"]
B --> C{"qcount > 0
缓冲区中有数据?"}
C -->|否| D{"recvq 非空?
有等待的接收者?"}
D -->|是| E["手递手: G->G 拷贝"]
D -->|否| F["创建 sudog
加入 sendq"]
C -->|是| G["从 recvx 取数据给调用者"]
G --> H["唤醒 recvq 队首 goroutine"]
F --> I["gopark 睡眠
等待被唤醒"]
E --> J["双方同时返回
继续执行"]
H --> K["release lock"]
I --> L["被唤醒后 release lock"]
```
核心逻辑分三步：
1. **尝试缓冲区**：如果 `qcount > 0`，直接从缓冲区取出数据给调用者，并唤醒一个等待的接收 goroutine。
2. **手递手**：如果缓冲区空但 `recvq` 中有等待者，直接将数据从发送者栈拷贝到接收者栈（绕过缓冲区），双方同时返回。这保证了无缓冲 channel 的严格同步语义。
3. **入队阻塞**：两者都不行，把当前 goroutine 包装成 `sudog` 插入 `sendq`，然后调用 `gopark()` 进入睡眠，直到被接收方唤醒。
> [!WARNING] 容易混淆的点
> send 操作中的"从缓冲区取数据给调用者"这一步看似反直觉——明明是发送方为什么在读取？实际上这是 hand-off 模式：当一个接收者在等的时候，channel 不经过缓冲区直接把数据从发送者栈传过去，或者先放进缓冲区再让接收者取走。具体路径取决于有无等待的接收者。
### 接收流程（recv）
接收是发送的镜像对称过程：
```mermaid
flowchart TD
A["val := <-ch"] --> B["获取 &ch.lock"]
B --> C{"qcount > 0
缓冲区中有数据?"}
C -->|是| D["从 sendx 读取数据"]
D --> E["唤醒 sendq 队首 goroutine"]
C -->|否| F{"sendq 非空?
有等待的发送者?"}
F -->|是| G["手递手: 从 G 栈取值"]
G --> H["唤醒 sendq 队首 goroutine"]
F -->|否| I["创建 sudog
加入 recvq"]
I --> J["gopark 睡眠"]
E --> K["return val, true"]
H --> K
J --> L["被唤醒后 continue"]
```
### close 语义
调用 `close(ch)` 后的行为：
| 操作 | 结果 |
|------|------|
| 向已关闭 channel 发送数据 | panic: send on closed channel |
| 从已关闭 channel 接收数据 | 返回元素类型的零值，第二个返回值 `false` |
| 从已关闭且空的 buffered channel 接收 | 同上，持续返回零值直到 `qcount == 0` |
| 对 nil channel 发送/接收 | 永久阻塞（不会 panic） |
| 重复 close 同一个 channel | panic: close of closed channel |
关闭操作本身也持有 `&ch.lock`，会遍历 `recvq` 中的所有 `sudog` 并唤醒它们（每个 sudog 标记为已关闭）。因此从 `closed` channel 中 drain 数据不会出现遗漏——在 close 之前已经送进 buffer 的数据一定会被接收到。
> [!WARNING]
> nil channel 上的收发会永久阻塞，既不会 panic 也不会被 close。这是编写超时逻辑时需要警惕的边界条件。nil channel 本质上是不存在的 channel。
### 三种 Channel 类型对比
```mermaid
graph TB
subgraph NC ["无缓冲 Channel make chan T"]
direction TB
NC1["buf = nil"]
NC2["qcount 始终为 0"]
NC3["Send 与 Recv 严格配对"]
NC1 --> NC3
NC2 --> NC3
end
subgraph BC ["有缓冲 Channel make chan T cap"]
direction TB
BC1["buf 指向环形数组"]
BC2["cap > 0"]
BC3["异步最多缓冲 cap 个元素"]
BC1 --> BC3
BC2 --> BC3
end
style NC3 fill:#e3f2fd,stroke:#1565c0
style BC3 fill:#e8f5e9,stroke:#2e7d32
```
- **无缓冲**：发送和接收必须同时就绪，本质上是一种同步原语。适合「一对一通知」场景。
- **有缓冲**：发送可以异步进行，最多缓存 `cap` 个元素。适合生产者 - 消费者模型中的流量削峰。
## 代码示例
### 正确使用 Close 的模式
```go
func worker(id int, jobs <-chan int, results chan<- int) {
for j := range jobs { // range 自动处理关闭 + draining
results <- doWork(j)
}
}
func main() {
jobs := make(chan int, 100)
results := make(chan int, 100)
// 启动 worker
for w := 0; w < 3; w++ {
go worker(w, jobs, results)
}
// 发送任务
for j := 1; j <= 5; j++ {
jobs <- j
}
close(jobs) // sender 负责关闭
// Drain results
for a := 1; a <= 5; a++ {
<-results
}
}
```
> [!TIP]
> **原则：谁生产谁关闭。** 多个 receiver 共用同一个 channel 时，receiver 不应该关闭它——只有唯一的生产者在发完所有数据后才应调用 close。
### Select 多路复用配合 Close 检测
```go
for {
select {
case v, ok := <-ch:
if !ok { // channel 已关闭且空
return
}
fmt.Println(v)
default:
// 非阻塞：没有可用数据时立即执行
fmt.Println("no data")
}
}
```
`ok == false` 表示 channel 已关闭并且缓冲区中的数据已全部读完，这是安全退出循环的信号。
### 避免 Deadlock 的三种场景
| 场景 | 原因 | 表现 |
|------|------|------|
| 无缓冲 + 单侧 | 只有一方做 send 或 recv | `fatal error: all goroutines are asleep - deadlock!` |
| 缓冲满 + 无人 recv | 缓冲区满了但没有接收者消费 | 同上 |
| 双向互相等待 | Goroutine A 等 B 发，B 等 A 发 | 典型的双重死锁 |
## 实践场景
### 面试官常问的两个决策题
**Q：无缓冲还是缓冲？**
- 需要精确控制并发度、保证 send 和 recv 严格配对时用无缓冲（如信号量、worker 同步）。
- 需要解耦生产者和消费者的速率差异时用有缓冲（如消息分发、批量请求聚合）。
- 缓冲大小的经验法则：根据预期峰值流量 + 合理容忍延迟来估算，一般设为 goroutine 数量的 1~10 倍。
**Q：谁来关闭 channel？**
- 唯一的生产者关闭。多个 receiver 共享 channel 时，任何 receiver 关闭都会导致 panic。
- 如果无法确定何时发完所有数据（如 HTTP server 无限接收请求），就不要关闭 channel，改用 context 取消。
### 与 Mutex 的协作模式
Channel 在简单场景下可以替代 Mutex：
```go
var ch = make(chan struct{}, 1)
ch <- struct{}{} // acquire
// critical section
<-ch // release
```
但要注意：这种方式不适合重锁场景，因为 channel 的加锁开销远大于 `sync.Mutex`。`sync.Mutex` 更适合同一进程中短时间竞争的场景；channel 更适合跨 goroutine 的消息传递。
## 扩展阅读
- [[Select 多路复用机制]] — select 建立在 channel 的 sendq/recvq 调度之上
- [[Goroutine 调度模型]] — goroutine 在 channel 上的休眠与唤醒由调度器驱动