Busy-Waiting (Spin-Waiting)
Busy-waiting spins in a tight loop polling a condition instead of blocking, wasting a full CPU core and starving other work. Replace it with condition variables, semaphores, futures, or channels that let the OS wake the thread when the condition actually changes.
Busy-waiting (or spin-waiting) is a thread repeatedly checking a condition in a tight loop until it becomes true, rather than blocking and letting the operating system wake it when the condition changes. The loop consumes a full CPU core doing nothing useful.
while (!ready) { /* spin */ }
process();
A bounded, microsecond-scale spin is a legitimate optimization (spinlocks under very short contention), but unbounded application-level spinning is almost always a defect.
Why It Happens
Busy-waiting is the most obvious way to express "wait until X." Blocking primitives such as condition variables, semaphores, futures, and channels require more setup and a mental model of who signals whom. Developers also reach for it when the producing code lives in another thread or process and there is no obvious notification mechanism, so polling feels like the only option. Copy-pasted spin loops from quick prototypes survive into production unchanged.
Why It Hurts
A spinning thread pins a core at 100% with zero throughput. On a multi-tenant host this steals cycles from threads doing real work and can invert priorities: a high-priority spinner starves the low-priority thread it is waiting on (priority inversion). On laptops and mobile it drains the battery and spins up fans. In containers it inflates CPU requests and cloud bills, and autoscalers may add capacity to serve phantom load. Under heavy contention, many spinners cause cache-line ping-pong that slows the whole system.
Warning Signs
- A
while (!flag)ordo {} whileloop with nosleep,yield, or blocking call inside. - CPU usage near 100% while the application is logically idle.
- Profilers showing most time in a polling function.
- "Fixes" that add
Thread.sleep(1)inside the loop to reduce CPU — a smell that the wait should block instead.
Better Alternatives
- Condition variables / monitors: block on a predicate and get signaled on change.
- Semaphores, latches, barriers: coordinate without polling.
- Futures / promises / async-await: model completion as a value you await.
- Channels and message queues: receive blocks until data arrives.
- OS or library notifications:
epoll/kqueue, file watchers,WaitForSingleObject. - For genuine short spins, use a platform spin hint (
pause,onSpinWait) and cap the spin before falling back to blocking (adaptive spinning).
How to Refactor Out of It
Identify what produces the condition you are polling. Introduce an explicit signal at that point: when the producer sets the flag, have it notify a condition variable or push to a channel. Replace the spin loop with a blocking wait on that primitive. If the producer is external (a file, socket, or process), use the platform's readiness notification (select/epoll, inotify) instead of repeated stat or read calls. Where you truly need low-latency handoff, use a bounded adaptive spin that yields and then blocks. Measure CPU before and after; idle CPU should drop to near zero.