0Pricing
Node.js Backend Development Bootcamp · Lección

El heap de V8, el GC generacional y los ciclos de vida de los objetos

Comprenda cómo V8 asigna y recopila memoria entre las generaciones joven y antigua.

El heap de V8, el GC generacional y los ciclos de vida de los objetos es una lección gratuita de Node.js Backend Development Bootcamp en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Node.js Backend Development Bootcamp, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Node.js Backend Development Bootcamp incluye 4 lecciones en total.

Partes de esta lección aún no han sido traducidas y se muestran en inglés.

Why Heap Mechanics Matter in Node

Every object, closure, and buffer your Node.js service allocates lives somewhere in V8's managed memory. Understanding where it lives and when it gets reclaimed is the difference between a service that holds steady at 200 MB and one that creeps toward an OOM crash under load.

V8 splits its managed memory into two main regions:

  • New space (young generation) — small, fast, where almost every object is born.
  • Old space (old generation) — large, where objects that survive go to live.

You can inspect the live numbers at runtime with process.memoryUsage().

// heap_snapshot.js — print V8 heap usage in MB
function mb(bytes) {
  return (bytes / 1024 / 1024).toFixed(2) + ' MB';
}

const u = process.memoryUsage();
console.log('rss        ', mb(u.rss));        // total process memory
console.log('heapTotal  ', mb(u.heapTotal));  // V8 heap reserved
console.log('heapUsed   ', mb(u.heapUsed));   // V8 heap live
console.log('external   ', mb(u.external));   // C++ objects bound to JS
console.log('arrayBuffers', mb(u.arrayBuffers));

The Weak Generational Hypothesis

V8's GC is built on a single empirical observation called the weak generational hypothesis: most objects die young.

In a typical request handler, you allocate request-scoped objects — parsed JSON bodies, temporary arrays, intermediate strings — that become garbage the instant the response is sent. A small minority (caches, connection pools, module-level singletons) survive for the lifetime of the process.

This skew lets V8 optimize aggressively: it collects the young generation frequently and cheaply, and the old generation rarely and thoroughly. Each generation gets a GC algorithm tuned to its survival profile.

New Space: Scavenge and Semi-Spaces

New space is collected by the Scavenger, a copying collector using Cheney's algorithm. New space is split into two equal halves called semi-spaces: to-space and from-space.

  • New objects are bump-allocated into to-space (just advance a pointer — extremely fast).
  • When to-space fills, a minor GC (scavenge) runs: live objects are copied into from-space, the roles flip, and the old to-space is wiped wholesale.

Because cost is proportional to surviving objects (not garbage), and most objects are dead by collection time, scavenges are very cheap — typically under a millisecond.

Allocating in the Young Generation

Watch the young generation in action. The loop below allocates millions of short-lived objects. Each one dies almost immediately, so they never leave new space — the Scavenger reclaims them in tight, cheap cycles and heapUsed stays roughly flat.

This is the ideal allocation pattern for a request handler: allocate freely, let objects die fast, and the GC barely notices.

// young_gen.js — millions of short-lived allocations
function work() {
  let acc = 0;
  for (let i = 0; i < 5_000_000; i++) {
    // {x, y} is born and dies within the iteration
    const point = { x: i, y: i * 2 };
    acc += point.x + point.y;
  }
  return acc;
}

const before = process.memoryUsage().heapUsed;
const result = work();
const after = process.memoryUsage().heapUsed;
console.log('result:', result);
console.log('heapUsed delta (MB):', ((after - before) / 1024 / 1024).toFixed(2));

Promotion: Surviving Into Old Space

An object that survives a scavenge is not immediately old. V8 tracks survival per object:

  • An object surviving its first scavenge is copied to from-space (still young, but now in an intermediate state).
  • An object that survives a second scavenge is promoted (tenured) into old space.

So objects referenced long enough to live through two minor GCs graduate to the old generation. There is also an aggressive promotion path: if to-space is more than ~80–90% full after a scavenge, V8 promotes survivors early to avoid thrashing the small semi-space.

Forcing Promotion With a Retained Reference

The pattern below retains every allocated object in a long-lived array. Those objects survive repeated scavenges, get promoted to old space, and heapUsed climbs steadily. This is exactly what an unbounded in-memory cache looks like — and how a slow leak begins.

The lesson: retention, not allocation rate, is what fills old space. A handler that allocates a million objects but keeps none costs almost nothing; one that keeps a thousand forever leaks.

// promotion.js — retained objects get tenured into old space
const retained = [];

for (let i = 0; i < 1_000_000; i++) {
  // pushing keeps a live reference -> survives scavenges -> promoted
  retained.push({ id: i, payload: 'item-' + i });
}

const u = process.memoryUsage();
console.log('retained length:', retained.length);
console.log('heapUsed (MB):', (u.heapUsed / 1024 / 1024).toFixed(2));
console.log('heapTotal (MB):', (u.heapTotal / 1024 / 1024).toFixed(2));

Old Space: Mark-Sweep-Compact

Old space is collected by a major GC using Mark-Sweep-Compact:

  • Mark — traverse the object graph from the GC roots (global object, the execution stack, native handles) and mark everything reachable.
  • Sweep — add the memory of unmarked (dead) objects to free lists for reuse.
  • Compact — occasionally relocate live objects to defragment, so large allocations can find contiguous space.

Major GC is far more expensive than a scavenge because it must walk the entire old generation. To avoid long pauses, V8 runs most of marking concurrently on background threads and incrementally interleaved with your JS — this is the Orinoco GC architecture.

Reachability Defines Garbage

An object is garbage if and only if it is unreachable from the GC roots. V8 does not use reference counting, so cycles are collected correctly — two objects pointing at each other are still garbage if nothing reachable points to either.

The corollary for backend code: a memory leak is almost always an accidental reference that keeps an object reachable. Common culprits are module-level Maps, event listeners never removed, and closures capturing large scopes.

// reachability.js — an unintentional cycle is still collectable
function makePair() {
  const a = {};
  const b = {};
  a.peer = b;   // a -> b
  b.peer = a;   // b -> a (cycle)
  return a;
}

let root = makePair();
console.log('reachable via root:', root.peer.peer === root);

root = null; // drop the only root reference
// Both a and b are now unreachable despite the cycle;
// V8 will reclaim them on the next GC. No leak.
console.log('root dropped; cycle is now garbage');

Sizing the Heap: --max-old-space-size

The old generation has a configurable ceiling. On 64-bit Node, the default old-space limit is roughly 2 GB (older versions defaulted near 1.5 GB; modern Node scales it to available memory). When old space cannot grow further and a major GC fails to free enough, the process dies with FATAL ERROR: ... JavaScript heap out of memory.

You raise the ceiling with the V8 flag --max-old-space-size (in MB):

  • node --max-old-space-size=4096 server.js sets a 4 GB old-space cap.

Raising it buys headroom but is not a fix for a leak — a leak will simply hit the new, higher limit later. Always pair sizing with leak diagnosis.

Observing GC With perf_hooks

You can directly observe minor vs. major GC events using the built-in perf_hooks PerformanceObserver with entryTypes: ['gc']. Each entry's detail.kind tells you the collection type:

  • NODE_PERFORMANCE_GC_MINOR — a scavenge (young generation).
  • NODE_PERFORMANCE_GC_MAJOR — a mark-sweep-compact (old generation).

Use this in load tests to confirm whether your service is dominated by cheap minor GCs (healthy) or frequent expensive major GCs (a retention problem).

// gc_observer.js — log each GC event and its duration
const { PerformanceObserver, constants } = require('perf_hooks');

const kinds = {
  [constants.NODE_PERFORMANCE_GC_MINOR]: 'minor (scavenge)',
  [constants.NODE_PERFORMANCE_GC_MAJOR]: 'major (mark-sweep)',
  [constants.NODE_PERFORMANCE_GC_INCREMENTAL]: 'incremental',
  [constants.NODE_PERFORMANCE_GC_WEAKCB]: 'weak-callback',
};

const obs = new PerformanceObserver((list) => {
  for (const e of list.getEntries()) {
    console.log(kinds[e.detail.kind] || 'other', '-', e.duration.toFixed(2), 'ms');
  }
});
obs.observe({ entryTypes: ['gc'] });

// generate garbage to trigger collections
let sink = [];
for (let i = 0; i < 2_000_000; i++) {
  sink.push({ i });
  if (sink.length > 50_000) sink = [];
}
console.log('done allocating');

Designing for the Generational GC

Concrete practices that keep your service friendly to V8's generational collector:

  • Let request data die young. Avoid stashing per-request objects in module-level structures; they get promoted and you pay major-GC cost forever.
  • Bound your caches. Use an LRU with a max size instead of an unbounded Map, so old space stays flat.
  • Prefer WeakMap/WeakRef for associative metadata keyed by objects you don't own — entries vanish when the key becomes unreachable.
  • Reuse big buffers via pools rather than re-allocating; large allocations stress old space and compaction.

The mental model: cheap, disposable young-generation churn is fine; long-lived growth in old space is what you must watch.

// weakmap_metadata.js — metadata that auto-collects with its key
const lastSeen = new WeakMap();

function touch(session) {
  lastSeen.set(session, Date.now()); // no strong ref to session
  return lastSeen.get(session);
}

let session = { id: 'abc' };
console.log('touched at:', touch(session));

session = null; // session unreachable -> WeakMap entry eligible for GC
console.log('session released; WeakMap entry will be reclaimed');

Quick Check: Object Lifetime

A reasoning question about how an object travels through V8's generations.

Recap: Heap, Generations, Lifetimes

What to carry forward:

  • Two generations. New space (young) holds freshly allocated objects; old space (old) holds survivors.
  • Weak generational hypothesis. Most objects die young, so V8 collects new space often and cheaply, old space rarely and thoroughly.
  • Scavenge. Minor GC copies live objects between semi-spaces; cost scales with survivors, not garbage.
  • Promotion. Surviving two scavenges (or filling to-space) tenures an object into old space.
  • Mark-Sweep-Compact. Major GC traces from roots, frees the unreachable, and occasionally compacts — run mostly concurrently/incrementally.
  • Leaks are retention. Unreachable means collectable, even through cycles; accidental long-lived references are what fill old space and cause OOM.
  • Tools. process.memoryUsage(), perf_hooks GC entries, and --max-old-space-size let you measure, observe, and size the heap.

Preguntas frecuentes

¿La lección «El heap de V8, el GC generacional y los ciclos de vida de los objetos» es gratis?

Sí — el texto completo de «El heap de V8, el GC generacional y los ciclos de vida de los objetos» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Node.js Backend Development Bootcamp, actualiza a CoddyKit PRO. El curso de Node.js Backend Development Bootcamp incluye 4 lecciones en total.

¿Qué aprenderé en «El heap de V8, el GC generacional y los ciclos de vida de los objetos»?

Comprenda cómo V8 asigna y recopila memoria entre las generaciones joven y antigua. Practicas Node.js Backend Development Bootcamp con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Node.js Backend Development Bootcamp?

No se requiere experiencia previa. Node.js Backend Development Bootcamp en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.

¿Cuánto tiempo toma la lección «El heap de V8, el GC generacional y los ciclos de vida de los objetos»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Node.js Backend Development Bootcamp?

Sí. Cada lección de Node.js Backend Development Bootcamp incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. El heap de V8, el GC generacional y los ciclos de vida de los objetos
  2. Captura y comparación de instantáneas del heap
  3. Perfilado de CPU y flame graphs para rutas críticas
  4. Detección y corrección de patrones comunes de fugas
← Volver a Node.js Backend Development Bootcamp