A Go for-select loop with a default case pins a CPU core while the service is idle. How do you confirm it and fix it?

## The shape of the bug Consider a datagram receiver daemon whose main loop was written like this so that it "never gets stuck": ```go for { select { case d := <-datagrams: handle(d) default: } } ``` The intent reads as "take a datagram if there is one, otherwise loop round". The effect is a spin. Because `default` makes the select non-blocking, the loop body completes in tens of nanoseconds and starts again, so the goroutine is *runnable at all times*. It occupies one P for its whole scheduling quantum, gets rescheduled, and repeats — one core saturated for as long as the process lives, at its worst when the service is completely idle. The reason this survives review is that the code looks defensive. "Non-blocking" sounds strictly safer than "blocking", and the daemon does work correctly; it just costs a core to do nothing. ## Confirming it, not guessing The engineer who notices an idle service pinning a core has several cheap confirmations available: 1. **A CPU profile.** Collect one from the idle process and inspect it with `go tool pprof`. A poll loop is unmistakable: essentially all samples sit in one function, with the runtime's select implementation (`runtime.selectgo`) directly beneath it, and nothing that resembles application work. A healthy idle service produces a nearly empty profile, because parked goroutines are not sampled at all. 2. **The goroutine profile.** Fetch a goroutine dump and read the state of each goroutine. A parked receiver reports a channel-receive wait state; the spinning one is simply `running`, and its stack points at the loop. 3. **An execution trace.** `go tool trace` shows the goroutine occupying a processor continuously with no blocking events — useful when you want to see that it is never yielding rather than merely that it is hot. The diagnostic discipline matters because "one core pinned" has other causes — a tight retry loop, a compression or regexp hot path, garbage collection — and the profile distinguishes them in seconds. ## The fix Almost always: **delete the `default`.** A blocking select is not a hazard; a parked goroutine consumes no CPU and is woken by the runtime the moment a channel operation becomes possible. Add a cancellation case so the loop still has a way out: ```go for { select { case d := <-datagrams: handle(d) case <-ctx.Done(): return } } ``` This is strictly better than the original on every axis: idle cost drops to zero, latency improves (the runtime hands the value straight to the parked receiver rather than waiting for the next poll iteration to notice it), and shutdown becomes deterministic. Things that do **not** fix it: - **Calling `runtime.Gosched()` in the `default` branch.** It yields the processor so other goroutines can run, which may make the symptom less visible on a multi-core box, but the loop is still runnable and still consumes every cycle the scheduler gives it. The core stays busy. - **Raising `GOMAXPROCS`.** More parallelism does not make a spin loop stop spinning; it just leaves more cores for everything else while one is still wasted. - **Adding a buffer to the channel.** Buffering changes when sends block, not whether this select waits. - **Sleeping in the `default` branch.** A `time.Sleep` does cut the CPU burn, but it converts the design into a poll with a fixed latency floor and a wake-up per interval. If a channel is the source of the work, blocking on it is better in every respect. ## When polling really is required Occasionally the thing you are waiting on is not a channel — a file's mtime, a device, a shared flag — and you have no way to be woken. Then the loop must be *paced*, and the way to pace a select is a timer channel as a real case, so the select still blocks between passes: ```go for { select { case <-tick.C: poll() case <-ctx.Done(): return } } ``` The goroutine is parked between ticks and the CPU cost falls to nothing. The general rule is worth stating plainly: **`default` belongs only in code that already has other useful work to do on this pass.** In a loop whose only purpose is to wait, a `default` is always a bug. ## Why it is worth catching in review The cost is real but easy to under-price on a laptop: one saturated core per replica, multiplied by every instance you run, showing up as inflated CPU requests, noisy autoscaling, and a machine that never enters a low-power state. It is also perfectly invisible to functional tests — correctness is unaffected — so the only defences are a profile taken at idle and a reviewer who asks what the empty `default` branch is for.