Kuinka Go-ajoympäristön scheduler toimii?

Question

Accepted Answer

Go-ajoympäristö sisältää **schedulerin**, joka multipleksoi monia goroutiineja pienelle määrälle OS-säikeitä. Tämä **M:N-scheduling** (M goroutiinea N OS-säikeellä) tekee goroutiineista niin halpoja ja Go:n concurrencystä niin skaalautuvaa. Sen ymmärtäminen selittää goroutiinien suorituskyvyn.

## G-M-P malli

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

Ajoympäristö kartoittaa monia goroutiineja (G) OS-säikeille (M) loogisten prosessorien (P) kautta. Oletuksena on yksi P prosessoriydintä kohti (`GOMAXPROCS`), joissa kullakin on jono valmiita goroutiineja suoritukseen.

## Kuinka se saavuttaa halvan, skaalautuvan concurrencyn

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

Koska scheduler käsittelee goroutiinin vaihtamisen käyttäjätilassa (ei kernel-tason säikeiden vaihtamista), ja goroutiineilla on pienet pinot, voit ajaa huomattavasti enemmän goroutiineja kuin OS-säikeitä, ja halvalla.

## Pääasiallisen schedulerin käyttäytyminen

```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** pitää ytimet varattuna, **preemption** estää yhden goroutiinin hallitsemasta ydintä, ja kriittisesti, kun goroutiini estyy (kanavalla tai syscalissa), scheduler pitää muut goroutiinit käynnissä sen sijaan että säie hukkautuisi.

## GOMAXPROCS

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

## Miksi goroutiinit eivät ole ilmaisia

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

## Miksi se on tärkeää

Go-scheduler on moottori goroutiinien hämmästyttävän halbuuden ja skaalautuvuuden takana — sen **M:N-mallin** ymmärtäminen (monia goroutiineja harvalla OS-säikeellä G-M-P-mallin kautta) selittää, *miksi* Go voi ajaa miljoonia goroutiineja kun OS-säikeet maksimissaan tuhansia, ja *miksi* sen concurrency on niin tehokas (käyttäjätilan vaihtaminen kalliiden OS-yhteydenvaihtosekvenssien sijasta, todellinen parallelismi ytimien yli GOMAXPROCS:in kautta).

Äly estävässä käsittelyssa (kanavan estämien goroutiinien parkeeraus, P:n luovutus syscallissa jotta säikeitä ei hukkaa), **work stealing** kuorman tasaamiseen ja **preemption** (versio 1.14 lähtien) starvaaation estämiseen ovat ne, jotka tekevät Go:n concurrencystä vankkaa todellisissa työkuormissa.

Vaikka harvoin interact schedulerin kanssa suoraan, sen ymmärtäminen syventää intuitiotasi goroutiinien suorituskyvystä, selittää käyttäytymisiä (miksi estäminen ei hukkaa säikeitä, miksi voit synteetisoida niin monia goroutiineja), ja informoi päätöksiä kuten concurrencyn rajoittaminen.

Se on edistyksellinen aihe, joka osoittaa todellisen syvyyden Go-ajoympäristön tietämisessä ja on arvostettu seniorikierrosten haastatteluissa.