Hogyan működik a Go runtime scheduler?

Question

Accepted Answer

A Go runtime egy **scheduler**-t tartalmaz, amely sok goroutine-t sokszoros-e el egy kis számú OS szál felé. Ez az **M:N scheduling** (M goroutine N OS szálon) az, ami a goroutine-okat olyan olcsóvá és a Go konkurenciáját olyan skálázhatóvá teszi. Ennek megértése magyarázza a goroutine teljesítményt.

## A G-M-P modell

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

A runtime sok goroutine (G) összekapcsolódik az OS szálakkal (M) logikai processzorokon (P) keresztül. Alapértelmezés szerint (`GOMAXPROCS`) egy P van CPU magoncsonként, mindegyik futásra készen álló goroutine-ok sorával.

## Hogyan éri el az olcsó, skálázható konkurenciát

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

Mert a scheduler a felhasználói térben kezeli a goroutine váltásokat (nem kernelszintű szálváltásokat), és a goroutine-oknak apró veremei vannak, sok több goroutine-t futtathat, mint OS szálakat, olcsón.

## A scheduler fő viselkedése

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

A **work stealing** szálat tartja foglalkoztatottnak, az **preemption** megakadályozza, hogy egy goroutine magára vonja a magot, és lényegesen, amikor egy goroutine blokkolja (a csatornán vagy a syscall-on), a scheduler más goroutine-okat futtat a szál pazarlása helyett.

## GOMAXPROCS

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

## Miért nem ingyenesek a goroutine-ok, azonban

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

## Miért fontos ez

A Go scheduler a motor a goroutine-ok figyelemreméltó olcsósága és skálázhatósága mögött — annak **M:N modelljének** (sok goroutine kevés OS szálon a G-M-P tervézen keresztül) megértése magyarázza meg *miért* képes a Go millió goroutine-t futtatni, amikor az OS szálak ezresekben maximálisodnak, és *miért* olyan hatékony konkurenciája (felhasználói térbeli váltás helyett költséges OS kontextusváltások, igazi párhuzamosság magok között a GOMAXPROCS-on keresztül).

A blokkolás okos kezelése (csatornára blokk goroutine-ok parkolása, P kiadása a syscall-okon, így a szálakat nem pazarlják el), a **work stealing** terheléselosztáshoz, és az **preemption** (1.14 óta) az éhezés megelőzéséhez az, ami a Go konkurenciáját robusztussá teszi a valós terhelések alatt.

Bár ritkán kommunikál közvetlenül a scheduler-rel, annak megértése mélyíti a goroutine teljesítményre vonatkozó intuícióját, magyarázza a viselkedéseket (miért nem pazarló blokkolás szálakat, miért lehet ennyi goroutine-t alapítani), és tájékoztatja az olyan döntéseket, mint a konkurencia korlátozása.

Ez egy fejlett téma, amely a Go runtime ismeretének valódi mélységét mutatja, és értékelt a felső szintű interjúkban.