Co způsobuje úniky goroutin a jak je předcházíte?

Question

Accepted Answer

**Únik goroutiny** je goroutina, která se nikdy neukončí — zůstane zablokovaná nebo běží navždy, spotřebovává paměť (a udržuje její odkazované objekty naživu) po dobu běhu programu. Protože jsou goroutiny levné na spuštění, je snadné je unést, a úniky se tichým způsobem hromadí, dokud se služba nepokazí nebo nevyčerpá paměť.

## Příčina 1: zablokovaná na kanálu bez odesílatele/příjemce

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

Goroutina zablokovaná na odesílání/příjímání na kanálu, které se nikdy nedokončí, bude čekat **navždy** — nikdy se nesbírá pro uvolnění paměti, protože je technicky stále "spuštěná".

## Příčina 2: bez zrušení / done signálu

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

## Prevence 1: použijte context pro zrušení

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

Dání každé dlouhodobě běžící goroutině způsobu, jak ji zrušit (`<-ctx.Done()`), je primární obrana — zajistí, že goroutiny skončí, když jejich práce už není potřeba.

## Prevence 2: použijte bufferované kanály nebo zajistěte příjemce

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

## Prevence 3: vždy zavřete kanály / vypusťte je správně

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

## Detekce úniků

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

Monitorování `runtime.NumGoroutine()` (neustále rostoucí počet signalizuje únik), kontrola výpisů goroutin přes `pprof` a používání `goleak` v testech jsou hlavními nástroji detekce.

## Proč to záleží

Úniky goroutin jsou jedním z nejčastějších a nejzáludnějších problémů v produkčních Go službách.

Protože jsou goroutiny tak levné na spuštění, vývojáři je vytváří svobodně — ale goroutina zablokovaná navždy (na kanálu bez protějšku, nebo v nekonečné smyčce bez zrušení) **se nikdy neukončí a nikdy neuvolní svou paměť** (včetně všeho, na co odkazuje).

V dlouhodobě běžícím serveru se tyto úniky tiše hromadí, postupně spotřebovávají paměť, dokud se služba nepokazí nebo nespadne — a je obtížné je zaznamenat, protože se zobrazuje okamžitá chyba.

Porozumění příčinám (zablokované operace na kanálech, chybějící zrušení) a prevencím (**zrušení na základě kontextu** jako primární obrana, správné zavírání kanálů, bufferované kanály, zajištění příjemců) je nezbytné pro psaní spolehlivého souběžného Go.

Znalost nástrojů detekce (`runtime.NumGoroutine`, pprof, goleak) je stejně důležitá.

Toto je kritické, často testované téma, které odděluje vývojáře, kteří umí psát produkční souběžné Go, od těch, kteří psují kód, který se unese pod soustředěnou zátěží.