¿Cómo funciona el planificador del runtime de Go?

Question

Accepted Answer

El runtime de Go incluye un **planificador** que multiplexea muchas goroutinas en un pequeño número de hilos del sistema operativo. Esta **programación M:N** (M goroutinas en N hilos del SO) es lo que hace que las goroutinas sean tan económicas y que la concurrencia de Go sea tan escalable. Entenderlo explica el rendimiento de las goroutinas.

## Por qué es importante

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

El runtime mapea muchas goroutinas (G) en hilos del SO (M) a través de procesadores lógicos (P). Hay un P por núcleo de CPU por defecto (`GOMAXPROCS`), cada uno con una cola de goroutinas listas para ejecutarse.

## Cómo logra concurrencia económica y escalable

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

Porque el planificador maneja el cambio de contexto de goroutinas en espacio de usuario (no cambios de hilos a nivel de kernel), y las goroutinas tienen pilas muy pequeñas, puedes ejecutar muchísimas más goroutinas que hilos del SO, de manera económica.

## Comportamientos clave del planificador

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

El **robo de trabajo** mantiene los núcleos ocupados, la **preemción** evita que una goroutina monopolice un núcleo, y crucialmente, cuando una goroutina se bloquea (en un canal o syscall), el planificador sigue ejecutando otras goroutinas en lugar de desperdiciar el hilo.

## GOMAXPROCS

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

## Por qué las goroutinas no son gratis, sin embargo

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

## Por qué es importante

El planificador de Go es el motor detrás de la economía y escalabilidad notable de las goroutinas — entender su **modelo M:N** (muchas goroutinas en pocos hilos del SO a través del diseño G-M-P) explica *por qué* Go puede ejecutar millones de goroutinas cuando los hilos del SO se agotan en miles, y *por qué* su concurrencia es tan eficiente (cambio de contexto en espacio de usuario en lugar de costosos cambios de contexto del SO, paralelismo verdadero entre núcleos via GOMAXPROCS).

El manejo inteligente de bloqueos (estacionamiento de goroutinas bloqueadas en canales, traspaso de P en syscalls para que los hilos no se desperdicien), **robo de trabajo** para equilibrio de carga, y **preemción** (desde 1.14) para prevenir inanición son lo que hace que la concurrencia de Go sea robusta bajo cargas de trabajo reales.

Aunque raramente interactúes directamente con el planificador, entenderlo profundiza tu intuición sobre el rendimiento de goroutinas, explica comportamientos (por qué el bloqueo no desperdicia hilos, por qué puedes crear tantas goroutinas), e informa decisiones como acotar la concurrencia.

Es un tema avanzado que demuestra conocimiento genuino y profundo del runtime de Go y es valorado en entrevistas para posiciones senior.