【テクニカル・上級編】Dartの「final」と「const」の厳密な違いとメモリ最適化への影響 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dartを掌握する極限の知見：`final`と`const`のメモリトポロジーとコンパイラ最適化の深層

Dart VM、AOTコンパイラ、そしてFlutterのレンダリングパイプラインの深淵において、メモリ割り当てとオブジェクトライフサイクルの制御は、アプリケーションのパフォーマンスが生死を分ける境界線となる。

多くのプログラマは、`final`と`const`を「再代入不可能な変数を作るための修飾子」という表層的な理解にとどめている。しかし、Dartのチーフアーキテクトの視点から言えば、この2つは「実行時（Runtime）の不変性」と「コンパイル時（Compile-time）の完全なイミュータビリティと定数畳み込み（Constant Folding）」という、まったく異なる次元のセマンティクスを持っている。

本稿では、`final`と`const`がDart VMのヒープ、定数プール（Constant Table）、そしてアロケータにどのような不可逆的な影響を与えるのか、低レイヤの挙動から徹底的に解剖する。

—

1. コンパイル時定数 (`const`) の本質：定数プールとカノニカル化

`const`は単なる言語の構文ではない。これは、AOTコンパイラ（あるいはJITのコンパイルフェーズ）に対し、「この値の領域をバイナリのデータセグメント（定数プール）にハードコードせよ」と命じる強力な指令である。

定数プール（Constant Table）への埋め込み

`const`で定義されたプリミティブ値やオブジェクトは、プログラムがロードされた瞬間（あるいはAOTコンパイルされたバイナリのロード時）にメモリ上の専用領域に配置される。実行時に動的なメモリ割り当て（Heap Allocation）は一切発生しない。

さらに、Dartの`const`はカノニカル化（Canonicalization）という極めて強力な最適化を受ける。

void examineCanonicalization() {
const a = [1, 2, 3];
const b = [1, 2, 3];

// 厳密な同一性判定
// ignore: unnecessary_const
print(identical(a, b)); // 常に true
}

このコードにおいて、Dart VMは`a`と`b`にそれぞれ異なるメモリ領域を割り当てたりはしない。コンパイラは抽象構文木（AST）の解析段階で、内容が完全に一致する`const`オブジェクトを単一のインスタンスにマージ（カノニカル化）する。結果として、`identical(a, b)`は`true`を返し、ポインタ比較（アドレスの比較）だけで等価性評価がO(1)で完了する。

ディープ・コンスタント（Deep Immutability）

`const`は「伝播」する。`const`なコレクションやオブジェクトの内部に含まれるすべてのフィールドや要素もまた、強制的にコンパイル時定数でなければならない。これにより、ランタイムにおけるガーベッジコレクタ（GC）の負荷を劇的に軽減できる。GCは「一度も動的ヒープに割り当てられず、移動もしない不変の定数領域」をスキャン対象から完全に除外できるからだ。

—

2. 実行時定数 (`final`): ヒープ上の不変ポインタ

一方、`final`はメモリレイアウトの観点においてまったく異なる振る舞いをする。

`final`は、「一度だけ代入できる変数（Single-assignment variable）」を定義するためのものであり、その指し示すオブジェクト自体が不変であるとは限らない。

void examineFinalBehavior() {
final list = [1, 2, 3]; // list自体は final（再代入不可）

// しかし、指し示す先のミュータブルなオブジェクトは変更可能
list.add(4);
print(list); // [1, 2, 3, 4]

// 再代入はコンパイルエラー
// list = [5, 6, 7];
}

ヒープアロケーションとライフサイクル

`final`変数が保持するオブジェクトは、実行時に動的ヒープ（Young Generation / Old Generation）にアロケートされる。
コンパイル時にはその値が確定していない場合（例えば、関数の引数、I/Oの結果、乱数生成器の出力など）でも使用できるため、ランタイムの柔軟性を担保するための必須のプリミティブである。

しかし、ここにパフォーマンス上の罠がある。もしループ内で毎回`final`なオブジェクトを動的に生成した場合、それはヒープを圧迫し、将来的にGCのストップ・ザ・ワールド（Stop-the-world）を引き起こすトリガーとなる。

—

3. メモリトポロジーの比較：アロケータの視点

Dart VMのメモリ管理において、`const`と`final`の決定的な違いは「アロケーションのタイミング」と「ポインタの寿命」にある。

低レイヤにおけるアセンブリレベルの挙動（概念的解説）

AOTコンパイラが吐き出すネイティブコードを想像してほしい。

`const`オブジェクトへのアクセスは、多くの場合、PC相対アドレッシング（Program Counter relative addressing）を用いた静的なデータセグメントからの直接読み込み、またはグローバルな定数レジスタへのポインタロードで完了する。
`final`オブジェクトの初期化は、ヒープアロケータ（Bump Pointer Allocator等）を呼び出し、メモリ領域を確保し、コンストラクタを実行し、レジスタに参照を書き込むという一連のランタイムコストを伴う。

—

4. アーキテクチャ設計における実践的防壁と最適化

シニアエンジニアとして、我々はこの言語仕様の差をシステム設計にどう落とし込むべきか。

アンチパターン：不必要な`final`によるヒープ汚染

Flutterのビルドメソッドや高頻度で実行されるイベントループのコールバック内で、以下のようなコードを見かけることがある。

// 悪夢のようなアンチパターン
void renderFrame() {
final padding = const EdgeInsets.all(8.0); // 惜しいが、毎回オブジェクトの参照が生成される文脈
// …
}

もし`EdgeInsets.all(8.0)`の内部が`const`コンストラクタであっても、それをローカル変数に`final`として代入するたびに、スタックフレーム上に変数が確保され、コードの構造によっては不要なオーバーヘッドを生む。
さらに悪いことに、以下のようなコードは最悪のパフォーマンスを生む。

// 【厳禁】動的計算を伴う final の乱用
class FrameProcessor {
void process() {
final config = AppConfig(timeout: 500, mode: ‘debug’); // 毎フレームヒープアロケーションが発生
_execute(config);
}
}

これを`const`に置き換えられるのであれば、構造体自体を`const`コンストラクタで定義し、可能な限り定数プールへ追いやるべきである。

// 【推奨】コンパイル時定数としての完全カプセル化
class AppConfig {
final int timeout;
final String mode;
const AppConfig({required this.timeout, required this.mode});
}

// グローバルまたはstaticなconstとして昇華
const _kDefaultConfig = AppConfig(timeout: 500, mode: ‘debug’);

void processOptimized() {
_execute(_kDefaultConfig); // アロケーションコストはゼロ（ゼロコスト抽象化）
}

—

5. 結論：Dartを掌握する者への指針

Dartの型システムとメモリモデルを極限までチューニングしたいのであれば、以下の鉄則を脳に刻み込め。

1. 動的に変化しないデータは、すべてを`const`で縛り上げろ。
これにより、定数プールの恩恵を受け、ヒープアロケーションをゼロにし、GCの負担を物理的に消し去ることができる。
2. 実行時のコンテキストに依存せざるを得ない値、または再代入の禁止が論理的に必要な局所変数にのみ`final`を用いよ。
3. 「変更不能（Immutability）」を語るなら、`final`で満足するな。真のイミュータビリティは`const`とディープ・コンスタントの領域にしか存在しない。

ランタイムの脈動を感じ、コンパイラの思考をトレースせよ。そこに妥協のないコードだけが持つ、圧倒的な実行速度の領域がある。