How does Go's GMP scheduler work and how does it affect concurrency design?

Question

Accepted Answer

G (Goroutine): the unit of work with its own stack and state M (Machine/OS thread): the entity that actually executes code on the CPU P (Processor): a logical processor with a local run queue, limited by GOMAXPROCS Each P can run one G at a time on one M — GOMAXPROCS controls parallelism, not concurrency Global run queue: overflow queue when local P queues are full Work stealing: idle P steals goroutines from busy P's local queue — automatic load balancing Preemption: goroutines are preempted at function calls and loop back-edges (Go 1.14+) — no starvation Blocking syscall: when G blocks on a syscall, P detaches from M and attaches to a new M so other goroutines keep running Network I/O: Go's netpoller parks goroutines awaiting I/O without blocking an OS thread import "runtime"

// Set number of OS threads used for parallel execution
runtime.GOMAXPROCS(runtime.NumCPU()) // default since Go 1.5

// For CPU-bound tasks: set GOMAXPROCS to NumCPU
// For I/O-bound tasks: more goroutines than CPUs is fine

// CGo blocks an OS thread — avoid in hot paths
// Long-running CGo calls prevent other goroutines from running on that M

// Check runtime stats
var stats runtime.MemStats
runtime.ReadMemStats(&stats)
fmt.Println("goroutines:", runtime.NumGoroutine())

How does Go's GMP scheduler work and how does it affect concurrency design?

The GMP model (Goroutines, OS threads, Processors) is Go's runtime scheduler that multiplexes goroutines onto OS threads using work-stealing, enabling massive concurrency with minimal overhead.

Scenario Questions

Follow-up Questions