Go runtime scheduler ทำงานอย่างไร?

Question

Accepted Answer

Go runtime มี **scheduler** ที่ multiplex goroutine จำนวนมากลงบน OS thread จำนวนน้อย การทำ **M:N scheduling** (M goroutine บน N OS thread) นี้คือสิ่งที่ทำให้ goroutine มีต้นทุนต่ำมากและ concurrency ของ Go ขยายขนาดได้ การเข้าใจมันอธิบายประสิทธิภาพของ 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) ผ่าน logical processor (P) โดยค่าเริ่มต้นมี P หนึ่งตัวต่อ CPU core (`GOMAXPROCS`) แต่ละตัวมี queue ของ 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 ใน user space (ไม่ใช่การสลับ thread ระดับ kernel) และ 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** ทำให้ core ยุ่งอยู่เสมอ **preemption** ป้องกันไม่ให้ goroutine ตัวเดียวยึด core ไว้ และที่สำคัญ เมื่อ goroutine block (บน 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 ของมันจึงมีประสิทธิภาพมาก (การสลับใน user space แทนการสลับ context ของ OS ที่มีต้นทุนสูง, ความเป็น parallel ที่แท้จริงข้าม core ผ่าน GOMAXPROCS)

การจัดการ block อย่างชาญฉลาด (การ park goroutine ที่ block บน channel, การส่งต่อ P เมื่อเกิด syscall เพื่อไม่ให้ thread เสียเปล่า), **work stealing** สำหรับการ load balancing และ **preemption** (ตั้งแต่ 1.14) เพื่อป้องกัน starvation คือสิ่งที่ทำให้ concurrency ของ Go แข็งแกร่งภายใต้ภาระงานจริง

แม้คุณจะแทบไม่ได้โต้ตอบกับ scheduler โดยตรง แต่การเข้าใจมันช่วยเพิ่มสัญชาตญาณเกี่ยวกับประสิทธิภาพของ goroutine อธิบายพฤติกรรม (ทำไมการ block ไม่ทำให้ thread เสียเปล่า, ทำไมคุณจึงสร้าง goroutine ได้มากมาย) และช่วยในการตัดสินใจ เช่น การจำกัดขอบเขต concurrency

มันเป็นหัวข้อขั้นสูงที่แสดงถึงความเข้าใจ Go runtime อย่างลึกซึ้งจริง ๆ และมีคุณค่าในการสัมภาษณ์ระดับ senior