PHP 8.x Fiberの内部物理メカニズム：協調的マルチタスクとコールスタック退避の全貌
コードレビューをしよう。君たちが何気なく使っている `Fiber`、そしてそれを組み込んだ非同期I/Oフレームワーク。
「スレッドセーフティの呪縛から解放された」「ノンブロッキングでリクエストをさばける」――そう言って安易にコールスタックの切り替えを乱用していないか？
PHP 8.xで導入されたFiberは、OSスレッドを消費せずにPHPの実行コンテキストをユーザーランドでスイッチングするための強力なプリミティブだ。しかし、Zend VMのメモリ空間とコールスタックの物理構造を理解せずにこれを扱うことは、爆弾を抱えてコードを書くようなものだ。
今回は、Fiberが内部のZend VM上でどのようにコールスタックを退避・復帰させ、メモリを消費し、イベントループと協調動作するのか。その深淵なるメカニズムをコードと物理レイヤの挙動から徹底的に解き明かそう。
—
1. Zend VMのコールスタックとFiberの物理実態
従来のPHP（特にPHP 7/8の同期実行モデル）において、関数やメソッドの呼び出しはCのコールスタック（あるいはZend VMのエグゼキューションスタック）上に `zend_execute_data` という構造体として積み上げられていく。
通常、スクリプトが深くまでネストすればスタックが伸び、returnすれば巻き戻る。このライフサイクルは完全に同期型であり、途中で処理を一時停止して「別の場所へコンテキストをジャンプし、後から元の位置に戻る」なんて芸当は、ネイティブのコールスタック上では不可能だった。これを解決するために、かつてはGenerator（ジェネレータ）を用いた疑似的な協調動作が行われていたが、あちらは「スタックの浅い部分（直近の呼び出し元）への値の返却」しかできなかった。
Fiberの本質：独立したスタックバッファの動的割り当て
Fiberは、PHPの実行コンテキスト（実行中のopcode、ローカル変数、シンボルテーブル、引数、そして `zend_execute_data` のチェーン）を、OSのコールスタックから切り離された独立したヒープ上のバッファ（スタック）として完全にカプセル化する。
[ メモリ空間のイメージ ]
Zend Engine Global (EG)
├── Main Execution Stack (通常のリクエスト処理)
│ └── zend_execute_data (index.php -> controller -> service)
│
└── Fiber Heap Buffers (独立したコンテキスト)
├── Fiber #1 [ Suspended ]
│ └── 独自のエグゼキューションスタック（ローカル変数・opcodeポインタ保持）
└── Fiber #2 [ Running ]
└── 現在Zend VMが実行中のエグゼキューションスタック
`Fiber::suspend()` が呼び出されると、Zend VMは現在の `zend_execute_data` ポインタの状態をそのFiberのオブジェクト構造体内に退避（Snapshot）し、制御権を Fiberの呼び出し元（あるいはイベントループの親コンテキスト）へと強制的に巻き戻す（Unwind）。
そして `Fiber::resume()` が呼ばれると、保存されていた `zend_execute_data` のポインタとスタックフレームが復元され、あたかも「直前までそこで処理が続いていたかのように」VMの実行が再開されるのだ。
この一連の動作において、OSレベルのスレッドスイッチは一切発生しない。すべてはZend VMの仮想マシンレイヤ、すなわちユーザースペースのメモリ操作だけで完結している。これが、Fiberが軽量たる所以である。
—
2. 協調的マルチタスクと非同期I/Oイベントループの連携
Fiberはそれ単体ではただの「中断・再開可能な関数」にすぎない。真価を発揮するのは、非同期I/O（Streams, sockets, EventLoop）と組み合わせたときだ。
実務でよく見かける間違った設計は、Fiberの中でブロッキングなI/O（例えば重い外部APIへの同期cURLリクエストや、ブロックモードのソケット読み込み）をそのまま実行してしまうことだ。これをしてしまうと、OSスレッド自体がブロックされるため、同一プロセス内で動いている他のすべてのFiberの実行も完全に凍結される。Fiberを使っている意味が完全に消滅する。
正しく設計されたFiberアーキテクチャでは、イベントループ（LibeventやEv、あるいは純粋なPHP製イベントループ）が非同期ソケットのreadable/writableを監視し、データが準備できた瞬間に該当のFiberを `resume()` する。
実務に耐えうる堅牢な非同期タスクオーケストレーターの実装
ここでは、PHP 8.xのFiberと原生のストリーム非同期化を組み合わせた、ミニマルかつ極限まで洗練された協調的マルチタスク・スケジューラのコードを示す。
/
class AsyncScheduler
{
private SplQueue $queue;
private bool $isRunning = false;
public function __construct()
{
// 実行待ち（あるいは再開待ち）のFiberを格納するキュー
$this->queue = new SplQueue();
}
/
- 新しいタスク（Fiber）をスケジューラに登録する
/
public function add(callable $task): void
{
$fiber = new Fiber(function () use ($task) {
try {
// タスクの実行
$task();
} else {
// 例外発生時のロギングや安全なキャッチ
}
});
$this->queue->enqueue($fiber);
}
/
- スケジューラのメインループを開始する
/
public function run(): void
{
$this->isRunning = true;
while (!$this->queue->isEmpty() && $this->isRunning) {
/ @var Fiber $fiber /
$fiber = $this->queue->dequeue();
try {
if (!$fiber->isStarted()) {
// 初回実行
$fiber->start();
} elseif (!$fiber->isTerminated()) {
// サスペンド状態からの再開
$fiber->resume();
}
// 実行後、ファイバーがまだ終了していなければキューの末尾に戻す（ラウンドロビン）
if (!$fiber->isTerminated()) {
$this->queue->enqueue($fiber);
}
} catch (Throwable $e) {
// プロダクション環境ではここで確実にエラーをハンドリングし、
// プロセス全体のクラッシュを防ぐ
error_log(sprintf(
‘[Fiber Error] %s in %s:%d’,
$e->getMessage(),
$e->getFile(),
$e->getLine()
));
}
}
}
public function stop(): void
{
$this->isRunning = false;
}
}
// ==========================================
// 実践的な利用例：非同期タスクのシミュレーション
// ==========================================
$scheduler = new AsyncScheduler();
// タスク1：データベースの非同期クエリ（を模したモック）
$scheduler->add(function () {
echo “[Task 1] データベースクエリ送信…\n”;
// I/O待ちを模してファイバーをサスペンド
// 実運用ではここでソケットのnon-blocking読み込みとイベントループの登録を行う
Fiber::suspend();
echo “[Task 1] データベースからの応答を受信し、処理を再開します。\n”;
});
// タスク2：外部APIへのリクエスト（を模したモック）
$scheduler->add(function () {
echo “[Task 2] 外部APIへHTTPリクエスト送信…\n”;
Fiber::suspend();
echo “[Task 2] 外部APIのレスポンスパース完了。\n”;
});
// スケジューラの駆動
$scheduler->run();
/
【実行結果】
[Task 1] データベースクエリ送信…
[Task 2] 外部APIへHTTPリクエスト送信…
[Task 1] データベースからの応答を受信し、処理を再開します。
[Task 2] 外部APIのレスポンスパース完了。
/
このコードのポイントは、`Fiber::suspend()` によって制御が一度スケジューラ（`run()` メソッドのループ）に戻り、別のタスク（Task 2）へコンテキストが切り替わっている点だ。OSスレッドを一切ブロックせず、1つのプロセス・1つのスレッド内で多重化された処理を実現している。
—
3. 実務における危険な罠：メモリリークと循環参照の恐怖
アーキテクトとして最も警鐘を鳴らしたいのは、Fiberのライフサイクルとメモリ空間の管理の難しさだ。
Fiberの内部で無名関数（Closure）を使用し、その中で重いオブジェクトやデータベースのコネクション、あるいは大きな配列を `use` したり、プロパティとして保持し続けた場合、そのFiberオブジェクトが破棄されるまで（あるいは `isTerminated()` になるまで）すべてのメモリがZend Engineのヒープ上に強固にバインドされ続ける。
特に、Webアプリケーション（PHP-FPM環境など）において、リクエストスコープを超えてFiberインスタンスを静的プロパティやグローバルなレジストリに保持してしまった場合、ガベージコレクション（GC）の参照カウントが落ちず、致命的なメモリリーク（Memory Leak）を引き起こす。
循環参照のメカニズム
Fiber内部で自身への参照や、親スコープの巨大な構造体（例えば依存性コンテナやリクエストオブジェクト）を保持し、かつ例外によってFiberが `terminated` にならずに中途半端な `suspended` 状態で放置された場合、Zend VMの循環参照GC（Circular Reference Collector）がそれを回収しきれないケースがある。
[危険なメモリ保持の構造]
[Global Registry / Static Cache]
└── AsyncScheduler (永続化される可能性)
└── Fiber Instance [ Suspended State ]
└── Closure (use ($heavyService, $dbConnection))
└── $heavyService
└── (循環参照の起点となりうるオブジェクト)
【厳守すべき設計ルール】
1. Fiberのスコープは極限まで短く保つ
Fiberは「長生きさせるもの」ではない。ひとつのリクエスト、あるいは単一の非同期処理セッションの中で完結させ、処理が終了したら速やかにインスタンスへの参照を断ち切るべし。
2. `use` 句での巨大オブジェクトのキャプチャを避ける
クロージャ内で必要なのはプリミティブな値や、必要なIDなどの軽量な識別子だけであるべきだ。巨大なオブジェクトを丸ごとFiber内に持ち込んではならない。
3. 例外時の確実なクリーンアップ
Fiber内で例外が発生し、かつそれがキャッチされない場合、ファイバーはデッドロック状態に陥るか、メモリ上にゾンビのように残り続ける。必ず `try-catch` で囲み、異常終了時でもリソース（オープンされたファイルハンドルやソケット）が確実に解放される構造を担保すること。
—
結び：アーキテクトとしての提言
FiberはPHPに真の非同期プログラミングの扉を開いた。しかし、「書けば勝手に速くなる魔法の杖」ではない。
コールスタックの退避、ヒープ上のメモリバッファ、イベントループとの調停――これらすべての物理メカニズムを脳内に描けて初めて、プロダクション環境で耐えうる堅牢な非同期アーキテクチャが構築できる。
コードレビューの際、安易に `new Fiber` を乱発し、メモリ管理や例外時のライフサイクルを考慮していないコードを見つけたら、こう問いかけたまえ。
「おい、このFiberがサスペンドしたままゾンビ化した時、Zend VMのメモリ空間で何が起きるか分かっているのか？」と。
その問いにロジカルに答えられないうちは、君たちのコードベースにFiberを導入する資格はない。低レイヤを知る者だけが、真にスケーラブルなシステムを支配できるのだ。