Kaip veikia Go runtime planuotojas?

Question

Accepted Answer

Go runtime apima **planuotoją**, kuris sąryšyje jungia daugybę goroutinių su mažu skaičiumi OS gijų. Šis **M:N planaviimas** (M goroutinių ant N OS gijų) yra tai, dėl ko goroutinės yra tokios pigios ir Go lygiagretumas toks mastelis. Jį supratę, paaiškinsitės goroutinės efektyvumą.

## G-M-P modelis

```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 sąryšyje jungia daugybę goroutinių (G) su OS gijomis (M) per loginius procesorius (P). Pagal numatytuosius nustatymus yra viena P CPU šerdžiai (`GOMAXPROCS`), kiekviena su eile goroutinių, paruoštų darbui.

## Kaip jis pasiekia pigias, mastelio galimybės lygiagretumą

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

Nes planuotojas valdo goroutinės perjungimą naudotojo erdvėje (o ne branduolio lygio gijų perjungimuose), o goroutinės turi minimalias kaupas, jūs galite paleisti daug daugiau goroutinių nei OS gijos, pigiai.

## Pagrindiniai planuotojo elgesiai

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

**Darbo vagystė** palaikauja šerdis užimtas, **preempcija** nuo vienos goroutinės savininko šerdies, ir svarbiausia, kai goroutinė užsikemša (kanale ar syscall), planuotojas toliau valdo kitas goroutines užuot iš tiesų švaisčiau gijoje.

## GOMAXPROCS

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

## Kodėl goroutinės nėra nemokamos, bet

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

## Kodėl tai svarbu

Go planuotojas yra variklis stebėtino goroutinių pigumo ir mastelio – supratę jo **M:N modelį** (daugybė goroutinių ant mažo skaičiaus OS gijų per G-M-P dizainą), paaiškinsitės, *kodėl* Go gali paleisti milijonus goroutinių, kai OS gijos pasibaigia tūkstančiais, ir *kodėl* jo lygiagretumas toks efektyvus (naudotojo erdvės perjungimas vietoj brangių OS konteksto perjungimų, tikras lygiagretumas skersai šerdžių per GOMAXPROCS).

Smart blokavimo apdorojimas (kanalo blokuotų goroutinių pastatymas, P perdavimas syscall metu, kad gijos nebūtų iš tiesų švaisčiau), **darbo vagystė** apkrovų subalansavimui ir **preempcija** (nuo 1.14) bado nuo starvacijos yra tai, kas daro Go lygiagretumą tvirtu pagal realiųjų darbo krūvių.

Nors jūs retai tiesiogiai sąveikaujate su planuotoju, jo supratimas pagilina jūsų intuiciją goroutinės efektyvumui, paaiškina elgesį (kodėl blokavimas neiš tiesų švaisčiau gijom, kodėl jūs galite prikelti tiek daug goroutinių), ir praneša sprendimus, tokius kaip lygiagretumų apribojimas.

Tai išplėstinė tema, kuri parodo tikrą Go runtime žinių gylį ir yra vertinama iš aukšto lygio pokalbių.