[!info] 关联笔记

• 所属 MOC：并发 MOC · 学习路线
• 前置概念：channel、goroutine
• 后续概念：context、取消传播、happens-before
• 容易混淆：switch、忙轮询、time.Sleep 当超时

Go select

这个概念为什么会出现

一个 goroutine 往往同时关心多条“通信事件”，而不是只等一个 channel：

• 结果 channel 有没有值？
• 取消信号到了没有？
• 超时是否触发？
• 另一条旁路命令是否到达？

若用嵌套接收或忙轮询，代码会迅速变成不可读的阻塞迷宫。select 把多路 channel 操作收成一次选择：哪些 case 能立刻进行通信，就从中挑一个执行。

它是 Go 并发控制流的“交叉路口”，不是普通 switch。

[!abstract] 一句话理解 select 等待一组 channel 发送/接收操作中至少一个就绪；若多个同时就绪则伪随机选一个；带 default 则非阻塞；把 case 的 channel 设为 nil 可动态禁用该分支。

最小可运行示例

先把示例放进业务场景，再看代码：

场景：支付回调处理——结果、请求取消、兜底超时三选一

支付服务调银行渠道后，handler 同时盯三件事：

1. 渠道结果先到 → 正常落单
2. 客户端断开 / 请求 ctx 取消先到 → 别再写库，尽快收尾
3. 兜底超时（比 ctx 更宽的本地保护）→ 防止极端情况下永久阻塞

select 就是这个交叉路口：哪个 channel 通信先就绪就走哪条分支。
它不是 switch 布尔条件，而是多路通信选择。

package main

import (
	"context"
	"fmt"
	"time"
)

func main() {
	// 模拟 HTTP 请求级 ctx：最多等 80ms（客户端超时/网关预算）。
	ctx, cancel := context.WithTimeout(context.Background(), 80*time.Millisecond)
	defer cancel()

	// 渠道结果通道：缓冲 1，避免发送方在无人接收时额外复杂化（演示用）。
	result := make(chan string, 1)

	// 后台：模拟银行渠道 30ms 后返回成功。
	go func() {
		time.Sleep(30 * time.Millisecond)
		result <- "payment-ok"
	}()

	// 一次 select：只挑一个就绪的 case 执行。
	// 持续监听事件应写成 for { select { ... } }。
	select {
	case v := <-result:
		// 渠道先回：正常业务路径。
		fmt.Println("got", v)
	case <-ctx.Done():
		// 请求预算先耗尽或上游取消。
		fmt.Println("cancelled:", ctx.Err())
	case <-time.After(200 * time.Millisecond):
		// 兜底：比 ctx 更晚的本地超时（本参数下通常轮不到）。
		// 注意：每次进入 select 都会新建 timer；热循环里应复用 Timer。
		fmt.Println("timeout via After")
	}
}

建议运行：

go run .

期望输出（渠道 30ms < ctx 80ms）：

got payment-ok

若把渠道 Sleep 改成 120 * time.Millisecond，通常会变成：

cancelled: context deadline exceeded

结合场景再看三个关注点

1. case 必须是 channel 发送/接收
   不是 case err != nil 这种布尔分支。

2. 多 case 同时就绪时伪随机选一个
   不要把书写顺序当优先级；真要优先级应嵌套 select 或分阶段。

3. 一次 select 只提交一次
   worker 常驻监听要包 for；本例是“等一次支付结果”的单次选择。

核心概念与准确模型

语法形态

select {
case <-ch1:
    // 接收
case v, ok := <-ch2:
    // 接收并判断是否关闭
case ch3 <- x:
    // 发送
default:
    // 可选：没有任何 case 可进行时立即执行
}

规范：Select statements

求值与选择规则

进入 select 时：

1. 按源码顺序求值各 case 的 channel 操作数与发送值（若有）。
2. 若有一个或多个通信可进行：从就绪集合中均匀伪随机选一个执行。
3. 若没有可进行的通信：
   • 有 default → 执行 default（非阻塞）
   • 无 default → 阻塞，直到某个 case 可进行
4. 选中 case 后，执行其通信，再跑 case 体。

“伪随机”意味着：不要依赖 case 书写顺序当优先级。需要优先级时，应显式嵌套 select 或拆分阶段。

default：非阻塞探测

select {
case v := <-ch:
    use(v)
default:
    // ch 此刻不可接收，立即继续
}

用途：

• 尝试发送/接收但不想卡住
• 实现“有就取，没有就跳过”的 drain
• 非阻塞状态机步进

滥用 default 会变成忙轮询，应配合 time.Ticker 或阻塞 select。

nil channel：动态禁用 case

对 nil channel：

• 发送永久阻塞
• 接收永久阻塞

因此：

var ch <-chan int = maybe
if disable {
    ch = nil
}
select {
case v := <-ch: // disable 时此 case 永不选中
    ...
case <-ctx.Done():
    return ctx.Err()
}

这是 fan-in、阶段性关闭某路输入的惯用技巧，但必须保留至少一条可退出路径，否则可能死锁。

超时模式

一次性等待：

select {
case v := <-ch:
    return v, nil
case <-time.After(time.Second):
    return zero, errTimeout
}

循环中慎用 time.After： 每次循环可能创建新计时器；长时间运行的 for { select { ... time.After } } 会堆积计时器。应使用：

t := time.NewTimer(d)
defer t.Stop()
select {
case <-ch:
case <-t.C:
}
// 若已收到 ch，最好 Stop 并在需要时 drain t.C，避免泄漏到后续逻辑

与 context 组合

select {
case res := <-resultCh:
    return res, nil
case <-ctx.Done():
    return zero, ctx.Err()
}

这是服务端 handler、worker、RPC 客户端的标准骨架：业务结果与取消/截止时间竞赛。详见 context。

空 select

select {} // 永久阻塞当前 goroutine

有时用于“只跑后台任务的 main”，但生产代码更常见的是显式 Wait / 信号量退出。

与 switch 的本质区别

	switch	select
分支条件	表达式/类型	channel 发送或接收
多分支同时真	顺序匹配（或 fallthrough）	就绪集合中伪随机
默认	default 无匹配时	default 无通信可进行时
阻塞	不阻塞	无 default 时可阻塞

设计动机

1. 把并发控制流写扁平
   超时、取消、结果在同一层表达。
2. 与 channel 所有权模型配套
   通信即同步点；多路等待仍保持 happens-before 语义。
3. 避免“先等谁”的隐式优先级 bug
   伪随机迫使你在需要优先级时显式设计。

边界情况与反直觉行为

1. 只执行一个 case
   即使多个就绪，一轮 select 只走一个分支。
2. case 求值副作用
   发送表达式会在进入 select 时求值，即便该 case 最终未被选中。
3. 已关闭 channel 的接收永远就绪
   会读到剩余缓冲或零值；ok=false 后若仍 case <-ch 会反复就绪，可能饿死其他 case——关闭后应 ch = nil 或退出循环。
4. 向已关闭 channel 发送
   在 select 中若该发送 case 被选中 → panic。
5. 无 default 且所有 case 的 channel 都是 nil
   永久阻塞。
6. 公平性
   规范保证的是就绪时的伪随机选择，不是跨时间片的严格公平调度保证。

常见误区

[!warning] 常见误区：把 select 当 if-else 优先级队列 错误：以为写在前面的 case 优先。
正确：多就绪时伪随机；要优先级就显式两层 select 或先检查高优先级 channel。

[!warning] 常见误区：循环里每次 time.After 错误：for { select { case <-time.After(d): ... } } 造成计时器堆积。
正确：time.NewTimer / Reset，并正确 Stop 与 drain。

[!warning] 常见误区：关闭后仍 range-select 同一 channel 错误：已关闭 channel 接收总是就绪，变成热循环。
正确：检测到 !ok 后退出或 ch = nil。

[!warning] 常见误区：用 default 当“超时” 错误：default 只表示“此刻不能通信”，不是“等一会儿”。
正确：超时用 timer / ctx 的 Done。

工程实践

1. 结果 vs 取消 永远放在同一 select，避免先阻塞在结果上听不到取消。
2. fan-in 用 for + select，输入结束则置 nil。
3. 有界工作 发送端 select { case ch <- v: case <-ctx.Done(): } 防止下游挂掉时上游泄漏。
4. 不要用 sleep 模拟就绪；用 channel/timer/ctx。
5. 测试 用短 timeout + 可控 fake clock 思路（或注入 channel），避免 flaky sleep。
6. 可读性 case 体保持短；复杂逻辑抽函数。

可验证实验

1. 两个缓冲 channel 都有值，循环 select 多次，观察分支分布是否大致均匀。
2. 无 default 时对空无缓冲 channel select → 阻塞/死锁。
3. 有 default 时立即打印 “idle”。
4. ch = nil 后对应 case 不再被选中。
5. close(ch) 后 select 是否总是立刻命中接收 case。
6. 对比循环中 time.After 与 NewTimer 的行为差异（可用 runtime.NumGoroutine 粗观察，结论以文档为准）。

本节总结

• 本质：多路 channel 通信上的一次选择。
• 关键规则：就绪伪随机、default 非阻塞、nil 禁用、关闭接收恒就绪。
• 工程主线：结果 + ctx.Done + 超时。
• 最易错：当优先级 switch、After 泄漏、关闭后热循环。
• 下一步：context 与 sync 的取舍。

自测题

概念题

1. 多个 case 同时就绪时，select 如何选择？
2. default 与 time.After 的语义差别是什么？
3. 为什么把 channel 设为 nil 可以禁用 case？

代码推理题

ch := make(chan int)
close(ch)
for i := 0; i < 3; i++ {
    select {
    case v, ok := <-ch:
        fmt.Println(v, ok)
    default:
        fmt.Println("default")
    }
}

会打印什么？为什么 default 可能根本走不到？

工程思考题

worker 从 jobs 取任务，同时必须响应 ctx 取消；jobs 关闭表示不再有新任务。如何写 for/select 才不会在关闭后空转？

参考答案

展开

1. 从就绪 case 中伪随机选一个。
2. default：此刻不能通信就立刻走；time.After：等待一段时间后 timer channel 就绪。
3. nil channel 上的发送/接收永不就绪，故该 case 不会被选中。
   代码：已关闭 channel 的接收始终就绪，通常连续打印 0 false（三遍），不进入 default。
   工程：case v, ok := <-jobs: if !ok { jobs = nil; 若还需退出可 return/break } ... case <-ctx.Done(): return ctx.Err()；两路都结束后要有明确退出条件。

延伸阅读与资料来源

资料	类型	支撑
Spec — Select statements	规范	求值与选择语义
Spec — Channel types	规范	nil/关闭与通信
Effective Go — Select	文档	用法
Package time	标准库	Timer / After
Package context	标准库	Done / 取消

---

笔记元信息

• 建议文件名：go-select.md
• 所属阶段：阶段四
• 本篇状态：已深化
• 建议下一篇：Go context