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

Question

Accepted Answer

Ruby gestiona la memoria **automáticamente** a través de un **recolector de basura (GC)** que reclama objetos que ya no están referenciados. Ruby moderno (MRI) utiliza un recolector **generacional, incremental mark-and-sweep** con compactación. Comprenderlo ayuda con el rendimiento y el diagnóstico de problemas de memoria en aplicaciones de larga duración.

## Recolección automática de basura

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

El GC te libera de la gestión manual de memoria. El enfoque **generacional** (recolectando objetos jóvenes frecuentemente y de forma económica, los antiguos raramente) lo hace eficiente, y la recolección incremental reduce las pausas.

## Inspeccionar y ajustar el 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.
```

## Las fugas de memoria aún ocurren (a pesar del 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.
```

## Por qué es importante

Comprender la gestión de memoria y la recolección de basura de Ruby es un conocimiento valioso, particularmente para **aplicaciones Ruby de larga duración** (como servidores web Rails, workers en segundo plano) donde el comportamiento de la memoria importa para la estabilidad y el rendimiento.

Aunque el GC te libera de la gestión manual de memoria (un beneficio importante de productividad), comprender *cómo* funciona ayuda con la optimización del rendimiento y el diagnóstico de problemas de memoria.

Saber que Ruby moderno utiliza un recolector **generacional, incremental, mark-and-sweep** (recolectando objetos jóvenes frecuentemente y de forma económica, los antiguos raramente, mientras distribuye el trabajo para reducir pausas) te ayuda a razonar sobre el comportamiento y la presión del GC, y que la asignación excesiva de objetos aumenta la sobrecarga del GC (por lo que reducir asignaciones innecesarias puede mejorar el rendimiento).

Críticamente, comprender que **las fugas de memoria aún ocurren** a pesar del GC — porque el GC solo libera objetos *inalcanzables*, por lo que las "fugas" provienen de **referencias que persisten** sin intención (colecciones globales o a nivel de clase que solo crecen, como cachés sin límite; referencias mantenidas en objetos de larga vida; objetos grandes mantenidos vivos por closures) — es importante para diagnosticar y reparar el crecimiento de memoria que afecta a los procesos Ruby de larga duración (un problema operacional real y frecuente).

Conocer el comportamiento del GC, cómo inspeccionarlo (`GC.stat`, `ObjectSpace`), opciones de ajuste, y especialmente las causas comunes del crecimiento de memoria (referencias retenidas) es valioso para operar aplicaciones Ruby performantes y estables.

Puesto que las aplicaciones Ruby (especialmente servidores Rails) se ejecutan durante períodos largos y las fugas de memoria por referencias retenidas son un problema frecuente en el mundo real, comprender el GC de Ruby — su modelo generacional mark-and-sweep, que no puede liberar objetos alcanzables, y las causas del crecimiento de memoria — es un conocimiento importante de nivel senior para el rendimiento y la confiabilidad, diferenciando desarrolladores que pueden diagnosticar y reparar problemas de memoria en Ruby en producción, y un tema relevante para roles enfocados en el rendimiento.