ブラウザのメモリプロファイラで見る：スコープごとのメモリ使用量とクロージャによるリークの兆候
JavaScriptのガベージコレクション（GC）は「自動」であるという神話は、実務の現場において幾度となく開発者の足をすくってきた。特にV8エンジンの内部構造、スコープチェーンの物理的実体、そしてクロージャが保持するコンテキストの寿命を正確に把握していない場合、メモリ使用量は徐々に、しかし確実に肥大化していく。
本稿では、V8エンジンがメモリ空間（Heap）上でスコープをどのように構築し、隠しクラス（Hidden Class / Map）とインラインキャッシュ（IC）がそこにどう関与しているのかを低レイヤの視点から解き明かす。さらに、Chrome DevToolsを用いたメモリプロファイリングの実践手法を通じ、クロージャによるメモリリークの兆候を検出し、これを断ち切るためのアーキテクチャ設計を提示する。
—
1. V8ランタイムにおけるスコープチェーンとメモリの物理配置
JavaScriptのスコープは、単なるコンパイル時の論理的な抽象概念ではない。V8エンジン（Ignition / TurboFan）の内部において、スコープは実行時にヒープ上に実体化する「Context（コンテキスト）」というオブジェクトのチェーン構造として構築される。
1.1 Lexical EnvironmentとContext Object
関数が定義され、それが別のスコープ（例えば外側の関数の変数）を参照する時、V8はスタックフレーム上ではなく、ヒープ上に `Context` オブジェクトを割り当てる。この `Context` は、変数の名前ではなくスロット（インデックス）によってアクセスされるため、プロパティルックアップのオーバーヘッドは最小限に抑えられる。
しかし、ここに一つの罠がある。クロージャによって参照される変数が一つでもある場合、そのスコープ全体の `Context` は、クロージャが存在し続ける限りガベージコレクションの対象から外れる。
function createLeakyAbomination(size) {
// この巨大会は、外側関数のスコープ（Context）に紐づく
const massivePayload = new Array(size).fill(0x3735);
// 内部関数がこのスコープを参照しているため、massivePayload は解放されない
return function leakContext() {
return massivePayload[0];
};
}
const leaky = createLeakyAbomination(1024 1024 50); // 約400MBの配列を保持
上記のコードにおいて、`leaky` 関数が生きている限り、`massivePayload` が占有する400MBのメモリ領域はV8のOld Spaceに居座り続ける。これが、意図しないスコープ保持によるメモリリークの基本的なメカニズムである。
—
2. Chrome DevToolsを用いたメモリプロファイリングの実践
メモリリークの兆候を感覚ではなく、データとして捉えるためには、Chrome DevToolsの Memoryパネル（Heap SnapshotおよびAllocation instrumentation on timeline）を駆使する必要がある。
2.1 Heap Snapshotの比較（Retaining Pathsの解析）
リークを特定するための黄金律は、「ダンプの比較（Comparison）」である。
1. アプリケーションの初期状態でHeap Snapshotを撮影（Baseline）。
2. メモリリークを引き起こすと疑われる操作（画面の遷移、イベントリスナーの着脱など）を複数回繰り返す。
3. 2回目のHeap Snapshotを撮影。
4. 表示形式を 「Comparison」 に切り替え、`# Delta`（差分）の大きい順にソートする。
ここで注目すべきは、オブジェクトの数やサイズそのものではない。「Retainers（保持者）」ツリーである。
closure (Closure) @148922
- context (Context) @148914
- massivePayload (Array) @148902
このRetainersツリーを辿ったとき、rootからどのように参照が繋がっているか（Retaining Path）を視覚的に追うことで、どのクロージャがどのスコープを保持し続けているのかが完全に暴かれる。
2.2 Allocation Timelineによるリアルタイム観測
「どのタイミングでメモリが割り当てられ、なぜ解放されないのか」を時系列で追うには、Allocation instrumentation on timelineが極めて有効である。
- 青いバー：メモリ割り当て（Allocation）
- 青いバーのまま残るもの：GCによって回収されなかった領域
ここにガベージコレクションの実行タイミング（グレイアウト処理）を重ね合わせることで、短命であるべきオブジェクトが長命なOld Spaceへ昇格（Promotion）している瞬間を特定できる。
—
3. クロージャリークの構造的アンチパターンとリファクタリング
実務の大規模コードベースにおいて、最も頻発するクロージャリークのパターンとその対策をコードで示す。
3.1 アンチパターン：グローバルイベントリスナーとDOMノードの幽霊参照
DOM要素への参照をクロージャが保持し続けることで、要素が画面から削除（`removeChild`）されてもメモリに残る現象（Detached DOM Tree）が発生する。
// 危険な実装：イベントリスナーが外側のスコープのDOMや大容量データを保持
function setupWidget() {
const giantData = new Array(1000000).fill(‘leak’);
const element = document.getElementById(‘my-button’);
element.addEventListener(‘click’, function hazardousHandler() {
// giantData自体の使用はここになくても、
// V8の仕様上、同じContext内にある変数はすべてクロージャの保持対象になる場合がある
console.log(‘Clicked’, giantData.length);
});
}
※注記：V8の近年のバージョンでは、クロージャが実際にアクセスする変数のみを保持するように最適化（Context Specialization / Trim）が進んでいるが、複雑なオブジェクトグラフや旧来のランタイム、あるいは間接的な参照が絡む場合、スコープ全体の保持リスクは依然として残る。
3.2 対策：スコープの分断と明示的な参照の切断（Nullification）
クロージャが必要とする最小限のプリミティブ値だけをキャプチャさせ、不要になった時点で参照を断ち切る設計へリファクタリングする。
安全な設計の原則：
1. クロージャに渡すデータは、必要なプリミティブ値（またはコピー）に絞る。
2. イベントリスナーやタイマーは、不要になった時点で必ず `removeEventListener` や `clearInterval` で破棄する。
3. モジュールスコープやシングルトンパターンにおける配列・Mapへの無制限なプッシュを避ける（WeakMapの活用）。
// 堅牢な実装
function setupWidgetOptimized() {
let giantData = new Array(1000000).fill(‘safe’);
const element = document.getElementById(‘my-button’);
const dataLength = giantData.length; // プリミティブ値だけを抽出
const handler = function safeHandler() {
console.log(‘Clicked’, dataLength);
};
element.addEventListener(‘click’, handler);
// クリーンアップ関数を返却し、ライフサイクルを完全に制御する
return function cleanup() {
element.removeEventListener(‘click’, handler);
giantData = null; // 参照を明示的に断ち、GCの回収を促す
};
}
—
4. WeakMapを用いたメタデータ管理とガベージコレクションの調和
DOMノードや外部オブジェクトに対して付加的なデータを保持する場合、`Map` を使うとメモリリークの温床になる。なぜなら、`Map` はキーへの強参照（Strong Reference）を保持するため、キーとなったオブジェクトが不要になっても `Map` が存在する限り解放されないからだ。
ここで投入すべき布石が `WeakMap` である。
// WeakMapを用いた安全なオブジェクト拡張とメタデータ管理
const nodeMetadata = new WeakMap();
function attachMetadata(node, data) {
// node がDOMツリーから削除され、他の強参照がなくなれば、
// WeakMap内のエントリも自動的にGCの回収対象となる
nodeMetadata.set(node, data);
}
function getMetadata(node) {
return nodeMetadata.get(node);
}
`WeakMap` のキーはガベージコレクションの対象外とはならない（＝キーへの参照が他に失われれば、エントリ全体が消滅する）ため、スコープやキャッシュに起因するメモリリークを防ぐための強力な防壁となる。
—
5. 総括：ランタイムを支配するエンジニアリングへ
JavaScriptのメモリ管理は、ランタイム（V8）の挙動とコードの構造が織りなす物理現象の帰結である。「なぜこの変数がヒープに残っているのか」という疑問に直面した時、ドキュメントの表層をなぞるのではなく、Contextオブジェクトの連鎖、隠しクラスの遷移、そしてRetaining Pathの構造を脳内で再現できなければならない。
スコープとクロージャの寿命をコードレベルで完全に統御すること。それこそが、数百万人のユーザーが利用するフロントエンドや、高負荷なNode.jsバックエンドを安定稼働させるための唯一無二の条件である。