Hva forårsaker goroutine-lekkasjer og hvordan forhindrer du dem?

Question

Accepted Answer

En **goroutine-lekkasje** er en goroutine som aldri avsluttes — den blir blokkert eller kjører for alltid, forbruker minne (og holder refererte objekter i live) for hele programmets levetid. Siden goroutines er billige å starte, er det lett å lekke dem, og lekkasjer akkumuleres stille inntil tjenesten blir treg eller går tom for minne.

## Årsak 1: blokkert på en kanal uten avsender/mottaker

```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 blokkert på en kanalsending/mottak som aldri fullføres, vil vente **for alltid** — den blir aldri garbage collected fordi den fortsatt er teknisk sett "kjørende."

## Årsak 2: ingen avbrytelse / 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
}
```

## Forebygging 1: bruk context for avbrytelse

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

Å gi hver langvarig goroutine en måte å bli avbrutt på (`<-ctx.Done()`) er det primære forsvaret — det sikrer at goroutines avsluttes når deres arbeid ikke lenger er nødvendig.

## Forebygging 2: bruk buffrede kanaler eller sikre mottakere

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

## Forebygging 3: lukk alltid kanaler / dren dem riktig

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

## Oppdage lekkasjer

```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åke `runtime.NumGoroutine()` (en stadig stigende telling signaliserer en lekkasje), inspisere goroutine-dumper via `pprof`, og bruke `goleak` i tester er hoveddeteksjonsverktøyene.

## Hvorfor det er viktig

Goroutine-lekkasjer er ett av de mest vanlige og lumske problemene i produksjons-Go-tjenester.

Fordi goroutines er så billige å starte, oppretter utviklere dem fritt — men en goroutine blokkert for alltid (på en kanal uten motstykke, eller i en uendelig løkke uten avbrytelse) **avsluttes aldri og frigjør aldri sitt minne** (inkludert alt den refererer til).

I en langvarig server akkumuleres disse lekkasjer stille, forbruker gradvis minne inntil tjenesten blir treg eller krasjer — og de er vanskelige å oppdage fordi det ikke er noen umiddelbar feil.

Å forstå årsakene (blokkerte kanaloperasjoner, manglende avbrytelse) og forebyggingen (**context-basert avbrytelse** som det primære forsvaret, riktig kanalstenging, buffrede kanaler, sikring av mottakere) er vesentlig for å skrive pålitelig concurrency-Go.

Å kjenne deteksjonsverktøyene (`runtime.NumGoroutine`, pprof, goleak) er like viktig.

Dette er et kritisk, hyppig testet emne som skiller utviklere som kan skrive produksjonsgodkjent concurrency-Go fra de som skriver kode som lekker under vedvarende belastning.