Scheduler của Go runtime hoạt động như thế nào?

Question

Accepted Answer

Go runtime bao gồm một **scheduler** ghép nhiều goroutine lên một số nhỏ các OS thread. **Lập lịch M:N** này (M goroutine trên N OS thread) là thứ khiến goroutine rẻ đến vậy và concurrency của Go có khả năng mở rộng đến vậy. Hiểu nó giải thích hiệu năng goroutine.

## Mô hình G-M-P

```text
G (Goroutine) — tác vụ concurrent của bạn (nhẹ, stack ~2KB lúc đầu)
M (Machine)   — một OS thread (thread thực mà OS lập lịch)
P (Processor) — một bộ xử lý logic / ngữ cảnh lập lịch; giữ một hàng đợi các G có thể chạy
                (số lượng P = GOMAXPROCS, mặc định = số core CPU)

Scheduler chạy các G trên các M, được điều phối qua các P:
  Mỗi P có một hàng đợi chạy cục bộ các goroutine; một M phải giữ một P để chạy các G.
```

Runtime ánh xạ nhiều goroutine (G) lên các OS thread (M) qua các bộ xử lý logic (P). Có một P mỗi core CPU theo mặc định (`GOMAXPROCS`), mỗi cái có một hàng đợi các goroutine sẵn sàng chạy.

## Cách nó đạt được concurrency rẻ, có khả năng mở rộng

```text
✓ Tạo một goroutine thì rẻ (stack nhỏ xíu, do runtime quản lý) → khả thi hàng triệu
✓ Chuyển đổi goroutine xảy ra trong KHÔNG GIAN USER (runtime), không qua context
  switch tốn kém của OS → nhẹ hơn nhiều so với chuyển đổi OS thread
✓ Với P = số core CPU, Go chạy goroutine thực sự song song trên các core
```

Vì scheduler xử lý việc chuyển đổi goroutine trong không gian user (không phải chuyển đổi thread cấp kernel), và goroutine có stack nhỏ xíu, bạn có thể chạy nhiều goroutine hơn OS thread rất nhiều, một cách rẻ.

## Các hành vi scheduler then chốt

```text
✓ Work stealing — một P rảnh ĐÁNH CẮP goroutine từ hàng đợi của một P bận → cân bằng tải
✓ Cooperative + preemptive — goroutine nhường tại các lời gọi hàm/thao tác channel/blocking;
  từ Go 1.14, scheduler cũng có thể CHIẾM QUYỀN (preempt) các goroutine chạy lâu (không starvation)
✓ Blocking được xử lý khôn ngoan:
   - Một goroutine bị chặn trên một CHANNEL/sync → park lại, M chạy goroutine khác (không lãng phí thread)
   - Một goroutine bị chặn trên một SYSCALL (ví dụ file I/O) → M chặn, nhưng P được
     bàn giao cho một M KHÁC để các goroutine khác tiếp tục chạy
```

**Work stealing** giữ các core bận rộn, **preemption** ngăn một goroutine chiếm dụng một core, và quan trọng nhất, khi một goroutine bị chặn (trên một channel hoặc syscall), scheduler giữ các goroutine khác chạy thay vì lãng phí thread.

## GOMAXPROCS

```go
runtime.GOMAXPROCS(4)    // giới hạn 4 OS thread chạy code Go đồng thời
// mặc định = số core CPU; hiếm khi cần thay đổi
```

## Vì sao goroutine không phải miễn phí

```text
Goroutine rẻ nhưng không phải chi phí bằng không — hàng triệu vẫn dùng bộ nhớ, và quá nhiều
goroutine thêm overhead lập lịch. Giới hạn concurrency (worker pool) cho các tải nặng.
```

## Tại sao điều này quan trọng

Scheduler của Go là động cơ đằng sau sự rẻ và khả năng mở rộng đáng kinh ngạc của goroutine — hiểu **mô hình M:N** của nó (nhiều goroutine trên ít OS thread qua thiết kế G-M-P) giải thích *vì sao* Go có thể chạy hàng triệu goroutine khi OS thread cạn ở hàng nghìn, và *vì sao* concurrency của nó hiệu quả đến vậy (chuyển đổi trong không gian user thay vì context switch OS tốn kém, song song thực sự qua các core nhờ GOMAXPROCS).

Việc xử lý blocking khôn ngoan (park các goroutine bị chặn trên channel, bàn giao P khi syscall để thread không bị lãng phí), **work stealing** để cân bằng tải, và **preemption** (từ 1.14) để ngăn starvation là những thứ khiến concurrency của Go vững chắc dưới các tải thực.

Mặc dù bạn hiếm khi tương tác trực tiếp với scheduler, hiểu nó làm sâu sắc trực giác của bạn về hiệu năng goroutine, giải thích các hành vi (vì sao blocking không lãng phí thread, vì sao bạn có thể sinh ra nhiều goroutine đến vậy), và định hình các quyết định như giới hạn concurrency.

Đây là một chủ đề nâng cao thể hiện chiều sâu thực sự về kiến thức Go runtime và được đánh giá cao trong các buổi phỏng vấn senior.