Was sind häufige Go-Concurrency-Muster?

Question

Accepted Answer

Go's Goroutines und Channels ermöglichen eine Reihe von etablierten **Concurrency-Mustern**, die häufige Probleme lösen — Verteilung von Arbeit, Fan-out/in, Pipelines und Rate Limiting. Die Kenntnis dieser idiomatischen Muster ermöglicht es dir, korrekte und effiziente Concurrent-Systeme zu erstellen.

## Worker Pool — Concurrency begrenzen

```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)
}
```

Ein **Worker Pool** führt eine feste Anzahl von Goroutines aus, die von einem gemeinsamen Jobs-Kanal konsumieren — dies begrenzt die Concurrency (z. B. öffne nicht 10.000 DB-Verbindungen; verwende 10 Worker). Dies ist das wichtigste Muster zur Kontrolle der Ressourcennutzung.

## Fan-out / Fan-in

```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
}
```

## Pipeline — Stufen verbunden durch Channels

```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) }
```

Eine **Pipeline** verbindet Verarbeitungsstufen über Channels — Daten fließen durch, und jede Stufe transformiert sie parallel.

## Rate Limiting

```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
}
```

## Abbruch mit Context (übergreifend)

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

## Warum es wichtig ist

Diese Concurrency-Muster sind das praktische Toolkit zum Erstellen echter Concurrent-Go-Systeme, das Raw-Goroutines und Channels in strukturierte, korrekte Lösungen für wiederkehrende Probleme umwandelt.

Der **Worker Pool** ist besonders wichtig — er begrenzt die Concurrency zum Schutz begrenzte Ressourcen (Datenbankverbindungen, API-Rate-Limits, Speicher) und verhindert den häufigen Fehler des Startens unbegrenzter Goroutines, die das System erschöpfen. **Fan-out/Fan-in** parallelisiert Arbeit und vereinigt Ergebnisse; **Pipelines** modellieren Streaming-Datentransformationen sauber; **Rate Limiting** kontrolliert den Durchsatz.

Gekoppelt mit **Context-basiertem Abbruch** (um Goroutine-Lecks zu vermeiden), sind diese Muster der Weg, wie Produktions-Go-Services Concurrency sicher und effizient handhaben.

Sie zu verstehen — und insbesondere zu wissen, dass man die Concurrency mit Worker Pools begrenzen sollte, anstatt unbegrenzte Goroutines zu starten — ist ein Kennzeichen von Senior-Go-Kompetenz und ein häufiges Thema in fortgeschrittenen Interviews, da naive Concurrency (unbegrenzte Goroutines, Lecks, Races) eine häufige Quelle für Produktionsfehler ist.