266 lines
9.6 KiB
Markdown
266 lines
9.6 KiB
Markdown
---
|
||
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]<br/>已读取"] --> B["buf[1]<br/>待写 ← sendx"]
|
||
B --> C["buf[2]<br/>待读 ← recvx"]
|
||
C --> D["buf[3]<br/>空位"]
|
||
D --> E["buf[N-1]<br/>空位"]
|
||
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<br/>缓冲区中有数据?"}
|
||
|
||
C -->|否| D{"recvq 非空?<br/>有等待的接收者?"}
|
||
D -->|是| E["手递手: G->G 拷贝"]
|
||
D -->|否| F["创建 sudog<br/>加入 sendq"]
|
||
|
||
C -->|是| G["从 recvx 取数据给调用者"]
|
||
G --> H["唤醒 recvq 队首 goroutine"]
|
||
|
||
F --> I["gopark 睡眠<br/>等待被唤醒"]
|
||
E --> J["双方同时返回<br/>继续执行"]
|
||
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<br/>缓冲区中有数据?"}
|
||
|
||
C -->|是| D["从 sendx 读取数据"]
|
||
D --> E["唤醒 sendq 队首 goroutine"]
|
||
|
||
C -->|否| F{"sendq 非空?<br/>有等待的发送者?"}
|
||
F -->|是| G["手递手: 从 G 栈取值"]
|
||
G --> H["唤醒 sendq 队首 goroutine"]
|
||
|
||
F -->|否| I["创建 sudog<br/>加入 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 上的休眠与唤醒由调度器驱动
|