ガベージコレクションのブラウザ内動作（世代別GCとメモリリーク）

なぜGCの内部を知るのか

JavaScriptはメモリの確保・解放を明示しない言語で、不要になったオブジェクトはガベージコレクタ（GC）が自動回収します。便利な反面、「GCがあるのにメモリが増え続ける」「ときどき処理がカクつく」といった現象は、GCの判断基準と回収タイミングを知らないと原因にたどり着けません。鍵となるのは、GCが回収するのは「使われていないオブジェクト」ではなくどこからも到達できなくなったオブジェクトだという一点です。本稿はChromeやNode.jsが使うV8を題材に、世代別GCの仕組みとリークの原理を内部動作から説明します。前提として JavaScript の値とオブジェクトの扱い、エンジン全体像は JavaScriptエンジンの内部 を押さえておくと理解が速いです。

到達可能性（Reachability）：GCの唯一の基準

V8のGCは参照カウントではなく到達可能性ベースで動きます。GCルート（グローバルオブジェクト、現在の実行スタック上の変数、組み込みのハンドルなど）を起点に参照をたどり、たどり着けるオブジェクトを「生存」、たどり着けないものを「ゴミ」と判定します。これがマーク&スイープの「マーク（印付け）」フェーズです。

参照カウント方式では循環参照（AがBを、BがAを参照）を回収できませんが、到達可能性ベースならルートから切り離された循環は丸ごと回収できます。逆に言えば、ルートからたどれる限り、たとえ二度と使わないオブジェクトでも回収されません。これが後述するリークの本質です。

世代別仮説と二つの領域

V8のヒープ設計は世代別仮説に立っています。「ほとんどのオブジェクトは生成後すぐ死ぬ。長く生きたオブジェクトはさらに長生きしやすい」という経験則です。関数内の一時オブジェクトやループ中の中間値は典型的な短命オブジェクトで、その大半はすぐ不要になります。

そこでヒープを二つに分けます。

短命なものを安く高速に回収し、生き残った少数だけを重い回収にかける——この分担で、回収コストを生存オブジェクトの量に見合わせます。新生領域のGCをマイナーGC、旧世代を含む全体のGCをメジャーGCと呼びます。

Scavenge：新生領域のコピーGC

新生領域はさらに From空間 と To空間 という同サイズの半分に分かれます（セミスペース方式）。新しいオブジェクトはFrom空間に詰めて確保され、空間が埋まるとScavengeが走ります。

1. マーク&コピー：ルートからたどって生きているオブジェクトだけを、From空間からTo空間へコピーする。
2. スワップ：コピー後、FromとToの役割を入れ替える。生存物が詰めて配置された新しいFrom空間が残る。
3. 解放：旧From空間はまるごと「空」とみなす。死んだオブジェクトを個別に消す処理は不要。

ポイントは、死んだオブジェクトには一切触れないことです。生存物だけをコピーするので、コストは「生きている量」に比例します。世代別仮説どおり生存物がごく少なければ、新生領域はほぼ生存ゼロのコピーで一掃でき、極めて高速です。確保もポインタを進めるだけ（バンプアロケーション）で安価です。

代償として新生領域は実効容量が半分になりますが、新生領域自体が小さい（数MB規模）ので問題になりません。Scavengeを2回生き延びたオブジェクトは「短命ではない」と判断され、旧世代へ**昇格（promotion）**します。

[From] A B C D E   <- E,F が死亡、A,B,C,D が生存
   |  生存物だけコピー
   v
[To]   A B C D     <- 詰めて配置。From/To を入れ替えて完了

Mark-Sweep-Compact：旧世代の回収

旧世代は容量が大きく、半分をコピー用に空けておくのは非効率です。そこでコピーではなく**Mark-Sweep（マーク&スイープ）**を使います。

• Mark：GCルートから到達可能なオブジェクトすべてに印を付ける。
• Sweep：印の付いていない領域を「空き」としてフリーリストに戻す。生存物は動かさない。

Sweepはオブジェクトを動かさないため高速ですが、空きが歯抜けに散らばる**フラグメンテーション（断片化）**が進みます。連続した大きな領域を確保できなくなると、**Compact（コンパクション）**で生存オブジェクトを片側に寄せ、空きを連続させます。コンパクションはオブジェクトを移動しポインタを張り替えるため重く、断片化が問題になったときだけ部分的に行われます。これが Mark-Sweep-Compact の名の由来です。

停止時間との戦い：インクリメンタル／並行／並列

GCの素朴な実装は、回収中にJavaScriptの実行を完全に止める Stop-The-World（STW） です。旧世代が大きいとMarkに時間がかかり、メインスレッドが長く止まればフレーム落ちやカクつき（jank）になります。V8はこれを次の三本柱で緩和します。

インクリメンタルマーキングには課題があります。少しずつ印を付けている最中にJSが参照を書き換えると、印付け済みの結果が古くなり、生存オブジェクトを誤って未マークのまま回収する恐れがあります。これを防ぐのがライトバリアです。マーキング中にオブジェクト参照が書き換わるたび小さなフックが走り、新たに参照されたオブジェクトを記録して取りこぼしを防ぎます（三色マーキングの不変条件を保つ仕組み）。V8の世代並行GCは「Orinoco」という名で知られ、Scavengeも並列・並行化されています。

メモリリークの原理：GCがあっても漏れる

GC言語のリークは、C言語の「解放し忘れ」とは違い、意図せず到達可能なまま残ることで起きます。コードの意図では捨てたつもりでも、参照が1本残っていればGCは回収できません。代表的な発生源を見ます。

デタッチDOM（Detached DOM）

DOM要素をJS変数に持ったまま、その要素をDOMツリーからremoveChild等で外すと、画面上は消えてもJS側の参照が生きている限りメモリには残ります。さらにその要素が子孫を持っていれば、サブツリー全体が解放されません。DOMの構造は DOM を参照。

let cache = [];
function show() {
  const el = document.createElement("div");
  document.body.appendChild(el);
  cache.push(el);          // 配列が参照を握り続ける
}
// 後で DOM から外しても、cache[i] が生きている限り回収されない
cache[0].remove();        // DOMツリーからは消えるが、配列の参照は残る

対策は、外すときに保持側の参照も切る（cache = []、該当要素を配列から除去）こと。あるいは寿命の都合で参照を持ちたい場合は WeakRef / WeakMap を使い、GCの回収を妨げない弱い参照にします。

クロージャによる閉じ込め

クロージャは外側スコープの変数を捕捉し続けます。長生きする関数（イベントハンドラ、setIntervalのコールバック、Promiseチェーン）が大きなオブジェクトを捕捉すると、そのオブジェクトはハンドラが生きている間ずっと到達可能です。

function setup(bigData) {
  el.addEventListener("click", () => {
    // bigData を使わなくても、同スコープにある限り捕捉され得る
    doSomething();
  });
}

要素やハンドラを破棄するときは removeEventListener で必ず解除します。解除しないとハンドラ→クロージャ→捕捉データの鎖が残り、要素を消してもデータが漏れます。

解除し忘れる長寿命コンテナ

setInterval、グローバルなMap/Set/配列、購読（subscribe）系は、明示的に止める／取り除くまで参照を保持し続けます。要素をキーにしたキャッシュは、要素が不要になってもMapが握り続けるので、WeakMapを使えばキー要素が他から到達不能になった時点で自動的にエントリごと回収されます。

回収を助けるコードの考え方

リーク対策は「使い終わったら参照を切る」に集約されます。実務での勘所をまとめます。

なお、短命オブジェクトを大量生成してもScavengeが安く回収するので、過度な「オブジェクト使い回し」最適化は不要なことが多いです。むしろ問題は長寿命コンテナへの溜め込みです。新生領域で死ぬはずだったものが配列やMap経由で旧世代へ昇格すると、重いメジャーGCの対象になり、断片化やSTW時間の増大につながります。性能計測の全体観は Webパフォーマンス も参照してください。

まとめ