Hvad er almindelige Go concurrency-mønstre?

Question

Accepted Answer

Go's goroutines og channels muliggør et sæt af veletablerede **concurrency-mønstre**, som løser almindelige problemer — distribuering af arbejde, fan-out/in, pipelines og rate limiting. At kende disse idiomatiske mønstre gør det muligt for dig at bygge korrekte, effektive concurrent systemer.

## Worker pool — begrænset concurrency

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

En **worker pool** kører et fast antal goroutines, som forbruger fra en delt jobs-kanal — hvilket begrænser concurrency (f.eks. åbn ikke 10.000 DB-forbindelser; brug 10 workers). Dette er det vigtigste mønster for at kontrollere ressourceforbrug.

## 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 — stadier forbundet via 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) }
```

En **pipeline** forbinder bearbejdningsstadier via channels — data strømmer igennem, og hvert stadie transformerer det concurrent.

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

## Annullering med context (på tværs af systemer)

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

## Hvorfor det betyder noget

Disse concurrency-mønstre er det praktiske værktøjssæt til at bygge rigtige concurrent Go-systemer, der omdanner rå goroutines og channels til strukturerede, korrekte løsninger på tilbagevendende problemer.

**Worker pool** er især vigtig — den begrænser concurrency for at beskytte begrænsede ressourcer (databaseforbindelser, API-begrænsninger, hukommelse), hvilket forhindrer den almindelige fejl med ubegrænsede goroutines, der udtømmer systemet. **Fan-out/fan-in** paralleliserer arbejde og fletter resultater; **pipelines** modellerer streaming-datatransformationer pænt; **rate limiting** styrer gennemstrømning.

I kombination med **context-baseret annullering** (for at undgå goroutine-lækager) er disse mønstre, hvordan produktions-Go-tjenester håndterer concurrency sikkert og effektivt.

At forstå dem — og især at vide, at man skal begrænse concurrency med worker pools snarere end at starte ubegrænsede goroutines — er et kendetegn på senior Go-kompetence og et hyppigt avanceret interviewemne, da naiv concurrency (ubegrænsede goroutines, lækager, races) er en almindelig kilde til produktionsfejl.