O que causa vazamentos de goroutine e como você os previne?

Question

Accepted Answer

Um **vazamento de goroutine** é uma goroutine que nunca termina — ela fica bloqueada ou em execução para sempre, consumindo memória (e mantendo seus objetos referenciados vivos) durante a vida útil do programa. Como goroutines são baratas de iniciar, é fácil vazá-las, e os vazamentos se acumulam silenciosamente até que o serviço se degrade ou fique sem memória.

## Causa 1: bloqueada em um canal sem remetente/destinatário

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

Uma goroutine bloqueada em um envio/recebimento de canal que nunca é concluído esperará **para sempre** — ela nunca é coletada como lixo porque tecnicamente ainda está "em execução".

## Causa 2: sem cancelamento / sinal de conclusão

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

## Prevenção 1: use context para cancelamento

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

Dar a cada goroutine de longa duração uma forma de ser cancelada (`<-ctx.Done()`) é a defesa principal — garante que as goroutines terminem quando seu trabalho não for mais necessário.

## Prevenção 2: use canais com buffer ou garanta receptores

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

## Prevenção 3: sempre feche canais / drene-os adequadamente

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

## Detectando vazamentos

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

Monitorar `runtime.NumGoroutine()` (uma contagem que sobe constantemente sinaliza um vazamento), inspecionar dumps de goroutine via `pprof` e usar `goleak` nos testes são as principais ferramentas de detecção.

## Por que isso importa

Vazamentos de goroutine são um dos problemas mais comuns e insidiosos em serviços Go em produção.

Como goroutines são muito baratas de lançar, desenvolvedores as criam livremente — mas uma goroutine bloqueada para sempre (em um canal sem contrapartida, ou em um loop infinito sem cancelamento) **nunca termina e nunca libera sua memória** (incluindo tudo o que ela referencia).

Em um servidor de longa duração, esses vazamentos se acumulam silenciosamente, consumindo memória gradualmente até que o serviço se degrade ou quebre — e são difíceis de detectar porque não há erro imediato.

Entender as causas (operações de canal bloqueadas, cancelamento ausente) e as prevenções (**cancelamento baseado em context** como defesa principal, fechamento adequado de canais, canais com buffer, garantindo receptores) é essencial para escrever Go concorrente confiável.

Conhecer as ferramentas de detecção (`runtime.NumGoroutine`, pprof, goleak) é igualmente importante.

Este é um tópico crítico e frequentemente testado que diferencia desenvolvedores que conseguem escrever Go concorrente de nível de produção daqueles que escrevem código que vaza sob carga sustentada.