¿Qué causa fugas de goroutines y cómo las previene?

Question

Accepted Answer

Una **fuga de goroutines** es una goroutine que nunca termina — permanece bloqueada o ejecutándose para siempre, consumiendo memoria (y manteniendo vivos los objetos que referencia) durante toda la vida del programa. Dado que las goroutines son baratas de iniciar, es fácil tener fugas, y éstas se acumulan silenciosamente hasta que el servicio se degrada o se queda sin memoria.

## Causa 1: bloqueada en un canal sin emisor/receptor

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

Una goroutine bloqueada en un envío/recepción de canal que nunca se completa esperará **por siempre** — nunca se recolecta como basura porque técnicamente sigue "en ejecución".

## Causa 2: sin cancelación / señal de finalización

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

## Prevención 1: usar context para cancelación

```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 larga vida una manera de ser cancelada (`<-ctx.Done()`) es la defensa principal — asegura que las goroutines terminen cuando su trabajo ya no es necesario.

## Prevención 2: usar canales con búfer o asegurar 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
```

## Prevención 3: siempre cerrar canales / descargarlos correctamente

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

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

Monitorear `runtime.NumGoroutine()` (un contador que sube constantemente señala una fuga), inspeccionar volcados de goroutines vía `pprof`, y usar `goleak` en pruebas son las herramientas principales de detección.

## Por qué es importante

Las fugas de goroutines son uno de los problemas más comunes e insidiosos en servicios Go en producción.

Como las goroutines son tan baratas de lanzar, los desarrolladores las crean libremente — pero una goroutine bloqueada para siempre (en un canal sin contraparte, o en un bucle infinito sin cancelación) **nunca termina y nunca libera su memoria** (incluyendo todo lo que referencia).

En un servidor de larga duración, estas fugas se acumulan silenciosamente, consumiendo gradualmente memoria hasta que el servicio se degrada o se bloquea — y son difíciles de detectar porque no hay un error inmediato.

Comprender las causas (operaciones de canal bloqueadas, cancelación faltante) y las prevenciones (**cancelación basada en context** como defensa principal, cierre adecuado de canales, canales con búfer, asegurar receptores) es esencial para escribir código Go concurrente confiable.

Conocer las herramientas de detección (`runtime.NumGoroutine`, pprof, goleak) es igualmente importante.

Este es un tema crítico y frecuentemente evaluado que distingue a los desarrolladores que pueden escribir Go concurrente de nivel producción de aquellos que escriben código que tiene fugas bajo carga sostenida.