【実務・中級編】Dartの変数スコープとクロージャ：変数のキャプチャがメモリに与える影響 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dartの変数スコープとクロージャ：変数のキャプチャがメモリに与える影響と「見えないリーク」の防ぎ方

コードレビューをしていて、最もゾッとする瞬間のひとつは、一見何気なく書かれたクロージャの中に、数MBもある巨大なステートやキャッシュへの参照がこっそりキャプチャされているのを発見したときだ。

「UIコンポーネントを破棄したはずなのに、なぜかメモリ使用量が落ちない」
「非同期処理の完了を待つ間、古い画面のコントローラーが保持され続けている」

Flutterでのフロントエンド開発や、サーバーサイド/Webでの非同期API連携において、Dartのクロージャ（Closure）は強力な武器だ。しかし、「変数のキャプチャがメモリ（特にDartのヒープとガベージコレクション）にどう作用するか」を理解していないと、あなたの書いたコードは静かに、しかし確実にメモリリークを引き起こす。

今回は、Dart VMがクロージャと変数をどう扱っているのかという裏側の挙動から、実務で絶対に踏み抜いてはならない設計上のアンチパターン、そしてそれを美しく回避するプロダクションコードの書き方までを徹底的に解説する。

—

1. Dart VMの裏側：クロージャはなぜ変数を「キャプチャ」するのか？

まず、Dartの言語仕様とランタイムの挙動を低レイヤーから捉え直そう。

関数（あるいはメソッド）が定義され、その外側のスコープにあるローカル変数にアクセスするとき、Dartの関数は単なる「コードの塊」ではなくなる。その実行コンテキスト（Context）を包み込んだクロージャオブジェクトへと昇華する。

Function createCounter() {
int count = 0; // ← このローカル変数の寿命はどうなる？
return () {
count++;
return count;
};
}

通常のローカル変数（スタック上に確保されるプリミティブなど）であれば、関数がスコープを抜けた瞬間に破棄されるべきだ。しかし、上記のコードでは、返された無名関数が `count` を参照し続けている。

コンパイラとVMの挙動

1. コンパイル時: DartのCFA（制御フロー解析）とコンパイラは、このローカル変数 `count` がスコープ外の無名関数から参照されていることを検知する。
2. ヒープ割り当て: この瞬間、`count` は通常のスタック変数ではなく、ヒープ上に生成される `Context`（コンテキストオブジェクト） のスロットへと昇格（Promote）させられる。
3. 参照の維持: クロージャは、自身が生成された瞬間の `Context` への強力な参照（Strong Reference）を内部に保持し続ける。

結果として、クロージャが存在し続ける限り、それに紐づく `Context` 内のすべての変数（キャプチャされた変数群）は、たとえ元のスコープが終了してもガベージコレクション（GC）の対象から外れ、メモリ上に居座り続けることになる。

—

2. フロントエンド開発が陥る「見えないメモリリーク」の罠

この仕組みが、実際のFlutterアプリや非同期処理の現場でどう牙を剥くかを見てみよう。

よくあるアンチパターンとして、肥大化したステートやコントローラー、あるいは重いリポジトリのインスタンスを、長寿命なイベントリスナーや非同期のコールバック内でうっかりキャプチャしてしまうケースがある。

❌ アンチパターン：長寿命オブジェクトへのクロージャ登録と暗黙のキャプチャ

class UserDashboardView extends StatefulWidget {
@override
_UserDashboardViewState createState() => _UserDashboardViewState();
}

class _UserDashboardViewState extends State {
// 数MB相当の重いバイナリキャッシュや大量のユーザーデータを持つとする
final HugeCacheManager _heavyCache = HugeCacheManager();
final ApiClient _apiClient = ApiClient();

@override
void initState() {
super.initState();

// グローバルなイベントバス（シングルトン）にリスナーを登録
GlobalEventBus.instance.subscribe((event) {
if (event is UserRefreshEvent) {
// 【致命的な罠】
// この無名関数は `this`（_UserDashboardViewState）を暗黙的にキャプチャしている！
// なぜなら、内部で _heavyCache や _apiClient にアクセスしているからだ。
_performRefresh();
}
});
}

void _performRefresh() {
_heavyCache.refresh();
_apiClient.fetch();
}

@override
Widget build(BuildContext context) {
return Container(/ 画面のUI /);
}

@override
void dispose() {
// 画面が破棄され、Stateがツリーから取り除かれた！
super.dispose();
// しかし… GlobalEventBus 側の購読を解除していない！
}
}

何が起きているのか？

1. `GlobalEventBus` はアプリケーション全体で生存し続けるシングルトン（長寿命）である。
2. `GlobalEventBus` が保持するコールバックリストには、`_UserDashboardViewState` のインスタンスを暗黙的にキャプチャしたクロージャが格納され続けている。
3. ユーザーが画面を閉じ、FlutterのWidgetツリーから `UserDashboardView` がパージされても、`GlobalEventBus` からクロージャが参照されているため、`_UserDashboardViewState` 全体がGCされない。
4. これにより、画面を往復するたびにヒープメモリが肥大化していく（メモリリークの完成）。

—

3. 堅牢な設計パターン：変数のスコープを絞り、キャプチャを制御する

では、このような事故を根絶し、パフォーマンスが高く保守性の高いコードを書くためにはどうすべきか。テクニカルリードとして推奨する3つの鉄則を提示する。

鉄則1: クロージャに渡す変数は「必要な最小限のプリミティブ」に絞る

オブジェクト全体（`this` や重いコントローラー）をクロージャのスコープ内に露出させず、必要な値だけをローカルの `final` 変数に切り出してからキャプチャする。あるいは、そもそもキャプチャを避ける。

鉄則2: 非同期処理やストリームでは `WeakReference` や明示的なライフサイクル管理を徹底する

特に `StreamSubscription` やイベントリスナーは、必ず `dispose` 時に `cancel()` する。

鉄則3: `const` と `static` の境界線を厳格にする

—

4. プロダクションコード例：美しく安全なイベントリスナーの設計

上記のアンチパターンを完全に解消し、メモリリークの隙を与えない実用的なコンポーネント設計のコードを示す。

import ‘dart:async’;
import ‘package:flutter/material.dart’;

// — モック用のクラス群 —
class HugeCacheManager {
void refresh() {}
void clear() {}
}

class ApiClient {
Future fetch() async {}
}

class UserRefreshEvent {}

class GlobalEventBus {
static final GlobalEventBus instance = GlobalEventBus._internal();
GlobalEventBus._internal();

final _controller = StreamController