Dartランタイムの深層：クロージャによる変数キャプチャとメモリの不可逆的罠
Dartのコアコミッターとして、日々数百万行のFlutter/DartコードのライフサイクルやAOT/JITコンパイラの振る舞いを見渡していると、ある種の「隠れたコスト」に無自覚なコードベースに度々遭遇する。
その筆頭が、クロージャによる変数のキャプチャと、それに伴うヒープ上のメモリ保持機構だ。
「なぜこの巨大な状態が解放されないのか？」「なぜこの一時的なイベントハンドラが原因でOOM（Out of Memory）を引き起こすのか？」
この問いに正確に答えられるシニアエンジニアは意外と少ない。本稿では、Dart VMの内部構造、コンパイラの最適化、そしてイベントループのキュー消費メカニズムにまで踏み込み、クロージャがメモリに与える影響の真実を解き明かす。
—
1. コンパイラ視点：クロージャは「関数」ではない、「コンテキストを持つオブジェクト」である
まず、Dartのセマンティクスにおけるクロージャの正体を再定義しよう。
C言語の関数ポインタや、単純なステートレス関数とは異なり、Dartのクロージャ（Lambda式や匿名関数）は、字義通り環境（Environment）を内包したオブジェクトである。
次のようなコードを考えてみる。
Function createCounter() {
int heavyPayload = 0; // 外部スコープの変数
// ここで大きなバイナリデータがあると仮定
List
return () {
heavyPayload++;
return heavyPayload;
};
}
人間にとって、`createCounter`の実行が完了すれば、ローカル変数である`buffer`や`heavyPayload`はスタックから消え去るように見える。しかし、Dart VMのAOT（Ahead-Of-Time）/JITコンパイラおよびメモリマネージャの挙動は異なる。
Context（コンテキスト）オブジェクトの生成
Dartコンパイラは、クロージャが外部スコープの変数（Upvalue）を参照していると検知すると、スタック上にあった変数をヒープ上の独立したメモリブロック（内部的に `Context` と呼ばれる構造体）へ「昇格（Promote）」させる。
返り値のクロージャは、この `Context` への強力な参照（ポインタ）を隠し持った状態で生成される。結果として、`buffer` はローカル変数ではなくなり、クロージャが存在する限り、`Context` を介してヒープ上に強制的に生存し続けることになる。
[Isolate Heap] FlutterやサーバーサイドDartにおいて、`async/await` や Microtask キューの多用は避けて通れない。ここで問題になるのが、非同期クロージャによる意図しないライフサイクルの延長だ。 以下のコードを検証してほしい。 class NetworkManager { void initializeRequest(String endpoint) { // イベントループのマイクロタスクキューにクロージャを積む // initializeRequest スコープはここで終了する 一見、`initializeRequest` が終了すれば `sessionToken` も解放されるように見える。しかし、`Future.microtask` に渡された非同期クロージャは、レキシカルスコープ全体を `Context` としてラップして保持している。 もし `_client.send` が何らかの理由で遅延したり、Futureの解決がブロックされたりした場合、`sessionToken` や、場合によっては `this`（NetworkManagerインスタンスそのもの）が、マイクロタスクが消化されるまでの間、ヒープに固定（Pinning）される。 さらに厄介なのは、Dart VMのガベージコレクタ（Generational GC）の挙動だ。 — では、このコンパイラの仕様とメモリ管理の物理法則にどう対抗すべきか。シニアエンジニアが実践すべき具体的な防御策を提示する。 クロージャを書く際、スコープ内のすべての変数が自動的にキャプチャされる仕様（Lexical scoping）を逆手に取り、「本当に必要なプリミティブ値だけ」をコピーして渡す。 // ❌ 悪い例：オブジェクト全体や不要な変数をキャプチャしている // クロージャが controller や config を丸ごとキャプチャする // ⭕ 良い例：必要なプリミティブ値のみを抽出してキャプチャする // controllerへの参照を断ち、プリミティブなローカル定数のみをキャプチャさせる このアプローチにより、クロージャが保持する `Context` のサイズを最小化し、不要なオブジェクトグラフの巻き込みを防ぐことができる。 変数の状態を持たない（ステートレスな）処理であれば、極力クロージャではなく、トップレベル関数や静的メソッド、あるいは `const` なコンストラクタを持つオブジェクトを利用する。 Dartでは、キャプチャを持たない匿名関数は、コンパイル時に効率的なシングルトンとして最適化されることがあるが、明示的に静的関数に切り出すことで、コンパイラに対して「余計なContext生成を行わない」という強いシグナルを送ることができる。 — Dartは、極めて洗練されたモダンな言語であり、ガベージコレクタが多くのメモリ管理の苦痛を肩代わりしてくれる。しかし、「メモリ管理を自動化してくれること」と「メモリのライフサイクルを無視してよいこと」は同義ではない。 クロージャは強力な表現力を持つ諸刃の剣だ。その背後で、コンパイラがヒープ上に `Context` を構築し、イベントループがそれを抱え込んでIsolateのメモリフットプリントを肥大化させているという事実を、コードを書くたびに脳内トレースできなければならない。 型、スコープ、非同期、そしてメモリ。 あなたの書いているそのクロージャは、本当に「今」、解放されるべきメモリを手放しているか？
└── Context Object
├── heavyPayload (int)
└── buffer (List2. イベントループとキャプチャ：非同期処理が招く「スコープの幽霊」
final _client = HeavyHttpClient(); // 莫大なリソースを持つクライアント
var sessionToken = _generateSecureToken(); // 機密情報・大容量データ
Future.microtask(() async {
// 意図：ネットワークリクエストを非同期で実行するだけ
await _client.send(endpoint, sessionToken);
print(‘Request completed.’);
});
}
}
生存期間が延びたオブジェクトは、若い世代（New Space）から古い世代（Old Space）へと昇格（Promotion）する。短命であるはずの一時変数がクロージャにキャプチャされたがためにOld Spaceに居座り続け、フルGCのコストを跳ね上げる原因となる。3. 実践的防御策：メモリを汚染しないためのコードパターン
対策A: キャプチャの局所化（不要な変数を巻き込まない）
void badPattern(HeavyController controller) {
var config = controller.loadHeavyConfig();
Timer.periodic(const Duration(seconds: 1), (_) {
if (controller.isClosed) return;
print(config.timeout);
});
}
void goodPattern(HeavyController controller) {
final int timeout = controller.loadHeavyConfig().timeout;
final bool Function() isClosedCheck = controller.isClosed;
Timer.periodic(const Duration(seconds: 1), (timer) {
if (isClosedCheck()) {
timer.cancel();
return;
}
print(timeout);
});
}対策B: `const` と静的関数の徹底
4. チーフアーキテクトからの提言：ランタイムの重みを認識せよ
これらがDart VM上でどう噛み合っているかを完全に掌握した者だけが、真に堅牢でスケーラブルなプロダクトを構築できる。
今一度、コードベースの `Context` の影に目を凝らしてほしい。