Co powoduje wycieki goroutine'ów i jak je zapobiegać?

Question

Accepted Answer

**Wyciek goroutine'a** to goroutine, który nigdy się nie zakończy — pozostaje zablokowany lub działa w nieskończoność, zużywając pamięć (i utrzymując referencje na obiekty) przez całe życie programu. Ponieważ goroutine'y są tanie w uruchomieniu, łatwo je przeciąć, a wycieki gromadzą się w milczeniu, aż do degradacji usługi lub wyczerpania pamięci.

## Przyczyna 1: zablokowanie na kanale bez nadawcy/odbiorcy

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

Goroutine zablokowany na wysłaniu/odbiorze z kanału, który nigdy się nie zakończy, będzie czekać **na zawsze** — nigdy nie zostanie zebrany przez garbage collector, ponieważ technicznie nadal jest "uruchomiony".

## Przyczyna 2: brak anulowania / sygnału zakończenia

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

## Zapobieganie 1: używanie context do anulowania

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

Danie każdemu długotrwałemu goroutine'owi możliwości anulowania (`<-ctx.Done()`) jest główną obroną — zapewnia, że goroutine'y kończą się, gdy ich praca nie jest już potrzebna.

## Zapobieganie 2: użycie buforowanych kanałów lub zapewnienie odbiorców

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

## Zapobieganie 3: zawsze zamykaj kanały / prawidłowo je opróżniaj

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

## Wykrywanie wycieków

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

Monitorowanie `runtime.NumGoroutine()` (stale rosnąca liczba sygnalizuje wyciek), inspekowanie zrzutów goroutine'ów za pomocą `pprof` i użycie `goleak` w testach to główne narzędzia do wykrywania.

## Dlaczego to ważne

Wycieki goroutine'ów to jeden z najczęstszych i najbardziej podstępnych problemów w produkcyjnych usługach Go.

Ponieważ goroutine'y są tak tanie w uruchomieniu, deweloperzy tworzą je swobodnie — ale goroutine zablokowany na zawsze (na kanale bez odpowiednika lub w nieskończonej pętli bez anulowania) **nigdy się nie zakończy i nigdy nie zwolni swojej pamięci** (w tym wszystko, co referencjonuje).

W długotrwałym serwerze te wycieki gromadzą się w milczeniu, stopniowo zużywając pamięć, aż usługa się degraduje lub przerywa — i trudno je zauważyć, ponieważ nie ma natychmiastowego błędu.

Zrozumienie przyczyn (zablokowane operacje kanałów, brak anulowania) i zapobiegania (**anulowanie oparte na context** jako główna obrona, prawidłowe zamykanie kanałów, buforowane kanały, zapewnienie odbiorców) jest niezbędne do pisania niezawodnego równoczesnego Go.

Znajomość narzędzi do wykrywania (`runtime.NumGoroutine`, pprof, goleak) jest równie ważna.

To krytyczny, często testowany temat, który odróżnia deweloperów, którzy potrafią pisać produkcyjne równoczesne Go, od tych, którzy piszą kod, który przecieka pod ciśnieniem prolongowanego obciążenia.