როგორ მუშაობს Go runtime-ის scheduler?

Question

Accepted Answer

Go runtime-ი მოიცავს **scheduler**-ს, რომელიც ბევრი goroutine-ს ოპერაციულ სისტემის ცოტა რაოდენობის thread-ზე აერთიანებს. ეს **M:N scheduling** (M goroutine-ი N OS thread-ზე) არის ის, რაც goroutine-ებს ისე იაფს და Go-ს concurrency-ს ისე მასშტაბირებადს ხდის. მისი გაგება აგიხსნით goroutine-ის შესრულების ხარისხს.

## G-M-P მოდელი

```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-ი ბევრი goroutine-ს (G) აკავშირებს OS thread-ებთან (M) ლოგიკური processor-ების (P) მეშვეობით. თითო P არსებობს CPU ბირთვზე ნაგულისხმევად (`GOMAXPROCS`), თითოეული მათგანი სართავის ქვეშ ყოფს goroutine-ებ, რომლებიც სამუშაოდ მზად არიან.

## როგორ მიაღწევს იგი იაფ, მასშტაბირებად concurrency-ს

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

რადგან scheduler-ი goroutine-ის გადართვას ინფორმაციის სივრცეში მართავს (არა kernel-დონის thread-ის გადართვა), და goroutine-ებს პატარა stack-ები აქვთ, თქვენ ბევრი მეტი goroutine-ი შეგიძლიათ გაჩხეთ, ვიდრე OS thread-ი, იაფად.

## Scheduler-ის ძირითადი ქცევა

```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** ცენტრებს დაკავებულს ხავს, **preemption** ხელი არ შეშლის ერთ goroutine-ს ცენტრის ფლობაში, და მნიშვნელოვნად, როდესაც goroutine დაბლოკირდება (channel ან syscall-ზე), scheduler ყოველი სხვა goroutine-ი მუშაობით აგრძელებს thread-ის გაფლანგვის ნაცვლად.

## GOMAXPROCS

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

## რატომ არ არის goroutine-ები თავისუფალი, თუმცა

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

## რატომ აქვს მას მნიშვნელობა

Go scheduler-ი არის ძრავი goroutine-ების საოცარი იაფნობისა და მასშტაბირებადობის უკან — მის **M:N მოდელის** (ბევრი goroutine ცოტა OS thread-ზე G-M-P დიზაინის გზით) გაგება ხსნის *რატომ* შეუძლია Go-ს მილიონი goroutine-ის გაშვება, როდესაც OS thread-ები ათასების სახელმწიფოსთან დასრულდება, და *რატომ* არის მისი concurrency ისე ეფექტური (ინფორმაციის სივრცეში გადართვა ძვირადღირი OS კონტექსტის გადართვების ნაცვლად, ნამდვილი parallelism ცენტრებში GOMAXPROCS-ის გზით).

ბლოკირების ჭკვიანი მეთვალყურეობა (channel-დაბლოკირებული goroutine-ების საპარკავი, P-ის გადაცემა syscall-ზე, რათა thread-ი არ იქნას ფლანგი), **work stealing** დატვირთვის დაბალანსებისთვის, და **preemption** (1.14-დან) გაჭიანებისგან თავის დაღწევის მიზნით არის ის, რაც Go-ს concurrency-ს ძლიერს აქცევს რეალური დატვირთვის პირობებში.

სანამ თქვენ 드직접로 scheduler-ს არ ურთიერთქმედობთ, მისი გაგება თქვენი intuition-ი გაღრმავებთ goroutine-ის შესრულებისთვის, ხსნის ქცევებს (რატომ არ ხმელს ბლოკირება thread-ებს, რატომ შეგიძლიათ ამდენი goroutine-ი აიძრა) და ქვეშ გადაწყვეტილებებს, როგორიცაა concurrency-ის შეზღუდვა.

ეს არის მოწინავე თემა, რომელიც აჩვენებს Go runtime-ის ცოდნის ნამდვილ სიღრმეს და ფასდება უფროსი interviewer-ების მიერ.