PHP 8.x FiberとZend VMの深淵：協調的マルチタスクとメモリ空間の物理メカニズム
PHPの世界において、長年「共有ード・ナッシング（Shared-Nothing）」アーキテクチャと1リクエスト1プロセス（あるいはFPMによるプール管理）は、Webアプリケーションのメンタルモデルの根幹であった。プロセス境界がメモリの安全性を担保し、リクエスト終端時にすべてのヒープがOSへ返却される。この構造は美しく、メモリリークの悪夢から開発者を守ってきた。
しかし、現代の非同期I/O、リアルタイム通信、マイクロサービス間の高頻度RPCが求めるスループットは、従来のブロッキングI/Oとプロセス/スレッド生成のコストを許容しない。そこでPHP 8.xで導入されたのが Fiber（ファイバー） である。
本稿では、一般的な「使い方の解説」という退屈な道は一切歩まない。Zend VMのコールスタック、Zend Executorの内部状態、そしてFiberがメモリ空間上でどのように実行コンテキストを物理的に退避・復帰させているのか。その低レイヤの真実を解き明かす。
—
1. 従来のコールスタックとFiberの物理的乖離
通常、PHPの関数呼び出しは、Zend VM上の `zend_execute_data` 構造体の連結リスト（コールスタック）によって管理される。各関数呼び出しはスタックフレームを消費し、ローカル変数、引数、一時変数を保持する。
[Global Execution] -> [controller()] -> [service()] -> [repository()]
これらはOSのスレッドスタック上に線形に構築されるため、途中で処理を中断して別の文脈にジャンプし、後から元の場所に戻るということは、C言語レベルの `setjmp`/`longjmp` やスタックのコピーを行わない限り不可能だった。
Fiberの本質：ユーザースペースにおけるスタックレス/スタックフル・コンテキストスイッチ
PHPのFiberは、「スタックフル・ファイバー（Stackful Fiber）」である。
OSのスレッドを切ることなく、Zend VMの実行コンテキスト（`zend_execute_data` および関連するVMスタック）をヒープ上に切り出し、独立した空間として保持する。
Fiberを生成した瞬間、Zend VMは通常のコールスタックとは別に、専用のVMスタック領域（Heap上に確保されたチャンク）を割り当てる。
[OS Thread Stack]
└─ Zend Executor (Main Loop)
│
├─ Fiber #1 Context (Heap Allocated zend_vm_stack)
└─ Fiber #2 Context (Heap Allocated zend_vm_stack)
この物理構造により、Fiberの内部で `Fiber::suspend()` が呼び出された際、Zend VMは現在の `EG(current_execute_data)` ポインタを退避させ、親となる（あるいはイベントループ側の）コンテキストへとポインタを付け替える。スレッドのコンテキストスイッチで発生するカーネルモードへの遷移（Ring 3からRing 0への切り替え、TLBフラッシュ、CPUレジスタの退避）が一切発生しないため、極めて高速に動作する。
—
2. FiberのライフサイクルとZend VM内部の挙動
以下のコードを見てほしい。一見すると同期的な処理だが、内部ではZend VMの実行コンテキストが動的にスイッチしている。
/
$fiber = new Fiber(function (string $name): void {
echo “[Fiber] {$name}: 実行開始\n”;
// 最初のサスペンド：親スコープへ値を返しつつ処理を中断
$received = Fiber::suspend(“データ要求: 最初の停止”);
echo “[Fiber] {$name}: 再開しました。受け取った値 -> {$received}\n”;
// 2度目のサスペンド
$resumedAgain = Fiber::suspend(“データ要求: 2回目の停止”);
echo “[Fiber] {$name}: 完了。最終値 -> {$resumedAgain}\n”;
});
// メインコンテキストからの制御
echo “[Main] ファイバー起動\n”;
$value1 = $fiber->start(“Worker-A”);
echo “[Main] ファイバーからサスペンドされた値: ‘{$value1}’\n”;
echo “[Main] ファイバーへデータを送り再開\n”;
$value2 = $fiber->resume(“A-ACK”);
echo “[Main] ファイバーから2度目にサスペンドされた値: ‘{$value2}’\n”;
echo “[Main] ファイバーを完全に終了させる\n”;
$fiber->resume(“A-FINAL”);
echo “[Main] すべての処理が終了\n”;
このコードの裏側で起きていること
1. `new Fiber(…)`: この時点ではまだコードは実行されない。Fiberオブジェクトの内部構造体（`zend_fiber`）が初期化され、クロージャがアタッチされるが、VMスタックの割り当ては遅延されるか、`start()` 呼び出し時に行われる。
2. `$fiber->start()`: メインのZend Executorが中断され、新規に割り当てられたVMスタックへ `EG(current_execute_data)` が切り替わる。クロージャの引数 `”Worker-A”` が渡され、関数内の実行が始まる。
3. `Fiber::suspend()`:
- 内部で `zend_fiber_suspend()` がコールされる。
- 現在のVMスタックの状態（ローカル変数、オペコードの実行位置を示す `opline`）がFiberのコンテキスト構造体に保存される。
- `EG(current_execute_data)` が呼び出し元（メインコンテキスト）のポインタに復元される。
- `start()` の戻り値として、引数に渡した `”データ要求: 最初の停止”` がメイン側に返される。
—
3. 非同期I/Oイベントループとの統合メカニズム
Fiber単体では、自発的に再開（Resume）することはできない。必ず外部の駆動者（Scheduler / Event Loop）が必要となる。ここにAmpやReactPHPといった現代の非同期PHPフレームワークの根幹がある。
非同期I/O（例: 非同期HTTPリクエストやソケット読み込み）を行う際の、理想的な協調的マルチタスクのアーキテクチャを考えてみよう。
/
class AsyncScheduler {
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();
try {
if (!$fiber->isStarted()) {
$fiber->start();
} else if (!$fiber->isTerminated()) {
$fiber->resume();
}
// ファイバーがまだ終了していなければ、キューの末尾に戻す（ラウンドロビン）
if (!$fiber->isTerminated()) {
$this->queue->enqueue($fiber);
}
} \Throwable $e {
// 例外の伝播処理
echo “[Scheduler Error] ” . $e->getMessage() . “\n”;
}
}
}
}
// スケジューラのインスタンス化
$scheduler = new AsyncScheduler();
$scheduler->add(new Fiber(function() {
echo “[Task 1] スタート\n”;
Fiber::suspend();
echo “[Task 1] I/O待機完了から復帰\n”;
Fiber::suspend();
echo “[Task 1] 終了\n”;
}));
$scheduler->add(new Fiber(function() {
echo “[Task 2] スタート\n”;
Fiber::suspend();
echo “[Task 2] 復帰\n”;
echo “[Task 2] 終了\n”;
}));
// イベントループ駆動開始
$scheduler->run();
この協調的マルチタスクにおいて、I/O待機（非同期ソケットの `epoll_wait` など）が発生した際、タスクは `Fiber::suspend()` によって実行権を手放し、イベントループが別のFiberを実行する。I/Oイベントが完了した時点で、イベントループが該当のFiberに対して `resume()` を叩くことで、シームレスに処理が再開される。
—
4. メモリ空間の物理メカニズムとガベージコレクションの罠
Fiberを利用する上で、Zendエンジン特有のメモリ管理構造を理解していないと、深刻なメモリリークや未定義動作（UAF: Use-After-Free）を引き起こす。
1. ヒープ消費とスタックチャンク
前述の通り、FiberごとのVMスタックはPHPのZendメモリマネージャー（ZMM）を介してヒープ上に確保される。デフォルトでは、各Fiberのスタックサイズは固定（通常は数万バイト単位、環境や設定に依存）であり、再帰呼び出しが深すぎるとスタックオーバーフローを引き起こす。これはOSのスレッドスタックと同様の制約である。
2. 参照カウント（Refcount）とクロージャの束縛
Fiberの引数やクロージャ内で外部変数をキャプチャ（`use`）する場合、その変数の参照カウントはFiberが生存している間インクリメントされたままとなる。
もし、ロングランニングなプロセス（Swoole、RoadRunner、あるいは自作のデーモンプロセス）上でFiberを多用し、終了したFiberオブジェクトの参照をグローバルな配列などに保持し続けた場合、回収されるべきZendコンテナ（配列やオブジェクト）がヒープ上に残り続け、メモリリークの温床となる。
[Global Scope Array] ──> [Fiber Instance] ──> [Closure] ──> [Large Data Context]
│
(Refcount > 0 で固定)
このため、Fiberベースの非同期アプリケーションでは、タスクが完了（`isTerminated() === true`）したファイバーインスタンスは速やかにスコープ外へ追いやり、参照を切断してZendのサーキュラーGC（循環参照コレクター）へ処理を委譲、あるいは明示的なメモリ解放を意識した設計が不可欠である。
—
5. セキュリティ・アーキテクチャの視点：Fiberとオブジェクトインジェクション
最後に、極限の知見としてセキュリティレイヤに踏み込む。
PHPアプリケーションにおけるオブジェクトインジェクション（PHP Object Injection）は、不健全なユーザー入力を `unserialize()` に渡すことで、既存のクラスが持つマジックメソッド（`__destruct()`, `__toString()`, `__wakeup()` など）を連鎖させ、Gadget Chainを構築して任意のコード実行（RCE）に至る脆弱性である。
Fiberの導入は、この脆弱性の攻撃ベクトルにどのような影響を与えるか？
非同期コンテキストにおけるオブジェクトの状態不整合
Fiberや非同期フレームワークを用いたアプリケーションでは、1つのプロセスが複数のリクエストやタスクの断片を時分割で処理する。
もし、セッションデータやグローバルなDIコンテナ内にシリアライズ可能な状態で保持されたオブジェクトが、異なるFiber間で共有・誤用された場合、従来のリクエスト分離モデル（Shared-Nothing）では想定されなかった「状態の競合（Race Condition）」およびそれに伴う不意のデストラクタ呼び出しが発生しうる。
攻撃者が悪意あるシリアライズデータを非同期ワーカーに注入することに成功した場合、イベントループのコンテキストスイッチの隙をついて予期せぬタイミングでガベージコレクションやオブジェクトの破棄（`__destruct` の発火）が誘発され、Gadget Chainの実行タイミングをより精密にコントロールされる危険性が高まる。
したがって、Fiberを採用するモダンな非同期PHP環境においては、データのイミュータブル（不変）性の担保、そして外部入力のシリアライズ・デシリアライズ処理に対する厳格な型検証とサニタイズが、これまで以上に致命的な防御要件となる。
—
総括
PHP 8.xのFiberは、単なる「書きやすい非同期構文の糖衣」ではない。それは、Zend VMの実行コンテキストをユーザーランドで自在にコントロールし、PHPの限界とされてきたI/Oバウンドな処理のボトルネックを打ち破るための、極めて低レイヤな機構である。
VMスタックの物理構造、Zend Executorのポインタ操作、そしてメモリ管理のライフサイクルを完全に見きわめた者だけが、真に堅牢かつ高スループットなPHPアーキテクチャを構築できる。コードの向こう側にあるZend VMの鼓動を感じ取れ。