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

Question

Accepted Answer

Ruby gère la mémoire **automatiquement** via un **garbage collector (GC)** qui récupère les objets qui ne sont plus référencés. Le Ruby moderne (MRI) utilise un collecteur **générationnel, incrémental et mark-and-sweep** avec compaction. Comprendre cela aide à diagnostiquer les problèmes de performance et de mémoire dans les applications de longue durée.

## Garbage collection automatique

```text
Ruby allocates objects on the heap; the GC reclaims those that are no longer REACHABLE
(referenced). You never free memory manually.

Modern MRI GC characteristics:
  ✓ Mark-and-sweep — marks reachable objects (from roots), sweeps unreachable ones
  ✓ Generational (since Ruby 2.1) — new objects collected often, old ones rarely
    (based on "most objects die young")
  ✓ Incremental — spreads GC work to reduce pause times
  ✓ Compacting (GC.compact, Ruby 2.7+) — reduces memory fragmentation
```

Le GC vous libère de la gestion manuelle de la mémoire. L'approche **générationnel** (collectant les jeunes objets fréquemment et à faible coût, les anciens rarement) la rend efficace, et la collection incrémentale réduit les pauses.

## Inspection et tuning du GC

```ruby
GC.stat                    # detailed GC statistics (counts, heap info)
GC.start                   # manually trigger a collection (rarely needed)
GC.compact                 # compact the heap (reduce fragmentation)
ObjectSpace.count_objects  # counts of objects by type (debugging)
# environment variables (RUBY_GC_*) tune heap growth, etc.
```

## Les fuites mémoire se produisent quand même (malgré le GC)

```ruby
# the GC frees only UNREACHABLE objects — "leaks" come from lingering references:
$global_cache = []
def process(item)
  $global_cache << item    # ❌ grows forever — never freed (still referenced)
end
```

```text
Common Ruby memory-growth causes:
  ✗ Global/class-level collections that only grow (caches, arrays)
  ✗ References held in long-lived objects (constants, class variables)
  ✗ Large objects kept alive by closures/blocks
→ The GC can't free reachable objects, so "leaks" = unintended retained references.
```

## Pourquoi c'est important

Comprendre la gestion de la mémoire et le garbage collection de Ruby est une connaissance précieuse, particulièrement pour les **applications Ruby de longue durée** (comme les serveurs web Rails, les workers de fond) où le comportement de la mémoire importe pour la stabilité et les performances.

Bien que le GC vous libère de la gestion manuelle de la mémoire (un bénéfice majeur de productivité), comprendre *comment* il fonctionne aide au tuning de performance et au diagnostic des problèmes de mémoire.

Savoir que le Ruby moderne utilise un collecteur **générationnel, incrémental et mark-and-sweep** (collectant les jeunes objets fréquemment et à faible coût, les anciens rarement, tout en répartissant le travail pour réduire les pauses) vous aide à raisonner sur le comportement et la pression du GC, et que l'allocation excessive d'objets augmente la surcharge du GC (ainsi réduire les allocations inutiles peut améliorer les performances).

Critiquement, comprendre que **les fuites mémoire se produisent quand même** malgré le GC — parce que le GC ne libère que les objets *inaccessibles*, donc les « fuites » proviennent de **références persistantes** non intentionnelles (collections au niveau global ou classe qui ne font que croître, comme les caches non bornés; références conservées dans les objets de longue durée; gros objets maintenus vivants par les closures) — est important pour diagnostiquer et corriger la croissance mémoire qui afflige les processus Ruby de longue durée (un problème opérationnel réel et courant).

Connaître le comportement du GC, comment l'inspecter (`GC.stat`, `ObjectSpace`), les options de tuning, et surtout les causes courantes de croissance mémoire (références conservées) est précieux pour exploiter des applications Ruby performantes et stables.

Comme les applications Ruby (particulièrement les serveurs Rails) s'exécutent pendant de longues périodes et les fuites mémoire dues aux références conservées sont un problème réel et fréquent, comprendre le GC de Ruby — son modèle générationnel mark-and-sweep, qu'il ne peut pas libérer les objets accessibles, et les causes de croissance mémoire — est une connaissance importante de niveau senior pour la performance et la fiabilité, distinguant les développeurs qui peuvent diagnostiquer et corriger les problèmes de mémoire en production Ruby, et un sujet pertinent pour les rôles axés sur la performance.