Go select default 为什么会让 CPU 飙高？从空转循环到可控等待

在 Go 代码里，select 的 default 常被用来做非阻塞判断：有数据就处理，没有数据就继续往下走。问题出在它被放进一个没有任何等待条件的 for 循环后，程序会在没有 channel 事件时一轮接一轮地立即返回，CPU 很容易被空转循环打满。遇到这类现象，不要只盯着语法是否正确，更要看循环在空闲时到底有没有机会停下来。

问题现场：select default 后 CPU 一直很高

一个典型现场是：服务没有明显请求量，业务日志却一直刷，机器 CPU 使用率居高不下。打开代码后，经常能看到类似下面的循环：

for {
    select {
    case job := 

这段代码能编译，也能运行，但它的空闲路径没有任何等待。只要 jobs 暂时没有数据，default 就会马上执行；执行完又回到下一轮 for，下一轮仍然没有数据，于是继续进入 default。循环速度由 CPU 能跑多快决定，而不是由任务到达速度决定。

初步判断：default 让循环不再阻塞等待

Go 语言规范里，select 会从可以进行通信的分支里选择一个执行；如果没有通信分支能继续，而存在 default，就会选择 default。这意味着 default 的核心价值是“不要等”。这个价值在一次性探测里很好用，但放到常驻循环里，就很容易把“不要等”变成“永远不停”。

可以把 default 理解成一条快速旁路：它绕过了 channel 的阻塞等待。如果旁路后面没有 sleep、ticker、I/O、锁等待、网络等待或退出信号，循环就会把空闲时间全部交给 CPU 消耗。

动手验证：用最小代码复现空转

下面这段代码故意让 ch 没有生产者。为了避免日志本身拖慢太多，示例里只累计空转次数，实际项目里如果每轮还打印日志，现象会更明显。

package main

import (
    "fmt"
    "time"
)

func main() {
    ch := make(chan int)
    var idle uint64
    deadline := time.After(2 * time.Second)

    for {
        select {
        case v := 

运行后会发现，两秒内空转次数非常高。这里的重点不是具体数字，而是现象：没有业务事件时，循环仍在持续工作。线上服务如果把这种循环放进多个 goroutine，CPU 压力会被成倍放大。

定位原因：没有等待条件的 for select 会忙等

排查这类问题时，可以先看三类证据。

• 监控里 CPU 使用率偏高，但请求量、队列量或任务量并没有同步升高。
• 日志里出现高频空闲日志、重复状态日志，或者同一段检查逻辑被连续触发。
• 采样结果显示热点集中在某个 for 循环、空闲分支或轮询函数附近。

如果代码里存在 for { select { ... default: ... } }，就要继续追问：default 分支是否真的需要在没有事件时立即重试？如果答案是否定的，就应该让循环在空闲时等待。

修复方案：阻塞等待、ticker 节流或 context 退出

修复方向并不是简单地把所有 default 删除，而是给循环补上合理的生命周期。常见做法有三种。

持续消费任务时，让 channel 自己阻塞

如果 goroutine 的职责就是等待任务，那它不需要 default。没有任务时阻塞在 channel 上，反而是最省资源、最清晰的写法。

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

需要周期性检查时，用 ticker 控制节奏

如果确实需要“隔一段时间检查一次”，就让时间成为触发条件，而不是让循环自己拼命重试。

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

for {
    select {
    case job := 

服务要能停下来时，加入 ctx.Done

后台循环最好有明确的退出路径。这样发布、重启、任务取消时，goroutine 不会一直留在进程里。

func workLoop(ctx context.Context, jobs 

验证结果：CPU 回落并且退出路径清楚

改完以后不要只看“服务能启动”。更可靠的复查方式是把空闲场景也跑一遍：没有任务输入时，CPU 应该回到正常水平；任务到来时能及时处理；取消上下文或关闭 channel 时，循环能按预期退出。

可以用下面这份检查清单做回归：

• 空闲 1 到 3 分钟，CPU 是否明显回落。
• 任务进入 jobs 后，处理延迟是否仍在可接受范围内。
• ctx.Done() 被触发后，goroutine 是否能退出。
• ticker.Stop() 是否写在合适位置，避免定时器资源继续占用。
• 日志是否从“每轮打印”改成了“状态变化时打印”。

相关问题

Go select 里的 default 是不是不能用？

不是。default 适合非阻塞试探，例如尝试读一次 channel、快速判断队列是否已有数据、在排空函数里读到空就返回。真正危险的是把它放进没有等待条件的无限循环里。

给 default 里加 time.Sleep 可以吗？

短期能降低 CPU，但不一定是最清晰的模型。周期性任务用 time.NewTicker 更容易表达频率；等待任务用阻塞 channel 更直接；需要退出就加入 ctx.Done()。

为什么本地看不明显，线上才 CPU 飙高？

本地通常 goroutine 数量少、运行时间短，空转影响不容易被放大。线上一旦有多个 worker、多个实例或更长运行时间，忙等循环会持续占用调度资源，监控就会更明显。

select 没有 default 会不会卡死？

如果所有分支都没有事件，select 会等待，这是它的正常行为。是否会“卡住”取决于程序设计：常驻 worker 等待任务是合理的；如果需要退出，就应该加入关闭 channel 或 ctx.Done()。

总结

select default 本身不是坏写法，它只是告诉程序“不要等”。当这条规则进入无限 for 循环时，就要特别小心：没有事件、没有节流、没有退出路径，三者叠加就是典型的 CPU 空转。把循环改成阻塞等待、定时触发或可取消退出，代码会更省资源，也更容易解释和维护。