Hur fungerar Go-körtidens scheduler?

Question

Accepted Answer

Go-körningen innehåller en **scheduler** som multiplexar många goroutines på ett litet antal OS-trådar. Denna **M:N-scheduling** (M goroutines på N OS-trådar) är det som gör goroutines så billiga och Go:s concurrency så skalbar. Att förstå den förklarar goroutine-prestanda.

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

Körningen mappar många goroutines (G) på OS-trådar (M) via logiska processorer (P). Det finns en P per CPU-kärna som standard (`GOMAXPROCS`), var och en med en kö av goroutines som är redo att köras.

## Hur den uppnår billig, skalbar 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
```

Eftersom schedulern hanterar goroutine-växling i användarutrymme (inte kernel-nivå trådväxlingar), och goroutines har små stackar, kan du köra långt fler goroutines än OS-trådar, billigt.

## Viktiga scheduler-beteenden

```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** håller kärnor upptagna, **preemption** förhindrar att en goroutine monopoliserar en kärna, och viktigt är att när en goroutine blockeras (på en kanal eller syscall) håller schedulern andra goroutines igång istället för att slösa tråden.

## GOMAXPROCS

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

## Varför goroutines inte är gratis trots allt

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

## Varför det spelar roll

Go-schedulern är motorn bakom goroutines anmärkningsvärda billighet och skalbarhet — att förstå dess **M:N-modell** (många goroutines på få OS-trådar via G-M-P-designen) förklarar *varför* Go kan köra miljontals goroutines när OS-trådar maxar ut på tusentals, och *varför* dess concurrency är så effektiv (användarutrymme-växling istället för dyra OS-kontextväxlingar, äkta parallellism över kärnor via GOMAXPROCS).

Den smarta hanteringen av blockering (parkering av kanal-blockerade goroutines, överlåtelse av P vid syscalls så trådar inte slösas bort), **work stealing** för lastbalansering och **preemption** (sedan 1.14) för att förhindra svält är det som gör Go:s concurrency robust under verkliga arbetsbelastningar.

Even om du sällan interagerar direkt med schedulern fördjupar förståelsen för den din intuition för goroutine-prestanda, förklarar beteenden (varför blockering inte slösar trådar, varför du kan starta så många goroutines), och informerar beslut som att begränsa concurrency.

Det är ett avancerat ämne som demonstrerar genuine Go-körningskunskap och värderas i seniora intervjuer.