汀的知识碎片

02 Channel 的底层结构与阻塞唤醒机制

25 min read

Channel 的底层结构与阻塞唤醒机制

摘要

Channel 是 Go 并发模型的通信基础，是 CSP（Communicating Sequential Processes）哲学在语言层面的直接体现——“不要通过共享内存来通信，而要通过通信来共享内存”。但 Channel 不是魔法，它底层是一个带互斥锁的环形缓冲区（hchan 结构体），发送方和接收方通过 sudog（suspended goroutine）等待队列实现阻塞与唤醒。理解这套机制，能解释很多工程实践中的疑问：无缓冲 Channel 为什么能实现”同步握手”？有缓冲 Channel 满了之后发送为什么会阻塞？关闭 Channel 为什么能广播通知？select 语句是如何在多个 Channel 上并发等待的？本文从 hchan 的内存布局出发，逐一剖析 send、recv、close 三个核心操作的完整流程，以及 select 的随机化多路复用实现。

第 1 章 CSP 模型：Channel 的设计哲学根源

1.1 共享内存并发的困境

在传统的多线程编程（如 Java/C++ 的 Thread + synchronized）中，并发的核心机制是共享内存：多个线程访问同一块内存区域，通过锁（Mutex）、信号量（Semaphore）等原语保证访问的互斥性和可见性。

这种模型在简单场景下可行，但随着并发度增加，问题愈发突出：

  • 死锁（Deadlock）：线程 A 持有锁 X 等待锁 Y，线程 B 持有锁 Y 等待锁 X——双方永久等待；
  • 活锁（Livelock）：线程不停地重试但永远无法前进；
  • 竞态条件（Race Condition）：锁粒度控制不当，导致并发访问产生不确定的结果；
  • 优先级反转（Priority Inversion）：低优先级线程持有锁，导致高优先级线程无法运行。

这些问题的根源是：共享状态让代码推理变得困难——你必须在脑海中同时跟踪所有可能的执行顺序，才能证明代码的正确性。

1.2 CSP：通过通信共享状态

1978 年，Tony Hoare 提出了 CSP（Communicating Sequential Processes，通信顺序进程） 模型，提供了一种完全不同的并发思路：

不要通过共享内存来通信，而要通过通信来共享内存。 ——Go 并发哲学

CSP 的核心思想：每个并发实体（进程/Goroutine）各自维护私有状态，不直接共享；需要协作时，通过消息传递（通道） 来交换数据。通道本身负责处理同步，调用方只需关心”发送”和”接收”的语义，而不需要关心锁的获取和释放。

这种模型让并发代码更易于推理：每个 Goroutine 只需要关心自己的数据和与它通信的 Channel，不需要全局地思考锁的顺序。数据的所有权随着 Channel 传递而转移——某种意义上，Channel 是”动态的所有权转移”机制，而不只是数据传输管道。

Go 的 Channel 是 CSP 理论的工程实现，但 Go 并不是纯粹的 CSP 语言——它同时提供了 sync 包中的互斥锁、原子操作等共享内存原语，允许程序员根据具体场景选择最合适的工具。

第 2 章 hchan：Channel 的内存结构

2.1 hchan 结构体

ch := make(chan int, 3) 在堆上分配一个 hchan 结构体（ch 变量本身是指向 hchan 的指针，8 字节）：

// runtime/chan.go（简化，加中文注释）
type hchan struct {
    qcount   uint           // 环形缓冲区中当前的元素数量
    dataqsiz uint           // 环形缓冲区的容量（make 时指定的缓冲大小）
    buf      unsafe.Pointer // 指向环形缓冲区的指针（dataqsiz == 0 时为 nil）
    elemsize uint16         // 元素大小（字节）
    closed   uint32         // 是否已关闭（0=未关闭，1=已关闭）
    elemtype *_type         // 元素类型信息（用于 GC 扫描）
    sendx    uint           // 发送游标：下次发送写入缓冲区的位置
    recvx    uint           // 接收游标：下次接收从缓冲区读取的位置
    recvq    waitq          // 等待接收的 Goroutine 队列（阻塞的接收方）
    sendq    waitq          // 等待发送的 Goroutine 队列（阻塞的发送方）
    lock     mutex          // 保护所有字段的互斥锁
}
 
// waitq 是一个双向链表，链表节点是 sudog
type waitq struct {
    first *sudog
    last  *sudog
}

**sudog（suspended goroutine）**是关键数据结构，代表一个”挂起在 channel 上的 Goroutine”：

// runtime/runtime2.go（简化）
type sudog struct {
    g        *g            // 被挂起的 Goroutine
    next     *sudog        // 队列中的下一个
    prev     *sudog        // 队列中的上一个
    elem     unsafe.Pointer // 要发送或要接收的数据指针
    c        *hchan        // 挂起在哪个 channel 上（用于 select）
    // ...
}

2.2 三种 Channel 的内存布局

无缓冲 Channel（make(chan int)）:
+----------+
| hchan    |
| qcount=0 |
| dataqsiz=0|
| buf=nil  |  ← 没有缓冲区
| sendx=0  |
| recvx=0  |
| recvq=[] |
| sendq=[] |
| lock     |
+----------+

有缓冲 Channel（make(chan int, 3)）:
+----------+     +---+---+---+
| hchan    |     | 0 | 0 | 0 |  ← 3 个 int 槽位的环形缓冲区
| qcount=0 |     +---+---+---+
| dataqsiz=3|        ↑
| buf ──────────→ [环形缓冲区]
| sendx=0  |     sendx 指向下次写入位置
| recvx=0  |     recvx 指向下次读取位置
| recvq=[] |
| sendq=[] |
| lock     |
+----------+

已满的有缓冲 Channel（qcount=3, dataqsiz=3）:
+----------+     +---+---+---+
| hchan    |     | 1 | 2 | 3 |  ← 缓冲区已满
| qcount=3 |     +---+---+---+
| dataqsiz=3|    recvx  sendx（两者追上后意味着满）
| sendq=[G4]|  ← G4 尝试发送第 4 个元素，被挂起到 sendq
+----------+

2.3 Channel 的类型约束

Channel 有三种方向类型：

ch1 := make(chan int)     // 双向 channel：可发送，可接收
var ch2 chan<- int = ch1  // 单向发送 channel（只能 ch2 <- v）
var ch3 <-chan int = ch1  // 单向接收 channel（只能 v := <-ch3）
 
// 函数参数中限定 channel 方向，是最佳实践：
func producer(out chan<- int) {
    out <- 42  // 只能发送
}
func consumer(in <-chan int) {
    v := <-in  // 只能接收
}

单向 Channel 是编译器层面的约束——运行时底层都是同一个 hchan，只是编译器限制了可用的操作。这让代码意图更清晰，也让编译器能在编译期发现”向只读 channel 发送”等错误。

第 3 章 发送操作（ch ← v）的完整流程

3.1 三条快速路径

ch <- v 在运行时调用 chansend 函数，执行以下判断（按优先级）：

路径一（直接发送给等待的接收方）：如果 recvq 不为空（有 Goroutine 阻塞等待接收），直接将数据写入等待接收的 Goroutine 的栈，唤醒它。这条路径绕过了缓冲区，是最高效的：

// runtime/chan.go（概念性）
func chansend(c *hchan, ep unsafe.Pointer) {
    lock(&c.lock)
    
    // 路径一：有等待接收的 Goroutine
    if sg := c.recvq.dequeue(); sg != nil {
        // 直接将数据 ep 复制到 sg.elem（等待接收 Goroutine 的栈变量）
        send(c, sg, ep, func() { unlock(&c.lock) })
        return
    }
    // ...
}

为什么直接写到接收方的栈，而不是经过缓冲区？ 因为等待的接收方已经明确表示”我要接收”，此时直接交给它是最短路径，省去了写缓冲区 + 从缓冲区读的两次内存拷贝，性能更好。这是一种”零拷贝”优化。

路径二（写入缓冲区）：如果 recvq 为空，但缓冲区未满（qcount < dataqsiz），将数据写入缓冲区的 sendx 位置，sendx 和 qcount 递增，解锁，返回：

    // 路径二：缓冲区有空位
    if c.qcount < c.dataqsiz {
        qp := chanbuf(c, c.sendx)  // 取 sendx 位置的指针
        typedmemmove(c.elemtype, qp, ep)  // 将数据复制到缓冲区
        c.sendx++
        if c.sendx == c.dataqsiz { c.sendx = 0 }  // 环形处理
        c.qcount++
        unlock(&c.lock)
        return
    }

路径三（阻塞等待）：缓冲区已满（或无缓冲 channel），当前 Goroutine 需要阻塞：

    // 路径三：需要阻塞
    gp := getg()
    sg := acquireSudog()  // 从 sudog 缓存池取一个 sudog
    sg.g = gp
    sg.elem = ep          // 保存要发送的数据指针
    sg.c = c
    
    c.sendq.enqueue(sg)   // 将 sudog 加入发送等待队列
    
    // 挂起当前 Goroutine（进入 _Gwaiting 状态）
    gopark(chanparkcommit, unsafe.Pointer(c), waitReasonChanSend, ...)
    // gopark 之后，当前 Goroutine 被调度出去，M 去运行其他 G
    
    // 当被唤醒时（有接收方取走了数据），从这里继续执行
    releaseSudog(sg)

3.2 发送到已关闭 Channel：panic

向已关闭的 Channel 发送数据，chansend 检测到 c.closed != 0 时会立即 panic：

if c.closed != 0 {
    unlock(&c.lock)
    panic(plainError("send on closed channel"))
}

这是设计上的刻意选择：Channel 关闭意味着”不会再有数据从这里发送”，向关闭的 Channel 发送是逻辑错误，应该在开发阶段就暴露，而不是静默失败。

第 4 章 接收操作（v := ←ch）的完整流程

4.1 三条路径（与发送对称）

接收操作调用 chanrecv，同样有三条路径：

路径一（直接从等待的发送方接收）：如果 sendq 不为空，且是无缓冲 channel——直接从等待发送的 Goroutine 取数据，唤醒它；如果是有缓冲 channel 且缓冲区已满，先从缓冲区头部取数据，再将等待发送的 Goroutine 的数据写入缓冲区尾部（维持 FIFO 顺序）。

路径二（从缓冲区读取）：sendq 为空，缓冲区有数据（qcount > 0）——从 recvx 位置读数据，recvx 递增，qcount 递减，解锁，返回。

路径三（阻塞等待）：缓冲区为空，没有等待的发送方——当前 Goroutine 挂起到 recvq，等待被发送方唤醒。

4.2 接收已关闭 Channel 的特殊语义

从已关闭 Channel 接收不会 panic，而是：

  • 如果缓冲区还有数据：继续接收数据（保证消费完所有数据）；
  • 缓冲区为空：立即返回元素类型的零值，ok = false（如果使用双返回值形式）。
ch := make(chan int, 3)
ch <- 1
ch <- 2
close(ch)
 
// 可以继续从已关闭的 channel 接收，直到缓冲区清空
v1, ok1 := <-ch  // v1=1, ok1=true
v2, ok2 := <-ch  // v2=2, ok2=true
v3, ok3 := <-ch  // v3=0, ok3=false（缓冲区已空，返回零值）
v4, ok4 := <-ch  // v4=0, ok4=false（继续返回零值）
 
// for range 语法会在 ok=false 时自动停止
for v := range ch { // 等价于 for { v, ok := <-ch; if !ok { break } ... }
    fmt.Println(v)
}

这个语义设计的价值：关闭 Channel 是一个广播信号——多个 Goroutine 同时在同一个 Channel 上等待接收，当 Channel 关闭时，所有等待者都会被唤醒，收到零值和 ok=false。这是实现”取消通知”（如 Context 超时传播）的底层基础。

第 5 章 关闭 Channel（close(ch)）

5.1 close 的流程

close(ch) 调用 closechan，执行以下步骤：

// runtime/chan.go（概念性）
func closechan(c *hchan) {
    if c == nil {
        panic("close of nil channel")
    }
    
    lock(&c.lock)
    
    if c.closed != 0 {
        unlock(&c.lock)
        panic("close of closed channel")  // 不能重复关闭
    }
    
    c.closed = 1  // 标记为已关闭
    
    // 收集所有等待接收的 Goroutine（recvq 中的）
    // 它们会收到零值 + ok=false
    var glist gList
    for {
        sg := c.recvq.dequeue()
        if sg == nil { break }
        sg.elem = nil  // 清空数据指针（接收零值）
        glist.push(sg.g)
    }
    
    // 收集所有等待发送的 Goroutine（sendq 中的）
    // 它们会 panic（因为向关闭 channel 发送）
    for {
        sg := c.sendq.dequeue()
        if sg == nil { break }
        sg.elem = nil
        glist.push(sg.g)
    }
    
    unlock(&c.lock)
    
    // 唤醒所有收集到的 Goroutine
    for !glist.empty() {
        gp := glist.pop()
        goready(gp, 3)  // 将 G 放回 Run Queue，等待调度
    }
}

关闭两次 Channel 会 panic：这也是刻意设计——double close 是编程错误。正确的做法是由”发送方”负责关闭（因为只有发送方知道不再有数据），或者通过 sync.Once 保证只关闭一次。

5.2 Channel 的使用规范

// 规则一：由发送方关闭（不是接收方）
func producer(ch chan<- int) {
    for i := 0; i < 10; i++ {
        ch <- i
    }
    close(ch)  // 发送方负责关闭
}
 
// 规则二：单个发送方 + 多个接收方
// 关闭简单：发送方 close，接收方 for range 自动停止
 
// 规则三：多个发送方 + 单个接收方（更复杂）
// 不能随意 close（因为不知道另一个发送方是否还会发）
// 解决方案：用 sync.WaitGroup + 额外的 done channel
 
func multiSender(done <-chan struct{}, chs ...chan<- int) {
    var wg sync.WaitGroup
    for i, ch := range chs {
        wg.Add(1)
        go func(id int, out chan<- int) {
            defer wg.Done()
            for {
                select {
                case <-done:
                    return  // 收到停止信号
                case out <- id:
                }
            }
        }(i, ch)
    }
    // 不直接 close ch，而是通过 done channel 通知停止
}

生产避坑：Channel 关闭的黄金法则

  • 不要在接收方关闭 Channel：接收方不知道是否还有发送方会发数据；
  • 不要在多个并发发送方中任意关闭 Channel：会导致其他发送方 panic；
  • 多发送方场景：用一个额外的”停止信号 channel”（done chan struct{}）代替直接 close，或者使用 sync.WaitGroup 等待所有发送方完成后再关闭；
  • double close 保护：如果无法避免多处调用 close，用 sync.Once 包装。

第 6 章 select：多路复用的实现

6.1 select 是什么

select 语句允许 Goroutine 同时等待多个 Channel 操作，哪个先就绪就执行哪个：

select {
case v := <-ch1:
    fmt.Println("received from ch1:", v)
case ch2 <- 42:
    fmt.Println("sent to ch2")
case <-time.After(1 * time.Second):
    fmt.Println("timeout")
default:
    fmt.Println("no channel ready")  // 如果有 default，select 不阻塞
}

select 的语义：

  • 如果有多个 case 同时就绪：随机选择一个执行（避免饥饿）；
  • 如果没有 case 就绪且有 default：执行 default；
  • 如果没有 case 就绪且无 default：阻塞，直到某个 case 就绪。

6.2 select 的实现：selectgo 函数

select 语句在运行时调用 selectgo 函数，其实现分为三个阶段：

阶段一：对所有 case 的 channel 加锁

为避免死锁，select 需要同时锁住所有涉及的 channel。但直接按声明顺序加锁会导致死锁（如果两个 select 以相反顺序锁同一组 channel）。Go 的解法：按 channel 地址排序，所有 select 都按相同的顺序加锁，避免死锁：

// 对 select 的 case 按 channel 地址排序，然后按序加锁
sortCases(cases)
for _, c := range cases {
    lock(&c.hchan.lock)
}

阶段二：随机扫描 + 检查就绪状态

对 cases 进行随机排列的顺序扫描（不是声明顺序，是为了公平性）：

// 生成随机的 case 遍历顺序
pollOrder := randomOrder(len(cases))
 
// 按随机顺序检查每个 case 是否可以立即执行
for _, idx := range pollOrder {
    c := cases[idx]
    switch c.kind {
    case caseRecv:
        if c.hchan.qcount > 0 || c.hchan.sendq.first != nil || c.hchan.closed != 0 {
            // 接收 case 就绪：缓冲区有数据、有发送方等待、或 channel 已关闭
            goto selected
        }
    case caseSend:
        if c.hchan.qcount < c.hchan.dataqsiz || c.hchan.recvq.first != nil {
            // 发送 case 就绪：缓冲区有空位、或有接收方等待
            goto selected
        }
    }
}

如果找到就绪的 case，解锁所有 channel，执行该 case。

阶段三：没有就绪 case——挂起到所有 channel 的等待队列

如果没有 case 就绪（且无 default），当前 Goroutine 需要同时在所有 channel 上等待：

// 为每个 case 创建一个 sudog，加入对应 channel 的 recvq 或 sendq
for _, c := range cases {
    sg := acquireSudog()
    sg.g = gp
    sg.elem = c.elem
    sg.c = c.hchan
    // 根据 case 类型加入 recvq 或 sendq
    if c.kind == caseRecv {
        c.hchan.recvq.enqueue(sg)
    } else {
        c.hchan.sendq.enqueue(sg)
    }
}
 
// 挂起当前 Goroutine
gopark(selparkcommit, ...)
 
// ——唤醒后，某个 channel 已就绪——
// 从所有其他 channel 的等待队列中移除当前 Goroutine 的 sudog（清理工作）
for _, c := range cases {
    c.hchan.recvq.remove(sudogForCase(c))
    // 或 c.hchan.sendq.remove(...)
}

select 的随机化为什么重要？如果 select 总是按 case 声明顺序检查，当多个 case 同时就绪时，第一个 case 会永远被优先选择——其他 case 对应的 Goroutine 可能永远得不到处理（饥饿）。随机化确保了当多个 case 同时就绪时，每个都有均等的被选中概率。

第 7 章 Channel 的性能与使用模式

7.1 Channel 的性能特征

Channel 操作有互斥锁（hchan.lock），因此不是”无锁”的——每次发送/接收都需要加锁解锁。在高并发场景（数百万次/秒的 channel 操作）中，这个锁会成为瓶颈。

基准测试数据（参考）：

  • 无缓冲 channel（直接传递，sender 和 receiver 都在等）：约 200-400ns/操作
  • 有缓冲 channel（不阻塞）：约 50-100ns/操作
  • sync.Mutex 加解锁：约 10-30ns/操作
  • 原子操作（sync/atomic）：约 5-10ns/操作

什么时候 Channel 比 Mutex 更适合：

  • 需要传递数据所有权（数据随 channel 传递，不再被发送方使用）；
  • 需要协调 Goroutine 的执行顺序（同步点）；
  • 需要广播通知（close channel）；
  • Pipeline 模式（数据流水线）。

什么时候 Mutex 比 Channel 更适合：

  • 保护共享状态（多个 Goroutine 读写同一个变量）；
  • 高频的简单加锁操作（无需传递数据）；
  • sync.RWMutex 的读多写少场景（允许并发读）。

7.2 常见的 Channel 使用模式

模式一：done channel（完成信号）

done := make(chan struct{})
go func() {
    doWork()
    close(done)  // 工作完成，广播通知
}()
<-done  // 等待完成

模式二：超时控制

result := make(chan int, 1)
go func() {
    result <- heavyComputation()
}()
 
select {
case v := <-result:
    fmt.Println("got result:", v)
case <-time.After(5 * time.Second):
    fmt.Println("timeout!")
}

模式三：限流（Semaphore）

// 用有缓冲 channel 作为信号量，限制最大并发数
sem := make(chan struct{}, 10)  // 最多 10 个并发
 
for _, task := range tasks {
    sem <- struct{}{}  // 占用一个槽位（满时阻塞）
    go func(t Task) {
        defer func() { <-sem }()  // 释放槽位
        process(t)
    }(task)
}

模式四：nil channel 的妙用

nil channel 上的发送和接收永远阻塞（不 panic，但永远不会就绪）。这在 select 中非常有用——可以动态禁用某个 case：

var ch1, ch2 chan int
ch1 = make(chan int, 1)
ch1 <- 42
 
// ch2 是 nil，select 时 ch2 的 case 永远不会被选中（相当于禁用）
select {
case v := <-ch1:
    fmt.Println(v)  // 42
case v := <-ch2:   // 永远不会执行（ch2 是 nil）
    fmt.Println(v)
}

总结

本篇从 CSP 哲学出发，完整梳理了 Channel 的底层机制：

hchan 的核心结构：带互斥锁的环形缓冲区（buf、sendx、recvx、qcount）+ 两个等待队列（sendq、recvq）。Channel 变量是指向 hchan 的指针，赋值时不复制数据，多个变量共享同一个 hchan。

发送/接收的三条路径：有等待的对方（直接零拷贝交付，最快）→ 缓冲区有空间/有数据（写/读缓冲区）→ 阻塞（创建 sudog 挂入等待队列，gopark 让出 CPU）。

关闭 Channel 的广播语义：close 将所有等待接收的 Goroutine 唤醒（返回零值 + ok=false），将所有等待发送的 Goroutine 唤醒（panic）。这是实现”取消广播”的基础，也是为什么只能由发送方关闭、且只能关闭一次的原因。

select 的随机化实现：对所有 channel 按地址排序加锁（避免死锁），按随机顺序扫描（保证公平性），没有就绪 case 时同时挂入所有 channel 的等待队列，被唤醒后清理其他队列。

性能定位：Channel 不是无锁数据结构（有互斥锁），适合”通过通信传递数据所有权”；高频共享状态保护用 Mutex；极端性能场景用原子操作。

下一篇深入 sync.Mutex、RWMutex 与 WaitGroup 的实现原理：03 sync 包——Mutex、RWMutex 与 WaitGroup 的实现。

参考资料

  • Go 运行时源码：runtime/chan.go、runtime/select.go
  • Go Blog,《Share Memory By Communicating》: https://go.dev/blog/codelab-share
  • Tony Hoare,《Communicating Sequential Processes》, 1978
  • Kavya Joshi,《Understanding Channels》, GopherCon 2017

思考题

  1. 向一个已关闭的 channel 发送数据会 panic，但从已关闭的 channel 接收数据不会。如果有多个 goroutine 同时向一个 channel 发送数据，由’谁’来负责关闭这个 channel？Go 中有哪些惯用模式来安全地关闭一个’多生产者单消费者’的 channel？
  2. 无缓冲 channel 的 send 和 receive 是同步的——send 方会阻塞直到有 receive 方就绪。Go 运行时在这种’同步握手’场景下做了一个优化：直接将数据从 send 方的栈拷贝到 receive 方的栈，绕过了 channel 的内部缓冲区。这个优化对 GC 有什么影响？为什么有缓冲 channel 不能做同样的优化？
  3. select 语句在多个 case 同时就绪时会’随机’选择一个。这个随机性的实现机制是什么（真随机还是伪随机）？在一个 select 中有一个从 time.After() 返回的 channel 用作超时控制——如果每次循环都调用 time.After()，未触发的 Timer 是否会被 GC 回收？这会导致内存泄漏吗？

Backlinks