Cosa causa i goroutine leak e come li previeni?

Question

Accepted Answer

Un **goroutine leak** è un goroutine che non termina mai — rimane bloccato o in esecuzione all'infinito, consumando memoria (e mantenendo vivi gli oggetti a cui fa riferimento) per tutta la durata del programma. Poiché i goroutine sono economici da avviare, è facile farli perdere, e i leak si accumulano silenziosamente finché il servizio non si degrada o non esaurisce la memoria.

## Causa 1: bloccato su un canale senza mittente/ricevitore

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

Un goroutine bloccato su un invio/ricezione di canale che non si completa mai rimarrà bloccato **per sempre** — non viene mai sottoposto a garbage collection perché è tecnicamente ancora "in esecuzione".

## Causa 2: nessuna cancellazione / segnale di conclusione

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

## Prevenzione 1: usa context per la cancellazione

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

Dare a ogni goroutine di lunga durata un modo per essere cancellato (`<-ctx.Done()`) è la difesa principale — garantisce che i goroutine terminino quando il loro lavoro non è più necessario.

## Prevenzione 2: usa canali bufferizzati o assicura ricevitori

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

## Prevenzione 3: chiudi sempre i canali / drenali correttamente

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

## Rilevamento dei leak

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

Monitorare `runtime.NumGoroutine()` (un conteggio in aumento costante segnala un leak), ispezionare i dump dei goroutine tramite `pprof` e usare `goleak` nei test sono i principali strumenti di rilevamento.

## Perché è importante

I goroutine leak sono uno dei problemi più comuni e insidiosi nei servizi Go in produzione.

Poiché i goroutine sono così economici da avviare, gli sviluppatori li creano liberamente — ma un goroutine bloccato per sempre (su un canale senza controparte, o in un ciclo infinito senza cancellazione) **non termina mai e non rilascia mai la sua memoria** (incluso tutto ciò a cui fa riferimento).

In un server di lunga durata, questi leak si accumulano silenziosamente, consumando gradualmente memoria finché il servizio non si degrada o non va in crash — e sono difficili da individuare perché non c'è un errore immediato.

Comprendere le cause (operazioni di canale bloccate, cancellazione mancante) e le prevenzioni (**cancellazione basata su context** come difesa principale, chiusura corretta dei canali, canali bufferizzati, assicurare ricevitori) è essenziale per scrivere Go concorrente affidabile.

Conoscere gli strumenti di rilevamento (`runtime.NumGoroutine`, pprof, goleak) è ugualmente importante.

Questo è un argomento critico e frequentemente testato che separa gli sviluppatori che riescono a scrivere Go concorrente di qualità produttiva da quelli che scrivono codice che perde memoria sotto carico sostenuto.