コードレビューを始めていく。今回のテーマは「非同期処理とスコープ：Promiseチェーン内での変数の生存期間とメモリリークの特定」だ。
よくあるジュニアエンジニアのコードレビューで、非同期処理をループやイベントリスナーの内部で雑に回し、「なぜかブラウザのメモリ使用量が右肩上がりに増え続ける」「SPAの画面遷移を繰り返すとタブがクラッシュする」というバグに直面して頭を抱えているシーンに遭遇する。
原因の大半は、V8エンジンのガベージコレクション（GC）のメカニズムと、クロージャがキャプチャするスコープのライフサイクルを誤解していることにある。今回は、V8のヒープ空間で何が起きているのかというランタイムの深層から、実務で即座に使える堅牢な設計パターンまでを一気に叩き込む。
—
1. なぜ非同期処理はメモリリークの温床になるのか
JavaScriptの非同期処理（`Promise`, `async/await`, `setTimeout`など）のコールバック関数は、その関数が定義されたレキシカル環境（Lexical Environment）への参照、すなわちクロージャを内部スロット（[[Scopes]]）に保持して生成される。
V8エンジンのガベージコレクションは、基本的に「ルート（グローバルオブジェクトや実行中のコールスタック）から到達可能（Reachable）か否か」で不要なメモリを判定・解放する。しかし、解決（Resolve）または拒否（Reject）される前のPromiseチェーンの内部に保持されたコールバックは、未解決の非同期タスクとしてマイクロタスクキューまたはイベントループに留まり続ける。
この状態のとき、クロージャがスコープチェーンを介して巨大なデータ（DOM要素、膨大な配列、APIレスポンスのキャッシュ等）をキャプチャしていると、その非同期処理が完了するか破棄されるまで、V8はそのデータをヒープメモリ（Old Space）に縛り付け続ける。これが非同期処理に起因するメモリリークの正体だ。
危険なアンチパターン：巨大なコンテキストの巻き込み
まずは、実務のコードレビューで絶対にリジェクトすべき「やってはいけない実装」を見てみよう。
// 【アンチパターン】コンポーネントや重い処理のスコープをそのままリークさせる例
class DataProcessor {
constructor() {
// メガバイト級の重いデータやDOM参照を保持していると仮定
this.heavyPayload = new Array(10000000).fill(‘leak-memory’);
this.activeRequests = new Set();
}
// 定期的なポーリングや非同期パイプライン
async executePipeline(itemId) {
const localContextData = { id: itemId, timestamp: Date.now() };
// 意図しないメモリリークの引き金
const promise = fetch(`/api/data/${itemId}`)
.then(res => res.json())
.then(data => {
// [!] ここでクロージャが生成され、this（DataProcessorインスタンス全体）や
// localContextData、さらにスコープ内の変数をキャプチャし続ける
this.processResult(data, localContextData);
});
this.activeRequests.add(promise);
// Promiseが解決・またはエラーになるまで、this.heavyPayload も
// localContextData も絶対にGCされない
try {
await promise;
} finally {
this.activeRequests.delete(promise);
}
}
processResult(data, context) {
console.log(`Processed ${context.id}`);
}
}
このコードの問題点は、`fetch`から続くPromiseチェーンのコールバックが、レキシカルスコープ経由でクラスインスタンス（`this`）やローカル変数（`localContextData`）への参照を保持し続ける点にある。もしこの非同期処理がネットワークの遅延やバックエンドのフリーズによって数秒〜数分間ペンディング状態になった場合、その間ずっと巨大なヒープ領域が占有され続けることになる。
—
2. V8エンジンの視点：スコープとガベージコレクションの挙動
V8はコンパイル時に、関数がどの外部変数にアクセスしているかを解析する（Context Allocation）。もし関数内で外部変数への参照が必要と判断されると、ヒープ上に「Context（コンテキスト）オブジェクト」が生成され、そこに変数が格納される。
Promiseチェーン（特に`.then()`や`.catch()`の連鎖）が長くなると、それぞれのハンドラーがコンテキストオブジェクトへの参照チェーンを維持する。
さらに厄介なのは、モダンブラウザのDevTools（Memoryパネル）でHeap Snapshotを取った際、「Closure」や「system / Context」として保持されているオブジェクトは、参照の根源（Root）を辿るのが非常に困難であるという点だ。
非同期処理を設計する上での鉄則は、「スコープの生存期間（Lifespan）を、非同期タスクの生存期間と同期させない、あるいは最小限に絞り込む」ことにある。
—
3. 堅牢なプロダクションコード設計：スコープの切断とAbortControllerの活用
では、メモリリークを完全に排除し、保守性の高い非同期処理をどう書くべきか。
ここで、実務のフロントエンド開発やAPIクライアント層で標準採用すべき「スコープのミニマライズ」および「キャンセル可能な非同期処理（`AbortController`）」を統合したモダンな実装パターンを提示する。
/
- 【プロダクションコード例】
- スコープの生存期間を制御し、メモリリークを防ぐ安全なデータプロセッサ
/
class SecureDataProcessor {
constructor() {
// 外部から巨大なペイロードを直接持たせず、必要な粒度で管理
this.activeControllers = new Map();
}
/
- 非同期パイプラインを実行する
- @param {string} itemId
- @param {AbortSignal} [externalSignal] 外部からのキャンセルシグナル
/
async executePipeline(itemId, externalSignal) {
// 各リクエスト固有のAbortControllerを発行し、スコープとライフサイクルを明確に分離する
const controller = new AbortController();
const taskId = Symbol();
this.activeControllers.set(taskId, controller);
// 外部シグナルが渡されている場合は連動させる
if (externalSignal) {
if (externalSignal.aborted) {
controller.abort();
} else {
externalSignal.addEventListener(‘abort’, () => controller.abort(), { once: true });
}
}
try {
// クロージャが巨大なコンテキストをキャプチャしないよう、
// 必要なプリミティブ値だけをスコープにバインドする
const result = await this.fetchWithTimeout(itemId, controller.signal);
// 処理結果のハンドリング（thisの参照を必要最小限に絞る）
return this.sanitizeAndProcess(result);
} catch (error) {
if (error.name === ‘AbortError’) {
console.info(`Task ${itemId} was safely aborted and memory released.`);
return null;
}
throw error;
} finally {
// 【重要】処理の完了・失敗に関わらず、必ずコントローラーの参照を断ち切る
// これにより、V8のヒープから不要な参照が消え、GCの対象となる
this.activeControllers.delete(taskId);
}
}
async fetchWithTimeout(itemId, signal) {
const response = await fetch(`/api/data/${itemId}`, { signal });
if (!response.ok) {
throw new Error(`HTTP Error: ${response.status}`);
}
return response.json();
}
sanitizeAndProcess(rawData) {
// 必要なデータのみを抽出し、元の重いコンテキストから切り離す
return {
id: rawData.id,
value: rawData.payload,
processedAt: Date.now()
};
}
/
- コンポーネントのアンマウント時やページ離脱時に全非同期処理を強制中断し、
- メモリリークを根絶する
/
dispose() {
for (const [taskId, controller] of this.activeControllers.entries()) {
controller.abort();
}
this.activeControllers.clear();
console.info(‘All pending async tasks aborted and scopes released.’);
}
}
// — 使用例 —
// const processor = new SecureDataProcessor();
// processor.executePipeline(‘item-123’);
//
// // コンポーネント破棄時
// processor.dispose();
—
4. コードレビューの視点：アーキテクトからのチェックリスト
チームのメンバーが書いたコードに対して、レビュー時に以下のポイントをチェックしてほしい。これらがクリアされていれば、非同期処理に起因するメモリリークの大部分は防げる。
1. Promiseチェーンの中で無駄なクロージャを作っていないか？
- `.then(data => this.hugeMethod(data))` のように、アロー関数内でインスタンス全体や外部の重いローカル変数をキャプチャしていないか確認する。可能であればトップレベルの純粋関数に切り出すか、必要なプリミティブ値だけを渡すように設計する。
2. 非同期処理のライフサイクル管理（キャンセル機構）はあるか？
- `fetch` や非同期イベントに対して `AbortController` が正しく使われているか。特にReactの `useEffect` やVueの `onUnmounted` のクリーンアップ関数内で、未完了のPromiseの結末を無視、あるいはキャンセルする仕組みが入っているか。
3. `finally` ブロックで参照のクリーンアップを行っているか？
- マップやセット（`Map`, `Set`）にPromiseやコントローラーを格納している場合、処理終了時に確実に `delete` や `clear` が呼ばれる構造になっているか。ここが漏れていると、コレクション自体がメモリリークの温床になる。
—
結びにかえて
JavaScriptは、ガベージコレクタがメモリ管理を自動で行ってくれる極めて優れた言語ランタイムだ。しかし、それは「メモリリークが絶対に起きない」ことを意味しない。むしろ、クロージャと非同期処理の仕組みを理解せずに雑なコードを書けば、C/C++並みにタチの悪いメモリリークをいとも簡単に引き起こす。
「非同期処理が完了するまで、そこに関わるすべてのスコープがV8のヒープ上で息を潜めて生き続ける」――このイメージを常に脳内に焼き付け、スコープの生存期間をコントロールする美しいコードを書き上げてほしい。君たちの書くコードのパフォーマンスが、プロダクト全体の品質を決定づけるのだ。