Day 037 — GC・エスケープ解析の理解（実践: 隠れたヒープ割当のコードレビュー）

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

Day 036では、エスケープ解析の判定ルール（ポインタ返却・goroutine/クロージャへのキャプチャ・インターフェース代入など）を6つの単純な関数で学び、-gcflags="-m"の読み方を身につけました。しかし実務のコードは、こうした単純な関数のように「1つのエスケープパターン」だけを含んでいることは少ないです。複数のエスケープ要因が1つの関数の中に重なり合い、しかもそれが一見「普通のコード」に見えるのが実際のコードレビューの難しさです。

Day 037では、ある架空のHTTPリクエスト処理のホットパス（1リクエストごとに必ず通る計測・ログ出力コード）を題材に、5箇所の「隠れた無駄なヒープ割当」を発見し、修正します。ここで重要な視点が2つあります。

📝 問題

以下は、架空のWebサーバーで「リクエストを1件処理するたびに必ず呼ばれる」計測・ログ出力コードです。機能的には正しく動作しますが、パフォーマンスレビューで「ホットパスのアロケーションが多すぎる」と指摘されました。

📋 コピーpackage main

import (
	"fmt"
)

type RequestMetrics struct {
	Path   string
	Status int
	Count  int
}

// (1) 毎リクエストごとにメトリクスキーを文字列で組み立てる
func buildMetricKey(path string, status int) string {
	return fmt.Sprintf("%s:%d", path, status)
}

// (2) 呼び出し元は値のフィールドしか使わないのに、ポインタを返している
func newMetrics(path string, status int) *RequestMetrics {
	return &RequestMetrics{Path: path, Status: status, Count: 1}
}

var globalCounters = map[string]int{}

// (3) ホットパス本体: 1リクエストごとに必ず呼ばれる
func recordRequest(path string, status int) {
	key := buildMetricKey(path, status)
	m := newMetrics(path, status)
	globalCounters[key] += m.Count

	// (4) ログ出力に可変長引数（interface{}）を使っている
	logf("request handled: path=%v status=%v", path, status)
}

func logf(format string, args ...interface{}) {
	fmt.Printf(format+"\n", args...)
}

// (5) 複数のリクエストパスを非同期ワーカーで処理する起動コード
func startWorkers(paths []string) {
	for _, p := range paths {
		go func() {
			recordRequest(p, 200)
		}()
	}
}

func main() {
	startWorkers([]string{"/api/users", "/api/orders", "/api/health"})
}

要件

1. (1)〜(5)それぞれについて、「エスケープ解析の観点でヒープ割当が発生するか」「発生するなら理由は何か」を判定する。(5)はGo 1.22以降のループ変数セマンティクスを踏まえて判定すること
2. (1)〜(4)の中から、エスケープ解析とは異なる種類の割当コスト（エスケープ解析の対象ではない無駄）を1つ選び、なぜそれがエスケープ解析の話ではないのかを説明する
3. recordRequest・buildMetricKey・newMetricsを、外部から見た動作（globalCountersの更新結果とログ出力内容）を変えずに、ホットパスでの無駄なヒープ割当をできる限り減らす形に書き直す。go run main.goでそのまま動く完全なコードを提示すること
4. 修正前後の差をgo build -gcflags="-m"とgo test -bench . -benchmemでどう検証するか、具体的なコマンドと「何を見て改善を判断するか」を示す
5. このような「1リクエストあたりの微小な無駄なアロケーション」が、なぜ本番システムで軽視できない問題になるのかを、GCの動作特性（Day 036で学んだ内容）と結びつけて説明する

🔍 ヒント（段階的開示）

📋 コピーmkdir day037 && cd day037
go mod init example.com/day037
# main.go に修正前のコードを保存し、まず -m を当てて escapes 行を確認する
go build -gcflags="-m" . 2>&1 | grep -E "escapes|moved to heap"

# ベンチマークで実測する
cat <<'EOF' > main_test.go
package main

import "testing"

func BenchmarkRecordRequest(b *testing.B) {
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		recordRequest("/api/users", 200)
	}
}
EOF
go test -bench . -benchmem
# => BenchmarkRecordRequest-8   1000000   XXXX ns/op   YYY B/op   Z allocs/op

✅ 模範解答

1. (1)〜(5)の判定表

2. エスケープ解析とは異なる種類の割当コスト

(3)内のglobalCounters[key] += m.Countというマップへの書き込みが該当します。

これはエスケープ解析（変数がスタックかヒープかというコンパイル時の判定）の話ではなく、Goのマップ（ハッシュテーブル）実装が内部でバケット配列を動的に拡張する際のメモリ確保の話です。マップは要素数が増えて負荷率（load factor）が閾値を超えると、内部のバケット配列を新しく確保し直して既存要素を再配置します（リハッシュ）。これはmake(map[K]V, n)であらかじめ容量のヒントを与えてバケット数を事前確保しておくことで軽減できますが、-gcflags="-m"では検出できない種類のコストであり、-benchmemでアロケーション回数の実測、あるいはpprofのヒーププロファイルで初めて可視化できます。

3. 修正後の完全なコード

方針: (1)のキー生成をstrconv.Itoa+連結に変更、(2)を値返却に変更、(4)の可変長interface{}を排除、(5)のクロージャ暗黙キャプチャを明示的な引数渡しに変更。

📋 コピーpackage main

import (
	"fmt"
	"strconv"
)

type RequestMetrics struct {
	Path   string
	Status int
	Count  int
}

// (1)' キー生成: fmt.Sprintfの可変長引数ボクシングを避け、strconv.Itoaで
// 数値だけを文字列化してから明示的に連結する。
func buildMetricKey(path string, status int) string {
	return path + ":" + strconv.Itoa(status)
}

// (2)' 呼び出し元は値のフィールドしか使わないため、ポインタではなく値を返す。
// Day 036の(A)と同じ「戻り値は値のコピー」パターンにすることで、
// この関数単体で見ればRequestMetricsをヒープに逃がす理由がなくなる
// （呼び出し元がこの値をさらにポインタとして外部に渡さない限り）。
func newMetrics(path string, status int) RequestMetrics {
	return RequestMetrics{Path: path, Status: status, Count: 1}
}

var globalCounters = map[string]int{}

// (3)' ホットパス本体。フォーマット済み文字列を直接logfに渡すことで
// logf側の可変長interface{}ボクシングを回避する。
func recordRequest(path string, status int) {
	key := buildMetricKey(path, status)
	m := newMetrics(path, status)
	globalCounters[key] += m.Count

	// (4)' 可変長interface{}引数をやめ、呼び出し側でフォーマット済みの
	// 文字列を組み立ててから渡す。ホットパスの「毎回のログ出力経路」から
	// interface{}ボクシングを排除する。
	logf("request handled: path=" + path + " status=" + strconv.Itoa(status))
}

func logf(msg string) {
	fmt.Println(msg)
}

// (5)' クロージャの暗黙キャプチャをやめ、引数として値を明示的に渡す。
// Go 1.22以降ではpも1.21以前と同じ結果になるが、意図を明示することで
// レビュー時に「何がgoroutineに渡っているか」が一目でわかる。
func startWorkers(paths []string) {
	for _, p := range paths {
		go func(path string) {
			recordRequest(path, 200)
		}(p)
	}
}

func main() {
	startWorkers([]string{"/api/users", "/api/orders", "/api/health"})
}

補足: (2)'のように値を返すよう変えても、recordRequest内でmのアドレスをどこにも渡していない限り、m自体はスタックに留まる可能性が高くなります（ただしRequestMetricsはPath stringを含むため、文字列ヘッダー自体は別途ヒープ上のバイト列を指す点は変わりません。これは値のコピーが軽量であることと、文字列の中身がヒープにあることは別の話です）。

4. 修正前後の検証手順

エスケープの変化を見る:

📋 コピーgo build -gcflags="-m" . 2>&1 | grep -E "escapes|moved to heap|does not escape"

修正前はnewMetricsの&RequestMetrics{...}についてescapes to heapという行が出ますが、修正後（値を返す版）ではRequestMetrics{...}がdoes not escape（あるいは該当行が出ない＝インライン化されてスタック上で完結）に変わることを確認します。

アロケーション回数・量を実測する:

📋 コピー// main_test.go
package main

import "testing"

func BenchmarkRecordRequest(b *testing.B) {
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		recordRequest("/api/users", 200)
	}
}

📋 コピーgo test -bench BenchmarkRecordRequest -benchmem -count=3

見るべき指標:

• allocs/op（1回の呼び出しあたりのヒープ割当回数）が修正前より減っていること
• B/op（1回の呼び出しあたりの割当バイト数）が減っていること
• 修正前はfmt.Sprintfのボクシング分・logfの可変長引数分・newMetricsのポインタ分が積み重なりallocs/opが高くなるはずで、修正後はそれぞれが削減される（globalCountersへのマップ書き込み分のアロケーションは、Q2で述べた通りエスケープ解析とは別要因なので、この修正だけでは完全にはゼロにならない点に注意）

-count=3を付けて複数回実行し、ノイズによるばらつきがないかを確認するのがベンチマーク駆動最適化（Day 040で扱う予定）の基本作法です。

5. 微小なアロケーションが本番システムで軽視できない理由

Day 036で学んだ通り、Goの並行GC（concurrent mark-and-sweep）は「ヒープ上の生存オブジェクトをマーキングし、不要なものをスイープする」という処理を継続的に行います。1回あたりのアロケーションが小さくても、リクエストの処理頻度が高ければ「単位時間あたりのヒープ割当総量」は線形に増えます。ヒープ割当総量が増えると、GCがマーキング・スイープを行う頻度（GCサイクルの発生間隔）が短くなり、以下の複合的な影響が出ます。

1. GCがCPUリソースを奪い合う: Goの並行GCはアプリケーションのgoroutineと並行して動くが、完全にコストゼロではない。マーキング作業の一部はミューテータ（アプリケーションコード）自身が「アシスト」として肩代わりする仕組み（GC assist）があり、割当量が多いgoroutineほどこのアシストコストを多く支払わされる
2. STW（Stop-The-World）の頻度が増える: 各GCサイクルの開始・終了時には短いSTW区間がある。GCサイクル自体は短くても、頻度が上がればレイテンシのテール（p99, p999）に無視できない影響を与える
3. ヒープサイズの変動によるメモリフットプリント増加: GOGC（デフォルト100）は「直近のヒープ生存サイズの何%増えたら次のGCを走らせるか」を制御するが、割当が多いワークロードではヒープの目標サイズ自体が大きくなりやすく、コンテナのメモリ制限に対する余裕が減る

🪜 Step-by-Step 解説

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

🌐 他言語との比較

🏆 実務での使いどころ

• APIハンドラのミドルウェアレビュー: 全リクエストが通るロギング・メトリクス計測・認可チェックのようなミドルウェア層は、この問題と同じ構造の「隠れたアロケーション」が積み重なりやすい最重要レビュー対象
• 構造化ログ移行の判断材料: fmt.Sprintfベースの独自ログ関数からlog/slogへの移行を検討する際、「型付きAPIによるボクシング回避」という定量的な根拠を持って提案できる
• go vet/カスタムlinterへの組み込み: ホットパスと分かっている関数群に対して、fmt.Sprintfの使用や不要なポインタ返却を検出する社内linterルールを設計する際の基礎知識になる
• コードレビューでの指摘の型: 「このポインタ、呼び出し元でどこまで使われますか？値渡しで済みませんか？」という質問を機械的に投げかけられるようになる

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: day037のベンチマークコードにb.ReportAllocs()を付けて実測し、(1)〜(4)それぞれを個別に元のコードに戻した場合のallocs/opの増分を1つずつ切り分けて計測してみましょう。どの修正が最も効果的だったかを実測データで裏付けます
• 次回予告: pprofによるプロファイリング①（CPU） — Day 038では、Day 036・037で学んだ「静的な予測」から一歩進めて、実際に動いているプログラムのCPU使用状況をpprofで計測し、ホットパスを実測データから特定する方法を学びます

🎯 自己評価

自分の回答

気づき・メモ