Hvordan fungerer Go runtime scheduler?

Question

Accepted Answer

Go runtime inkluderer en **scheduler**, der multiplekser mange goroutines på et lille antal OS threads. Denne **M:N scheduling** (M goroutines på N OS threads) er det, der gør goroutines så billige og Gos concurrency så skalerbar. At forstå det forklarer goroutine performance.

## G-M-P modellen

```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.
```

Runtime mapper mange goroutines (G) på OS threads (M) via logiske processorer (P). Der er en P per CPU core som standard (`GOMAXPROCS`), hver med en kø af goroutines klar til at køre.

## Hvordan det opnår billig, skalerbar concurrency

```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
```

Fordi scheduler håndterer goroutine switching i user space (ikke kernel-level thread switches), og goroutines har små stacks, kan du køre langt flere goroutines end OS threads, billigt.

## Vigtige scheduler-adfærd

```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** holder cores optaget, **preemption** forhindrer en goroutine i at monopolisere en core, og afgørende: når en goroutine blokerer (på en channel eller syscall), holder scheduler andre goroutines i gang i stedet for at spilde threaden.

## GOMAXPROCS

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

## Hvorfor goroutines ikke er gratis, dog

```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.
```

## Hvorfor det betyder noget

Go scheduler er motoren bag goroutines' bemærkelsesværdige billigdom og skalerbarhed — at forstå dens **M:N model** (mange goroutines på få OS threads via G-M-P designet) forklarer *hvorfor* Go kan køre millioner af goroutines når OS threads makserer ud på tusinder, og *hvorfor* dens concurrency er så effektiv (user-space switching i stedet for dyrt OS context switches, ægte parallelisme på tværs af cores via GOMAXPROCS).

Den intelligente håndtering af blocking (parkering af channel-blokerede goroutines, overgivelse af P på syscalls så threads ikke spildes), **work stealing** for load balancing, og **preemption** (siden 1.14) for at forhindre sult er det, der gør Gos concurrency robust under virkelige arbejdsbelastninger.

Skønt du sjældent interagerer med scheduler direkte, uddyber forståelse af den din intuition for goroutine performance, forklarer adfærd (hvorfor blocking ikke spiller threads, hvorfor du kan spawne så mange goroutines), og informerer beslutninger som at begrænse concurrency.

Det er et avanceret emne, der demonstrerer genuin dybde af Go runtime viden og værdsættes i senior interviews.