Go select 里的 default 为什么会让 CPU 飙高：忙等循环怎么改

线上服务 CPU 突然抬高，但请求量、队列长度和数据库压力都没明显变化，这时别急着先看算法复杂度。Go 代码里有一类很隐蔽的空转点：for 循环里套 select，再放一个 default。当所有 channel 都没有就绪时，default 会立刻被选中，外层循环马上进入下一轮，CPU 就可能被一段“什么都没做”的代码耗掉。

一个小信号：CPU 高但业务量没上来

这个问题的现场通常很别扭：接口没有明显变慢，队列里也没堆很多任务，但某个 Go 进程的 CPU 一直挂在高位。翻日志时可能只看到一堆重复的“no job”“idle”“wait next”之类文本；如果日志被关掉，表面上甚至像什么都没发生。

真正的问题在循环节奏。下面这段代码没有语法错误，也能正常运行，但当 jobs 暂时没有消息时，它不会睡一会儿，而是马上进入下一轮：

for {
    select {
    case job := 

default 本来解决的是非阻塞尝试

select 里的 default 并不是坏东西。它的作用是：当其他 case 都不能立即进行时，提供一个马上返回的分支。比如你只是想试探一下 channel 里有没有值，有就拿，没有就继续做别的事，这时候 default 很合适。

select {
case job := 

问题出在“试一下”被放进了没有节奏控制的循环里。单次非阻塞尝试很轻；每秒跑几十万次的非阻塞尝试，就变成了忙等。CPU 不是被业务计算消耗掉的，而是被循环本身磨掉的。

哪些代码最容易踩成忙等

这类代码常出现在后台任务、连接保活、消息消费、监控采集和自写调度器里。开发时觉得“没有任务就跳过”，上线后才发现“跳过”也需要成本。

这里别只看“有没有业务代码”。空分支也会消耗调度和 CPU；空分支里如果再加日志、指标上报或状态查询，影响会更明显。

风险不只 CPU：日志和退出也会被放大

忙等循环最直观的问题是 CPU 高，但它经常顺带带出两个尾巴。

第一个是日志放大。很多人会在 default 分支里写一句“没有任务”，上线后日志系统先被打满，真正有用的错误日志反而被淹没。

第二个是退出不干净。一个后台 goroutine 如果只顾着空轮询，没有把 ctx.Done() 或 stop channel 放进同一个 select，服务关闭时可能拖住资源释放。排查时看到的现象不一定是 CPU，而是发布变慢、进程迟迟不退、测试偶发超时。

改法：让循环有一个明确等待点

改这类问题，不是简单把 default 删掉就完事，而是先问：这段循环到底要等什么？如果它要等任务，就阻塞等任务；如果它要定时检查，就用 ticker；如果它要响应退出，就把退出信号放进 select。

只消费任务时，可以让接收自然阻塞：

for job := range jobs {
    handle(job)
}

需要兼顾退出时，把 ctx.Done() 放进去：

for {
    select {
    case job := 

需要定时检查时，用 time.Ticker 明确频率，不要靠 default 空跑：

ticker := time.NewTicker(500 * time.Millisecond)
defer ticker.Stop()

for {
    select {
    case job := 

如果只是为了“稍后再查”，不要在循环里反复创建 time.After。这类写法容易让计时器分配变多，读起来也不如 ticker 表达清楚。

上线后看哪几个指标

改完以后，建议至少看这几类信号：

• 进程 CPU 是否回落，尤其是低流量时段。
• 日志量是否下降，是否还存在高频重复文本。
• goroutine 数是否稳定，发布或关闭时是否能及时退出。
• pprof 采样里，热点是否还停留在同一个循环函数附近。
• 任务处理延迟有没有被 ticker 间隔影响，必要时调小间隔或改成阻塞消息驱动。

这个结果先别下结论太快。CPU 回落只是第一步，如果任务响应变慢了，说明等待策略可能过于保守；如果 CPU 没变，可能还有其他空轮询、锁竞争或 JSON 编解码热点。

相关问题

select 里一定不能写 default 吗？

不是。单次非阻塞尝试、快速探测、避免调用方被卡住时，default 很有用。危险点是它被放进没有等待点的无限循环。

在 default 里加 time.Sleep 可以吗？

可以临时止血，但通常不如 ticker 清楚。Sleep 容易散落在逻辑里，后面很难看出循环的真实检查频率。

ticker 间隔应该设多大？

看业务能接受的延迟。后台清理任务可以几秒，状态探测可能几百毫秒，任务消费最好不要靠固定轮询，而是让 channel 消息驱动。

为什么本地测试没发现 CPU 高？

本地机器任务少、运行时间短，很容易忽略空转。上线后进程长时间运行，日志、指标和调度成本才会慢慢露出来。

总结

select 里的 default 不是禁用项，它的问题在于让循环失去等待点。看到 for { select { ... default: ... } } 时，先问这段代码到底是在等消息、定时检查，还是等退出。把这个问题回答清楚，CPU 空转、日志放大和 goroutine 不退出，通常就有了很具体的改法。