Gestión de memoria y recolector de basura en JavaScript: cómo funciona

¿Por qué JavaScript limpia por nosotros, pero aun así debemos entender cómo funciona?

Cuando escribes en JavaScript, rara vez piensas en lo que sucede con las variables después de que salen del ámbito de visibilidad. A diferencia de C o C++, donde debes llamar manualmente a free() o delete, JavaScript se encarga del trabajo sucio de limpiar la memoria. Esto es conveniente, hasta que llega el momento en que tu aplicación comienza a «ir lenta», consumir gigabytes de RAM o fallar repentinamente con el error Out of Memory.

¿Te suena familiar? Entonces analicemos cómo funciona realmente la gestión de memoria en JavaScript y qué es el recolector de basura de JavaScript. Spoiler: no es magia, sino un algoritmo estricto que se puede (y se debe) tener en cuenta al escribir código.

Cómo almacena datos JavaScript: pila y montón

Antes de hablar sobre la recolección de basura, debemos entender dónde viven los datos. En JavaScript hay dos almacenes principales:

\n
• Pila (Stack) — memoria rápida pero limitada. Allí se almacenan los primitivos (números, cadenas, valores booleanos) y las referencias a objetos. Cada llamada a función crea un nuevo marco en la pila.
\n
• Montón (Heap) — área de memoria no estructurada donde viven objetos, arreglos, funciones y clausuras. Aquí es donde ocurre la principal lucha por la memoria.
\n

Cuando creas un objeto:

let user = { name: 'Iván', age: 30 };\n

La referencia user va a la pila, y el objeto en sí { name: 'Iván', age: 30 } va al montón. Mientras el objeto tenga al menos una referencia, está vivo. Cuando no quedan referencias, el objeto se convierte en «basura».

Recolector de basura en JavaScript: el protagonista

El recolector de basura en JavaScript (Garbage Collector, GC) es un proceso en segundo plano que verifica periódicamente el montón y elimina los objetos inalcanzables. Suena simple, pero en la práctica es un compromiso complejo entre la velocidad de limpieza y el rendimiento de tu código.

Algoritmo Mark-and-Sweep (Marcado y barrido)

Los motores modernos (V8 en Chrome, SpiderMonkey en Firefox) utilizan el algoritmo Mark-and-Sweep. Funciona en dos etapas:

\n
1. Mark (Marcado): El GC comienza desde los objetos raíz (objeto global, funciones actuales, variables locales). Recorre todas las referencias desde las raíces y marca cada objeto alcanzable.
\n
2. Sweep (Barrido): Todos los objetos no marcados se consideran basura y se eliminan. La memoria se libera.
\n

Ejemplo sencillo:

let a = { data: 'A' };\nlet b = { data: 'B' };\na.ref = b;  // a referencia a b\nb.ref = a;  // b referencia a a\n\n// Ahora tenemos una referencia circular\na = null;   // a ya no apunta al objeto\nb = null;   // b ya no apunta al objeto\n

Antes (de la llegada de Mark-and-Sweep), estas referencias circulares provocaban fugas. Pero el GC moderno entiende: si ambos objetos son inalcanzables desde la raíz, son basura, incluso si se referencian entre sí.

Generaciones de objetos: jóvenes y viejos

La mayoría de los objetos viven poco tiempo. Por ejemplo, variables temporales dentro de una función. Por eso V8 divide el montón en generaciones:

\n
• Young Generation (Generación joven): objetos nuevos. La recolección aquí ocurre con frecuencia y rapidez (Scavenge — algoritmo que copia objetos vivos a otra área).
\n
• Old Generation (Generación vieja): objetos que han sobrevivido varias recolecciones. Se revisan con menos frecuencia, pero el proceso lleva más tiempo.
\n

Este enfoque permite no «congelar» la página durante una verificación completa de todo el montón.

Fugas de memoria en JavaScript: cómo provocarlas (y no hacerlo)

Incluso con un inteligente recolector de basura, se puede crear una situación en la que la memoria no se libere. Estas son las causas más comunes de fugas