Senior · Memory and runtime
Goroutines, threads and CPU quotas
Why does adding goroutines fail to speed up CPU work?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Goroutines are scheduled by the runtime onto OS threads. GOMAXPROCS limits simultaneous execution of Go code; it is not a limit on goroutine count or every OS thread.
CPU-bound work only benefits until CPU capacity and parallelizable work are exhausted. More runnable goroutines can add scheduling overhead, cache misses and memory pressure. Blocking I/O has different behavior.
Account for the runtime version and container CPU policy when inspecting the effective GOMAXPROCS. Use CPU profiles, runtime traces and cgroup throttling metrics before choosing worker counts.
Common trap
One goroutine per task with an unbounded queue is not a CPU capacity strategy.
Try it
A two-CPU container starts 1,000 hashing workers and p99 grows. What do you change first?
Worked solution
Bound active hashing workers and queue length, measure throughput and CPU throttling, then compare a small range of concurrency limits. Reject or defer overload instead of retaining unlimited work.
Change the constraint
How does blocking in a syscall differ from spending all CPU time in Go code?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.