Go select default 导致 CPU 飙高怎么办

Go 里看到某个 goroutine 的 CPU 持续升高，代码又是“for + select + default”，优先怀疑的是忙循环，而不是 channel 本身失控。select 没有可执行的发送或接收时，会立即选择 default；外层循环下一次又立刻进入 select，于是程序反复检查同一组条件，几乎没有等待时间。

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

修复方向很明确：不需要非阻塞就删掉 default；确实需要周期性检查时，就给轮询加一个明确的时间通道，并让退出信号拥有清晰的生命周期优先级。下面只围绕这条边界展开。

先定位 default 忙循环

先看一个容易被忽略的循环。它不是“等待消息”，而是“没有消息时立即继续”。

package main

import "fmt"

func poll(ch 

当 ch 暂时没有值时，default 不是睡眠点。它只代表“此刻没有通信可做，那就执行这里”。如果这个分支没有计数、日志或短暂等待，循环会以很高频率重复执行。用 CPU profile 观察时，通常会看到这个轮询函数反复占用采样；用简单计数器观察时，空闲期间的循环次数也会异常增长。

不需要非阻塞时直接等待

如果业务含义是“有消息就处理，没有消息就等”，最简单也最稳定的做法是删除 default。规范规定，没有 default 且当前没有可执行通信时，select 会阻塞到至少一个通信可以继续。

func consume(ctx context.Context, ch 

这个版本把等待交给运行时，CPU 不会为了“确认还没有消息”而不断重试。实际工程中，ctx.Done() 也很重要：只阻塞在业务 channel 上而没有退出分支，服务关闭时仍可能留下无法回收的 goroutine。

必须轮询时加入定时退避

有些代码确实需要做非阻塞检查，例如同时查看一个本地状态、刷新信号或执行周期性维护。这时可以保留 default 的业务语义，但不能让它无间隔空转。把检查动作放到 ticker 通道上，循环就会按照固定节奏被唤醒。

func monitor(ctx context.Context, jobs 

这种写法通常比在 default 中直接调用 time.Sleep 更容易组合多个事件：消息到达可以立即处理，定时维护按周期触发，取消信号也能打断等待。周期不是越小越好，应结合检查成本和业务时效选择；50 毫秒只是示例，不是通用阈值。

区分退避、丢消息与退出

加了退避以后，仍有三个边界需要单独判断。

• 退避不等于消费消息。 如果 channel 中有数据，接收分支可以被选择；处理函数本身仍要控制耗时和背压。
• 退避不等于丢弃消息。 不要把读取 channel 写在 default 外的随意探测逻辑中；要明确是阻塞接收、带缓冲接收还是有意丢弃。
• 停止 ticker 不等于停止 goroutine。 循环必须有 return 或其他退出条件，ticker 只是停止后续 tick。

如果只是一次性的“尽量读取当前已有消息”，也可以使用带短暂退出的非阻塞分支，但要让退出条件可见：

func drainOnce(ch 

这里的 default 是一次性操作的结束条件，和“永久 for 循环中的 default”不是同一风险。判断关键不在于代码里有没有 default，而在于选中它之后是否还会无条件回到下一轮。

用运行信号确认修复方向

修复后不要只看某一次 CPU 数字。可以同时记录处理次数、周期性检查次数和退出次数，区分“流量真的增加”和“空闲时不断空转”。下面的轻量计数只展示排查思路，生产环境可接入现有指标系统。

type Counters struct {
	Messages uint64
	Polls    uint64
	Exits    uint64
}

func notePoll(c *Counters) {
	// Polls 在无消息期间仍快速增长，通常说明轮询间隔过短或没有退避。
	atomic.AddUint64(&c.Polls, 1)
}

我通常把“无消息时是否应该等待”作为第一问：答案是等待，就删掉 default；答案是按周期检查，就用 ticker；答案是只扫一遍当前数据，就让 default 直接结束本轮。这样能把性能修复和消息语义放在同一个决策里。

常见问题

为什么 default 会让 CPU 飙高？

因为没有可执行通信时它会立即执行，外层循环又立刻开始下一次 select，循环没有自然等待点。

把 default 改成 time.Sleep 就够了吗？

短暂 sleep 能降低空转，但会把消息响应和退出响应变成固定延迟。多个事件需要同时等待时，优先使用 ticker 或 timer 通道统一纳入 select。

有 ticker 还需要 Stop 吗？

当前 Go 的 time 文档说明，新版本垃圾回收器可以回收不再可达的 ticker；显式 Stop 仍然能表达业务生命周期，并在需要时立即停止后续 tick，保留它通常更清楚。