Hvordan fungerer Go-kjøretidsplanleggeren?

Question

Accepted Answer

Go-kjøretiden inkluderer en **planlegger** som multiplekserer mange goroutiner på et lite antall OS-tråder. Denne **M:N-planleggingen** (M goroutiner på N OS-tråder) er det som gjør goroutiner så billige og Gos samtidighet så skalerbar. Å forstå den forklarer ytelsen til goroutiner.

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

Kjøretiden kartlegger mange goroutiner (G) på OS-tråder (M) via logiske prosessorer (P). Det er en P per CPU-kjerne som standard (`GOMAXPROCS`), hver med en kø med goroutiner som er klare til kjøring.

## Hvordan det oppnår billig, skalerbar samtidighet

```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 planleggeren håndterer goroutin-bytte i brukerrom (ikke kjernelevel-trådbytte), og goroutiner har små stakker, kan du kjøre langt flere goroutiner enn OS-tråder, billig.

## Nøkkelplanleggeroppførsel

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

**Arbeidstyving** holder kjerner opptatte, **preempsjon** forhindrer at en goroutin monopoliserer en kjerne, og avgjørende, når en goroutin blokkeres (på en kanal eller syscall), fortsetter planleggeren å kjøre andre goroutiner i stedet for å kaste bort tråden.

## GOMAXPROCS

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

## Hvorfor goroutiner ikke er gratis, men

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

Go-planleggeren er motoren bak goroutinenes bemerkelsesverdige billigheid og skalerbarhet — å forstå dens **M:N-modell** (mange goroutiner på få OS-tråder via G-M-P-designet) forklarer *hvorfor* Go kan kjøre millioner av goroutiner når OS-tråder makserer ut på tusenvis, og *hvorfor* dens samtidighet er så effektiv (brukerrombytte i stedet for kostbare OS-kontekstkvalifiseringer, ekte parallellisme på tvers av kjerner via GOMAXPROCS).

Den smarte håndteringen av blokkering (parkering av kanalblokket goroutiner, overlevering av P på syscalls slik at tråder ikke kastes bort), **arbeidstyving** for lastbalansering, og **preempsjon** (siden 1.14) for å forhindre sulting er det som gjør Gos samtidighet robust under virkelige arbeidsbelastninger.

Altsom du sjelden samvirker direkte med planleggeren, utdyper forståelse av den din intuisjon for goroutin-ytelse, forklarer atferd (hvorfor blokkering ikke kaster bort tråder, hvorfor du kan spawne så mange goroutiner), og informerer beslutninger som å grense samtidighet.

Det er et avansert emne som demonstrerer genuin dybde av Go-kjøretidskunnskap og er verdsatt i seniorsamtaler.