Vad orsakar goroutine-läckor och hur förhindrar du dem?

Question

Accepted Answer

En **goroutine-läcka** är en goroutine som aldrig avslutas — den förblir blockerad eller körs för alltid, förbrukar minne (och håller dess refererade objekt vid liv) under programmets livstid. Eftersom goroutines är billiga att starta är det lätt att läcka dem, och läckor ackumuleras tyst tills tjänsten försämras eller slut på minne.

## Orsak 1: blockerad på en kanal utan avsändare/mottagare

```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 blockerad på en kanalsändning/mottagning som aldrig slutförts väntar **för alltid** — den skräpsamlas aldrig in eftersom den tekniskt sett fortfarande "körs".

## Orsak 2: ingen avbokning / 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
}
```

## Prevention 1: använd context för avbokning

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

Att ge varje långlivad goroutine ett sätt att avbokas (`<-ctx.Done()`) är det primära försvaret — det säkerställer att goroutines avslutas när deras arbete inte längre behövs.

## Prevention 2: använd buffrade kanaler eller säkerställ mottagare

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

## Prevention 3: stäng alltid kanaler / dränera dem på rätt sätt

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

## Detektera läckor

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

Övervakning av `runtime.NumGoroutine()` (ett stadigt stigande antal signalerar en läcka), inspektion av goroutine-dumpar via `pprof` och användning av `goleak` i tester är de viktigaste detektionsverktygen.

## Varför det är viktigt

Goroutine-läckor är ett av de vanligaste och mest illvilliga problemen i Go-tjänster i produktion.

Eftersom goroutines är så billiga att lansera skapar utvecklare dem fritt — men en goroutine blockerad för alltid (på en kanal utan motsvarighet, eller i en oändlig loop utan avbokning) **avslutas aldrig och frigör aldrig sitt minne** (inklusive allt det refererar till).

I en långkörd server ackumuleras dessa läckor tyst och förbrukar gradvis minne tills tjänsten försämras eller kraschar — och de är svåra att upptäcka eftersom det inte finns något omedelbart fel.

Att förstå orsakerna (blockerade kanaloperationer, saknad avbokning) och förebyggandet (**context-baserad avbokning** som det primära försvaret, korrekt kanalstängning, buffrade kanaler, säkerställande av mottagare) är väsentligt för att skriva tillförlitlig gleichzeitig Go.

Att känna till detektionsverktygen (`runtime.NumGoroutine`, pprof, goleak) är lika viktigt.

Detta är ett kritiskt, ofta testat ämne som skiljer utvecklare som kan skriva Go-kod i produktionsklass från de som skriver kod som läcker under ansträngd belastning.