Day 034 — race condition検出（go test -race）

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

Day 029〜033では Worker Pool・Fan-in/Fan-out・Pipeline・errgroup と、複数goroutineを協調させるパターンを一通り実装してきました。その過程で「共有カウンタはatomicかmutexで守る」というルールを繰り返し使ってきましたが、そのルールを破るとGoの実行結果がどうなるかを、実際に手を動かして確認したことはまだありません。

Goのメモリモデルでは、複数goroutineが同じメモリを同期なしに読み書きするとデータ競合（data race）が発生し、プログラムの動作は未定義になります。厄介なのは、データ競合があっても大抵の場合はプログラムが「たまたま正しく動いてしまう」ことです。同じマシン・同じgo runを10回実行して10回とも正常終了しても、11回目にクラッシュしたり、本番のCPUコア数・負荷状況が変わった瞬間に壊れたりします。目視のコードレビューだけでデータ競合を100%見つけるのは非現実的です。

そこでGoはgo test -race（およびgo run -race, go build -race）というRace Detectorを標準ツールチェーンに内蔵しています。これはコンパイル時にメモリアクセスへの計装（instrumentation）を挿入し、実行時に「同期されていない並行アクセス」が実際に発生した瞬間を検出する動的解析ツールです。静的解析ではなく動的解析なので、「そのテスト実行で実際に競合が起きたパス」しか検出できません——つまり再現条件を満たすテストコードを書くこと自体が技術になります。

Day 034ではこれまで書いてきた「安全なつもり」のコードに意図的な欠陥を混入させ、-raceで機械的に検出し、修正する一連の流れを体験します。

📝 問題

以下は、チームメンバーがDay 033のfetchAllLimitedを「もっとシンプルにできる」と言って書き直したコードです。レビューを依頼された想定で、このコードに潜むデータ競合をすべて指摘し、go test -raceで検出できるテストコードを書いた上で、正しく修正してください。

📋 コピーpackage main

import (
	"context"
	"fmt"
	"time"

	"golang.org/x/sync/errgroup"
)

type stats struct {
	total   int
	success int
	failed  int
	errMsgs []string
}

// fetchAllWithStats はfetchPriceを並列実行し、成功/失敗件数を集計する。
// atomic.Int32ではなく素朴なintフィールドに変更して「読みやすくした」つもりのコード。
func fetchAllWithStats(ids []int, limit int) (*stats, error) {
	g, ctx := errgroup.WithContext(context.Background())
	g.SetLimit(limit)

	s := &stats{}

	for _, id := range ids {
		id := id
		g.Go(func() error {
			s.total++ // (A)

			_, err := fetchPrice(ctx, id)
			if err != nil {
				s.failed++                                             // (B)
				s.errMsgs = append(s.errMsgs, fmt.Sprintf("id=%d: %v", id, err)) // (C)
				return nil // 集計目的なので早期打ち切りはしない
			}
			s.success++ // (D)
			return nil
		})
	}

	if err := g.Wait(); err != nil {
		return s, err
	}
	return s, nil
}

func fetchPrice(ctx context.Context, id int) (int, error) {
	select {
	case <-time.After(5 * time.Millisecond):
	case <-ctx.Done():
		return 0, ctx.Err()
	}
	if id%7 == 0 {
		return 0, fmt.Errorf("item %d: fetch failed", id)
	}
	return id * 10, nil
}

func main() {
	ids := make([]int, 50)
	for i := range ids {
		ids[i] = i + 1
	}
	s, _ := fetchAllWithStats(ids, 8)
	fmt.Printf("total=%d success=%d failed=%d errCount=%d\n", s.total, s.success, s.failed, len(s.errMsgs))
}

要件

1. コード中の (A)〜(D) のうち、データ競合を起こしている箇所をすべて特定し、それぞれ「何と何が競合するのか」を説明する
2. go test -race でこれらの競合を実際に検出できるテストコード（_test.go）を書く。ただのgo run -raceではなく、go testで自動検出できる形にすること（競合が発生する条件——limitやids件数——を意識してテストを設計する）
3. stats構造体を、Day 033で学んだatomicパッケージとsync.Mutexを適材適所で使い分けて修正する（スライスへのappendはatomicでは守れないことに注意）
4. 修正後、同じテストが-raceエラーなしで通ることを確認する手順をコメントで示す

🔍 ヒント（段階的開示）

📋 コピーtype stats struct {
	total   atomic.Int64
	success atomic.Int64
	failed  atomic.Int64

	mu      sync.Mutex
	errMsgs []string
}

func fetchAllWithStats(ids []int, limit int) (*stats, error) {
	g, ctx := errgroup.WithContext(context.Background())
	g.SetLimit(limit)

	s := &stats{}

	for _, id := range ids {
		id := id
		g.Go(func() error {
			s.total.Add(1)

			_, err := fetchPrice(ctx, id)
			if err != nil {
				s.failed.Add(1)
				s.mu.Lock()
				s.errMsgs = append(s.errMsgs, fmt.Sprintf("id=%d: %v", id, err))
				s.mu.Unlock()
				return nil
			}
			s.success.Add(1)
			return nil
		})
	}

	if err := g.Wait(); err != nil {
		return s, err
	}
	return s, nil
}

✅ 模範解答

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

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

go 1.22

require golang.org/x/sync v0.8.0

main.go（修正後の完全版）

📋 コピーpackage main

import (
	"context"
	"fmt"
	"sync"
	"sync/atomic"
	"time"

	"golang.org/x/sync/errgroup"
)

// stats はfetchAllWithStatsの集計結果を保持する。
// 単純カウンタはatomicで、スライスはmutexで保護する。
// atomicはCPUのCAS命令1つで完結する単純な値にしか使えず、
// append によるスライスの再割り当てのような複合操作は守れないため、
// フィールドの性質ごとに保護手段を使い分けている。
type stats struct {
	total   atomic.Int64
	success atomic.Int64
	failed  atomic.Int64

	mu      sync.Mutex
	errMsgs []string
}

func (s *stats) recordError(msg string) {
	s.mu.Lock()
	defer s.mu.Unlock()
	s.errMsgs = append(s.errMsgs, msg)
}

func (s *stats) errCount() int {
	s.mu.Lock()
	defer s.mu.Unlock()
	return len(s.errMsgs)
}

// fetchAllWithStats はfetchPriceを並列実行し、成功/失敗件数を集計する。
// Day 033のSetLimitで同時実行数を制御しつつ、集計目的なのでctxのキャンセルには
// 依存させず、全件を最後まで実行する(returnは常にnil)。
func fetchAllWithStats(ids []int, limit int) (*stats, error) {
	g, ctx := errgroup.WithContext(context.Background())
	g.SetLimit(limit)

	s := &stats{}

	for _, id := range ids {
		id := id
		g.Go(func() error {
			s.total.Add(1)

			_, err := fetchPrice(ctx, id)
			if err != nil {
				s.failed.Add(1)
				s.recordError(fmt.Sprintf("id=%d: %v", id, err))
				return nil // 集計目的なので早期打ち切りはしない
			}
			s.success.Add(1)
			return nil
		})
	}

	if err := g.Wait(); err != nil {
		return s, err
	}
	return s, nil
}

func fetchPrice(ctx context.Context, id int) (int, error) {
	select {
	case <-time.After(5 * time.Millisecond):
	case <-ctx.Done():
		return 0, ctx.Err()
	}
	if id%7 == 0 {
		return 0, fmt.Errorf("item %d: fetch failed", id)
	}
	return id * 10, nil
}

func main() {
	ids := make([]int, 50)
	for i := range ids {
		ids[i] = i + 1
	}
	s, _ := fetchAllWithStats(ids, 8)
	fmt.Printf("total=%d success=%d failed=%d errCount=%d\n",
		s.total.Load(), s.success.Load(), s.failed.Load(), s.errCount())
}

main_test.go（データ競合を検出・再確認するテスト）

📋 コピーpackage main

import (
	"testing"
)

// TestFetchAllWithStats_Race は go test -race で実行することを前提にしたテスト。
// limitとids件数を十分に大きくし、複数goroutineが同時にstatsへ触れる状況を
// 意図的に作ることで、修正前のコード(素朴なint/append)なら確実に
// "WARNING: DATA RACE" が報告される条件を再現する。
//
// 実行手順:
//   go test -race -run TestFetchAllWithStats_Race -count=5 .
// (count=5で複数回実行し、たまたま競合しなかった実行に依存しないようにする)
func TestFetchAllWithStats_Race(t *testing.T) {
	ids := make([]int, 40)
	for i := range ids {
		ids[i] = i + 1
	}

	const limit = 12
	s, err := fetchAllWithStats(ids, limit)
	if err != nil {
		t.Fatalf("unexpected error: %v", err)
	}

	total := s.total.Load()
	success := s.success.Load()
	failed := s.failed.Load()
	errCount := int64(s.errCount())

	if total != int64(len(ids)) {
		t.Errorf("total = %d, want %d", total, len(ids))
	}
	if success+failed != total {
		t.Errorf("success(%d) + failed(%d) != total(%d)", success, failed, total)
	}
	if failed != errCount {
		t.Errorf("failed(%d) != len(errMsgs)(%d)", failed, errCount)
	}
}

mkdir day034 && cd day034
go mod init example.com/day034
go get golang.org/x/sync@v0.8.0
# main.go, main_test.go を上記の内容で保存

# 1. 修正前(s.total++ 等の素朴なint版)に main.go を一時的に戻して実行すると:
go test -race -run TestFetchAllWithStats_Race -count=5 .
# => WARNING: DATA RACE
#    Write at 0x... by goroutine N:
#      main.fetchAllWithStats.func1()
#    Previous write at 0x... by goroutine M:
#      main.fetchAllWithStats.func1()
#    のような報告が(A)(B)(C)(D)それぞれについて出力される

# 2. atomic + mutex に修正した本ファイルの main.go で実行すると:
go test -race -run TestFetchAllWithStats_Race -count=5 .
# => ok  example.com/day034  0.XXXs   (DATA RACEの報告なし)

🪜 Step-by-Step 解説

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

🌐 他言語との比較

🏆 実務での使いどころ

• CIパイプラインへの組み込み: go test -race ./... をCIの必須ステップにし、データ競合を含むコードがマージされることを機械的に防ぐ（多くのGoプロジェクトで標準的な運用）
• 並行処理を含むPRのレビュー基準: 「goroutineを複数起動するコードには、必ず-race付きテストを書く」というレビューチェックリスト項目として使う
• 本番障害の再現・切り分け: 本番で「たまに値がおかしい」「たまにクラッシュする」といった再現困難な障害が出た際、疑わしい並行処理コードに対して-race付きでテストを再実行し、原因箇所を特定する
• リファクタリング時の安全網: Day 033のように「読みやすくしよう」とした変更がデータ競合を混入させていないか、-race付きテストで機械的に確認してからマージする

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: -raceが検出する競合には今回のような「単純な変数競合」以外に、「一度closeしたchannelへの再度のclose」や「nilマップへの書き込み」に近い、より発見しにくいパターンもあります。Day 010〜011で書いたchannelコードに戻り、-race付きで再実行して問題がないか確認してみましょう
• 次回予告: メモリモデルとhappens-before関係 — Day 035では「なぜデータ競合が未定義動作になるのか」を、Goのメモリモデル仕様が定義するhappens-beforeの概念から正確に理解します

🎯 自己評価

自分の回答

気づき・メモ