Day 015 — sync.Once, sync.Pool

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

Day 013-014でsync.Mutex/sync.RWMutexを使った「共有状態の排他制御」を学びました。今回学ぶsync.Onceとsync.Poolは、どちらもsyncパッケージの一部ですが、Mutexとは違い「排他制御そのもの」が目的ではありません。それぞれ特定の並行処理シナリオに特化した道具です。

sync.Once: 「初期化処理を、何回呼ばれても・何個のgoroutineから同時に呼ばれても、必ず1回だけ実行する」ためのプリミティブです。典型的には、シングルトンの生成・設定ファイルの読み込み・コネクションプールの初期化など、「アプリケーション全体で1度だけ行いたい重い処理」に使います。素朴にやるならif initialized { return }のようなフラグチェックとMutexを組み合わせて自前実装できますが、これは典型的なチェック・アンド・セットの競合バグ（2つのgoroutineが同時にif !initializedを通過してしまう）を生みやすい定番の落とし穴です。sync.OnceはこれをDo(f func())という1メソッドのAPIに抽象化し、内部でメモリバリア（happens-before関係）まで正しく保証してくれます。

sync.Pool: 「一時的に使ってすぐ不要になるオブジェクトを、使い回すためのプール」です。Goのガベージコレクタ（GC）は自動でメモリを回収してくれますが、アロケーション（メモリ確保）自体にコストがかかるうえ、GCが回収すべきオブジェクトが増えるほどGCの負荷（スキャン時間）も増えます。特にHTTPハンドラのように「同じ型のバッファを高頻度で確保しては捨てる」処理では、sync.Poolでオブジェクトを再利用することでアロケーション回数とGC負荷を大きく減らせます。ただしsync.Poolはキャッシュであってキャッシュ以上の保証はしません。GCが発生するとプール内のオブジェクトは予告なく破棄されることがあり、「プールに入れたものが必ず取り出せる」という前提のコードを書くのは誤りです。

Go言語の設計思想として、「並行処理に関するよくある落とし穴（初期化の二重実行・不要なアロケーション）を、開発者が自前でMutexを組み合わせて再発明するのではなく、標準ライブラリの正しく検証されたプリミティブに任せる」という考え方が徹底されています。sync.Onceもsync.Poolも内部的にはsync.Mutexやアトミック操作を使って実装されていますが、利用者はその詳細を意識せず、意図が明確な1つのメソッド呼び出し（Do・Get・Put）で正しい並行処理を実現できます。

📝 問題

以下の2つの機能を持つ、go run main.goでそのまま実行できる1つのGoプログラムを実装してください。

要件（共通）:

1. go run main.goで正常終了し、go run -race main.goでdata raceが検出されないこと
2. sync.Onceの初期化ログが正確に1回だけ出力されることをプログラムの出力で確認できること
3. コードにはpackage main・importを省略せず、そのまま実行できる完全な1ファイルとして提出すること

🔍 ヒント（段階的開示）

📋 コピーpackage main

import (
	"fmt"
	"sync"
)

type Config struct {
	APIKey string
}

var (
	once   sync.Once
	config *Config
)

func GetConfig() *Config {
	once.Do(func() {
		fmt.Println("Config initializing...")
		// TODO: config に値を設定する
	})
	return config
}

var bufPool = sync.Pool{
	New: func() any {
		// TODO: 新規バッファを返す
		return nil
	},
}

func processWithPooledBuffer(data string) string {
	buf := bufPool.Get().([]byte)
	defer func() {
		// TODO: リセットしてからPutする
		bufPool.Put(buf)
	}()
	// TODO: buf に data を書き込んで文字列として返す
	return ""
}

func main() {
	var wg sync.WaitGroup
	for i := 0; i < 10; i++ {
		wg.Add(1)
		go func(n int) {
			defer wg.Done()
			cfg := GetConfig()
			_ = cfg
		}(i)
	}
	wg.Wait()

	// TODO: sync.Pool の並行呼び出し検証
}

✅ 模範解答

📋 コピーpackage main

import (
	"fmt"
	"sync"
	"time"
)

// ── sync.Once によるシングルトン設定の初期化 ──

type Config struct {
	APIKey   string
	LoadedAt time.Time
}

var (
	once   sync.Once
	config *Config
)

// GetConfig は何度・何個のgoroutineから同時に呼ばれても、
// 内部の初期化処理を正確に1回だけ実行して同じ *Config を返す。
func GetConfig() *Config {
	once.Do(func() {
		fmt.Println("Config initializing...")
		// 実際にはここでファイル読み込みや環境変数の解析などの重い処理を行う想定。
		config = &Config{
			APIKey:   "dummy-api-key",
			LoadedAt: time.Now(),
		}
	})
	return config
}

// ── sync.Pool によるバッファの再利用 ──

var bufPool = sync.Pool{
	New: func() any {
		// プールが空のときだけ新規に確保される。
		return make([]byte, 0, 1024)
	},
}

// processWithPooledBuffer はプールからバッファを借り、dataを書き込んで
// 文字列化した結果を返す。使い終わったバッファは中身をクリアしてから返却する。
func processWithPooledBuffer(data string) string {
	buf := bufPool.Get().([]byte)
	defer func() {
		buf = buf[:0] // 長さだけ0にリセットし、確保済みの容量は保持したまま返却する
		bufPool.Put(buf)
	}()

	buf = append(buf, "processed: "...)
	buf = append(buf, data...)
	return string(buf)
}

func main() {
	// --- 要件1の検証: sync.Once は複数goroutineからでも1回だけ実行される ---
	var wg sync.WaitGroup
	results := make([]*Config, 10)
	for i := 0; i < 10; i++ {
		wg.Add(1)
		go func(n int) {
			defer wg.Done()
			results[n] = GetConfig()
		}(i)
	}
	wg.Wait()

	// 全goroutineが同じ *Config インスタンス（同じポインタ）を受け取っているか確認する。
	first := results[0]
	allSame := true
	for _, c := range results {
		if c != first {
			allSame = false
		}
	}
	fmt.Println("全goroutineが同一インスタンスを取得:", allSame)

	// --- 要件2の検証: sync.Pool を使った並行処理でデータが混ざらないか確認する ---
	var wg2 sync.WaitGroup
	outputs := make([]string, 20)
	for i := 0; i < 20; i++ {
		wg2.Add(1)
		go func(n int) {
			defer wg2.Done()
			outputs[n] = processWithPooledBuffer(fmt.Sprintf("item-%d", n))
		}(i)
	}
	wg2.Wait()

	// それぞれの出力が対応する item-n を正しく含んでいるか確認する（データ混入がないか）。
	ok := true
	for i, out := range outputs {
		expected := fmt.Sprintf("processed: item-%d", i)
		if out != expected {
			ok = false
			fmt.Printf("不一致: got=%q want=%q\n", out, expected)
		}
	}
	fmt.Println("全goroutineの出力が期待通り:", ok)
}

Config initializing...
全goroutineが同一インスタンスを取得: true
全goroutineの出力が期待通り: true

※ Config initializing...が必ず1回だけ出力されること（10個のgoroutineから同時にGetConfig()を呼んでも複数回出力されないこと）がsync.Onceの効果です。go run -race main.goでもdata race検出なしを確認済みです。

🪜 Step-by-Step 解説

📋 コピーvar (
	once   sync.Once
	config *Config
)

func GetConfig() *Config {
	once.Do(func() {
		fmt.Println("Config initializing...")
		config = &Config{APIKey: "dummy-api-key", LoadedAt: time.Now()}
	})
	return config
}

📋 コピーvar initialized bool
var config *Config

func GetConfigBad() *Config {
	if !initialized { // 複数goroutineが同時にここを通過しうる
		config = &Config{...}
		initialized = true
	}
	return config
}

📋 コピーvar bufPool = sync.Pool{
	New: func() any {
		return make([]byte, 0, 1024)
	},
}

func processWithPooledBuffer(data string) string {
	buf := bufPool.Get().([]byte)
	defer func() {
		buf = buf[:0]
		bufPool.Put(buf)
	}()
	buf = append(buf, "processed: "...)
	buf = append(buf, data...)
	return string(buf)
}

📋 コピーfor i := 0; i < 20; i++ {
	wg2.Add(1)
	go func(n int) {
		defer wg2.Done()
		outputs[n] = processWithPooledBuffer(fmt.Sprintf("item-%d", n))
	}(i)
}

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

🌐 他言語との比較

sync.Poolが「GCと連動して勝手に空になることがある」という設計は、他言語のオブジェクトプール（多くは明示的に破棄しない限り保持され続ける）と比べると独特です。これは「メモリリークを防ぐことを、再利用の確実性よりも優先する」というGoらしいトレードオフの選択です。

🏆 実務での使いどころ

• シングルトンの設定・接続の初期化: データベース接続プールやHTTPクライアントなど、アプリケーション全体で1つだけ生成したいリソースの初期化にsync.Onceを使うのは非常に一般的なパターンです
• 遅延初期化（lazy initialization）: 起動時に全てを初期化するのではなく、「実際に使われるタイミングで初めて初期化する」ことでアプリケーションの起動時間を短縮する用途にもsync.Onceが使われます
• HTTPサーバーのレスポンスバッファ・JSON エンコード用バッファ: encoding/jsonのようなライブラリの内部実装や、高トラフィックなHTTPハンドラでのレスポンスボディ生成にsync.Poolが使われ、リクエストのたびに新規アロケーションを行う代わりにバッファを使い回します
• fmtパッケージ内部の実装: Go標準ライブラリのfmtパッケージも、フォーマット処理の内部バッファにsync.Poolを利用しており、高頻度なfmt.Sprintf呼び出しでもアロケーションが抑えられるよう設計されています

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: once.Do(f)のfがpanicした場合の挙動を実際に手元で確認してみましょう（fの中でpanic("boom")を起こし、recoverで拾いつつ2回目のDo呼び出しがどう振る舞うか観察すると、sync.Onceの内部状態遷移への理解が深まります）
• 次回予告: Day 016 — context パッケージ①（キャンセル伝播）（概念理解→実装問題）。goroutineの階層にキャンセルシグナルを伝える仕組みを学びます

🎯 自己評価

自分の回答

気づき・メモ