Go select 为什么 default 分支导致忙等

我第一次排查 Go worker 的 CPU 占用时，看到的代码并不复杂：一个无条件的 for，里面放着带 default 的 select。消息没有到来时，worker 没有睡眠，也没有退出，而是不断回到下一轮检查。问题不在 select 失控，而在 default 明确选择了“现在不等”。

当所有 channel 操作都没有就绪时，带 default 的 select 会立即执行 default。如果它位于无条件循环中，循环就会变成忙等；删除 default、引入定时器，或加入有边界的退避，才是对应的修复方向。

Go 语言规范规定：有通信可以进行时选择其中一个；没有通信就绪但存在 default 时选择它；没有 default 才会阻塞等待。因此，排查这类问题的关键不是把 default 当成错误，而是确认“非阻塞检查”是否真的符合这个循环的任务模型。

先把 default 看成“立即返回”

下面两个片段只差一个 default，等待语义却完全不同。第一个把检查交给运行时：没有消息时，当前 goroutine 可以阻塞。第二个要求 select 立刻给出结果，因此没有消息时也会立刻继续执行。

// 没有消息时阻塞，适合等待型 worker。
select {
case msg := 

第二种写法本身没有问题，例如尝试把结果送入一个不应阻塞的通知 channel。但如果把它放到没有退出条件的 for 中，就等于把“立即返回”放大成“立即返回很多次”。

default 为什么会把循环变成忙等

典型问题通常长这样：

func poll(jobs 

当 jobs 暂时没有值时，循环体没有任何阻塞调用，下一轮仍会立刻进入 select。这会带来三个常见现象：

• CPU 使用率在没有任务时仍然偏高；
• 调度器反复唤醒同一个 goroutine，真正的业务工作反而很少；
• 如果循环里还创建临时对象、记录日志或读取时间，额外开销会继续放大。

这里要区分“非阻塞”和“忙等”：前者描述一次 select 的语义，后者描述它在高频循环中的组合结果。只看单个 select 很容易误判，必须把它和外层循环、退出信号以及空闲时动作一起看。

等待型 worker 应该去掉 default

如果任务的自然节奏是“有消息就处理，没有消息就等”，最小修复通常是删掉 default，并同时保留取消路径。这样 worker 不会在空闲时主动轮询，也能在服务关闭时及时返回。

func consume(ctx context.Context, jobs 

这类改法适合队列消费者、事件处理器和后台 worker。检查点是：是否存在明确的退出信号，channel 关闭后是否返回，以及 process 是否可能长时间阻塞。如果处理本身需要超时，还应把同一个 ctx 继续传给下游操作。

需要周期检查时，用 ticker 表达时间边界

有些任务不是纯消息驱动，例如每 100 毫秒刷新一次状态、检查一次本地缓存或补偿一次超时任务。这时不要用 default 猜一个“尽快再试”，而应把周期写成显式的 ticker.C。

func refreshLoop(ctx context.Context, jobs 

ticker 让“多久检查一次”成为代码中的业务约束，也避免每一轮创建新的 time.After。周期应根据任务延迟和成本选择，不要把很小的间隔当作默认答案。

必须低延迟轮询时，加上退避

少数场景确实要求尝试后立刻继续，例如读取一个可选的内存通知并在短时间内尽快响应。此时可以保留 default，但空闲分支必须主动让出执行机会，或者按失败次数增加等待时间。下面是固定短暂休眠的最小版本：

func opportunisticPoll(ctx context.Context, jobs 

固定休眠只是一个清晰的止损方案，并不等于低延迟和低 CPU 可以同时无限提高。更复杂的轮询可根据连续空闲次数增长 duration，收到任务后再恢复较小的间隔；如果业务允许，优先把通知改成 channel、条件变量或带超时的阻塞等待。

按任务选择等待方式

我现在会先问一个问题：这个循环在没有消息时，业务上应该做什么？答案决定是否保留 default。

复查时可以沿着这几项看代码：空闲路径有没有阻塞点或时间边界，循环有没有取消出口，channel 关闭是否能结束，空闲分支是否会分配对象或写日志，以及延迟目标是否真的需要轮询。不要只因为 CPU 降了就认为修复完成；如果消息延迟、关闭时间或任务吞吐变差，说明等待策略还需要重新取舍。

几个容易混淆的边界

default 不会让 select 等待超时

default 只表示“当前没有通信可进行时立刻走这里”，它不是超时机制。需要超时语义时，使用 time.NewTimer 或 time.After，并明确超时后的处理。

有 default 不代表一定忙等

如果 select 只执行一次，或者外层循环每次都会在 default 分支做有界等待，它仍可能是合理的非阻塞设计。真正危险的是“无条件循环 + 无等待空分支”的组合。

sleep 不是所有 worker 的最佳修复

sleep 能降低空转速度，却也会引入固定的响应延迟。对消息驱动的任务，阻塞 channel 往往更准确；对固定频率的任务，ticker 更能表达意图。

结论

Go select 的 default 分支会在没有就绪通信时立即被选中。它适合一次性的非阻塞尝试，不适合无条件循环里的无限快速探测。等待型 worker 去掉 default，周期任务用 ticker，确实需要轮询时再给空闲路径加退避，并把取消、关闭和资源释放一起设计进去，才能真正解决忙等。

相关问题

• 为什么 select 没有 default 时 goroutine 会一直停住？
• ticker 和 time.After 放在循环里有什么区别？
• channel 关闭后 select 应该怎样退出？
• 如何判断 worker 是阻塞等待还是在忙等？