Hvad forårsager goroutine-lækager, og hvordan forhindrer du dem?

Question

Accepted Answer

En **goroutine-lækage** er en goroutine, der aldrig terminerer — den bliver blokeret eller kører for evigt, consumer hukommelse (og holder refererede objekter i live) i hele programmets levetid. Eftersom goroutines er billige at starte, er det let at lække dem, og lækager akkumuleres stiltiende, indtil tjenesten degraderes eller løber tør for hukommelse.

## Årsag 1: blokeret på en kanal uden afsender/modtager

```go
// ❌ LEAK — this goroutine blocks forever waiting to send
func leak() {
    ch := make(chan int)   // unbuffered
    go func() {
        ch <- 42           // blocks forever — NOBODY ever receives
    }()                     // the goroutine is stuck, never exits
    // function returns without reading ch → the goroutine leaks
}
```

En goroutine blokeret på en kanal send/receive, der aldrig fuldføres, venter **for evigt** — den bliver aldrig garbage collected, fordi den teknisk set stadig "kører".

## Årsag 2: ingen aflysning / done-signal

```go
// ❌ LEAK — a goroutine in an infinite loop with no way to stop
func worker(jobs <-chan int) {
    for {
        job := <-jobs      // blocks forever if jobs is never closed and stops sending
        process(job)
    }                       // no exit condition — leaks when no longer needed
}
```

## Forebyggelse 1: brug context til aflysning

```go
// ✅ the goroutine can be told to stop
func worker(ctx context.Context, jobs <-chan int) {
    for {
        select {
        case job := <-jobs:
            process(job)
        case <-ctx.Done():       // cancellation signal → exit cleanly
            return                // the goroutine terminates, no leak
        }
    }
}
// caller: ctx, cancel := context.WithCancel(...); defer cancel()
```

At give hver langvarig goroutine mulighed for at blive aflyst (`<-ctx.Done()`) er det primære forsvar — det sikrer, at goroutines terminerer, når deres arbejde ikke længere er nødvendigt.

## Forebyggelse 2: brug bufferede kanaler eller sikr modtagere

```go
// ✅ ensure a receiver exists, or use a buffered channel so the send doesn't block
ch := make(chan int, 1)   // buffered → the send completes even if no one receives yet
go func() { ch <- 42 }()   // doesn't block
```

## Forebyggelse 3: luk altid kanaler / dræn dem korrekt

```go
// ✅ close channels so range loops terminate
go func() {
    defer close(results)    // signal completion → for-range over results ends
    for _, job := range jobs { results <- process(job) }
}()
```

## Detektering af lækager

```go
runtime.NumGoroutine()         // monitor the goroutine count — steady growth = leak
import _ "net/http/pprof"      // pprof exposes goroutine stacks (/debug/pprof/goroutine)
// the goleak library asserts no leaked goroutines in tests
```

Overvågning af `runtime.NumGoroutine()` (en konstant stigende tæller signalerer en lækage), inspektion af goroutine-dumps via `pprof`, og brug af `goleak` i tests er de vigtigste detektionsværktøjer.

## Hvorfor det betyder noget

Goroutine-lækager er et af de mest almindelige og ondskabsfulde problemer i produktions-Go-tjenester.

Fordi goroutines er så billige at starte, opretter udvikler dem frit — men en goroutine blokeret for evigt (på en kanal uden modpart, eller i en uendelig løkke uden aflysning) **terminerer aldrig og frigiver aldrig dens hukommelse** (inklusive alt, den refererer til).

I en langtidskørende server akkumuleres disse lækager stiltiende og consumer gradvist hukommelse, indtil tjenesten degraderes eller crasher — og de er svære at få øje på, fordi der ikke er nogen øjeblikkelig fejl.

At forstå årsagerne (blokerede kanaloperationer, manglende aflysning) og forebyggelserne (**context-baseret aflysning** som det primære forsvar, korrekt kanallukning, bufferede kanaler, sikring af modtagere) er afgørende for at skrive pålidelig concurrent Go.

At kende detektionsværktøjerne (`runtime.NumGoroutine`, pprof, goleak) er lige så vigtigt.

Dette er et kritisk, ofte testet emne, der adskiller udvikler, der kan skrive produktionskvalitet concurrent Go, fra dem, der skriver kode, der lækker under vedvarende belastning.