Day 040 — pprofによるプロファイリング②（メモリ）（実践: スライス共有によるメモリリークのコードレビュー）

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

Day 039では「文字列連結によるアロケーション過多（alloc_spaceがn²オーダーで膨らむが、inuse_spaceは小さい）」という、メモリリークではないが遅いパターンを扱いました。今回は逆に、inuse_spaceが実行時間とともに増え続ける、正真正銘のメモリリークをヒーププロファイルからどう読み解くかを扱います。

Goにはガベージコレクタがあるため、「メモリリーク」はC/C++のようにポインタの解放忘れでは起きません。Goでのメモリリークの典型パターンは、「本当はもう不要なデータへの参照を、どこかがまだ持ち続けている」ことです。GCは「参照されているかどうか」だけを見て回収を判断するため、開発者から見て「使い終わった」つもりのデータでも、コード上のどこかから辿れる限り回収されません。

📝 問題

以下は、外部から届く1MBの生ログ行（raw）から、決まった位置に埋め込まれたセッションID（16バイト）を取り出し、リクエストIDをキーにしてキャッシュに保存するコードです。機能テストは通り、sessionCacheに保存されている論理的なデータ量は「セッションID 16バイト × リクエスト数」のはずですが、本番投入後、サーバーのメモリ使用量（RSS）がリクエスト数に比例してほぼ青天井に増え続け、最終的にOOM Killerに落とされる障害が発生しました。

📋 コピーpackage main

import (
	"fmt"
)

const rawSize = 1 << 20 // 1MB: 外部システムから届く生ログ行を想定

// sessionCache はリクエストIDをキーにセッションIDを保持するグローバルキャッシュ。
// サーバー起動中ずっと保持され続ける想定。
var sessionCache = make(map[int][]byte)

// generateRawLine は「外部から届いた1MBの生ログ行」を模擬する。
// 先頭100〜116バイト目にセッションIDが埋め込まれている。
func generateRawLine(id byte) []byte {
	raw := make([]byte, rawSize)
	for i := 100; i < 116; i++ {
		raw[i] = id
	}
	return raw
}

// extractSessionID は生ログ行からセッションID部分（16バイト）を取り出す。
func extractSessionID(raw []byte) []byte {
	return raw[100:116]
}

// handleRequest は1件のリクエストを処理し、セッションIDをキャッシュに保存する。
func handleRequest(reqID int) {
	raw := generateRawLine(byte(reqID))
	sessionCache[reqID] = extractSessionID(raw)
}

func main() {
	for i := 0; i < 2000; i++ {
		handleRequest(i)
	}
	fmt.Println("キャッシュ件数:", len(sessionCache))
	fmt.Println("論理的なデータ量の見積もり:", len(sessionCache)*16, "byte")
}

要件

1. このプログラムをruntime.ReadMemStatsで計測した場合、HeapAllocは「キャッシュ件数 × 16バイト」に近い値になるか、それともリクエスト数 × 1MBに近い値になるか、スライスのヘッダー構造（ポインタ・長さ・容量）の観点から理由とともに説明する
2. go tool pprof -top -inuse_spaceでこのプログラムのヒーププロファイルを取った場合、上位に表示されるはずの関数名を、コードの構造から予測する（extractSessionIDではなく別の関数が出るはずである。それはなぜか）
3. extractSessionIDを、巨大なrawのバッキング配列への参照を断ち切る形に書き直す（go run main.goでそのまま動く完全なコードを提示すること）
4. 修正前後でruntime.ReadMemStatsのHeapAllocがどう変化すると予測されるか、実際に計測して比較するための完全なmain関数（runtime.GC()を挟んだ前後比較）を示す
5. string(raw[100:116])のようにバイトスライスを文字列に変換してから保存する場合、今回のリークは自動的に解消されるか。Goの「[]byteからstringへの変換」の仕様に基づいて説明する

🔍 ヒント（段階的開示）

📋 コピーfunc extractSessionID(raw []byte) []byte {
	id := make([]byte, 16)
	copy(id, raw[100:116])
	return id
}

✅ 模範解答

📋 コピーpackage main

import (
	"fmt"
	"runtime"
)

const rawSize = 1 << 20 // 1MB: 外部システムから届く生ログ行を想定

// generateRawLine は「外部から届いた1MBの生ログ行」を模擬する。
// 先頭100〜116バイト目にセッションIDが埋め込まれている。
func generateRawLine(id byte) []byte {
	raw := make([]byte, rawSize)
	for i := 100; i < 116; i++ {
		raw[i] = id
	}
	return raw
}

// extractSessionIDLeaky はバグ版。raw と同じバッキング配列を指すヘッダーを返すだけなので、
// 戻り値がどこかに保存され続ける限り、raw の1MB配列全体がGCから回収されない。
func extractSessionIDLeaky(raw []byte) []byte {
	return raw[100:116]
}

// extractSessionIDFixed は修正版。必要な16バイトだけを新しい配列にコピーして返す。
// raw への参照を一切保持しないため、raw はこの関数から抜けた時点でGC対象になり得る。
func extractSessionIDFixed(raw []byte) []byte {
	id := make([]byte, 16)
	copy(id, raw[100:116])
	return id
}

func heapAllocMB() float64 {
	runtime.GC() // 直近のゴミを回収してから測定し、inuse相当の値に近づける
	var m runtime.MemStats
	runtime.ReadMemStats(&m)
	return float64(m.HeapAlloc) / 1024 / 1024
}

func runScenario(name string, extract func([]byte) []byte, n int) {
	cache := make(map[int][]byte)
	before := heapAllocMB()
	for i := 0; i < n; i++ {
		raw := generateRawLine(byte(i))
		cache[i] = extract(raw)
	}
	after := heapAllocMB()
	fmt.Printf("[%s] リクエスト数=%d, 開始時HeapAlloc=%.2fMB, 終了時HeapAlloc=%.2fMB (差分=%.2fMB)\n",
		name, n, before, after, after-before)
	fmt.Printf("[%s] 論理的なデータ量の見積もり: %d byte (%.4fMB)\n",
		name, len(cache)*16, float64(len(cache)*16)/1024/1024)
	_ = cache // cacheがGC対象にならないよう関数末尾まで生存させる
}

func main() {
	const n = 2000

	fmt.Println("=== バグ版: extractSessionIDLeaky ===")
	runScenario("leaky", extractSessionIDLeaky, n)

	runtime.GC()
	fmt.Println()

	fmt.Println("=== 修正版: extractSessionIDFixed ===")
	runScenario("fixed", extractSessionIDFixed, n)
}

実行結果の傾向（環境依存だが、差は数百倍のオーダーになるはずである）:

📋 コピー=== バグ版: extractSessionIDLeaky ===
[leaky] リクエスト数=2000, 開始時HeapAlloc=0.35MB, 終了時HeapAlloc=1953.61MB (差分=1953.26MB)
[leaky] 論理的なデータ量の見積もり: 32000 byte (0.0305MB)

=== 修正版: extractSessionIDFixed ===
[fixed] リクエスト数=2000, 開始時HeapAlloc=0.38MB, 終了時HeapAlloc=0.42MB (差分=0.04MB)
[fixed] 論理的なデータ量の見積もり: 32000 byte (0.0305MB)

🪜 Step-by-Step 解説

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

🌐 他言語との比較

🏆 実務での使いどころ

• APIゲートウェイ・プロキシでのヘッダー/トークン抽出: リクエストボディやヘッダーの巨大なバイト列から、一部（トークン・IDなど）だけを抜き出してログやキャッシュに保存する処理は、本問と全く同じパターンでリークしやすい典型例
• ログ収集・パーサーの実装: 1行が長いログ（JSON全体など）から、特定のフィールドだけを抽出して後段の集計処理に渡す場合、抽出結果を[]byteのまま長期保持するコードは要注意
• メモリリーク調査の初手としてのヒーププロファイル比較: 「RSSが右肩上がりに増え続ける」障害調査では、時間を空けて2回inuse_spaceのヒーププロファイルを取得し、topの上位関数を比較する。増加分のtopに見覚えのない・意図しない巨大アロケーション関数が出てきたら、その戻り値がどこかに長期保存されていないかを疑う
• bytes.Clone（Go 1.20+）の活用: 標準ライブラリにbytes.Cloneが追加されたのは、まさに本問のような「独立したコピーが欲しい」というニーズが頻出するため。make+copyを毎回書く代わりにbytes.Clone(raw[100:116])と書ける

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: sessionCacheにTTL（有効期限）付きのエビクション機構を追加し、「そもそも無期限に保持し続けるキャッシュ設計」自体の妥当性も見直してみましょう。今回はスライス共有が主因でしたが、無制限キャッシュ自体も別種のメモリ増大要因になり得ます
• 次回予告: ベンチマーク駆動最適化 — Day 038（CPU）・Day 039（アロケーション過多）・Day 040（スライス共有リーク）で学んだ3種類のプロファイリング観点を組み合わせ、Before/Afterを定量的に比較しながら最適化を進める一連のワークフローを扱います

🎯 自己評価

自分の回答

気づき・メモ