【テクニカル・上級編】DartのNull安全とジェネリクスの深い関係：List<T>とList<T?>の挙動の違い – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dart Sound Null Safetyの深層：`List` と `List` がコンパイラとVMのメモリレイアウトに与える決定的差異

DartのSound Null Safetyは、単なる静的解析の気休めではない。コンパイル時における型の厳密な境界定義であり、実行時（Dart VM）のメモリ表現、アロケーション戦略、そしてJIT/AOTコンパイラの最適化パスそのものを根底から規定する物理法則である。

多くのシニアエンジニアですら、ジェネリクスにおける `T` と `T?` の差異を「nullを許容するかどうか」という高レイヤな意味論だけで捉えている。しかし、ランタイムエンジンの内部構造に踏み込めば、この2つの型はアロケーションコスト、ガベージコレクション（GC）の負荷、そして型チェックのオーバーヘッドにおいて全く異なる振る舞いを見せる。

本稿では、`List` と `List` がDart VM上でどのように扱われ、なぜ型安全なコレクション操作においてその違いが致命的なパフォーマンスの差を生むのかを、コンパイラとメモリの観点から極限まで解き明かす。

—

1. 型パラメータの境界とNull許容性の伝播ルール

Dartのジェネリクスにおいて、型変数 `T` を宣言した際、明示的に `T extends Object` と指定しない限り、`T` はデフォルトで `Object?`（Null許容） の境界を持つ。

// このクラスの T は実質的に T extends Object? である
class Container {
T? value; // T 自体が Null許容かもしれないのに、さらに ? を付けると T?? (Flatteningにより T? に畳み込まれる)
}

ここでDartのコンパイラ（CFA: Control Flow Analysis および Type System）が裏で行っている処理に注目してほしい。`T` がすでに Null許容である場合、`T?` は型平坦化（Type Flattening）のルールにより `T` そのものに縮約される。しかし、`T` が Non-nullable（例: `int`）としてインスタンス化された瞬間、状況は一変する。

具象化（Instantiation）の瞬間

`List` と `List` を宣言したとき、Dart VMのC++ランタイム（`runtime/vm/`）は、これらを全く異なるオブジェクトとして扱う。

`List`: 要素はプリミティブな64ビット整数（または32ビットプラットフォームでの圧縮ポインタ/SMI表現）として、メモリ上に連続してパッキングされる可能性を持つ。
`List`: 要素は必ず「ボックス化（Boxing）」されたオブジェクト、あるいはポインタの配列として扱われなければならない。なぜなら、`null` という「値の欠如」を表現するための番地（Sentinel）が必要になるからだ。

—

2. メモリレイアウトとGCの挙動差：なぜ `List` は重いのか

Dart VMのヒープにおいて、コレクションのメモリ効率はスループットを左右する最大のボトルネックである。

ポインタ配列 vs 連続した実体領域

AOTコンパイルされたDartコードにおいて、非ヌルなプリミティブ型を格納するリストは、VMの最適化によってアンボックス（Unbox）された連続メモリ領域として確保されることがある。これにより、キャッシュヒット率が劇的に向上する。

一方、`List`（例: `List`）の内部構造をVMのメモリダンプの視点から見ると、実態は「ポインタの配列（Array of Pointers）」である。
1. 各要素はヒープ上のオブジェクト（あるいはVM内部のポインタ）を指す。
2. `null` は特別なヌルポインタ、または番地として格納される。

[ List のメモリイメージ (理想的な連続領域) ]
[ 0x01 ] [ 0x02 ] [ 0x03 ] [ 0x04 ] (ダイレクトに値が並ぶ)

[ List のメモリイメージ (ポインタの配列) ]
[ Pointer A ] -> [ Boxed int (1) ]
[ Null Pointer ] -> null
[ Pointer B ] -> [ Boxed int (3) ]

この違いは、Generational GC（世代別ガベージコレクション）のマーキングフェーズにおいて甚大な差を生む。`List` は無数のポインタを内包するため、GCのコンカレント・マーク・スイープ時にスキャンすべき参照の数が跳ね上がり、ストップ・ザ・ワールド（Stop-the-world）のレイテンシを悪化させる原因となる。

—

3. 実践：型安全なコレクション操作と境界の制御

では、この低レイヤの挙動を理解した上で、どのように型安全なコードを設計すべきか。以下のコードブロックを見てほしい。意図せず `List` を生み出し、パフォーマンスを劣化させるアンチパターンと、それを防ぐための防壁としてのジェネリクス設計だ。

// — アンチパターン：不要なNull許容性の伝播 —
class UnoptimizedCache {
// T が非ヌルであっても、内部リストが Null許容だと
// VMはすべてのスロットにボックス化の可能性を考慮したポインタ配列を強制される
final List _storage = [];

void put(T item) {
_storage.add(item);
}

T? get(int index) {
if (index < 0 || index >= _storage.length) return null;
return _storage[index]; // 冗長なNullチェックの発生
}
}

// — 最適化されたパターン：厳格な型境界の定義 —
class OptimizedCache {
// T extends Object により、T自体が非ヌルであることが保証される。
// ただし、List 自体は要素の欠落を許さない。
final List _storage = [];

void put(T item) {
_storage.add(item); // 実行時に余計なボックス化コストを回避可能
}

// 取得時の安全性を担保しつつ、内部ストレージの整合性を守る
T elementAt(int index) {
return _storage[index]; // 境界外アクセスは RangeError (フェイルファスト)
}
}

void main() {
// コンパイル時およびVM実行時において最適化されるパス
final cache = OptimizedCache();
cache.put(42);

// 意図的に Null を扱いたい場合は、コンテナのレイヤで明示的に分離する
// これにより「常に存在するデータ」と「欠落しうるデータ」のメモリレイアウトを分離できる
}

コードの解説とVMの挙動

`OptimizedCache` と定義することで、Dartのコンパイラは `T` が決して `null` を取らないという最強の不変式（Invariant）を手に入れる。これにより、JIT/AOTコンパイラは不要なヌルチェック命令（`BranchIfNull` など）をアセンブリレベルでインライン展開から排除することが可能になる。

—

4. イベントループと非同期処理におけるジェネリックNull安全

Dartのイベントループ（Microtask Queue / Event Queue）を介してデータを非同期ストリームやフューチャーでやり取りする際も、この型安全性の維持は極めて重要である。

// ストリーム処理における Null許容性の伝播エラーを防ぐ
Stream safeStreamProcessor(Stream source) async {
await for (final item in source) {
// 実行時型チェックとイベントループのキュー消費
if (item != null) {
yield item; // ここでコンパイラは item が T であることをスマートキャスト（CFA）する
}
}
}

イベントループがミリ秒単位で数千のイベントを処理する高ス負荷なシステムにおいて、`Stream` から流れてくる `null` のフィルタリングを怠ると、下流のコンポーネントで無駄な Null チェックが連鎖し、CPUパイプラインの分岐予測（Branch Prediction）ミスを誘発する。結果として、CPUのクロックサイクルが無駄に消費されることになる。

—

5. 結論：型システムはハードウェアへの命令書である

Dartの Sound Null Safety は、IDE上で赤い波線を出すための道徳的なお説教ではない。それは、「このメモリ領域には絶対に `null` が存在しない」という絶対保証をコンパイラに与え、生成されるマシンコードを極限まで最適化するための最高峰の武器である。

`List` と `List` の選択は、単なるコーディングスタイルの好みではなく、メモリフットプリント、GCの効率、そしてCPUの実行パフォーマンスを支配するアーキテクチャ上の重大な決断なのだ。

シニアエンジニアたるもの、自分が書いた一行のジェネリクスが、Dart VMのヒープ上でどのようにアロケーションされ、CPUにどう解釈されるかまでを脳内で完全にトレースできなければならない。型を制する者が、ランタイムを制する。