Go Channel 深入解析：从语义到 Runtime 底层实现

var ch chan int
// ch <- 1 // 永久阻塞
// <-ch // 永久阻塞
// close(ch) // panic

这个特性在 select 里很有用。将某个 case 对应的 channel 设为 nil，相当于临时禁用该分支，常用于状态切换或阶段性关闭逻辑。

var in <-chan int
for {
    select {
    case v := <-in:
        _ = v
    default:
        return
    }
}

4.2 无缓冲 channel

核心是发送和接收必须配对完成，本质是一种同步握手。

ch := make(chan int)
go func() { ch <- 42 }()
v := <-ch
fmt.Println(v)

发送方执行 ch <- 42 后，若接收方未 ready，则阻塞；反之亦然。适合表达'我要等对方真的接住'。

4.3 有缓冲 channel

固定容量的环形队列。

ch := make(chan int, 8)

行为规则：

• buffer 未满，发送直接写入，不阻塞
• buffer 非空，接收直接读取，不阻塞
• buffer 满了，发送阻塞，进入 sendq
• buffer 空了，接收阻塞，进入 recvq

注意：FIFO 不等于 goroutine 调度绝对公平。元素顺序按先入先出，但谁先抢到执行机会取决于调度器。

4.4 关闭 channel

不是销毁，而是广播声明：'发送方结束了，后面不会再有新值'。

关闭后的行为：

• 如果 buffer 里还有数据，接收方继续读完
• 当 buffer 被读空以后，再接收立刻返回零值，且 ok=false

ch := make(chan int, 2)
ch <- 1
ch <- 2
close(ch)
fmt.Println(<-ch) // 1
fmt.Println(<-ch) // 2
v, ok := <-ch
fmt.Println(v, ok) // 0 false

一定会 panic 的情况：

• 向已关闭 channel 发送
• 对同一个 channel 重复 close

官方推荐做法：由发送方主动 close。

5. channel 让你意想不到的亮点

channel 不只是传值工具，还是同步原语。

它能建立 happens-before 关系。某次发送或关闭之前发生的写操作，对后续被唤醒的接收方可见。

var s string
done := make(chan struct{})
go func() {
    s = "hello"
    close(done)
}()
<-done
fmt.Println(s) // 一定能看到 hello

这里关键的不是 done 里的值，而是内存模型给出的同步保证。这也是 done chan struct{} 写法常见的原因：利用的是同步语义，而非数据语义。

6. runtime 里 channel 的样子

核心结构叫 hchan。关键字段如下：

简化版结构：

type hchan struct {
    qcount   uint
    dataqsiz uint
    buf      unsafe.Pointer
    sendx    uint
    recvx    uint
    recvq    waitq
    sendq    waitq
    closed   uint32
    lock     mutex
}

还有一个关键角色：sudog。

它解决了 goroutine 和 channel 非一对一的问题。一个 goroutine 可能同时等多个 channel，一个 channel 也可能被多个 goroutine 等待。sudog 就是记录'某个 goroutine 正在某个 channel 上等待一次发送或接收'的单元。

7. send / recv / close / select 底层怎么走

7.1 ch <- x 的底层顺序

1. 如果 channel 是 nil：永久阻塞
2. 如果 channel 已关闭：panic
3. 如果有等待中的接收者：直接把值交给接收者，绕过 buffer
4. 如果 buffer 还有空位：写入环形缓冲区
5. 否则：封装成 sudog，进入 sendq，阻塞等待

切记：即使是 buffered channel，只要此时已经有接收者在等，发送也可能直接把值交给接收者，而不是先进 buffer。

7.2 v := <-ch 的底层顺序

1. 如果 channel 是 nil：永久阻塞
2. 如果 channel 已关闭且已空：立刻返回零值，ok=false
3. 如果有等待中的发送者：和发送者直接配对，必要时与 buffer 交接
4. 如果 buffer 里有数据：直接从环形缓冲区读取
5. 否则：进入 recvq，阻塞等待发送者唤醒

ok=false 的含义是：channel 已经关闭，并且已经没有剩余数据了。

7.3 close(ch) 做了什么

本质是：设置关闭标记，然后广播唤醒所有等待者。

1. 检查 nil 和重复关闭
2. 把 closed 标记设为 1
3. 唤醒所有等待中的接收者和发送者

等待中的接收者被唤醒后：若有 buffer 数据继续读，读空后返回零值和 ok=false。 等待中的发送者被唤醒后：不会补发成功，最终走向 panic。

7.4 select 为什么明显更复杂

语言层面规则简单，但 Runtime 难点在于：一个 goroutine 同时等多个 channel，但最终只能有一个 case 赢。

实现要点：

1. 随机化扫描顺序，避免偏向前面的 case
2. 按 channel 地址统一加锁顺序，避免死锁
3. 先尝试找立即可执行的 case
4. 如果都不 ready，把当前 goroutine 以多个 sudog 的形式挂到多个 channel 的等待队列
5. 某个 case 成功后，清理其它 case 的等待记录

8. 工程实践

8.1 close 通常应该由发送方做

发送方最清楚'后面还有没有数据'。如果由接收方随手关闭，容易导致另一个发送方还没停，下次发送直接 panic。

单发送者场景下，发送方自己关闭最简单。多发送者场景下，最好由协调者统一关闭（如专门的管理 goroutine 或 sync.Once）。

8.2 不要拿 len(ch) 做同步判断

这是一个非常常见的坑。len(ch) 只是某一瞬间的快照，不是同步保证。

if len(ch) > 0 {
    v := <-ch
    _ = v
}

检查完长度到真正接收之间，别的 goroutine 完全可能已经把 channel 清空了。这是典型的 TOCTOU 问题。

更稳的写法：

select {
case v := <-ch:
    _ = v
default:
    // 暂时没数据
}

8.3 下游不收了，上游必须能停，不然就会 goroutine 泄漏

如果消费者退出，生产者还在不停发数据，生产者 goroutine 很可能永久阻塞在发送上。这些 goroutine 不会自动被 GC 回收。

解决思路：使用 context 或 done channel。

func producer(ctx context.Context, ch chan<- int) {
    for {
        select {
        case <-ctx.Done():
            return
        case ch <- getValue():
        }
    }
}

或者：

done := make(chan struct{})
go func() {
    for {
        select {
        case <-done:
            return
        case ch <- getValue():
        }
    }
}()
// 需要停止时 close(done)

8.4 buffered channel 很适合做限流

拿 buffered channel 充当计数信号量。

limit := make(chan struct{}, 3) // 最多 3 个并发
for _, job := range jobs {
    job := job
    go func() {
        limit <- struct{}{} // acquire
        defer func() { <-limit }() // release
        do(job)
    }()
}

8.5 什么时候该用 channel，什么时候该用 mutex

判断标准：channel 更擅长表达协作流程和所有权转移，mutex 更擅长保护共享状态。

如果是任务分发、worker 协作、广播退出、流水线处理、有界并发控制，channel 往往很合适。

如果只是保护一个共享 map、修改一个共享 struct、进入很短的临界区，sync.Mutex 往往更直接，成本也更低。

不要为了'Go 推崇 channel'就到处硬用。

9. 自检

• channel 对外是带类型的通信管道，对内是 锁 + 环形缓冲区 + sendq/recvq + 唤醒逻辑
• nil channel 发送和接收都会永久阻塞，close(nil) 会 panic
• 无缓冲 channel 的本质是同步握手，不是队列
• 有缓冲 channel 的本质是固定容量环形队列
• close 不是销毁，而是广播'不会再有新值'
• v, ok := <-ch 里，ok=false 只会在'channel 已关闭且已空'时出现
• channel 不只是传值工具，还是同步原语，会建立 happens-before
• hchan 的关键字段要知道：qcount、dataqsiz、buf、sendx、recvx、recvq、sendq、closed、lock
• sudog 记录的是'某个 goroutine 正在某个 channel 上等待一次发送或接收'
• select 的复杂度来自'一个 goroutine 同时等多个 channel，但最终只能有一个 case 赢'
• 工程上，发送方通常负责 close，不要靠 len(ch) 做同步判断，下游不消费时上游必须可停

真正理解 channel，不是会写 make(chan T)，而是你已经知道它什么时候像队列，什么时候像同步点，什么时候像广播器，什么时候会把 goroutine 永远卡住。这一步迈过去，Go 并发编程才算真正入门。