Qu'est-ce qui cause des fuites de goroutines et comment les prévenir ?

Question

Accepted Answer

Une **fuite de goroutine** est une goroutine qui ne se termine jamais — elle reste bloquée ou s'exécute indéfiniment, consommant de la mémoire (et gardant vivants les objets qu'elle référence) pendant toute la durée du programme. Puisque les goroutines sont peu coûteuses à démarrer, il est facile de les laisser fuir, et les fuites s'accumulent silencieusement jusqu'à ce que le service se dégrade ou manque de mémoire.

## Cause 1 : bloquée sur un canal sans émetteur/récepteur

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

Une goroutine bloquée sur un envoi/réception de canal qui ne se termine jamais attendra **indéfiniment** — elle ne sera jamais récupérée par le garbage collector car elle est techniquement toujours « en exécution ».

## Cause 2 : pas de cancellation / signal done

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

## Prévention 1 : utiliser context pour la cancellation

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

Donner à chaque goroutine longue durée un moyen d'être annulée (`<-ctx.Done()`) est la défense principale — cela garantit que les goroutines se terminent quand leur travail n'est plus nécessaire.

## Prévention 2 : utiliser des canaux bufferisés ou assurer les récepteurs

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

## Prévention 3 : toujours fermer les canaux / les vider correctement

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

## Détecter les fuites

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

Surveiller `runtime.NumGoroutine()` (un nombre qui augmente régulièrement signale une fuite), inspecter les dumps de goroutines via `pprof`, et utiliser `goleak` dans les tests sont les principaux outils de détection.

## Pourquoi c'est important

Les fuites de goroutines sont l'un des problèmes les plus courants et les plus insidieux dans les services Go en production.

Parce que les goroutines sont si peu coûteuses à lancer, les développeurs les créent librement — mais une goroutine bloquée indéfiniment (sur un canal sans contrepartie, ou dans une boucle infinie sans cancellation) **ne se termine jamais et ne libère jamais sa mémoire** (y compris tout ce qu'elle référence).

Dans un serveur longue durée, ces fuites s'accumulent silencieusement, consommant progressivement de la mémoire jusqu'à ce que le service se dégrade ou plante — et elles sont difficiles à repérer car il n'y a pas d'erreur immédiate.

Comprendre les causes (opérations de canal bloquées, cancellation manquante) et les préventions (**cancellation basée sur context** comme défense principale, fermeture correcte des canaux, canaux bufferisés, assurer les récepteurs) est essentiel pour écrire des Go concurrents fiables.

Connaître les outils de détection (`runtime.NumGoroutine`, pprof, goleak) est tout aussi important.

C'est un sujet critique et fréquemment testé qui sépare les développeurs qui peuvent écrire du Go concurrent de qualité production de ceux qui écrivent du code qui fuit sous charge soutenue.