Go の一般的な並行処理パターンは何ですか?

Question

Accepted Answer

Go の goroutine とチャネルは、一般的な問題を解決する確立された**並行処理パターン**のセットを実現しています。仕事の分散、ファンアウト/ファンイン、パイプライン、レート制限などです。これらのイディオマティックなパターンを知ることで、正確で効率的な並行システムを構築できます。

## なぜ重要なのか

```go
func workerPool(jobs <-chan int, results chan<- int, numWorkers int) {
    var wg sync.WaitGroup
    for w := 0; w < numWorkers; w++ {     // a FIXED number of workers
        wg.Add(1)
        go func() {
            defer wg.Done()
            for job := range jobs {        // each worker pulls jobs until the channel closes
                results <- process(job)
            }
        }()
    }
    wg.Wait()
    close(results)
}
```

**ワーカープール**は、固定数の goroutine が共有されたジョブチャネルから消費します。これにより並行処理が制限されます(例えば、10,000 個の DB 接続を開かず、10 個のワーカーを使用します)。これはリソース使用量を制御するための最も重要なパターンです。

## ファンアウト / ファンイン

```text
Fan-out: distribute work across MULTIPLE goroutines (parallelize)
Fan-in:  MERGE results from multiple goroutines back into one channel
```

```go
// fan-in: merge several channels into one
func merge(channels ...<-chan int) <-chan int {
    out := make(chan int)
    var wg sync.WaitGroup
    for _, ch := range channels {
        wg.Add(1)
        go func(c <-chan int) {
            defer wg.Done()
            for v := range c { out <- v }   // forward each channel's values to out
        }(ch)
    }
    go func() { wg.Wait(); close(out) }()    // close out when all sources are drained
    return out
}
```

## パイプライン — チャネルで接続されたステージ

```go
// each stage is a goroutine: receives from an input channel, sends to an output channel
func generate(nums ...int) <-chan int {
    out := make(chan int)
    go func() { for _, n := range nums { out <- n }; close(out) }()
    return out
}
func square(in <-chan int) <-chan int {
    out := make(chan int)
    go func() { for n := range in { out <- n * n }; close(out) }()
    return out
}
// compose: square(generate(1,2,3)) → a streaming pipeline
for result := range square(generate(1, 2, 3)) { fmt.Println(result) }
```

**パイプライン**は処理ステージをチャネルで連鎖させます。データが流れ、各ステージが並行処理で変換します。

## レート制限

```go
limiter := time.Tick(200 * time.Millisecond)   // a tick every 200ms
for req := range requests {
    <-limiter                                    // wait for the next tick before proceeding
    go handle(req)                                // → at most 5 requests/second
}
```

## context による取り消し(横断的)

```go
select {
case result := <-work:
case <-ctx.Done():    return   // stop on cancellation — prevents leaks
}
```

## なぜ重要なのか

これらの並行処理パターンは、実際の Go 並行システムを構築するための実用的なツールキットであり、生の goroutine とチャネルを構造化された正確なソリューションに変えて、再発する問題を解決します。

**ワーカープール**は特に重要です。これは限定されたリソース(データベース接続、API レート制限、メモリ)を保護するために並行処理を制限し、システムを消耗させるような無制限の goroutine を生成するという一般的な誤りを防ぎます。**ファンアウト/ファンイン**は仕事を並列化して結果をマージします。**パイプライン**はストリーミングデータ変換をきれいにモデル化します。**レート制限**はスループットを制御します。

**context ベースの取り消し**(goroutine リークを避けるため)と組み合わせることで、これらのパターンは本番環境の Go サービスが並行処理を安全かつ効率的に処理する方法です。

それらを理解すること — そして特に無制限の goroutine を起動するのではなくワーカープールで並行処理を制限することを知ること — はシニア Go 開発者の能力の証であり、頻繁に出される上級インタビュートピックです。なぜなら素朴な並行処理(無制限の goroutine、リーク、競合状態)は本番環境の障害の一般的な原因だからです。