Day 036 — GC・エスケープ解析の理解

📚 背景知識（読んでから問題へ）

Day 035ではhappens-before関係という「可視性」の軸を学びました。Day 036ではGoランタイムのもう1つの重要な軸——ある変数がスタックに置かれるかヒープに置かれるか——を扱います。

Goにはnewや&T{}のような明示的な「ヒープ確保」構文がなく、Java/Pythonのように「オブジェクトは常にヒープ」でもありません。代わりにGoコンパイラはエスケープ解析（escape analysis）という静的解析を行い、「その変数への参照が、それを生成した関数のスコープを超えて生き残る可能性があるか」をコンパイル時に判定します。生き残る可能性がなければスタックに、可能性があれば（関数の戻り値として返される、goroutineに渡される、インターフェースに格納される、ポインタが外部に漏れる、など）ヒープに配置されます。これが「エスケープする（escape to heap）」という言葉の意味です。

なぜこの区別が重要なのでしょうか。スタック割当はGCの管理対象外であり、関数のリターンとともに自動的に解放されます。一方ヒープ割当はGC（ガベージコレクタ）の管理対象となり、生存確認（マーキング）・回収（スイープ）のコストがかかります。Goの並行GC（concurrent mark-and-sweep）は優秀ですが、それでも「ヒープに何も置かない」ことに勝る最適化はありません。ホットパス（高頻度に呼ばれる関数）で不要なヒープ割当が起きていると、GC負荷が増大し、STW（Stop-The-World、GCが全goroutineを一時停止させる区間）の頻度・レイテンシへの間接的な影響が無視できなくなります。

「ポインタを返せばヒープに乗る」という単純な理解では不十分で、値レシーバでもクロージャに捕捉されればエスケープしますし、逆にポインタを返しても関数がinline化されれば呼び出し元のスタックで完結することもあります。Day 036では、この「コンパイラの判断ルール」を正確に理解し、-gcflags="-m"の出力を読めるようになることを目標にします。

📝 問題

以下の6つの関数について、それぞれ後述の要件に答えてください。

📋 コピーpackage main

import "fmt"

// (A)
func makeIntLocal() int {
	x := 42
	return x
}

// (B)
func makeIntPointer() *int {
	x := 42
	return &x
}

// (C)
func makeSliceSmall() []int {
	s := make([]int, 3)
	s[0] = 1
	return s
}

// (D)
type Counter struct {
	n int
}

func (c *Counter) Inc() {
	c.n++
}

func useCounterLocal() int {
	c := Counter{}
	c.Inc()
	c.Inc()
	return c.n
}

// (E)
func startWorker() {
	x := 100
	go func() {
		fmt.Println(x)
	}()
}

// (F)
type Stringer interface {
	String() string
}

type MyInt int

func (m MyInt) String() string {
	return fmt.Sprintf("%d", int(m))
}

func useAsInterface() Stringer {
	var m MyInt = 7
	return m
}

要件

1. (A)〜(F) それぞれについて、変数（x, s, c, mなど主要なローカル変数）がスタックに置かれるか、ヒープにエスケープするかを判定し、その理由を説明する
2. (B)は「ポインタを返しているのでヒープに確保される」と考えがちだが、それが常に正しいとは限らない。この判断がどのような条件に依存するかを、Goのエスケープ解析の原則から説明する
3. (F)がエスケープする理由を、「インターフェース型への代入」という観点から説明する。値型（MyIntという小さい整数型）であってもエスケープするのはなぜか
4. go build -gcflags="-m"（または-gcflags="-m -m"でより詳細）を使って(A)〜(F)を実際に検証する手順を示し、期待される出力例を示す
5. ホットパスで不要なヒープ割当を避けるための実践的なコーディング指針を3つ挙げる

🔍 ヒント（段階的開示）

./main.go:8:2: moved to heap: x
./main.go:14:9: &x escapes to heap

📋 コピーmkdir day036 && cd day036
go mod init example.com/day036
# main.go に問題のコードを保存

go build -gcflags="-m" ./... 2>&1 | grep -E "escapes|moved to heap|inlin"

✅ 模範解答

1. 判定表

2. (B)が「常にヒープ」とは限らない理由

エスケープ解析の判断基準は「ポインタか値か」ではなく、「参照がコンパイラの追跡可能な範囲を超えて生存するか」です。

• return &xの呼び出し元が同じコンパイル単位内にあり、コンパイラがそのポインタの使われ方全体を解析できる場合、インライン化（inlining）によってmakeIntPointerの呼び出し自体が呼び出し元のコードに展開されることがある。インライン化された結果、&xが事実上「呼び出し元の中のローカル変数のアドレス」に等価変換されれば、外部への漏洩が起きず、スタックに留まる可能性がある
• 逆に、関数が大きすぎてインライン化されない、呼び出し元が動的ディスパッチ経由（インターフェース越しの呼び出しなど）でこの関数を呼ぶ、あるいは戻り値のポインタが構造体のフィールドやグローバル変数に代入される場合は、確実にヒープへエスケープする

つまり「ポインタを返す関数は必ずヒープ」という理解は、インライン化が起きない典型的なケースでは正しいことが多いが、コンパイラの最適化能力に依存する経験則にすぎません。正確な判断は-gcflags="-m"の出力を見るしかありません。

3. (F)がエスケープする理由（インターフェース代入の観点）

Goのインターフェース値は、内部的に2ワード構造（itabまたは型情報へのポインタ＋データへのポインタ）で表現されます。MyIntのような小さい値型であっても、インターフェースに代入される際には動的な型情報とともに扱えるようにデータ部分がポインタ経由で参照可能な形に変換される必要があります。

これは、インターフェース値がその後どのように使われるか（例えばStringer型のスライスに格納される、別の関数に渡される、interface{}として長期間保持される等）をコンパイラが静的に追跡しきれないためです。値型であっても、「動的型情報を伴う抽象化」という性質上、インターフェースへの代入はエスケープの典型的なトリガーになります。

ただし、Go 1.9以降で導入されたmid-stack inliningや、特定のコンパイラバージョンでの最適化（小さい定数値のインターフェース変換の特別扱いなど）により、単純なケースでは回避されることもあります。これも「必ずエスケープする」という断定ではなく、-gcflags="-m"で実際に確認すべき事項です。

4. -gcflags="-m"による検証手順

ファイル構成: day036/go.mod + day036/main.go

📋 コピー// go.mod
module example.com/day036

go 1.22

main.goは問題文の(A)〜(F)のコード一式をそのまま配置します。検証コマンドは以下の通りです。

📋 コピーgo build -gcflags="-m" ./... 2>&1

期待される出力例（バージョンにより多少の差異あり）:

./main.go:7:6: can inline makeIntLocal
./main.go:8:2: x escapes to heap        # ※実際にはinline化状況により変化する
./main.go:13:6: can inline makeIntPointer
./main.go:15:9: &x escapes to heap
./main.go:14:2: moved to heap: x
./main.go:20:6: can inline makeSliceSmall
./main.go:21:11: make([]int, 3) escapes to heap
./main.go:35:6: can inline useCounterLocal
./main.go:36:2: c does not escape       # ← ポインタレシーバでもエスケープしない好例
./main.go:44:6: can inline startWorker
./main.go:46:2: moved to heap: x        # ← goroutineキャプチャによるエスケープ
./main.go:47:15: x escapes to heap
./main.go:63:6: can inline useAsInterface
./main.go:65:9: m escapes to heap       # ← インターフェース代入によるエスケープ

-mを-m -mにすると、なぜその判断に至ったかのより詳細な理由が追加で出力されます。確認のポイント: X does not escapeという行が出れば、コンパイラがそのケースをスタック配置と判断したことを意味します。(D)のc does not escapeが最も直感に反しやすく、重要な学びになります。

5. ホットパスで不要なヒープ割当を避ける実践的指針

1. 不要なポインタ返却・インターフェース経由の抽象化を避ける: ホットパスの内部処理では、汎用性より局所性を優先し、具象型の値渡しで完結できないか検討する。fmt.Sprintfやinterface{}を挟む処理はエスケープの典型的な発生源になるため、頻度の高い箇所では避ける
2. goroutine・クロージャへのキャプチャを最小限にする: go func(){ ... }()で外部変数を大量にキャプチャすると、それらすべてがヒープにエスケープする。必要な値だけを引数として明示的に渡す（go func(x int){ ... }(x)）ことで、キャプチャ対象を絞り込める
3. -gcflags="-m"とベンチマーク（go test -bench . -benchmem）を組み合わせて計測してから最適化する: エスケープ解析の結果は推測ではなく実際に確認する。-benchmemのallocs/opが高い箇所を特定し、そこだけピンポイントで-gcflags="-m"を当てて原因のエスケープ箇所を特定するのが効率的。推測だけで「これはヒープに乗っているはず」と決めつけて過剰にコードを歪めるのは避ける（Day 037以降のpprofによる計測駆動最適化にもつながる考え方）

🪜 Step-by-Step 解説

💡 設計思想・なぜこう書くのか

🌐 他言語との比較

🏆 実務での使いどころ

• ホットパスのGC負荷削減: 高頻度に呼ばれるAPIハンドラやループ内で-benchmemのallocs/opが高い場合、-gcflags="-m"で該当箇所のエスケープ原因を特定し、インターフェース経由の抽象化やクロージャキャプチャを見直す
• sync.Poolの適用判断: エスケープが避けられずヒープ割当が頻発する構造体（一時的なバッファなど）に対して、sync.Poolによるオブジェクト再利用を検討する際の前提知識になる（Phase 2のDay 015、Phase 4での応用につながる）
• コードレビューでの「隠れたアロケーション」の指摘: interface{}を多用するAPI設計や、ログ出力で毎回fmt.Sprintfを呼ぶコードなど、一見軽量に見えて実はエスケープを誘発しているパターンをレビューで指摘できるようになる
• ライブラリ設計時のAPI選択: 値レシーバ・ポインタレシーバのどちらを使うか、戻り値をポインタにするか値にするかという設計判断において、「呼び出し側での使われ方次第でエスケープの有無が変わる」ことを踏まえた慎重な設計ができる

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: 実際にday036のコードをgo build -gcflags="-m -m"でビルドし、(A)〜(F)の詳細な理由の文言を読み比べてみましょう。特に(D)のc does not escapeがどのように導かれるかの理由を確認します
• 次回予告: pprofによるプロファイリング①（CPU） — Day 037では、Day 036で学んだ「静的な予測」から一歩進めて、実際に動いているプログラムのCPU使用状況をpprofで計測し、ホットパスを実測データから特定する方法を学びます

🎯 自己評価

自分の回答

気づき・メモ