Dartランタイムの深淵：変数スコープとクロージャ・キャプチャのメモリトポロジー
Dartの言語仕様は表面上、クリーンでモダンな構文の裏に隠された高度な抽象化を提供している。しかし、シニアエンジニアやプラットフォームの限界に挑む者にとって、コンパイラが生成する機械語、あるいはDart VMが実行するBytecodeの挙動を脳内でトレースできないコードは、常に潜在的な地雷原でしかない。
今回は、変数宣言（`var`、`final`、`const`）が生み出すスコープの概念が、コンパイル時にどのようにメモリレイアウトへ変換されるか、そしてクロージャ（Closure）が変数をキャプチャする際に発生する「Context（コンテキスト）オブジェクトのヒープ昇格」のメカニズムを、ランタイムの底層から解剖する。
—
1. スコープとメモリ寿命：スタックとヒープの境界線
Dartはガベージコレクション（GC）言語であり、開発者は明示的なメモリ管理から解放されている。しかし、GCの効率を最大化し、ジャンク（フレームドロップ）を防ぐためには、変数がどのスコープで生成され、いつ解放の対象になるかを把握していなければならない。
詞よりコード：スコープのライフサイクル
void processTransaction(List
// const: コンパイル時定数。ヒープにすらアロケートされず、
// Dart VMのイソレート（Isolate）定数プールに埋め込まれる。
const double taxRate = 0.10;
for (int i = 0; i < rawData.length; i++) { // 局所スコープの final 変数。 // ループイテレーション毎にスタックフレーム内（またはレジスタ）で処理され、 // イテレーション終了と共にスコープ外となり、即座に破棄対象となる。 final double baseAmount = rawData[i]; final double total = baseAmount (1 + taxRate); _logTransaction(total); } }
コンパイラの視点：`const` と `final` / `var` の決定的な違い
1. `const` の実態
`const` で宣言された値は、AOT（Ahead-Of-Time）コンパイル時にバイナリのデータセクション（読み取り専用メモリ）に焼き付けられる。実行時にアロケーションコストは一切発生しない。
2. `final` / `var` の実態
これらはランタイムの変数である。プリ型（`int`, `double`, `bool`）であっても、スコープや使用状況によってはスタック上に配置されるが、クロージャにキャプチャされた瞬間、その運命は劇的に変わる。
—
2. クロージャの罠：変数の「キャプチャ」とContext構造体
関数が自身の定義されたスコープの外にある変数にアクセスするとき、Dartはそれをクロージャとして評価する。ここで多くのエンジニアが誤解しているのは、「変数の値がコピーされる」という幻想だ。
実際のDart VM（およびJIT/AOTコンパイラ）は、キャプチャされた変数がスコープを抜けても生存し続けられるよう、`Context` と呼ばるヒープ上のオブジェクト（構造体）を動的に生成し、そこに変数を参照として保持させる。
メモリ上で何が起きているのか？
以下のコードを例に取ろう。
Function createCounter() {
int count = 0; // 通常であればスタックに積まれる局所変数
// この無名関数が count を参照しているため、
// count は「クロージャにキャプチャ」される。
return () {
count++;
print(count);
};
}
void main() {
var counter = createCounter();
counter(); // 1
counter(); // 2
}
このコードがコンパイル・実行されるとき、Dart VMの内部では以下のメモリトポロジーの変革が発生する。
1. `createCounter()` が呼び出されると、スタックフレームが作られる。
2. しかし、`count` 変数は通常のスタック変数としては扱われず、ヒープ上にアロケートされた `Context` オブジェクトのフィールドとして確保される。
3. `createCounter()` が終了し、そのスタックフレームが破棄されても、返されたクロージャ（関数オブジェクト）はヒープ上の `Context` へのポインタ（参照）を保持し続けるため、`count` はガベージコレクションされずに生き残る。
> アーキテクトの警告：意図しないメモリリークの温床
> 巨大なオブジェクトや、UIコンポーネントの参照を保持するローカル変数を、意図せず軽量なクロージャ（例えば非同期処理のコールバックなど）内部でキャプチャした場合、そのクロージャが生存している間（イベントキューにタスクが残っている等）、巨大なオブジェクトツリー全体がヒープ上の `Context` に繋がったままGCから逃れ続ける。これが、Flutterアプリなどで突然発生するメモリ肥大化の主たる原因の一つである。
—
3. イベントループと非同期クロージャにおけるキャプチャの挙動
Dartはシングルスレッド（Isolate）モデルであり、イベントループ（Event Loop）によって非同期処理を調停する。マイクロタスクキューやイベントキューに登録されるクロージャが、ループ変数をキャプチャする際によく見られるアンチパターンを検証する。
非同期処理ループにおけるクロージャのスコープバグ
void executeBatchOperations() {
for (var i = 0; i < 3; i++) {
// 非同期タイマーやマイクロタスクにクロージャを渡す
Future.delayed(Duration(milliseconds: 100 i), () {
// ここでキャプチャされる i はどう評価されるか？
print('Executing task: $i');
});
}
}
もし、あなたが古い言語仕様の感覚でいると、「0, 1, 2 が順番に出力される」と期待するかもしれない。しかし、Dartのスコープとループ変数の扱いにおいて、`for (var i = 0; ...)` の宣言位置が極めて重要になる。
現代のDart（Dart 2.2以降、およびNull安全導入後の仕様）では、`for` ループの初期化部分で宣言された `var i` は、ループの各イテレーションごとに新しい変数インスタンス（スコープ）としてクローンされるように最適化（Desugar）される。
したがって、各クロージャはそれぞれのイテレーションにおける固有の `i` の `Context` をキャプチャするため、正しく `0`, `1`, `2` が出力される。
しかし、もし変数をループの外側で宣言していた場合はどうなるか？
void executeBatchOperationsFlawed() {
var i = 0;
for (; i < 3; i++) {
Future.delayed(Duration(milliseconds: 100), () {
// ループ外の単一の i を全てのクロージャが共有（キャプチャ）している！
print('Flawed task: $i');
});
}
}
この場合、イベントループが実際に非同期コールバックを実行する時点では、すでに `for` ループは完了しており、`i` の値は `3` に達している。結果として、出力は以下のようになる。
Flawed task: 3
Flawed task: 3
Flawed task: 3
この挙動は、コンパイラが「どのスコープのどの変数を `Context` にバインドしたか」という静的解析の結果に完全に依存している。変数宣言の位置ひとつで、非同期処理の整合性が崩壊する典型例である。
---
4. 極限の最適化：コンパイラはクロージャをどう消去するか
DartのAOTコンパイラ（およびJITの最適化コンパイラ）は非常にアグレッシブである。もしクロージャが「実際にはスコープ外の変数を変更も参照もしていない（真の純粋関数である）」、あるいは「その場で即座にインライン展開できる」と判断した場合、クロージャオブジェクトの生成そのものを完全にコンパイル時に消去（Devirtualization / Allocation Elimination）する。
しかし、ひとたび変数をキャプチャし、`Context` オブジェクトの生成が強制されると、以下のオーバーヘッドがランタイムに負荷を与える。
1. ヒープアロケーションのコスト: スタックではなくヒープ領域へのメモリ割り当てが発生。
2. GCプレッシャー: 短命な `Context` オブジェクトが大量に生成されることで、若い世代のGC（Young Generation GC）の回収サイクルを高頻度で誘発。
シニアエンジニアが取るべき防壁デザイン
1. 不必要なキャプチャの排除:
非同期処理やコールバックのクロージャ内部で、外側のローカル変数を参照する必要があるのか、あるいは関数の引数として明示的に渡すべきなのかを常に精査する。
2. `const` の徹底:
変更されないデータや構造は徹底的に `const` を付与し、イソレート定数プールへ追いやることで、ヒープアロケーションとGCのフットプリントを極限までゼロに近づける。
3. ループ変数のスコープを最小化する:
ループ変数や一時変数は、極力ループの内部（イテレーションスコープ）で宣言し、意図しない `Context` への昇格やスコープ汚染を防ぐ。
—
結び
Dartの変数宣言とスコープ、そしてクロージャのキャプチャメカニズムは、単なる「書きやすさのための糖衣構文」ではない。それは、コンパイラとランタイムがメモリの寿命を管理するための厳密な契約である。
コードを書くとき、あなたの脳内には常に「この変数はどのスタックフレームに存在し、クロージャによってどのヒープ上の `Context` へエスケープするのか」というメモリトポロジーが描かれていなければならない。その解像度こそが、真に堅牢で高性能なDart/Flutterシステムを構築するための唯一の防壁となる。