0Pricing
Node.js Backend Development Bootcamp · 课时

V8 堆、分代垃圾回收与对象生命周期

了解 V8 如何在新生代和老生代之间分配并回收内存。

V8 堆、分代垃圾回收与对象生命周期 是 CoddyKit 上的免费 Node.js Backend Development Bootcamp 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Node.js Backend Development Bootcamp 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Node.js Backend Development Bootcamp 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

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.

常见问题解答

「V8 堆、分代垃圾回收与对象生命周期」课时是免费的吗？

是的 — 「V8 堆、分代垃圾回收与对象生命周期」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Node.js Backend Development Bootcamp 课程的其余内容，请升级到 CoddyKit PRO。 Node.js Backend Development Bootcamp 课程共包含 4 节课。

「V8 堆、分代垃圾回收与对象生命周期」这节课中我会学到什么？

了解 V8 如何在新生代和老生代之间分配并回收内存。 你通过在浏览器中直接运行的动手代码来练习 Node.js Backend Development Bootcamp，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Node.js Backend Development Bootcamp 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Node.js Backend Development Bootcamp 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。

「V8 堆、分代垃圾回收与对象生命周期」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Node.js Backend Development Bootcamp 课中编写并运行代码吗？

能。每节 Node.js Backend Development Bootcamp 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. V8 堆、分代垃圾回收与对象生命周期
  2. 捕获并比较堆快照
  3. 热点路径的 CPU 分析与火焰图
  4. 检测并修复常见泄漏模式
← 返回 Node.js Backend Development Bootcamp