Kako radi Go runtime scheduler?

Question

Accepted Answer

Go runtime uključuje **scheduler** koji multipleksira mnogo goroutina na mali broj OS niti. Ovaj **M:N scheduling** (M goroutin na N OS niti) je ono što goroutine čini tako jeftinima i Go's concurrency tako skalabilnim. Razumijevanje toga objašnjava performanse goroutin.

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

Runtime mapira mnogo goroutin (G) na OS niti (M) preko logičkih procesora (P). Postoji jedan P po CPU jezgri prema zadanom (`GOMAXPROCS`), svaki s redom čekanja goroutin spremnih za izvođenje.

## Kako postiže jeftinu, skalabilnu konkurenciju

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

Jer scheduler upravlja prebacivanjem goroutin u korisničkom prostoru (ne prebacivanjem niti na razini kernela), a goroutine imaju male hrpe, možete pokrenuti mnogo više goroutin nego OS niti, jeftino.

## Ključno ponašanje scheduler-a

```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** čini jezgre zaposlenima, **preemption** sprječava goroutinu od hogging jezgre, a što je najvažnije, kada goroutina blokira (na kanalu ili syscallu), scheduler nastavlja s izvođenjem ostalih goroutin umjesto trošenja niti.

## GOMAXPROCS

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

## Zašto goroutine nisu besplatne, ipak

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

## Zašto je to važno

Go scheduler je motor iza goroutin-e nevjerojatne jeftine i skalabilnosti — razumijevanje **M:N modela** (mnogo goroutin na nekoliko OS niti preko G-M-P dizajna) objašnjava *zašto* Go može pokrenuti milijune goroutin kada OS niti dosegnu tisuće, i *zašto* je njegova konkurencija tako efikasna (prebacivanje u korisničkom prostoru umjesto skupih OS context switcha, pravi paralelizam preko jezgri preko GOMAXPROCS).

Pametna obrada blokiranja (parkiranje kanalom blokiranim goroutinama, predaje P na syscallima kako niti ne bi bile potrcane), **work stealing** za uravnotežavanje opterećenja, i **preemption** (od 1.14) za sprječavanje gladi su što čini Go konkurenciju robusnom pod stvarnim opterećenjima.

Mada rijetko direktno komunicirate sa scheduler-om, razumijevanje ga produbljuje vašu intuiciju za performanse goroutin-e, objašnjava ponašanja (zašto blokiranje ne troši niti, zašto možete stvoriti toliko goroutin), i informira odluke poput ograničavanja konkurencije.

To je naprednuta tema koja pokazuje pravo dubinu znanja Go runtime-a i cijenjena je na senior intervjuima.