Goランタイムの深層：Goroutineが「魔法のように」切り替わる仕組みを解剖する
こんにちは。開発環境の設計を専門にしている者です。
多くのエンジニアが「Goは並行処理が得意だ」と口にしますが、なぜ数百万ものGoroutineが、たった数個のOSスレッドの上で軽快に動けるのかを説明できる人は意外と少ないものです。
今日は、その「魔法」の正体であるコンテキストスイッチとレジスタの退避について、低レイヤの視点から紐解いていきましょう。この仕組みを理解すると、あなたのコードは「なんとなく動くもの」から「計算機リソースを自在に操るもの」へと進化します。
—
1. なぜ「OSスレッド」ではなく「Goroutine」なのか？
現代のOSにおけるコンテキストスイッチは高コストです。OSスレッドを切り替えるには、カーネルモードへの遷移、レジスタ一式のメモリへの退避、メモリ管理ユニット（MMU）の設定変更など、数千サイクルものCPUコストがかかります。
一方、Goのランタイム（`runtime`パッケージ）は、ユーザー空間で独自のスケジューラを回しています。OSに頼らず、自分たちでレジスタをメモリに退避し、別のGoroutineのスタックをロードする。これこそがGoの高速性の本質です。
—
2. アセンブリレベルでの「コンテキスト保存」：何が起きているのか
Goroutineが停止し、別のGoroutineに切り替わる際、Goのランタイムは内部で `gogo` や `gosave` といったアセンブリルーチンを呼び出します。
レジスタ退避の舞台裏
CPUの「レジスタ」は演算の心臓部です。ここには「今どこを実行しているか（PC：プログラムカウンタ）」や「スタックの底はどこか（SP：スタックポインタ）」が保持されています。
Goのランタイムは、Goroutineの構造体（`g`構造体）の中に、これらを保存するための領域を持っています。
// src/runtime/runtime2.go 内の g 構造体の一部（概念図）
type g struct {
stack stack // スタックの境界（どこからどこまでがこのGoroutineのメモリか）
sched gobuf // コンテキスト保存領域
// …
}
type gobuf struct {
sp uintptr // スタックポインタの退避先
pc uintptr // 次に実行すべき命令の退避先
ret uintptr // 戻り値
bp uintptr // ベースポインタ
}
切り替えの瞬間、ランタイムはこれらの値を現在稼働中のCPUレジスタからこの構造体へコピーします。OSから見れば「ただのメモリ操作」ですが、プログラムから見れば「別のタスクへの瞬間移動」です。
—
3. 実践：Goroutineの動きを可視化してみる
理論だけでは掴みにくいので、Goのランタイムの挙動を垣間見るシンプルなプログラムを書いてみましょう。
動作確認用コード：`main.go`
このコードは、Goroutineがどのようにスケジューラに預けられるかを意識するためのものです。
package main
import (
“fmt”
“runtime”
“sync”
)
func main() {
// ランタイムのCPU利用を1に制限し、明示的なスイッチを誘発させる
runtime.GOMAXPROCS(1)
var wg sync.WaitGroup
wg.Add(2)
for i := 0; i < 2; i++ { go func(id int) { defer wg.Done() for j := 0; j < 3; j++ { // ここで明示的にスレッドを譲る（コンテキストスイッチの発生） runtime.Gosched() fmt.Printf("Goroutine %d: カウント %d\n", id, j) } }(i) } wg.Wait() }
実行結果の読み解き
$ go run main.go
Goroutine 0: カウント 0
Goroutine 1: カウント 0
Goroutine 0: カウント 1
…
`runtime.Gosched()` を呼ぶたびに、現在のGoroutineは実行キューの末尾に回され、別のGoroutineがレジスタを乗っ取ります。裏側では、OSスレッドが「Goroutine Aのレジスタをメモリへ退避」→「Goroutine BのレジスタをCPUへロード」という作業を爆速で行っています。
—
4. なぜこの知識が「現場」で重要なのか？
「アセンブリなんて普段書かないから関係ない」と思っていませんか？ 違います。この挙動を知ることで、以下の設計判断ができるようになります。
1. スタックの深さを意識できる: GoのGoroutineは開始時に2KBのスタックを割り当てられますが、必要に応じて動的に拡張されます。再帰呼び出しを無限に行うと、この「スタック切り替え」のコストが無視できなくなります。
2. ブロッキング処理の恐怖: `runtime.Gosched()` やチャネルによる待機以外で、CPUを独占する重いループを書くと、ランタイムのスケジューラが効かなくなります。これが「システム全体の応答遅延」を招く原因です。
まとめ：効率的なエンジニアへの第一歩
Goroutineは、OSが提供する重厚な仕組みを、Goのランタイムが「軽量なデータ構造の付け替え」という神業に変換しているからこそ実現されています。
- PC/SPレジスタを構造体に退避・復元する。
- OSではなく、ランタイムが実行権を管理する。
この概念さえあれば、大規模な並行処理システムを設計する際、「今どこでコストがかかっているか」が手に取るように見えてくるはずです。
次は、Goのアセンブリ（`go tool compile -S`）を覗いて、実際にどの命令がレジスタを動かしているか確認してみましょう。その一歩が、あなたを「言語を使う人」から「言語を操る人」へと変えてくれるはずです。