Closures, Scope Chains y Garbage Collection
Tiempo estimado de lectura: 4 min
- Closures retienen el Lexical Environment: una función mantiene referencias al entorno donde fue creada.
- Scope chain y resolución: el motor busca identificadores subiendo por la cadena de entornos hasta global.
- Hoisting real y TDZ: funciones, var, let/const se registran de forma distinta durante la fase de creación.
- GC y fugas: closures pueden retener objetos grandes; motores aplican optimizaciones pero no son infalibles.
- Prácticas: usar WeakMap, nullificar referencias y auditar memoria con DevTools.
Closures, Scope Chains y Garbage Collection: saber definir un closure es solo el primer paso. Lo que cuenta en producción es entender cómo el Lexical Environment, la resolución de scope y el Hoisting real afectan la retención de memoria y la estabilidad de tus apps. Si no controlas eso, acabarás depurando fugas que solo aparecen tras días de uptime.
En las siguientes secciones desgloso cómo funciona realmente el motor, por qué las variables “siguen vivas” y qué reglas prácticas aplicar para evitar memory leaks.
Resumen rápido (lectores con prisa)
Un closure es una función que conserva una referencia al Lexical Environment donde fue creada. Úsalo para encapsular estado, pero evita mantener dentro datos pesados si la función debe persistir. La resolución de identificadores recorre la scope chain desde el entorno actual hacia afuera; el GC libera lo inaccesible desde las raíces, pero un closure mantiene accesible su entorno. Reglas prácticas: preferir let/const, usar WeakMap para caches recuperables y nullificar referencias grandes cuando ya no hacen falta.
Cómo interactúan Closures, Scope Chains y Garbage Collection
Un closure no es magia. Es una función que mantiene una referencia al Lexical Environment donde fue creada. Ese entorno contiene los Environment Records con las variables locales y una referencia al outer environment. Esa cadena de enlaces es la Scope Chain.
Técnicamente:
- Cada invocación crea un Execution Context (fase de creación + fase de ejecución). (ECMAScript spec)
- En la fase de creación el motor reserva espacio para identificadores (hoisting real).
- El Lexical Environment conserva variables y la referencia al parent; cuando una función exterior retorna pero su función interior sigue referenciable, ese Lexical Environment sigue vivo.
Resolución de identificadores (algoritmo)
- mira el Environment Record del contexto actual;
- si no está, sube al outer;
- repite hasta el global;
- si no lo encuentra, lanza
ReferenceError.
Ese viaje explica por qué let/const (scope de bloque) y var (scope de función) se comportan distinto. Referencias útiles: MDN Event Loop / Scope y ECMAScript Execution Contexts.
Hoisting real y Temporal Dead Zone (TDZ)
Olvida la metáfora “el motor mueve las declaraciones arriba”. Durante la fase de creación el motor:
- registra
functiondeclarations completamente; - reserva
varinicializado aundefined; - registra
letyconstpero las deja en estado uninitialized.
Intentar acceder a una let antes de su inicialización entra en la TDZ y lanza ReferenceError. Ejemplo:
console.log(a); // ReferenceError (TDZ)
let a = 3;
Contrástalo con var:
console.log(b); // undefined
var b = 3;
Documentación V8 sobre let/const: Documentación V8 sobre let/const.
El lado oscuro: closures que retienen más de lo necesario
El Garbage Collector (Mark-and-Sweep) libera objetos inaccesibles desde las raíces. Un closure mantiene accesible su Lexical Environment, y por tanto todas las variables que contiene pueden quedar retenidas.
Ejemplo típico de fuga:
function creaLeak() {
const datosPesados = new Array(1e6).fill('*'); // memoria grande
const info = 'ok';
return function () {
console.log(info); // solo usamos `info`, pero `datosPesados` puede quedar retenido
};
}
const fn = creaLeak(); // datosPesados sigue referenciado por el ambiente de fn
Motores modernos (p. ej. V8) aplican optimizaciones como Variable Elimination y Escape Analysis para evitar retener variables que no “escapan”. Pero estas optimizaciones pueden fallar con eval, with, o si el entorno está expuesto al inspector/debugger. V8 blog: V8 blog.
Patrones seguros y antipatrónes a vigilar
Patrones a promover:
- Factory functions y módulos para encapsular estado (closures usados con intención).
WeakMappara caches donde las claves deben ser recolectables.- Nullificar referencias grandes cuando el closure debe persistir pero los datos no:
bigObject = null.
Antipatrónes comunes:
- Closures en listeners globales sin remover el listener.
- Uso de
varen loops que provoca referencias compartidas (legacy). - Retener objetos grandes “por si acaso” dentro de scopes accesibles.
Auditoría práctica: cómo detectar y reparar leaks
- Captura heap snapshots en Chrome DevTools (Memory → Heap snapshot). Busca objetos con alto “retained size”.
- Reproduce en staging con carga real y toma snapshots antes/después de operaciones críticas.
- Identifica closures que retienen objetos: DevTools muestra paths to GC roots.
- Refactoriza: mover datos pesados fuera del closure, usar
WeakMap, o eliminar listeners.
Guía DevTools: Guía DevTools.
Reglas de oro para equipos técnicos
- Usa
let/constpor defecto.varcrea más posibilidades de confusión. - Revisa closures en code review: pregunta “¿qué datos retiene esto?”.
- Evita
evalywith(bloquean optimizaciones). - Para objetos grandes, preferir estructuras weakly-referenced cuando la vida útil debe coincidir con el objeto clave.
- Automatiza perfiles de memoria en staging y alerta por crecimiento continuo.
Conclusión
Closures y scope chains son poderosas herramientas de diseño; su coste real aparece en producción cuando retienen más memoria de la necesaria. Aprende a leer el Lexical Environment, comprende el Hoisting real y la TDZ, y aplica patrones que permitan al GC hacer su trabajo. Tu aplicación será más estable, tus ops menos nocturnas y tu equipo verá menos incendios por memoria.
Lecturas y referencias
FAQ
- ¿Qué es exactamente un closure?
- ¿Cuándo un closure puede provocar una fuga de memoria?
- ¿Cómo difiere el hoisting entre var, let y const?
- ¿Qué herramientas usar para detectar closures que retienen memoria?
- ¿Cuándo debo usar WeakMap?
- ¿Qué prácticas de equipo reducen riesgos de memory leaks?
¿Qué es exactamente un closure?
Un closure es una función junto con el Lexical Environment en el que fue creada; mantiene referencias a las variables de ese entorno aunque la función exterior haya retornado.
¿Cuándo un closure puede provocar una fuga de memoria?
Cuando el closure sigue siendo referenciable y su Lexical Environment contiene objetos grandes que ya no se usan, esos objetos permanecen accesibles desde las raíces y no son recolectados.
¿Cómo difiere el hoisting entre var, let y const?
var: se registra durante la fase de creación e inicializa a undefined. let/const: se registran pero quedan en estado no inicializado hasta la ejecución, entrando en TDZ si se accede antes.
¿Qué herramientas usar para detectar closures que retienen memoria?
Chrome DevTools — Heap snapshots y análisis de paths to GC roots. Reproduce en staging y compara snapshots antes/después de operaciones críticas.
¿Cuándo debo usar WeakMap?
Usa WeakMap para caches o asociaciones donde la clave debe ser recolectable cuando no existan otras referencias fuertes; útil para evitar retener objetos por el cache.
¿Qué prácticas de equipo reducen riesgos de memory leaks?
Adoptar let/const, revisar closures en code reviews preguntando qué datos retienen, evitar eval/with, y automatizar perfiles de memoria en staging con alertas por crecimiento continuo.
