Go ランタイムのスケジューラはどのように動作しますか?

Question

Accepted Answer

Go ランタイムには、多数のゴルーチンを少数の OS スレッドに多重化する**スケジューラ**が含まれています。この**M:N スケジューリング**（M 個のゴルーチンを N 個の OS スレッド上で実行）により、ゴルーチンが非常に軽量で、Go の並行処理が拡張性に優れています。これを理解することで、ゴルーチンのパフォーマンスを説明できます。

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

ランタイムは、多数のゴルーチン（G）を OS スレッド（M）にロジカルプロセッサ（P）経由でマップします。デフォルトでは CPU コアごとに 1 つの P があり（`GOMAXPROCS`）、各 P は実行可能なゴルーチンのキューを持ちます。

## 安価でスケーラブルな並行処理を実現する方法

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

スケジューラはゴルーチンの切り替えをユーザー空間で処理し（カーネルレベルのスレッド切り替えではなく）、ゴルーチンのスタックが非常に小さいため、OS スレッドよりもはるかに多くのゴルーチンを安価に実行できます。

## スケジューラの重要な動作

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

**ワークスティーリング**がコアをビジー状態に保ち、**プリエンプション**は 1 つのゴルーチンがコアを独占するのを防ぎ、そして重要なことに、ゴルーチンがブロック（チャネルまたはシステムコールで）したとき、スケジューラはスレッドを無駄にするのではなく、他のゴルーチンを実行し続けます。

## GOMAXPROCS

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

## ゴルーチンが無料ではない理由

```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 スケジューラは、ゴルーチンの優れた軽量性と拡張性を支える中核的なエンジンです。その**M:N モデル**（G-M-P 設計を経由した少数の OS スレッド上での多数のゴルーチン）を理解することで、Go がなぜ OS スレッドが数千で限界を迎える中でも数百万のゴルーチンを実行できるのか、そしてその並行処理がなぜ非常に効率的なのか（コストのかかる OS コンテキストスイッチではなくユーザー空間での切り替え、GOMAXPROCS 経由でのコア全体での真の並列処理）を説明できます。

ブロッキングの賢い処理（チャネルでブロックされたゴルーチンの駐車、スレッドを無駄にしないようにシステムコール時に P をハンドオフ）、負荷分散のための**ワークスティーリング**、そして飢餓状態を防ぐための**プリエンプション**（1.14 以降）が、Go の並行処理を実際のワークロード下で堅牢にしています。

スケジューラと直接やり取りすることはまれですが、それを理解することでゴルーチンのパフォーマンスに対する直感が深まり、動作を説明し（ブロッキングがスレッドを無駄にしない理由、多くのゴルーチンをスポーンできる理由）、並行性を制限するなどの決定に情報を与えます。

Go ランタイムの本当の深い知識を示す高度なトピックであり、シニアレベルのインタビューで価値があります。