¿Cómo gestiona Python la memoria y la recolección de basura?

Question

Accepted Answer

Python gestiona la memoria de forma **automática** mediante dos mecanismos: el **conteo de referencias** (el método principal) más un **recolector de basura cíclico** que maneja los ciclos de referencias. Nunca liberas memoria manualmente, pero entender cómo funciona explica el comportamiento de la memoria y las fugas.

## Conteo de referencias: el mecanismo 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
```

Cada objeto rastrea cuántas referencias apuntan a él. Cuando el conteo llega a **cero**, la memoria se libera **de inmediato**. Esto es determinista y rápido: los objetos mueren en cuanto nada los referencia.

## El problema: los ciclos de referencias

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

Dos objetos que se referencian mutuamente mantienen el conteo del otro por encima de cero incluso cuando son inalcanzables: un ciclo que el conteo de referencias puro no puede recolectar.

## El recolector de basura cíclico

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

El **recolector de basura generacional** complementario de Python detecta y libera periódicamente estos ciclos inalcanzables. Es *generacional*: los objetos más nuevos se revisan con más frecuencia (la mayoría de los objetos mueren jóvenes), lo cual es eficiente.

## Implicaciones prácticas y fuentes de fugas

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

El GC maneja los ciclos, pero no puede liberar objetos que todavía son *alcanzables*: la "fuga" común del mundo real es mantener vivas referencias sin querer (por ejemplo, una caché global que solo crece).

## Otros detalles

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

## Por qué es importante

Comprender el modelo de memoria de Python —conteo de referencias rápido más un GC cíclico— explica comportamientos reales: por qué los objetos suelen liberarse de inmediato, por qué los ciclos de referencias necesitan el GC y, sobre todo, por qué las "fugas de memoria" en Python provienen de referencias *alcanzables* (cachés que crecen, closures persistentes, callbacks no eliminados) en lugar de liberaciones olvidadas.

Este conocimiento es esencial para diagnosticar el crecimiento de memoria en servicios de larga duración y para escribir código consciente de la memoria, sabiendo que la solución suele ser romper referencias (acotar cachés, limpiar registros) en lugar de algo que el GC pueda hacer por ti.