Go：channel 与 select —— 用通信来共享内存

无缓冲 channel：一次会合，不是一个队列

ch := make(chan int)      // 无缓冲!

go func() {
    ch <- 42              // 【阻塞在这里】,直到有人来接
    fmt.Println("发出去了")  // 这一行,发生在接收方拿到之后
}()

time.Sleep(time.Second)   // 让发送方在那儿等一秒

v := <-ch                 // 接收 —— 这一刻,双方【同时】被唤醒
fmt.Println("收到", v)

所以：ch := make(chan struct{}) 是一个常见的惯用法 —— 它不传任何数据（struct{} 占 0 字节），它只传「时间」：

done := make(chan struct{})

go func() {
    doWork()
    close(done)          // 「我干完了」
}()

<-done                   // 等它干完(收到零值,但我不关心值,我关心的是时机)

缓冲 channel：一个减震器，不是一个蓄水池

ch := make(chan int, 3)   // 缓冲 3 个

ch <- 1    // 不阻塞(buf: 1)
ch <- 2    // 不阻塞(buf: 2)
ch <- 3    // 不阻塞(buf: 3)
ch <- 4    // 【阻塞!】缓冲满了 —— 等有人取走一个

下面这个弹珠台把它跑起来。先把「缓冲区容量」拖到 0，看会合的样子；再拖到 3，把「消费者耗时」拖到 60ms —— 看缓冲区怎么被填满，然后生产者怎么被顶住。

close、nil、以及那些必须背下来的语义

channel 的行为是一张真值表，而且里面有几格会 panic。这张表值得贴在工位上：

// ❌ 多个发送方,谁来 close?
// 谁 close 都可能让别人 panic("send on closed channel")

// ✅ 方案:用一个独立的 done channel 通知发送方停止
func producer(ch chan<- int, done <-chan struct{}) {
    for {
        select {
        case ch <- produce():
        case <-done:            // 有人喊停
            return              // 【不 close ch】,只是自己退出
        }
    }
}
// 然后由一个 WaitGroup 等所有发送方退出后,再由【协调者】close(ch)

for range 和「逗号 ok」

// 检测 channel 是否关闭
v, ok := <-ch
if !ok {
    // channel 已关闭且已排空
}

// for range:自动在 close 后退出循环
for v := range ch {      // ← 【必须有人 close(ch)】,否则这个循环永远不结束
    process(v)           //    (然后这个 goroutine 就泄漏了 —— 下一章)
}

select：channel 的多路复用

select {
case v := <-ch1:
    fmt.Println("从 ch1 收到", v)

case ch2 <- x:
    fmt.Println("发到 ch2 了")

case <-time.After(time.Second):     // 超时!
    fmt.Println("等了一秒,不等了")

case <-ctx.Done():                  // 取消!(下一章)
    return ctx.Err()

default:                            // 【有 default = 非阻塞】
    fmt.Println("什么都没准备好,我不等")
}

技巧：用 nil channel 动态禁用一个 case

// 目标:从 in 读,写到 out。但 in 关闭后,要把剩下的写完再退出。
var out chan int          // 先是 nil —— select 会【忽略】这个 case
var pending int

for {
    select {
    case v, ok := <-in:
        if !ok {
            in = nil      // ← 输入没了,【把这个 case 关掉】
            continue      //    (否则关闭的 channel 会一直返回零值,死循环!)
        }
        pending = v
        out = realOut     // ← 有货了,【启用】发送 case

    case out <- pending:
        out = nil         // ← 发完了,【再关掉】发送 case,等下一个输入

    case <-ctx.Done():
        return
    }
    if in == nil && out == nil { return }   // 两头都关了 → 收工
}

这是 Go 里一个非常地道的模式（Rob Pike 在他的「Go 并发模式」演讲里推广的）：把 channel 变量设成 nil，就等于把那个 select 分支临时删掉了。

// ❌ CPU 100% 的死循环
for {
    select {
    case v := <-ch:        // ch 关闭后,这个 case 【永远立刻就绪】,返回零值!
        process(v)         // 于是 select 疯狂空转,烧光一个核
    case <-done:
        return
    }
}

// ✅ 必须检查 ok,并且把 channel 设成 nil
for {
    select {
    case v, ok := <-ch:
        if !ok { ch = nil; continue }   // ← 关掉这个 case
        process(v)
    case <-done:
        return
    }
}

那句 fatal error: all goroutines are asleep

func main() {
    ch := make(chan int)
    ch <- 1          // 阻塞:没有接收方
    fmt.Println(<-ch)
}

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.main()
	/tmp/main.go:5 +0x37

Go runtime 有一个全局死锁检测器：如果所有 goroutine 都在睡（没有一个是 runnable 的），它知道没有任何东西能再唤醒它们了，于是直接崩掉。

什么时候用 channel，什么时候用锁

这是 Go 社区争论最多的问题。Go 官方 wiki 给了一个很务实的答案：

下一章：Go 的代价。go f() 让控制流跳出去，再也不回来 —— 于是「取消」和「生命周期」这两件事，Go 完全甩给了你。而这就是 goroutine 泄漏成为 Go 头号生产事故的原因。