Was verursacht Goroutine-Lecks und wie verhinderst du sie?

Question

Accepted Answer

Ein **Goroutine-Leck** ist eine Goroutine, die sich nie beendet — sie bleibt blockiert oder läuft endlos, verbraucht Speicher (und hält ihre referenzierten Objekte am Leben) für die Lebensdauer des Programms. Da Goroutines billig zu starten sind, ist es leicht, sie lecken zu lassen, und Lecks sammeln sich stillschweigend an, bis der Service sich verschlechtert oder der Speicher ausgeht.

## Ursache 1: blockiert auf einem Channel ohne Sender/Empfänger

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

Eine auf einen Channel-Sende-/Empfangsvorgang blockierte Goroutine, die sich nie abschließt, wartet **auf ewig** — sie wird nie garbage collected, weil sie technisch immer noch "ausgeführt" wird.

## Ursache 2: keine Abbruch- / 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
}
```

## Prävention 1: Context für Abbruch verwenden

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

Jede langlebige Goroutine mit einer Möglichkeit zur Abmeldung (`<-ctx.Done()`) zu versehen ist die primäre Verteidigungslinie — es stellt sicher, dass Goroutines beendet werden, wenn ihre Arbeit nicht mehr benötigt wird.

## Prävention 2: gepufferte Channels oder Empfänger sicherstellen

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

## Prävention 3: Channel immer schließen / sie ordnungsgemäß ausleeren

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

## Lecks erkennen

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

Überwachung von `runtime.NumGoroutine()` (eine kontinuierlich steigende Zahl signalisiert ein Leck), Überprüfung von Goroutine-Dumps über `pprof` und die Verwendung von `goleak` in Tests sind die wichtigsten Erkennungswerkzeuge.

## Warum es wichtig ist

Goroutine-Lecks sind eines der häufigsten und heimtückischsten Probleme in produktiven Go-Services.

Weil Goroutines so billig zu starten sind, erstellen Entwickler sie freizügig — aber eine Goroutine, die für immer blockiert (auf einem Channel ohne Gegenpart, oder in einer Endlosschleife ohne Abbruch) **beendet sich nie und gibt ihren Speicher nie frei** (einschließlich alles, worauf sie verweist).

In einem langlebigen Server sammeln sich diese Lecks stillschweigend an, verbrauchen allmählich Speicher, bis sich der Service verschlechtert oder abstürzt — und sie sind schwer zu erkennen, weil es keinen unmittelbaren Fehler gibt.

Das Verständnis der Ursachen (blockierte Channel-Operationen, fehlende Abbrüche) und der Präventionsmaßnahmen (**Context-basierter Abbruch** als primäre Verteidigungslinie, ordnungsgemäßes Channel-Schließen, gepufferte Channels, Sicherstellung von Empfängern) ist essentiell für das Schreiben von zuverlässigem concurrent Go.

Das Kennen der Erkennungswerkzeuge (`runtime.NumGoroutine`, pprof, goleak) ist ebenso wichtig.

Dies ist ein kritisches, häufig getestetes Thema, das Entwickler unterscheidet, die produktionsreifes concurrent Go schreiben können, von denjenigen, die Code schreiben, der unter Dauerlast leckt.