Comment fonctionne le scheduler du runtime Go ?

Question

Accepted Answer

Le runtime Go inclut un **scheduler** qui multiplexe de nombreuses goroutines sur un petit nombre de threads OS. Ce **scheduling M:N** (M goroutines sur N threads OS) est ce qui rend les goroutines si peu coûteuses et la concurrence de Go si scalable. Le comprendre explique les performances des goroutines.

## Le modèle G-M-P

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

Le runtime mappe de nombreuses goroutines (G) sur des threads OS (M) via des processeurs logiques (P). Il y a un P par cœur CPU par défaut (`GOMAXPROCS`), chacun avec une queue de goroutines prêtes à s'exécuter.

## Comment cela réalise une concurrence bon marché et scalable

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

Parce que le scheduler gère les changements de contexte des goroutines dans l'espace utilisateur (pas des changements de threads au niveau kernel), et que les goroutines ont des stacks minuscules, vous pouvez exécuter bien plus de goroutines que de threads OS, et ce à bas coût.

## Comportements clés du scheduler

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

Le **work stealing** maintient les cœurs occupés, la **préemption** empêche une goroutine de monopoliser un cœur, et surtout, quand une goroutine se bloque (sur un canal ou un appel système), le scheduler continue d'exécuter d'autres goroutines au lieu de gaspiller le thread.

## GOMAXPROCS

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

## Pourquoi les goroutines ne sont pas gratuites, cependant

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

## Pourquoi c'est important

Le scheduler Go est le moteur derrière la remarquable bon marché et scalabilité des goroutines — comprendre son **modèle M:N** (de nombreuses goroutines sur peu de threads OS via le design G-M-P) explique *pourquoi* Go peut exécuter des millions de goroutines quand les threads OS plafonnent dans les milliers, et *pourquoi* sa concurrence est si efficace (changement dans l'espace utilisateur au lieu de coûteux context switches OS, vrai parallélisme entre cœurs via GOMAXPROCS).

La gestion intelligente du blocage (parking des goroutines bloquées sur canal, passation de P sur les appels système pour que les threads ne soient pas gaspillés), le **work stealing** pour l'équilibrage de charge, et la **préemption** (depuis 1.14) pour prévenir la famine sont ce qui rend la concurrence de Go robuste sous des charges réelles.

Bien que vous interagissiez rarement directement avec le scheduler, le comprendre approfondit votre intuition pour les performances des goroutines, explique les comportements (pourquoi le blocage ne gaspille pas les threads, pourquoi vous pouvez créer autant de goroutines), et informe les décisions comme limiter la concurrence.

C'est un sujet avancé qui démontre une véritable profondeur de connaissance du runtime Go et est valorisé dans les entretiens senior.