【テクニカル・上級編】FiberとGeneratorの比較：協調的マルチタスクにおけるパフォーマンス特性とユースケースの境界線 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

PHPコアの深淵：FiberとGeneratorの交錯、そして協調的マルチタスクの真実

PHPは長らく「1リクエスト＝1プロセス（またはスレッド）」という、プリミティブで泥臭い共有ナッシングの実行モデルのうえに構築されてきた。Apache + mod_phpの時代から現代のPHP-FPMに至るまで、このアーキテクチャはWebのスケールにおいて驚異的な耐障害性とシンプルさを提供し続けたが、同時にI/Oバウンドなワークロードにおけるスループットの限界を常に内包していた。

非同期処理、あるいはノンブロッキングI/Oといえば、Node.jsのイベントループやGoのGoroutineが引き合いに出される。PHPにおいても、ReactPHPやAmpといったユーザーランドのイベントループライブラリが、`stream_select`を駆使して非同期の幻影を作り上げてきた。しかし、その実装の本質は「コールバック地獄」あるいは「Generator（Generators）を用いた複雑なステートマシーンの構築」であった。

PHP 8.1で導入された Fiber（ファイバー） は、このパラダイムを根底から覆す可能性を秘めている。スタックフルなコルーチンを言語コアレベルで提供し、任意の深さのコールスタックから処理を中断（Suspend）し、再開（Resume）できるようになったからだ。

本稿では、イテレータの域を出ない Generator と、真の実行コンテキストを持つ Fiber の違いを、Zend VMの低レイヤ挙動、メモリ管理（HashTableとzend_execute_data）、そしてコンテキストスイッチのコストという極限の観点から解剖する。

—

1. 内部構造の比較：Generatorのステートマシーン vs Fiberのスタックフル・コルーチン

まず、Zend Engineがこれら二つの言語機能をどのように解釈し、メモリ上で処理しているのかを理解しなければならない。両者はどちらも「処理を中断・再開できる」という共通の特長を持つが、その内部表現は全く異なる。

Generator：コンパイル時に生成されるステートマシーン

Generatorは、PHP 5.5での導入以来、メモリ効率の良いイレテータとして愛用されてきた。しかし、Zend VMの視点から見れば、Generatorの本質は「自動生成されたステートマシーンを持つクラスインスタンス（`zend_generator`）」に過ぎない。

Generator関数が呼び出されたとき、Zend VMは通常の関数フレーム（`zend_execute_data`ヒープ領域）を即座に破棄せず、ヒープ上に`zend_generator`構造体をアロケーションする。コード内の `yield` キーワードは、コンパイル時にオペコード（`ZEND_YIELD`）へと変換される。

// Generatorの概念的挙動：内部でステータス（STATE_RUNNING, STATE_SUSPENDED等）を管理
function yield_heavy_process(): Generator {
$data = fetch_from_db_chunk(); // ブロッキングI/O
yield $data;
}

メモリフットプリント: 極めて軽量。現在の実行ポインタ（PC）とローカル変数を保持するための最小限の構造体しか消費しない。
制約: コールスタックの「深さ」を自律的に保持できない。つまり、Generatorの中から呼び出した通常の関数（サブルーチン）の内部から直接 `yield` することはできず、値の伝播は常に呼び出し元へのバケツリレー（`yield from` を含む）を強制される。

Fiber：真のスタックフル・コルーチン

一方、PHP 8.1で実装された Fiber は、Zend VMの実行コンテキストそのものをカプセル化する。

Fiberは、独自のCスタック（正確にはZend VMの実行スタックである `zend_execute_data` のチェインおよびプレースホルダー）をヒープ上に確保する。これにより、「どのネストの深さからでも、関数呼び出しのコンテキストを維持したまま中断できる」という、GoのGoroutineやC#のasync/awaitに近い特性を手に入れた。

use Revolt\EventLoop; // 現代の非同期エコシステム

$fiber = new Fiber(function (): void {
$result = deep_nested_io_operation(); // どの深度からでも中断可能
echo “Resumed with: {$result}\n5”;
});

$fiber->start();

メモリフットプリント: Generatorと比較して重い。独立した実行コンテキスト（`zend_execute_data`のスタックフレーム群）を保持するため、インスタンス化のコストやメモリ消費量は大きくなる。
利点: 既存のコールツリーを変更することなく、任意の地点で非同期境界を引くことができる。

—

2. ベンチマークとパフォーマンス特性：コンテキストスイッチの代償

「Fiberは便利だが、遅いのではないか？」
この疑問に答えるためには、Zend VMにおけるオーバーヘッドを計測し、その物理的構造を理解する必要がある。

以下のベンチマークコードは、数万回の協調的マルチタスク（切り替え）を行った際のパフォーマンス特性を比較したものである。

Generator vs Fiber コンテキストスイッチ負荷計測

// 1. Generatorベースの疑似協調的マルチタスク
function generator_task_runner(int $iterations) {
$gen = (function() use ($iterations) {
for ($i = 0; $i < $iterations; $i++) { yield $i; } })(); $start = hrtime(true); foreach ($gen as $val) { // 何もしない切り替え処理 } $end = hrtime(true); return $end - $start; } // 2. Fiberベースの協調的マルチタスク function fiber_task_runner(int $iterations) { $fiber = new Fiber(function() use ($iterations) { for ($i = 0; $i < $iterations; $i++) { Fiber::suspend($i); } }); $start = hrtime(true); while (!$fiber->isTerminated()) {
$val = $fiber->start();
if ($val === null && !$fiber->isTerminated()) {
$fiber->resume();
}
}
$end = hrtime(true);
return $end – $start;
}

$iterations = 10000;
echo “Generator Time: ” . (generator_task_runner($iterations) / 1e6) . ” ms\n”;
echo “Fiber Time: ” . (fiber_task_runner($iterations) / 1e6) . ” ms\n”;

実行結果から読み解くZend VMの挙動

通常、このベンチマークを実行すると、Generatorの方が圧倒的に高速に動作する。なぜなら、Generatorの `yield` は単なるステートマシーンのポインタ書き換えとローカル変数の退避・復元であるのに対し、Fiberの `Fiber::suspend()` と `resume()` は、Zend VMの実行スタックの切り替え、例外ハンドリングコンテキストの保存、そしてガーベジコレクタ（GC）との連携など、より複雑なCレベルの処理を伴うからだ。

しかし、ここに「ユースケースの境界線」がある。

Generatorを選ぶべき領域:
大規模なデータセットのストリーミング処理（DBのカーソル結果や巨大なCSVファイルの行単位処理）。
メモリ効率が最優先であり、非同期イベントループとの統合が不要な場合。
Fiberを選ぶべき領域:
複数の独立したタスク（HTTPリクエスト、WebSocketのクライアントセッション等）を並行して駆動し、コードの構造を「同期的な記述」のまま保ちたい場合。
既存のライブラリ（PDO、Curl、Redis等）をノンブロッキング化するイベントループ層（Revoltなど）と統合する場合。

—

3. 実践：Fiberを活用したノンブロッキングHTTPクライアントのアーキテクチャ

単なる理論ではなく、実務の現場でFiberの真価を発揮するパターンを示そう。非同期イベントループ（ここでは概念的なRevolt風のイベントループを想定）とFiberを組み合わせることで、PHPでありながらNode.jsやGoに匹敵するI/O並行性を実現できる。

Fiberベースの簡易イベントループとノンブロッキングHTTPフェッチャー

class AsyncExecutor {
private \SplQueue $queue;

public function __construct() {
$this->queue = new \SplQueue();
}

public function add(Fiber $fiber): void {
$this->queue->enqueue($fiber);
}

public function run(): void {
while (!$this->queue->isEmpty()) {
/ @var Fiber $fiber /
$fiber = $this->queue->dequeue();

if ($fiber->isTerminated()) {
continue;
}

try {
if (! $fiber->isStarted()) {
$fiber->start();
} else {
$fiber->resume();
}

// まだ終了していなければキューの末尾に戻す（ラウンドロビン）
if (!$fiber->isTerminated()) {
$this->queue->enqueue($fiber);
}
} catch (\Throwable $e) {
// 本番環境では適切にロギングすること
error_log(“Fiber Exception: ” . $e->getMessage());
}
}
}
}

// モック：ノンブロッキングなソケット通信をシミュレート
function async_http_get(string $url): string {
// 実際の実装ではここで stream_socket_client と stream_select を使用し、
// 読み込み可能になるまで Fiber::suspend() を呼ぶ。

$fiber = Fiber::getCurrent();
if (!$fiber) {
throw new \LogicException(“Fiber外からの非同期呼び出しは許可されていません。”);
}

// イベントループに「このソケットの準備ができるまでサスペンドする」と伝える
// ここでは簡略化のためダミーの遅延をシミュレート
$callbackId = simulated_non_blocking_io(function() use ($fiber) {
$fiber->resume(“Response from {$url}”);
});

return Fiber::suspend();
}

function simulated_non_blocking_io(callable $onReady): void {
// 非同期I/Oの完了を模倣（実際にはイベントループがタイマーやストリーム監視で実行）
// マルチスレッドやシグナル処理、あるいはstream_selectの仕組みがここに絡む
$onReady();
}

// — 実行エントリポイント —
$executor = new AsyncExecutor();

$urls = [
“https://api.example.com/v1/users”,
“https://api.example.com/v1/orders”,
“https://api.example.com/v1/products”
];

foreach ($urls as $url) {
$executor->add(new Fiber(function () use ($url) {
echo “Fetching: {$url}\n”;
$response = async_http_get($url);
echo “Received: {$response}\n”;
}));
}

$executor->run();

このコードにおいて、各リクエストは完全に独立したコールスタックを持ちながら、単一プロセス・単一スレッドの上で協調的に動作する。CPUがI/O待ちでブロックされる時間は極限まで削減される。

—

4. セキュリティ・ハックの文脈：Fiberとオブジェクトインジェクションの危険な交差点

最高峰のアーキテクトとして、光があれば影（脆弱性メカニズム）についても言及しなければならない。PHPコアの進化は、時として新しい攻撃ベクターを生み出す。

PHPにおける古くからの悪夢といえば PHPオブジェクトインジェクション（PHP Object Injection） である。ユーザー入力を `unserialize()` に渡すことで、任意のクラスの `__wakeup()` や `__destruct()` マジックメソッドを強制起動し、Gadget Chain（ガジェットチェーン）を構築してRCE（リモートコード実行）に至る脆弱性だ。

Fiberインスタンスのシリアライズという罠

ここで読者に問いかけたい。「Fiberオブジェクトはシリアライズ可能か？」

答えは No である。Fiberの内部にはCレベルの実行コンテキスト（スタックフレーム、ポインタ、リソース）が深く絡み合っているため、PHPのシリアライズエンジン（`serialize()` / `unserialize()`）はFiberのシリアライズを拒絶し、例外を投げるように設計されている。

しかし、もし仮に何らかのカスタムシリアライザや、アプリケーション層での不適切なデータ構造の保存（例えばセッションストレージやキャッシュに非同期タスクのクロージャやFiberのメタデータを保存しようとする試み）において、不完全な状態管理が行われた場合どうなるか？

// 危険なアンチパターンの例：非同期状態をRedisやセッションに不正保存
// クロージャ（Closure）やFiber内部の状態を含むオブジェクトを安易にシリアライズしようとすると…
class TaskContext {
public $fiber;
public function __construct(Fiber $fiber) {
$this->fiber = $fiber;
}
}

PHPのクロージャ（`Closure`）は `serialize()` 可能であるが、その内部でキャプチャしている変数や実行コンテキストが複雑化した場合、特定のバージョンにおけるZend VMのメモリ管理の不備（Use-After-Freeやタイプジャグリングの脆弱性）と組み合わさることで、メモリ破壊を引き起こすリスクが理論上存在する。

防御的アーキテクチャの鉄則

1. ユーザー入力を決してシリアライズエンジンに渡さない: これは鉄則中の鉄則であるが、モダンな非同期フレームワークにおいて、タスクのキューイング（Job Queue）にクロージャをそのままシリアライズして放り込む設計は、セキュリティの観点から極めて脆弱である。
2. タスクの識別子は常にプリミティブ型を使う: ジョブの永続化には、オブジェクトそのものではなく、識別子（ID）やパラメータ（配列/JSON）のみを使用し、実行コンテキストはサーバーメモリ上の安全なスコープ内で再構築すること。
3. OPcacheプリローディング環境での厳格な型安全性: FiberやGeneratorを多用するコードベースをOPcacheのプリロード（`opcache.preload`）対象にする場合、動的な型変化やスコープの漏洩が致命的なメモリリークやセグメンテーション違反（Segfault）を引き起こすことがあるため、静的解析ツール（PHPStan Level 9など）による厳格な型チェックをビルドパイプラインに組み込むことが不可欠である。

—

結びにかえて

PHPは、もはや単なる「Webのテンプレートエンジン」ではない。Zend VMの内部構造を深く理解し、GeneratorとFiberの特性を適材適所で使い分けることで、同期処理の直感性を維持したまま、高スループットな非同期並行処理システムを構築することが可能になった。

低レイヤのメモリ管理を知る者だけが、PHPの限界を突破し、真に堅牢かつ高速なWebシステムをアーキテクトできる。この知見をあなたのコードベースに落とし込み、エンジンの限界を極限まで引き出してほしい。