【入門編】PHPのジェネレータ（Generators）によるメモリ効率化の物理的根拠 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

2026.08.05

こんにちは。普段、JavaやGo、あるいはNode.jsといった他言語の高水準な非同期処理やストリーム処理をバリバリこなしているあなたなら、PHPのコードを書くときふと、こんな疑問を抱いたことはありませんか？

「数百万件のレコードをバッチ処理で扱うとき、なぜPHPはプレーンな配列（Array）でメモリを爆発させずに処理できるのか？」
「フレームワークのORMが返す巨大な結果セットを、なぜジェネレータ（Generator）に流し込むだけでメモリ使用量がピタリと安定するのか？」

ネット上の入門記事を見ると、「ジェネレータを使うとメモリを節約できます」というお決まりの文句が並んでいますよね。でも、シニアなエンジニアであるあなたに必要なのは、そんな表面的なお題目ではないはずです。

「Zend VMの内部で、一体何が起きているのか？」
「C言語レベルのメモリ空間や、PHPのシンボルテーブルはどう変化しているのか？」

今回は、世界中のWebシステムを支えるPHPの心臓部、Zend VMの実行メカニズムとメモリ管理の物理的根拠に踏み込み、ジェネレータの正体を丸裸にしていきましょう。ここを理解すると、PHPという言語の裏側が驚くほど美しく見えてきますよ。

—

1. 巨大配列がPHPのメモリを殺す理由（Zend VMの視点）

まず、敵を知るために、私たちが普段何気なく使っている「配列」がZend VMの内部でどう扱われているかを見てみましょう。

PHPの配列は、実態としてはただのリストではありません。順序付きハッシュマップ（Ordered Hash Table）であり、C言語の構造体としては非常にリッチな作りをしています。

// 100万件の整数を持つ配列を作る愚行
$heavyArray = range(1, 1000000);

これを実行した瞬間、Zend VMはメモリ（zend_mm_heap）上に100万個の `zval`（PHPのあらゆる変数を表現する構造体）を生成し、それらをハッシュテーブルのバケツで繋ぎ止めます。
1つの `zval` は通常16バイト、さらにハッシュのメタデータやポインタのオーバーヘッドを加味すると、たった100万件の整数配列をメモリ上に展開するだけで、数十メガバイトから場合によっては百数十メガバイトもの物理メモリが一瞬で消飛ぶことになります。

Webサーバーの1リクエスト（FPMプロセス）において、これを数人のユーザーが同時に踏んだらどうなるか……想像するだけで背筋が凍りますよね。これが、PHPで「全データを一度に配列へロードするな」と言われる物理的な理由です。

—

2. ジェネレータの本質：配列を作らず「実行コンテキスト」を凍結する

ここで登場するのが、`yield` キーワードを持つジェネレータです。

他言語（例えばPythonやJavaScript）でもお馴染みの概念ですが、PHP（Zend VM）におけるジェネレータは、言語仕様の美しさとC言語レベルの省メモリ設計が絶妙に融合した傑作です。

ジェネレータの本質をひと言で言えば、「関数フレーム（実行コンテキスト）のメモリ上での凍結と復元」です。

通常、関数が呼び出されると、Zend VMはコールスタック上に新しい `zend_execute_data`（関数実行用のスタックフレーム）を積み、ローカル変数を展開し、処理が終わればそのメモリをごっそり解放します。

しかし、関数内に `yield` が存在すると、Zend VMの挙動が劇的に変わります。

1. フレームの永続化: 関数が呼び出されたとき、通常のスタックではなく、ヒープメモリ上に `zend_generator` オブジェクトという特別なコンテキストがアロケートされます。
2. 実行のサスペンド（一時停止）: `yield` に到達すると、VMはその時点でのローカル変数の状態、プログラムカウンタ（オペコードのどこまで実行したか）、そしてコールスタックの状況をすべてそのオブジェクト内に保存したまま、呼び出し元に制御を返します。
3. レジューム（再開）: 外部から次の値が要求されると（`->current()` や `foreach` の次のループ）、VMは保存されたコンテキストを復元し、前回停止したオペコードの次の行から実行を再開します。

百聞は一見に如かず。実際にメモリ効率を極限まで高めたジェネレータのコードを見てみましょう。

“User_ID_” . $i;
}
}

// メモリ使用量を計測してみる
$memoryBefore = memory_get_usage(true);

// 呼び出しても、この時点では100万件のデータは一切メモリ上に存在しない！
$generator = generateMillionRecords();

$memoryAfter = memory_get_usage(true);

echo “ジェネレータ初期化時のメモリ増加量: ” . ($memoryAfter – $memoryBefore) . ” bytes\n”;
// 出力結果はおよそ数千バイト（数KB）程度に収まります。

信じられますか？ 100万件のデータを扱う定義をしたにもかかわらず、初期化時点でのメモリ消費はほとんどゼロ（数KBのオブジェクト構造体分のみ）です。配列を使っていた頃の数十MBとは、文字通り桁が違います。

—

3. 内部エンジンの裏側：オペコードと `zend_generator` のライフサイクル

もう少しだけ深く、Zend VMのミドルウェア層の動きを覗いてみましょう。

PHPのソースコードは、コンパイルされてオペコード（Opcode）の列になります。通常の値の返却には `RETURN` オペコードが使われますが、ジェネレータを含む関数の場合、コンパイラ（Zend Compiler）は通常のreturnを、内部的なサスペンド処理を行う特別なオペコードにすげ替えます。

`foreach` やイテレータの仕組みを通じてジェネレータが操作されるとき、Zend VM内部では以下のようなC言語レベルの関数ポインタが高速に往復しています。

  • `zend_generator_get_current_data` （現在の値の `zval` を取得）
  • `zend_generator_resume` （VMの実行状態を復元し、次の `yield` まで走らせる）

この仕組みの美しいところは、「データを保持するのではなく、データを生み出す手順（ロジック）のポインタを保持している」という点です。メモリ上には、常に「今処理している、たった1つの `zval`」しか存在しません。

実務で使える：巨大CSVの逐次ストリーミング処理

この知見を実際のWebアプリケーション、例えば「数GBある巨大なCSVファイルをメモリ溢れさせずに安全にパースしてDBにインサートするバッチ処理」に応用してみましょう。

  • 巨大なCSVファイルを1行ずつ安全に読み込むジェネレータ

    • /
    public static function readInChunks(string $filePath): Generator
    {
    $handle = fopen($filePath, ‘rb’);
    if ($handle === false) {
    throw new RuntimeException(“ファイルが開けません: {$filePath}”);
    }

    try {
    // fgetcsvは1行ずつバッファから読み込むため、これ自体が非常にメモリ効率が良い
    while (($row = fgetcsv($handle, 0, ‘,’)) !== false) {
    // 1行分の配列をyieldで呼び出し元へパスする
    // 呼び出し側が処理を終えるまで、この行のメモリ空間だけが一時的に維持される
    yield $row;
    }
    } finally {
    // 例え途中で例外やbreakが発生しても、確実にごみを掃除する
    fclose($handle);
    }
    }
    }

    // — 実際のバッチ処理スクリプト —
    $csvPath = ‘/var/data/huge_transaction_log.csv’;

    // メモリを気にせず、何千万行あっても安全に回せる
    foreach (CsvReader::readInChunks($csvPath) as $rowIndex => $columns) {
    // 例: DBへのバルクインサート用バッファに詰めるなど
    // process_to_database($columns);

    // デバッグ用出力
    if ($rowIndex % 10000 === 0) {
    echo “現在 {$rowIndex} 行目を処理中… 現在のメモリ: ” . round(memory_get_usage(true) / 1024 / 1024, 2) . ” MB\n”;
    }
    }

    このコードの美しさは、`finally` ブロックとの組み合わせにあります。ジェネレータが途中で破棄（`unset` やスコープアウト）された場合でも、Zend VMはデストラクタを通じて確実にリソース（ファイルハンドルなど）を解放する設計になっています。

    —

    4. アーキテクトからのメッセージ

    いかがでしたでしょうか？

    「ジェネレータはメモリに優しい」という言葉の裏側には、Zend VMが実行コンテキスト（スタックフレーム）をヒープ上で巧みに凍結・再開し、`zval` の爆発を防いでいるという、極めてエレガントな物理的メカニズムが存在しています。

    他言語での経験があるあなたなら、この「遅延評価（Lazy Evaluation）」の概念が、PHPという歴史あるインタプリタ言語の中でどれほど洗練されて実装されているか、痛いほど感じ取れるはずです。

    「なぜこの書き方が速いのか」「なぜメモリリークを防げるのか」。
    その理由を底层（ローレベル）から理解したあなたなら、もうフレームワークの魔法に怯える必要はありません。自信を持って、大規模で堅牢なPHPシステムを設計・構築してください。

    あなたの背中を、この知見が力強く支えてくれることを願っています。

    スポンサーリンク
    " "
    タイトルとURLをコピーしました