Comment Python gère-t-il la mémoire et la récupération des déchets ?

Question

Accepted Answer

Python gère la mémoire **automatiquement** en utilisant deux mécanismes : le **comptage de références** (la méthode principale) plus un **collecteur de déchets cyclique** qui traite les cycles de références. Vous ne libérez jamais manuellement la mémoire, mais comprendre son fonctionnement explique le comportement de la mémoire et les fuites.

## Comptage de références — le mécanisme principal

```python
import sys

x = [1, 2, 3]        # the list object has refcount 1
y = x                 # refcount 2 (another name references it)
sys.getrefcount(x)    # shows the count (slightly higher due to the call itself)

del y                 # refcount 1
del x                 # refcount 0 → the object is FREED immediately
```

Chaque objet suit le nombre de références qui le pointent. Quand le nombre tombe à **zéro**, la mémoire est libérée **immédiatement**. C'est déterministe et rapide — les objets disparaissent dès que rien ne les référence.

## Le problème : les cycles de références

```python
# reference counting alone can't free this:
a = {}
b = {}
a["b"] = b      # a references b
b["a"] = a      # b references a → they reference EACH OTHER
del a, b        # the names are gone, but the objects still reference each other
# → refcounts never reach 0 → they'd leak with refcounting alone
```

Deux objets se référençant mutuellement gardent le refcount de l'autre au-dessus de zéro même lorsqu'ils sont inaccessibles — un cycle que le comptage pur de références ne peut pas collecter.

## Le collecteur de déchets cyclique

```python
import gc

# the generational GC periodically finds and frees unreachable CYCLES
gc.collect()        # manually trigger a collection
gc.get_count()      # objects tracked per generation
```

Le **collecteur de déchets générationnel** supplémentaire de Python détecte et libère périodiquement ces cycles inaccessibles. Il est *générationnel* — les objets plus récents sont vérifiés plus souvent (la plupart des objets meurent jeunes), ce qui est efficace.

## Implications pratiques et sources de fuites

```text
✓ Most memory is reclaimed promptly via reference counting
⚠️ Leaks still happen from REACHABLE references that outlive their usefulness:
   - global caches/lists that only grow
   - objects held by long-lived closures or class attributes
   - registered callbacks/listeners never removed
```

Le GC traite les cycles, mais il ne peut pas libérer les objets qui sont toujours *accessibles* — la « fuite » réelle courante dans le monde réel est de garder involontairement les références actives (par exemple un cache global en constante croissance).

## Autres détails

```text
- Small integers (-5..256) and short strings are CACHED/interned (shared, reused)
- CPython uses memory pools (pymalloc) for small objects (efficiency)
```

## Pourquoi c'est important

Comprendre le modèle de mémoire de Python — comptage de références rapide plus un GC cyclique — explique les comportements réels : pourquoi les objets sont généralement libérés immédiatement, pourquoi les cycles de références ont besoin du GC, et surtout pourquoi les « fuites de mémoire » en Python proviennent de références *accessibles* (caches en croissance, closures persistantes, callbacks non supprimés) plutôt que de libérations oubliées.

Cette connaissance est essentielle pour diagnostiquer la croissance de la mémoire dans les services longue durée et pour écrire du code conscient de la mémoire — sachant que la solution est généralement de casser les références (limiter les caches, nettoyer les enregistrements) plutôt que quelque chose que le GC puisse faire pour vous.