Golang Channel
底层原理

// 手写版：共享切片 + mutex（mutex = 互斥锁，一次只让一个 goroutine 进）
var mu sync.Mutex
var queue []string

// 生产者 A
mu.Lock(); queue = append(queue, url); mu.Unlock()

// 消费者 B：队列空了怎么办？只能自己轮询
for {
    mu.Lock()
    if len(queue) > 0 {
        u := queue[0]; queue = queue[1:]
        mu.Unlock(); fetch(u); continue
    }
    mu.Unlock()
    time.Sleep(time.Millisecond) // ← 罪魁祸首
}

• ① 忙等只能二选一：sleep 1ms → 每条链接平均多等 0.5ms；去掉 sleep → 一个 CPU 核被空转吃满。两条路都不对——「等」这件事本该交给调度器，不该写在业务代码里。
• ② 没有"结束"信号：A 产完了，B 不知道该退出，只能再加一个 done bool，再加一处加锁去读它。
• ③ 忘加锁不会报错：漏一个 mu.Lock() 编译照过，线上偶发脏数据，只有 go run -race 才抓得到。
• ④ 背压得自己发明：队列多长算满？满了让谁停？停多久？全部手写。

// channel 版：同一件事，三行
ch := make(chan string, 100)   // 100 = 背压阀门
go func() { for _, u := range urls { ch <- u }; close(ch) }()
for u := range ch { fetch(u) }    // close 后自动退出

所以本 deck 干的事是：把这台机器拆开——先看它的零件（hchan / 环形缓冲 / 等待队列），再看它的动作（发送、接收、关闭、select）。拆完之后，前面那些"诡异行为"都能从源码分支一条条推出来，而不用背结论。

• CSP 模型（Communicating Sequential Processes，Hoare 1978）：Go 的口号是 "Don't communicate by sharing memory; share memory by communicating"——不靠共享内存通信，而靠通信来共享内存。
• channel 是 goroutine 之间的类型安全管道：既传数据，也是同步/信号原语。数据以值拷贝交接，天然形成「所有权转移」语义。
• 四种形态：无缓冲（同步汇合 rendezvous）、有缓冲（异步解耦）、单向 <-chan / chan<-（编译期约束方向）、nil channel（收发永久阻塞）。
• 本质：一把 mutex 保护的环形缓冲区 + 收/发两个等待队列 + 与 GMP 调度器的挂起/唤醒联动。它不是无锁结构——锁被封装进了 runtime。

• qcount/dataqsiz 正是 len/cap 的取值来源；dataqsiz 创建后只读，可用于无锁判断。
• buf 是 unsafe.Pointer——与 hchan 可能同块内存（见 makechan 页），由 elemtype 决定拷贝大小与 GC 行为。
• recvq/sendq 是互斥的存在证据：接收者入队 ⇔ 缓冲为空；发送者入队 ⇔ 缓冲已满（或无缓冲）。由此推出直接拷贝路径的成立条件。
• lock 是运行时自旋/信号量混合锁（futex）；持锁期间禁止 goready，防止与栈收缩（shrinkstack）死锁。
• waitq 是 FIFO：enqueue 入队尾、dequeue 出队头，先阻塞先服务；sudog 同时被信号量（sync.Mutex 底层）复用，是 runtime 通用等待结点。
• 版本注：Go 1.23 起 hchan 新增 timer *timer 字段（time.Timer 的内部通道改为无缓冲实现）；其余结构不变。

• sudog 是“等待票据”：一个 G 阻塞在某个 channel 上时，创建一个 sudog 记录（谁、在哪个通道、数据放哪），串进 recvq/sendq。
• 对象池化：acquireSudog/releaseSudog 从 sched.sudogcache 取还，避免热路径分配。
• 交接协议：唤醒方设置 gp.param = sg、sg.success；被唤醒的 G 检查 mysg != gp.waiting 判断队列一致性，用 success 区分「拿到数据」还是「因 close 醒来」。
• 调度联动：gopark 把 G 置为 _Gwaiting 并解绑 M → M 立刻去跑别的 G；goready 置为 _Grunnable 放入 P 的本地运行队列。这就是「channel 阻塞 ≠ 线程阻塞」——OS 线程从不空等。
• 全局死锁检测：所有 G 都 _Gwaiting 且无定时任务时，fatal error: all goroutines are asleep - deadlock!（proc.go）。

1. 1校验：close(nil) → panic；closed != 0 → panic("close of closed channel")（二次关闭）。通过后置 closed = 1。
2. 2清算接收者：逐个出队 recvq，把对方 ep 清零（typedmemclr）、success=false → 醒来收到零值 + ok=false。
3. 3清算发送者：逐个出队 sendq，elem=nil、success=false → 醒来即 panic("send on closed channel")。
4. 4统一唤醒：先 unlock，再用 glist 逐个 goready —— 源码特意注释持锁期间不得 ready G（防与栈收缩死锁）。

• 两个顺序，两个目的：pollorder —— 对所有 case 做 Fisher-Yates 式随机洗牌，多 case 就绪时等概率选择，保证公平防饥饿；lockorder —— 按通道地址排序（堆排序）后依次加锁，全局一致的加锁顺序杜绝多通道场景下的 AB-BA 死锁。
• 执行流程：按 lockorder 全部加锁 → 按 pollorder 逐个尝试，命中就绪 case 立即执行并解锁 → 都不就绪且无 default：为每个通道 enqueue 一个 isSelect=true 的 sudog → gopark。
• 唯一赢家：任一对端到来时，sudog 以 CAS selectDone 竞争胜出，赢者完成通信，其余 sudog 作废出队 —— 保证多路等待只有恰好一个 case 执行。
• select + default ≡ 以 block=false 走 chansend/chanrecv 快速路径，不满足立即返回；select{}（空块）= 永久阻塞。
• 细节：同一个通道出现在多个 case 合法（会被去重合并）；case 多时「锁全部通道」开销可观，热点路径避免巨型 select。

// select.go · 两个顺序的生成
for i := range pollorder {
    // cheaprandn: 随机洗牌
    j := cheaprandn(uint32(n+i)+uint32(n))
    pollorder[norder] = pollorder[j]
    pollorder[j] = uint16(i)
}
for i := range lockorder {
    // 按通道地址堆排序
    c := scases[pollorder[i]].c
    … c.sortkey() …  // = 通道地址
}
sellock(scases, lockorder) // 全加锁

① 收发五级判定 —— 顺序即优先级，白板默写就写这张

② panic 清单 —— 只有三种，其余都不 panic

③ close 清算四步 · select 两个顺序

• close：校验（nil/二次关 → panic）→ 置 closed=1 → 清算 recvq（给零值，ok=false）→ 清算 sendq（醒来 panic）→ 先 unlock 再统一 goready
• select：pollorder 随机洗牌保公平（多 case 就绪等概率）+ lockorder 按通道地址排序防死锁；带 default = 以 block=false 走同一套函数

④ 五条不变式 —— 所有行为都能由它们推出

• 有接收者在等 ⇒ 缓冲必为空；有发送者在等 ⇒ 缓冲必已满（或无缓冲）。这条是"直接拷贝"成立的前提
• 阻塞发送者的数据不在缓冲区，而在它自己的栈上（地址记在 sudog.elem），由未来的接收者来取
• 读走后必须清槽（typedmemclr）：buf 里不留悬垂指针，GC 才不会误留对象存活
• 持锁期间不得 goready：源码明确注释，防与栈收缩（shrinkstack）死锁 —— 所以 close 先 unlock 再唤醒
• channel 有锁：hchan 里就是 mutex。"channel 无锁所以快"是误区；选它是为正确性与可组合性，不是吞吐

⑤ happens-before 四条 —— 一句话版

⑥ 工程三条底线