Wie funktioniert der Go-Runtime-Scheduler?

Question

Accepted Answer

Die Go-Runtime enthält einen **Scheduler**, der viele Goroutines auf eine kleine Anzahl von OS-Threads verteilt. Dieses **M:N-Scheduling** (M Goroutines auf N OS-Threads) macht Goroutines so günstig und Gos Concurrency so skalierbar. Das Verständnis dafür erklärt die Goroutine-Performance.

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

Die Runtime ordnet viele Goroutines (G) auf OS-Threads (M) über logische Prozessoren (P) zu. Es gibt standardmäßig einen P pro CPU-Kern (`GOMAXPROCS`), jeder mit einer Warteschlange von Goroutines, die ausgeführt werden können.

## Wie es kostengünstige, skalierbare Concurrency erreicht

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

Da der Scheduler das Goroutine-Switching im User-Space verarbeitet (keine Kernel-Level-Thread-Switches), und Goroutines winzige Stacks haben, können Sie deutlich mehr Goroutines als OS-Threads, und das kostengünstig, ausführen.

## Schlüsselverhaltensweisen des Schedulers

```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ält Cores beschäftigt, **Preemption** verhindert, dass eine Goroutine einen Core monopolisiert, und entscheidend ist: Wenn eine Goroutine blockiert (auf einem Channel oder Syscall), hält der Scheduler andere Goroutines am Laufen, anstatt den Thread zu verschwenden.

## GOMAXPROCS

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

## Warum Goroutines nicht kostenlos sind

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

## Warum es wichtig ist

Der Go-Scheduler ist das Herzstück der bemerkenswerten Kostengünstigkeit und Skalierbarkeit von Goroutines – das Verständnis seines **M:N-Modells** (viele Goroutines auf wenigen OS-Threads über das G-M-P-Design) erklärt, *warum* Go Millionen von Goroutines ausführen kann, während OS-Threads in den Tausenden ausmaxen, und *warum* seine Concurrency so effizient ist (User-Space-Switching anstelle von teuren OS-Kontextwechseln, echter Parallelismus über Cores via GOMAXPROCS).

Die intelligente Handhabung von Blockierungen (Parken von Channel-blockierten Goroutines, Abgabe von P bei Syscalls, damit Threads nicht verschwendet werden), **Work stealing** für Lastverteilung und **Preemption** (seit 1.14) zur Verhütung von Starvation sind das, was Gos Concurrency unter realen Workloads robust macht.

Obwohl Sie selten direkt mit dem Scheduler interagieren, vertieft sein Verständnis Ihre Intuition für Goroutine-Performance, erklärt Verhaltensweisen (warum Blockierungen keine Threads verschwenden, warum Sie so viele Goroutines spawnen können) und informiert Entscheidungen wie das Begrenzen von Concurrency.

Es ist ein fortgeschrittenes Thema, das echtes tiefgehendes Go-Runtime-Wissen demonstriert und wird in Senior-Interviews geschätzt.