0Pricing
Node.js Backend Development Bootcamp · Lezione

Heap di V8, garbage collection generazionale e ciclo di vita degli oggetti

Comprenda come V8 alloca e raccoglie la memoria tra le generazioni young e old.

Heap di V8, garbage collection generazionale e ciclo di vita degli oggetti è una lezione Node.js Backend Development Bootcamp gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Node.js Backend Development Bootcamp, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Node.js Backend Development Bootcamp include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

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.

Domande Frequenti

La lezione «Heap di V8, garbage collection generazionale e ciclo di vita degli oggetti» è gratuita?

Sì — il testo completo di «Heap di V8, garbage collection generazionale e ciclo di vita degli oggetti» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Node.js Backend Development Bootcamp, passa a CoddyKit PRO. Il corso Node.js Backend Development Bootcamp include 4 lezioni in totale.

Cosa imparerò in «Heap di V8, garbage collection generazionale e ciclo di vita degli oggetti»?

Comprenda come V8 alloca e raccoglie la memoria tra le generazioni young e old. Eserciti Node.js Backend Development Bootcamp con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Node.js Backend Development Bootcamp?

Non è richiesta alcuna esperienza precedente. Node.js Backend Development Bootcamp su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.

Quanto tempo richiede la lezione «Heap di V8, garbage collection generazionale e ciclo di vita degli oggetti»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Node.js Backend Development Bootcamp?

Sì. Ogni lezione Node.js Backend Development Bootcamp include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Heap di V8, garbage collection generazionale e ciclo di vita degli oggetti
  2. Acquisizione e confronto degli heap snapshot
  3. Profilazione della CPU e flame graph per gli hot path
  4. Rilevamento e risoluzione dei pattern comuni di memory leak
← Torna a Node.js Backend Development Bootcamp