Comment Go gère-t-il la mémoire et le garbage collection?

Question

Accepted Answer

Go **gère automatiquement la mémoire** avec un garbage collector, vous libérant de l'allocation/libération manuelle. Son GC est un collecteur **concurrent, à faible latence, non-générationnel de marquage-balayage** conçu pour minimiser les temps de pause — une raison clé pour laquelle Go convient aux services sensibles à la latence.

## Stack vs heap et escape analysis

```go
// the compiler decides where each value lives via ESCAPE ANALYSIS
func noEscape() int {
    x := 42        // stays on the STACK — doesn't escape, freed when function returns (cheap)
    return x
}
func escapes() *int {
    x := 42        // ESCAPES to the HEAP — its pointer outlives the function (GC-managed)
    return &x
}
```

Le compilateur Go effectue une **escape analysis** à la compilation : les valeurs qui ne survivent pas à leur fonction restent sur le **stack** bon marché, automatiquement libéré ; les valeurs dont les références s'échappent vont sur le **heap** (où le GC les gère). L'allocation sur le stack est essentiellement gratuite, donc minimiser les échappements de heap réduit le travail du GC.

## Le garbage collector : marquage-balayage concurrent

```text
Go's GC characteristics:
  ✓ MARK-AND-SWEEP — marks reachable objects (from roots), sweeps the rest
  ✓ CONCURRENT — runs mostly alongside your program (not stop-the-world)
  ✓ LOW LATENCY — optimized for short pauses (typically sub-millisecond), not throughput
  ✓ NON-GENERATIONAL — unlike the JVM, treats all objects uniformly (simpler)
```

Go priorise délibérément les **temps de pause courts** sur le débit brut — le GC fait la plupart du travail de façon concurrente avec votre programme, gardant les pauses "stop-the-world" très courtes. Cela rend Go robuste pour les serveurs sensibles à la latence.

## Tuner le GC

```bash
GOGC=100   # default: trigger GC when heap grows 100% since the last collection
           # higher GOGC → less frequent GC (more memory, less CPU)
           # lower GOGC → more frequent GC (less memory, more CPU)
GOMEMLIMIT=2GiB   # a soft memory limit (Go 1.19+) — GC works harder near it
```

## Réduire la pression GC (technique de performance)

```go
// 1. reuse objects with sync.Pool to reduce allocations
var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}
buf := bufPool.Get().(*bytes.Buffer)
defer bufPool.Put(buf)

// 2. preallocate slices with known capacity (avoid repeated growth/realloc)
data := make([]int, 0, 1000)

// 3. minimize heap escapes; avoid unnecessary pointers/allocations in hot loops
```

Moins d'allocations = moins de travail GC. `sync.Pool` (réutilisation d'objets), préallocation, et minimisation des échappements sont les principaux moyens de réduire la pression GC dans les chemins critiques.

## Les fuites mémoire arrivent toujours

```text
GC frees only UNREACHABLE objects. Leaks come from lingering REFERENCES:
  ✗ goroutine leaks (a blocked goroutine keeps its referenced memory alive)
  ✗ growing global maps/slices, unclosed resources, forgotten subscriptions
```

## Pourquoi c'est important

La gestion automatique de la mémoire de Go est une grande victoire en termes de productivité et de sécurité (pas de free manuel, pas de pointeurs pendants), mais comprendre *comment* cela fonctionne est précieux pour les applications critiques en performance et sensibles à la latence — pour lesquelles Go est souvent choisi.

Points clés : l'**escape analysis** détermine l'allocation stack vs heap (stack est gratuit ; minimiser les échappements de heap réduit le travail GC), et le **GC concurrent, à faible latence** de Go priorise les pauses courtes sur le débit (idéal pour les serveurs, contrairement aux collecteurs axés sur le débit).

Savoir comment réduire la pression GC (`sync.Pool`, préallocation, moins d'allocations dans les boucles critiques), le tuner (`GOGC`, `GOMEMLIMIT`), et reconnaître que les **fuites arrivent toujours** à partir de références persistantes (notamment les fuites de goroutines) est important pour opérer des services Go haute-performance.

Ceci est une connaissance profonde et pratique qui distingue les développeurs Go seniors et est un sujet d'entretien avancé courant pour les rôles sensibles à la performance.