0Pricing
Node.js Backend Development Bootcamp · レッスン

V8ヒープ、世代別GC、オブジェクトのライフサイクル

V8が若い世代と古い世代にまたがってメモリを割り当て、回収する仕組みを理解します。

「V8ヒープ、世代別GC、オブジェクトのライフサイクル」はCoddyKit上の無料Node.js Backend Development Bootcampレッスンです。 これはレッスン1/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応の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ヒープ、世代別GC、オブジェクトのライフサイクル」レッスンは無料ですか？

はい。「V8ヒープ、世代別GC、オブジェクトのライフサイクル」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Node.js Backend Development Bootcampコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Node.js Backend Development Bootcampコースには全4レッスンが含まれています。

「V8ヒープ、世代別GC、オブジェクトのライフサイクル」で何を学びますか？

V8が若い世代と古い世代にまたがってメモリを割り当て、回収する仕組みを理解します。 ブラウザで直接実行するハンズオンコードでNode.js Backend Development Bootcampを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Node.js Backend Development Bootcampを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのNode.js Backend Development Bootcampは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン1/4です。

「V8ヒープ、世代別GC、オブジェクトのライフサイクル」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このNode.js Backend Development Bootcampレッスンでコードを書いて実行できますか？

はい。すべてのNode.js Backend Development Bootcampレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. V8ヒープ、世代別GC、オブジェクトのライフサイクル
  2. ヒープスナップショットの取得と比較
  3. ホットパス向けCPUプロファイリングとフレームグラフ
  4. 一般的なリークパターンの検出と修正
← Node.js Backend Development Bootcampに戻る