Hoe werkt de Go runtime scheduler?

Question

Accepted Answer

De Go runtime bevat een **scheduler** die veel goroutines op een klein aantal OS threads multiplext. Dit **M:N scheduling** (M goroutines op N OS threads) is wat goroutines zo goedkoop en Go's concurrency zo schaalbaar maakt. Als je dit begrijpt, verklaar je de goroutine performance.

## Het G-M-P model

```text
G (Goroutine) — your concurrent task (lightweight, ~2KB stack to start)
M (Machine)   — an OS thread (the actual thread the OS schedules)
P (Processor) — a logical processor / scheduling context; holds a queue of runnable Gs
                (the number of P's = GOMAXPROCS, default = number of CPU cores)

The scheduler runs G's on M's, coordinated through P's:
  Each P has a local run queue of goroutines; an M must hold a P to run G's.
```

De runtime mapped veel goroutines (G) op OS threads (M) via logische processors (P). Er is standaard een P per CPU core (`GOMAXPROCS`), elk met een queue van goroutines die klaar zijn om te draaien.

## Hoe het goedkope, schaalbare concurrency bereikt

```text
✓ Creating a goroutine is cheap (tiny stack, runtime-managed) → millions feasible
✓ Switching goroutines happens in USER space (runtime), not via expensive OS
  context switches → far lighter than switching OS threads
✓ With P = CPU cores, Go runs goroutines truly in parallel across cores
```

Omdat de scheduler goroutine switching in user space afhandelt (geen kernel-level thread switches), en goroutines tiny stacks hebben, kun je veel meer goroutines dan OS threads draaien, goedkoop.

## Sleutel scheduler gedragingen

```text
✓ Work stealing — an idle P STEALS goroutines from a busy P's queue → load balancing
✓ Cooperative + preemptive — goroutines yield at function calls/channel ops/blocking;
  since Go 1.14, the scheduler can also PREEMPT long-running goroutines (no starvation)
✓ Blocking handled smartly:
   - A goroutine blocked on a CHANNEL/sync → parked, the M runs other goroutines (no thread wasted)
   - A goroutine blocked on a SYSCALL (e.g. file I/O) → the M blocks, but the P is
     handed to ANOTHER M so other goroutines keep running
```

**Work stealing** houdt cores actief, **preemption** voorkomt dat één goroutine een core monopoliseert, en cruciaal: wanneer een goroutine blokkeert (op een channel of syscall), houdt de scheduler andere goroutines draaiende in plaats van de thread te verspillen.

## GOMAXPROCS

```go
runtime.GOMAXPROCS(4)    // limit to 4 OS threads running Go code simultaneously
// default = number of CPU cores; rarely needs changing
```

## Waarom goroutines niet gratis zijn, hoewel

```text
Goroutines are cheap but not zero-cost — millions still use memory, and excessive
goroutines add scheduling overhead. Bound concurrency (worker pools) for heavy loads.
```

## Waarom het belangrijk is

De Go scheduler is de motor achter goroutines' opmerkelijke goedkoopheid en schaalbaarheid — het begrijpen van zijn **M:N model** (veel goroutines op weinig OS threads via het G-M-P design) verklaart *waarom* Go miljoen goroutines kan draaien waar OS threads uitgeteld zijn in de duizenden, en *waarom* zijn concurrency zo efficiënt is (user-space switching in plaats van dure OS context switches, true parallelism via GOMAXPROCS).

De slimme handling van blocking (channel-blocked goroutines parkeren, P doorgeven op syscalls zodat threads niet verspild worden), **work stealing** voor load balancing, en **preemption** (sinds 1.14) om starvation te voorkomen, zijn wat Go's concurrency robuust maakt onder echte workloads.

Hoewel je zelden direct met de scheduler interageert, verdiept het begrijpen ervan je intuïtie voor goroutine performance, verklaart het gedragingen (waarom blocking threads niet verspilt, waarom je zo veel goroutines kunt spawnen), en informeert het beslissingen zoals het begrenzen van concurrency.

Het is een geavanceerd onderwerp dat echte diepte van Go runtime kennis aantoont en wordt gewaardeerd in senior interviews.