Skip to content
NeuralSkills
Depuracion

Cazador de Fugas de Memoria

Detecta fugas de memoria mediante analisis de heap, rastreo de referencias y patrones de comportamiento del garbage collector.

Avanzado Gratis Publicado: 15 de abril de 2026
Herramientas Compatibles claude-codechatgptgeminicopilotcursorwindsurfuniversal

El Problema

Las fugas de memoria son asesinas silenciosas — tu app funciona bien durante horas, luego se ralentiza gradualmente hasta que crashea con un error de memoria agotada. A diferencia de los crashes que apuntan a una linea de codigo, las fugas no dejan rastro directo. Un event listener que nunca se elimina, un closure que captura un objeto grande, un cache sin politica de desalojo — cada uno agrega unos kilobytes que nunca se liberan.

El Prompt

Eres un experto forense en fugas de memoria. Analiza este escenario y ayudame a rastrear la fuga:

RUNTIME: [ej. Node.js, Python, Java, browser JavaScript, Go]
SINTOMA: [ej. "RSS crece 50MB/hora", "uso de heap nunca baja despues de GC", "OOM kill tras 6 horas"]
DATOS DE PERFIL DE MEMORIA (si disponibles):
[pega diff de heap snapshot, timeline de memoria, u objetos retenidos principales]

CODIGO SOSPECHOSO:
[pega secciones de codigo que manejan suscripciones, event listeners, caches, closures u objetos de larga vida]

Realiza analisis de fuga de memoria:
1. **Clasificacion de Firma de Fuga**: Basado en el patron (crecimiento lineal, escalera, pico subito), clasificar el tipo probable de fuga.
2. **Analisis de Cadena de Retencion**: Para los objetos sospechosos, rastrear la cadena de referencias desde la raiz GC al objeto fugado. Que lo mantiene vivo?
3. **Patron de Acumulacion**: Calcular la tasa de fuga — cuanta memoria por operacion/request/minuto? Proyectar cuando ocurrira OOM.
4. **Top 5 Sospechosos**: Basado en el codigo y sintoma, rankear las fuentes de fuga mas probables con razonamiento.
5. **Fix Quirurgico**: Para cada sospechoso, proporcionar el cambio de codigo exacto para romper la cadena de retencion sin efectos secundarios.
6. **Protocolo de Verificacion**: Como confirmar que la fuga esta corregida — pasos especificos de comparacion de heap snapshots.

Ejemplo de Salida

Firma de fuga: Crecimiento lineal (~2MB/min) — clasica acumulacion de event listeners
Cadena de retencion: GC Root → WebSocket.listeners → closure anonimo → instancia de Componente → arbol DOM (50KB por componente)
Acumulacion: Cada navegacion de ruta agrega un listener WS pero nunca lo remueve. 1000 navegaciones = 50MB fugados
Fix: Agregar cleanup: return () => ws.removeEventListener('message', handler);
Verificacion: Tomar heap snapshot, navegar 100 veces, tomar segundo snapshot — "Objetos asignados entre snapshots" deberia mostrar 0 listeners desconectados

Cuando Usar

Usa este skill cuando el uso de memoria de tu aplicacion crece con el tiempo sin volver a la linea base, cuando ves crashes OOM en produccion despues de uptime prolongado, o cuando los heap snapshots muestran un numero inusual de objetos retenidos.

Tips Pro

  • Compara dos heap snapshots, no uno — un solo snapshot muestra todo en memoria. El diff entre dos muestra solo lo que se AGREGO, que es la fuga.
  • Fuerza GC antes de medir — en Node.js, ejecuta con --expose-gc y llama global.gc() antes de tomar mediciones.
  • Busca “Detached” en Chrome DevTools — filtra heap snapshots por “Detached” para encontrar nodos DOM que ya no estan en el documento pero siguen referenciados por JavaScript.
  • WeakRef y WeakMap son tus amigos — para caches y patrones observer, usa referencias debiles para que el GC pueda reclamar objetos.