Day 016 — context パッケージ①（キャンセル伝播）

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

Day 009〜015でgoroutine・channel・select・syncパッケージを学び、複数のgoroutineを協調させる基本的な道具は揃いました。しかし1つ、重要な問題が手つかずのまま残っています。「起動したgoroutineに、途中でやめてほしいと伝える標準的な方法」です。

素朴には、done := make(chan struct{})のような「終了通知専用チャネル」を自前で用意し、close(done)で全workerに知らせる、という自作パターンで対応できます。実際、Goの初期にはこのパターンが広く使われていました。しかし実務のシステムでは、次のような要求が次々に出てきます。

• HTTPリクエストの処理中に、クライアントが接続を切ったら、そのリクエストのために起動した全goroutineを止めたい
• 「5秒でタイムアウト」のような時間制限つきキャンセルをしたい
• ある処理をキャンセルしたら、その処理から呼び出している下位の処理（DBクエリ・外部API呼び出しなど）も連鎖的にキャンセルしたい
• キャンセルの理由（タイムアウトなのか、明示的なキャンセルなのか）を末端のgoroutineまで伝えたい

これらをdone chan struct{}の自作パターンで毎回作り込むのは非効率かつバグの温床です。そこでGo 1.7で標準ライブラリに追加されたのがcontextパッケージです。context.Contextは「キャンセルシグナル・タイムアウト・リクエストスコープの値を、goroutineの呼び出しツリー全体に伝播させるための共通インターフェース」です。

context.Contextはツリー構造を持ちます。context.Background()（あるいはcontext.TODO()）を根として、context.WithCancel(parent)のように親のcontextから子のcontextを派生させます。この派生関係が重要で、親がキャンセルされると、その親から派生した全ての子・孫contextも自動的にキャンセルされます（逆に子をキャンセルしても親には影響しません）。goroutineはctx.Done()が返す<-chan struct{}をselectで監視し、このチャネルがcloseされたら「キャンセルされた」と判断して後片付けをして終了します。キャンセルされた理由はctx.Err()で取得でき、明示的なキャンセルならcontext.Canceled、タイムアウトならcontext.DeadlineExceededが返ります。

Goの設計思想として、context.Contextは「goroutineをまたぐキャンセル・タイムアウト・値伝播という、並行処理で繰り返し必要になる関心事を、言語機能ではなく1つの小さいインターフェース（Done()・Err()・Deadline()・Value()の4メソッドのみ）に集約する」という形をとっています。これにより、標準ライブラリ（net/http・database/sqlなど）からサードパーティのライブラリまで、context.Contextを第一引数として受け取る（func Do(ctx context.Context, ...)）という統一された規約でキャンセル伝播を扱えるようになっています。

📝 問題

以下の要件を満たす、go run main.goでそのまま実行できる1つのGoプログラムを実装してください。

1. worker(ctx context.Context, id int, wg *sync.WaitGroup)という関数を実装してください。この関数は、一定間隔（例: 100ミリ秒ごと）で「作業中」というログを出し続け、ctxがキャンセルされたらselectでそれを検知して、ctx.Err()の内容とともにログを出してから終了するようにしてください
2. context.Background()を根とし、context.WithCancelで作った親contextを使って、3つのworkerをgoroutineとして起動してください
3. 親contextからさらにcontext.WithCancelで子contextを1つ派生させ、その子contextを使ってもう1つworkerを起動してください
4. 500ミリ秒待ってから親contextだけを明示的にキャンセルし、子contextも連鎖してキャンセルされること（子contextのDone()も自動でcloseされ、対応するworkerも終了すること）を、プログラムの出力で確認できるようにしてください
5. 全workerが終了するのをsync.WaitGroupで待ち、最後に親・子それぞれのctx.Err()の値を出力してください
6. context.WithCancelで得たcancel関数は、リークを防ぐため必ず呼び出すようにしてください（deferの利用を推奨）

🔍 ヒント（段階的開示）

📋 コピーpackage main

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

func worker(ctx context.Context, id int, wg *sync.WaitGroup) {
	defer wg.Done()
	ticker := time.NewTicker(100 * time.Millisecond)
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			// TODO: ctx.Err() を使って終了ログを出す
			return
		case <-ticker.C:
			// TODO: 作業中ログを出す
		}
	}
}

func main() {
	parentCtx, cancelParent := context.WithCancel(context.Background())
	defer cancelParent()

	var wg sync.WaitGroup
	// TODO: parentCtx を使って worker を3つ起動する

	// TODO: parentCtx から childCtx を派生させ、cancelChild も defer する
	// TODO: childCtx を使って worker をもう1つ起動する

	time.Sleep(500 * time.Millisecond)
	// TODO: 親contextだけをキャンセルする

	wg.Wait()
	// TODO: parentCtx.Err() / childCtx.Err() を出力する
}

✅ 模範解答

📋 コピーpackage main

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

// worker はctxがキャンセルされるまで一定間隔で作業を行い、
// キャンセルされたら理由（ctx.Err()）を出力して終了する。
func worker(ctx context.Context, id int, wg *sync.WaitGroup) {
	defer wg.Done()
	ticker := time.NewTicker(100 * time.Millisecond)
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			fmt.Printf("worker %d: 停止しました（理由: %v）\n", id, ctx.Err())
			return
		case <-ticker.C:
			fmt.Printf("worker %d: 作業中...\n", id)
		}
	}
}

func main() {
	// 親context: 全workerの生存期間を制御する根。
	parentCtx, cancelParent := context.WithCancel(context.Background())
	defer cancelParent() // 早期returnやpanicがあってもリークしないよう必ずdeferする

	var wg sync.WaitGroup
	for i := 1; i <= 3; i++ {
		wg.Add(1)
		go worker(parentCtx, i, &wg)
	}

	// 子context: 親から派生させることで、親がキャンセルされると自動的に連鎖する。
	childCtx, cancelChild := context.WithCancel(parentCtx)
	defer cancelChild()

	wg.Add(1)
	go worker(childCtx, 99, &wg)

	time.Sleep(500 * time.Millisecond)
	fmt.Println("--- 親contextをキャンセルします ---")
	cancelParent()

	wg.Wait()

	fmt.Println("親ctx.Err():", parentCtx.Err())
	fmt.Println("子ctx.Err():", childCtx.Err())
}

worker 1: 作業中...
worker 2: 作業中...
worker 3: 作業中...
worker 99: 作業中...
worker 1: 作業中...
worker 2: 作業中...
worker 3: 作業中...
worker 99: 作業中...
...(500msの間、100msごとに繰り返し)...
--- 親contextをキャンセルします ---
worker 1: 停止しました（理由: context canceled）
worker 2: 停止しました（理由: context canceled）
worker 3: 停止しました（理由: context canceled）
worker 99: 停止しました（理由: context canceled）
親ctx.Err(): context canceled
子ctx.Err(): context canceled

※ 親contextに紐づくworker（1・2・3）だけでなく、親から派生した子contextに紐づくworker（99）も、cancelParent()だけを呼んだ結果として停止していることが確認できます。子context自身のcancelChild()は一度も呼んでいませんが、childCtx.Err()もcontext canceledになっています。

🪜 Step-by-Step 解説

📋 コピーfunc worker(ctx context.Context, id int, wg *sync.WaitGroup) {
	defer wg.Done()
	ticker := time.NewTicker(100 * time.Millisecond)
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			fmt.Printf("worker %d: 停止しました（理由: %v）\n", id, ctx.Err())
			return
		case <-ticker.C:
			fmt.Printf("worker %d: 作業中...\n", id)
		}
	}
}

📋 コピーparentCtx, cancelParent := context.WithCancel(context.Background())
defer cancelParent()

var wg sync.WaitGroup
for i := 1; i <= 3; i++ {
	wg.Add(1)
	go worker(parentCtx, i, &wg)
}

📋 コピーchildCtx, cancelChild := context.WithCancel(parentCtx)
defer cancelChild()

wg.Add(1)
go worker(childCtx, 99, &wg)

📋 コピーtime.Sleep(500 * time.Millisecond)
fmt.Println("--- 親contextをキャンセルします ---")
cancelParent()

wg.Wait()

fmt.Println("親ctx.Err():", parentCtx.Err())
fmt.Println("子ctx.Err():", childCtx.Err())

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

🌐 他言語との比較

Goのcontextが際立っているのは、「言語仕様の一部ではなくただのライブラリの型」でありながら、事実上エコシステム全体の共通言語になっている点です。これはfunc Do(ctx context.Context, ...)という「第一引数にctxを取る」というコミュニティの規約（convention）によって支えられており、Go自体がこれを強制しているわけではありません。

🏆 実務での使いどころ

• HTTPサーバーのリクエストスコープ管理: net/httpのハンドラはr.Context()でリクエストに紐づくcontextを取得できます。クライアントが接続を切ると、このcontextが自動的にキャンセルされるため、ハンドラ内で起動したDBクエリや外部API呼び出しも連鎖して中断でき、無駄な処理を継続しません
• DBクエリのタイムアウト制御: database/sqlのQueryContext(ctx, ...)のようなAPIにcontext.WithTimeoutで作ったcontextを渡すことで、「このクエリは3秒でタイムアウトさせる」という制御を、DBドライバの実装に関わらず統一的に行えます
• マイクロサービス間のリクエストチェーン: サービスAがサービスBを呼び、BがサービスCを呼ぶような構成で、Aへのリクエストがタイムアウトしたときに、B・Cへの呼び出しも連鎖してキャンセルすることで、無駄なリソース消費（ゾンビリクエスト）を防げます
• graceful shutdown: アプリケーション終了シグナル（SIGTERMなど）を受けたときに、ルートのcontextをキャンセルすることで、稼働中の全goroutineに一斉に「後片付けして終了して」と伝える設計がよく使われます（Phase 3で扱う「graceful shutdown実装」テーマに直結します）

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: context.WithTimeout(parent, 3*time.Second)を使い、明示的なcancel()を呼ばなくても3秒経過で自動的にctx.Err()がcontext.DeadlineExceededになることを実際に確認してみましょう。今回学んだWithCancelとの違い（誰が・いつキャンセルを引き起こすか）が明確になります
• 次回予告: Day 017 — context パッケージ②（タイムアウト・値の伝播）（実装問題）。WithTimeout/WithDeadlineと、リクエストスコープの値を安全に伝播させるWithValueの正しい使い方を学びます

🎯 自己評価

自分の回答

気づき・メモ