Wat veroorzaakt goroutine leaks en hoe voorkom je ze?

Question

Accepted Answer

Een **goroutine leak** is een goroutine die nooit afsluit — deze blijft geblokkeerd of draait voor eeuwig, verbruikt geheugen (en houdt de objecten waarnaar het verwijst in leven) voor de hele levensduur van het programma. Omdat goroutines goedkoop zijn om te starten, kun je ze gemakkelijk lekken, en leaks stapelen zich stil op totdat de service verslechtert of geen geheugen meer heeft.

## Oorzaak 1: geblokkeerd op een channel zonder zender/ontvanger

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

Een goroutine die geblokkeerd is op een channel send/receive die nooit voltooid wordt, zal **voor eeuwig** wachten — het wordt nooit garbage collected omdat het technisch gezien nog steeds "actief" is.

## Oorzaak 2: geen cancellation / 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
}
```

## Preventie 1: gebruik context voor cancellation

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

Aan elke langdurige goroutine een manier geven om geannuleerd te worden (`<-ctx.Done()`) is de primaire verdediging — het zorgt ervoor dat goroutines afsluitten wanneer hun werk niet meer nodig is.

## Preventie 2: gebruik buffered channels of zorg voor ontvangers

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

## Preventie 3: sluit channels altijd / drain ze correct

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

## Leaks detecteren

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

Monitoring van `runtime.NumGoroutine()` (een gestaag stijgend aantal duidt op een leak), het inspecteren van goroutine dumps via `pprof`, en het gebruik van `goleak` in tests zijn de belangrijkste detectiehulpmiddelen.

## Waarom het belangrijk is

Goroutine leaks zijn een van de meest voorkomende en sluw problemen in productie Go-services.

Omdat goroutines zo goedkoop zijn om te starten, creëren ontwikkelaars ze vrijelijk — maar een goroutine die voor eeuwig geblokkeerd is (op een channel zonder tegenhanger, of in een oneindige lus zonder cancellation) **sluit nooit af en geeft zijn geheugen nooit vrij** (inclusief alles waar het naar verwijst).

In een langdurige server stapelen deze leaks zich stil op, verbruiken geleidelijk geheugen totdat de service verslechtert of crasht — en ze zijn moeilijk op te merken omdat er geen onmiddellijke fout optreedt.

Het begrijpen van de oorzaken (geblokkeerde channel operaties, missende cancellation) en de preventies (**context-gebaseerde cancellation** als primaire verdediging, correct channel sluiten, buffered channels, zorgen voor ontvangers) is essentieel voor het schrijven van betrouwbare concurrent Go.

Het kennen van de detectiehulpmiddelen (`runtime.NumGoroutine`, pprof, goleak) is even belangrijk.

Dit is een kritisch, vaak geteste onderwerp dat ontwikkelaars die productie-grade concurrent Go kunnen schrijven onderscheidt van degenen die code schrijven die onder aanhoudende belasting lekt.