Go Channel：有缓冲 vs 无缓冲，以及关闭后的读写行为

把 Channel 想成“goroutine 之间传东西的管道”。chan int 表示“这根管道里只能传 int”。

ch := make(chan int)
fmt.Println(cap(ch)) // 0

ch := make(chan int, 3)
fmt.Println(cap(ch)) // 3

三个必须认识的符号

为什么通常要配 goroutine？

ch := make(chan int)

ch <- 10       // 这里会一直等接收者
x := <-ch       // 永远走不到这里

无缓冲 Channel 的发送需要有人同时接收。这里只有一个 goroutine，它自己卡在发送处，后面的接收语句永远执行不到，因此运行时最终会报死锁。

ch := make(chan int)

go func() {
    ch <- 10
}()

x := <-ch
fmt.Println(x)

go func() { ... }() 表示启动一个新的 goroutine。现在“发送”和“接收”可以由两个 goroutine 配对。

为什么 Go 要同时提供两种？

因为并发程序里有两类需求：一种是“你必须接到，我才继续”，强调同步； 另一种是“我先放这里，你稍后处理”，强调生产者与消费者解耦。

1. 无缓冲：像当面递作业

可以把它理解成两个人面对面递一本书。桌子上没有临时存放的位置。 A 如果到了、B 还没到，A 就得拿着书等；B 如果先到了，也只能等 A。

2. 有缓冲：像有 3 个格子的快递柜

阻塞条件一张表记住

问题 1：向已关闭的 Channel 发送会怎样？

ch := make(chan int)
close(ch)
ch <- 1 // panic: send on closed channel

问题 2：从已关闭的 Channel 接收会怎样？

分两种情况，千万别只回答“返回零值”。

为什么要有 ok？

因为单看值无法判断“这是业务真的发送了一个 0”，还是“Channel 已关闭且读空以后返回的 int 零值 0”。

v, ok := <-ch
if !ok {
    fmt.Println("channel 已关闭且没有剩余数据")
}

for range 为什么经常和 close 一起出现？

for v := range ch {
    fmt.Println(v)
}

range ch 会不断接收数据。当 Channel 已关闭并且剩余数据全部读完时，循环自动结束。 如果发送方永远不关闭，而接收方又一直 range，接收方可能永远等下去。

在 Go runtime 中，Channel 的核心运行时对象叫 hchan。源码会随版本演进， 面试不需要逐字段背诵，但下面这些字段应该知道用途。

type hchan struct {
    qcount   uint           // 当前缓冲区已有多少个元素
    dataqsiz uint           // 缓冲区总容量；0 表示无缓冲
    buf      unsafe.Pointer // 指向环形缓冲区
    elemsize uint16         // 每个元素大小
    closed   uint32         // 是否已经关闭
    elemtype *_type         // Channel 元素类型

    sendx    uint           // 下次写入 buffer 的位置
    recvx    uint           // 下次读取 buffer 的位置

    recvq    waitq          // 等待接收的 goroutine 队列
    sendq    waitq          // 等待发送的 goroutine 队列

    lock     mutex          // 保护 hchan 中的共享状态
}

sendq / recvq 里装的是什么？

并不是“把整个 goroutine 塞进链表”。Runtime 使用一个叫 sudog 的等待节点来描述 “哪个 goroutine 正在某个同步对象上等待”，节点里会关联 goroutine、待发送/接收的数据位置等信息。

为什么 buffer 是环形队列？

固定容量队列不断出队、入队。如果每次接收都把剩余元素整体向前搬，会浪费 CPU。 环形队列只移动两个索引：sendx 和 recvx，到末尾后绕回 0。

// 假设容量 = 3
buffer: [ A ][ B ][ 空 ]
              ↑        ↑
            recvx    sendx

// 读 A/B、写 C/D 时，只移动索引，不整体搬数组

A. 发送 ch <- value 的简化流程

注意这说明了一个重要事实：Channel 的发送不是简单等价于“向数组 append”。 Runtime 首先看是否有等待中的接收者；有的话可以直接匹配。

B. 接收 value := <-ch 的简化流程

1. 如果 Channel 已关闭且 buffer 已空：立即返回零值，双返回形式中 ok=false。
2. 如果有等待中的发送者：
   • 无缓冲：直接从发送者复制数据。
   • 有缓冲且缓冲已满：先从 buffer 头部取一个，再把等待发送者的数据补到 buffer 尾部。
3. 如果 buffer 里有数据：从 recvx 读出，qcount--。
4. 否则没有数据可拿：把当前 goroutine 通过 sudog 放进 recvq，然后挂起。

C. close(ch) 的简化流程

这 4 组行为必须背熟

保存为 main.go 后运行 go run main.go。

package main

import (
    "fmt"
)

func main() {
    bufferedDemo()
    closedSendDemo()
}

func bufferedDemo() {
    fmt.Println("=== buffered channel ===")

    // 创建容量为 2 的有缓冲 Channel。
    ch := make(chan int, 2)

    // 没有接收者也能先发送两个值，因为 buffer 有两个位置。
    ch <- 10
    ch <- 20

    fmt.Println("len =", len(ch), "cap =", cap(ch))

    // close 只是告诉接收方：以后不会再有新数据。
    // 10、20 不会因此消失。
    close(ch)

    v1, ok1 := <-ch
    fmt.Println(v1, ok1) // 10 true

    v2, ok2 := <-ch
    fmt.Println(v2, ok2) // 20 true

    // Channel 已关闭，并且 buffer 已经读空。
    // int 的零值是 0，ok 为 false。
    v3, ok3 := <-ch
    fmt.Println(v3, ok3) // 0 false

    // 再读多少次都立即返回 0, false，不会阻塞。
    v4, ok4 := <-ch
    fmt.Println(v4, ok4) // 0 false
}

func closedSendDemo() {
    fmt.Println("=== send to closed channel ===")

    ch := make(chan string, 1)
    close(ch)

    // 这里只为了演示 panic 内容。
    // 正常业务代码不要依赖 recover 来“安全发送”。
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("捕获到 panic:", r)
        }
    }()

    ch <- "hello" // panic: send on closed channel
}

预期输出

=== buffered channel ===
len = 2 cap = 2
10 true
20 true
0 false
0 false
=== send to closed channel ===
捕获到 panic: send on closed channel

再看一个无缓冲 Channel 的最小例子

package main

import "fmt"

func main() {
    ch := make(chan int)

    go func() {
        fmt.Println("发送者：准备发送")
        ch <- 100
        fmt.Println("发送者：接收方已经接走数据，我才能走到这里")
    }()

    v := <-ch
    fmt.Println("接收者收到：", v)
}

1. 无缓冲：容量 0，收发双方配对，强调同步交接。
2. 有缓冲：有环形队列；未满可发，非空可收；满发阻塞，空收阻塞。
3. 关闭后发送：panic。
4. 关闭后接收：先读完历史数据，再返回零值 + ok=false。
5. 底层：hchan + buf + sendx/recvx + sendq/recvq + lock + closed。
6. 阻塞 goroutine：通过 sudog 挂到等待队列，gopark，以后再被唤醒。
7. 谁 close：能确定“不再有任何发送”的一方。