select 调度

在 Go 里，select 本身不会因为写了 default 就自动等待。只要当前没有任何通道通信可以进行，带 default 的 select 会立刻执行默认分支。把这种写法放进没有节拍的 for 循环，就会不断重复检查，表现为 CPU 占用升高。

官方资料：https://go.dev/ref/spec

判断方法很简单：如果 default 分支执行后没有阻塞、睡眠、等待事件或退出，下一轮又马上回到 select，这就是忙轮询。允许等待时删除 default；必须轮询时给检查动作增加受控节拍，并保证能被取消。

为什么 default 会让 select 循环变成忙轮询

Go 规范规定：如果有多个通信操作可以继续，select 选择其中一个；如果没有通信可以继续但存在 default，就选择 default；只有没有 default 时，select 才会等待至少一个通信可进行。

因此，下面的代码在工作通道暂时没有数据时不会停下来：

package main

import "context"

func consume(ctx context.Context, work 

这里的关键不在于 default 分支里有没有代码，而在于它让当前这一轮立刻结束。即使分支为空，循环也会再次进入 select；如果调度器没有机会让循环停下来，程序就会持续消耗 CPU 检查相同的通道状态。

允许等待时，直接删除 default

如果消费方的职责就是“有任务就处理，没有任务就等待”，最简单的改法是删除 default。此时 work 和 ctx.Done() 都没有就绪事件时，select 会阻塞，直到任务到达或收到退出信号。

func consume(ctx context.Context, work 

这个版本把“等待”交给 select，而不是用固定时长的 time.Sleep 猜测下一次任务何时到达。任务到达就能被接收，任务长期不到达也不会反复执行空分支。

必须定期检查时，用 ticker 代替无节拍轮询

有些循环确实需要周期性检查，例如刷新一次状态或扫描一次内存中的条件。这时不能简单删除所有分支，但应该把检查动作放在可控的 ticker 上，并在退出时停止 ticker：

import "time"

func monitor(ctx context.Context, work 

ticker 不是为了让 select “变慢”，而是把检查频率变成明确的工程参数。周期越短，响应越快但检查次数越多；周期越长，资源开销更低但响应会变慢。

三个容易误判的边界

nil channel 不会触发通信。对 nil channel 的发送和接收永远不能进行。如果 select 没有 default，它会继续等待其他可用 case；如果同时存在 default，就会直接走 default，所以动态启用通道时要确认赋值时机。

关闭的接收通道会持续可读。关闭后的通道接收会立即返回零值；在循环里应使用 value, ok := ，当 ok 为 false 时退出或禁用该 case，否则即使没有新数据也可能反复命中。

退出信号必须进入 select。仅仅在 default 中写一段“稍后再试”并不能保证 goroutine 能结束。把 ctx.Done() 或明确的 stop channel 放进 select，才能让等待状态也有退出路径。

速查：该不该保留 default

最后可以用一句话判断：default 适合“一次性试探”，不适合“没有等待条件的无限循环”。如果它位于长期运行的循环中，就要继续寻找事件、节拍或退出信号。

相关问题

select 没有 default 会不会一直卡住？会，直到某个通信可进行或 goroutine 被其他方式结束；这正是等待型消费者通常需要的行为。

能不能在 default 里加 time.Sleep？可以暂时降低空转频率，但它仍是粗粒度轮询；如果有明确的事件通道，优先删除 default，让 select 等待事件。