Fiberのキャンセル機構とリソース解放：Zend VMのコンテキストスイッチとメモリ管理の深淵
PHP 8.1で導入された`Fiber`（ファイバー）は、PHPにおける非同期並行処理パラダイムのゲームチェンジャーとなった。従来の`Generator`ベースの協調的マルチタスキングの限界を突破し、コールスタックを独立したヒープ領域に切り離すことで、任意の深さの関数呼び出しから中断（Suspend）と再開（Resume）を可能にした。
しかし、この強力なプリミティブは、Zend VMのメモリ管理モデルおよびC言語レベルのリソースライフサイクルに対する深い理解なしに運用すれば、瞬く間に致命的なメモリリークやリソースの枯渇、さらには競合状態（Race Condition）を引き起こす。
本稿では、Fiberのキャンセル機構におけるZend VM内部の挙動、実行コンテキストの破棄に伴うリソース解放のメカニズム、そして堅牢な非同期ランタイムを構築するための極限の知見を解説する。
—
1. Fiberの内部構造とZend VMのコンテキストスイッチ
PHPのFiberは、C言語レベルでは`zend_fiber`構造体として表現される。通常の関数コールがコールスタック（Cスタック）上で線形に積まれるのに対し、Fiberは独自のスタックバッファをヒープ上に動的確保する。
コールスタックのヒープ退避
Fiberが生成されると、Zendエンジンは以下の処理を実行する。
1. スタック領域の確保: デフォルトでは通常数MBのスタックサイズが割り当てられ（OSや設定に依存）、`zend_execute_data`とスタックフレームのポインタがFiber固有のコンテキストに紐付けられる。
2. プレパレーション: `Fiber::start()`が呼ばれると、VMの実行コンテキスト（`EG(current_execute_data)`など）がFiberのそれへとすり替わり、コンテキストスイッチが発生する。
この仕組みにより、Fiber内で`Fiber::suspend()`がコールされると、現在のZend VMの実行状態が凍結され、親のコンテキスト（通常はメインのリクエストスレッド）へと制御が移譲される。
—
2. Fiberの「キャンセル」という概念の不在と安全な停止戦略
極めて重要な事実として、PHPのFiberコアには「外部から強制的にFiberを殺す（Kill/Cancel）」ための安全なプリミティブは存在しない。
もしOSのスレッドのように外部から強制終了させようとすれば、Zend VMが保持しているシンボルテーブルの整合性、オブジェクトの参照カウント（Refcount）、そして何よりも割り当てられたリソース（DBコネクション、ファイルディスクリプタ等）の解放処理が中途半端な状態で途絶え、Segmentation Fault（セグフォルト）や致命的なメモリリークを引き起こす。
したがって、Fiberの「キャンセル」とは、協調的（Cooperative）に中断リクエストを検知させ、Fiber自身のコードパス内で正常にクリーンアップを実行して終了させる設計を指す。
実装パターン：例外送出による協調的キャンセル
Fiberへ外部から割り込むためには、`Fiber::throw()`を用いる。これにより、Fiberが現在停止している（Suspendしている）地点に例外をインジェクションし、スタックを巻き戻しながら（Stack Unwinding）安全にデストラクタを走らせることができる。
/
class CancellableTask {
private ?\Fiber $fiber = null;
private $resource = null;
public function start(): void {
$this->fiber = new \Fiber(function (string $connectionString): void {
try {
// 1. リソースのオープン（ファイル、ソケット、DB等）
// ここではシミュレーションとして一時リソースを確保
$this->resource = fopen(‘php://memory’, ‘r+’);
if ($this->resource === false) {
throw new \RuntimeException(“リソースの確保に失敗しました。”);
}
echo “[Fiber] リソース確保完了。処理を開始します。\n”;
// 2. 非同期ループのシミュレーション
for ($i = 1; $i <= 5; $i++) {
echo "[Fiber] ステップ {$i} 実行中...\n";
// 外部からの中断やイベントループの介入を許すためにサスペンド
\Fiber::suspend($i);
}
} catch (\Throwable $e) {
// 3. 例外（キャンセル要求含む）をキャッチした際のクリーンアップ
echo "[Fiber] キャンセルまたは例外を検知: " . $e->getMessage() . “\n”;
throw $e; // 必要に応じて上位へ伝播、あるいはここで完結させる
} finally {
// 4. 確実なリソース解放（Destructorやfinallyブロックの保証）
$this->cleanupResource();
}
});
// Fiberの初回実行
$this->fiber->start(“tcp://example.com:80”);
}
public function resume(): mixed {
if ($this->fiber && !$this->fiber->isTerminated()) {
return $this->fiber->resume();
}
return null;
}
/
- 外部からFiberへ例外を注入し、安全にキャンセルさせる
/
public function cancel(string $reason): void {
if ($this->fiber && $this->fiber->isSuspended()) {
try {
echo “[Host] Fiberへキャンセル例外を注入します: {$reason}\n”;
// Fiberのサスペンド地点に例外をスローさせる
$this->fiber->throw(new \RuntimeException(“Cancelled: ” . $reason));
} catch (\Throwable $e) {
echo “[Host] キャンセル処理中の例外捕捉: ” . $e->getMessage() . “\n”;
}
}
}
private function cleanupResource(): void {
if (is_resource($this->resource)) {
fclose($this->resource);
$this->resource = null;
echo “[Fiber] リソース（ファイルハンドル）を確実にクローズしました。\n”;
}
}
}
// — 実行と検証 —
$task = new CancellableTask();
$task->start();
// 2ステップ実行を進める
$task->resume();
$task->resume();
// 途中で外部からキャンセルを指示
$task->cancel(“タイムアウトまたはユーザー切断”);
/
期待される出力例:
[Fiber] リソース確保完了。処理isCompositeを開始します。
[Fiber] ステップ 1 実行中…
[Fiber] ステップ 2 実行中…
[Host] Fiberへキャンセル例外を注入します: タイムアウトまたはユーザー切断
[Fiber] キャンセルまたは例外を検知: Cancelled: タイムアウトまたはユーザー切断
[Fiber] リソース（ファイルハンドル）を確実にクローズしました。
[Host] キャンセル処理中の例外捕捉: Cancelled: タイムアウトまたはユーザー切断
/
—
3. Zend VMメモリ空間とオブジェクトインジェクション・Gadget Chainの脅威
Fiberを用いた非同期システムにおいて、セキュリティ上の最大の懸念事項は「コンテキスト間での状態汚染」と「不完全な状態でのオブジェクト破棄」である。
PHPのメモリ管理は参照カウント（Refcount）とトレイリング・ガベージコレクション（GC）に依存している。Fiber内で例外やキャンセルによってスタックが強制的にアンワインドされる際、ローカル変数に保持されていた悪意あるオブジェクトのデストラクタ（`__destruct()`）やマジックメソッドが予期せぬタイミングで発火する。
ガジェットチェーンの誘発
非同期イベントループ上で複数のFiberが並行動作している環境において、入力値検証が不十分なデータをFiber間で共有（グローバルステートやクロージャのuse句を通じたキャプチャ）した場合、攻撃者は意図的なタイミングでFiberをキャンセルさせることができる。
これにより、以下の脆弱性が連鎖する。
1. オブジェクトインジェクション: シリアライズされた状態がFiberのクロージャ内に混入。
2. タイミング攻撃とガジェット発火: キャンセルに伴うスタック破棄時にオブジェクトのライフサイクルが強制終了し、脆弱なクラスの`__destruct()`や`__toString()`が想定外のコンテキスト（権限やモジュールが異なる状態）で実行される。
3. リモートコード実行（RCE）: 既存のオブジェクト指向型の脆弱性と結びつき、制御権が奪われる。
防御策:
Fiber内で処理するデータは必ずイミュータブル（不変）な値オブジェクトとして渡し、外部からの参照を完全に遮断すること。クロージャによる暗黙的なスコープ共有（`use ($ref)`）は、マルチスレッド環境におけるデータ競合と同様の未定義動作をPHPのVM上で引き起こすため、極力排除しなければならない。
—
4. 高速化とOPcacheプリローディングの文脈におけるFiber
PHP 8.2以降、OPcacheのプリローディング（Preloading）環境下において、Fiberを使用する際のアーキテクチャ上の注意点が存在する。
プリロードされたスクリプト（`opcache.preload`で指定されたファイル群）内のクラス定義や関数は、シャアードメモリ（SHM）上に永続化され、リクエスト間で共有される。しかし、Fiberのインスタンスやその実行コンテキストそのものをプリロード・永続化することは不可能である。Fiberは実行時のコールスタックやローカル変数を動的に保持するため、リクエストごとのヒープ割り当てが必須となる。
したがって、高速な非同期基盤を構築する場合の設計原則は以下の通りである。
1. タスク定義のクラスはプリロード対象にする: ループやイベントループを処理するコアロジックのクラスはOPcacheに載せ、パースコストをゼロにする。
2. Fiberインスタンスはリクエストスコープで都度生成する: 永続的なプロセス（RoadRunnerやFrankenPHPなど）上でFiberベースの非同期ワーカーを動かす場合、各リクエストまたは各タスクのライフサイクルごとにFiberを生成・破棄し、メモリリークの温床となる「クロージャ内での重いオブジェクトの保持」を厳禁とする。
—
5. 結論：アーキテクトが遵守すべき鉄則
FiberはPHPを「単なるリクエスト・レスポンスのスクリプト言語」から「高度な非同期I/Oランタイムを持つ言語」へと引き上げた。しかし、その恩恵を安全に享受するためには、以下の低レイヤの制約を常に頭に置いておかなければならない。
- Fiberには強制終了の概念はない。常に協調的な例外送出（`Fiber::throw()`）による安全なスタックアンワインディングを設計に組み込むこと。
- リソースの解放は`finally`ブロックに集約する。キャンセルや例外発生時であっても、ファイルハンドルやネットワークソケットが確実にクローズされるコードパスを強制すること。
- コンテキスト間の共有ステートを排除する。意図せぬオブジェクトのデストラクタ発火によるガジェットチェーンの構築を防ぐため、Fiberに渡すデータは完全なカプセル化とイミュータビリティを担保すること。
Zend VMの内部構造とメモリモデルを掌握した者だけが、PHPの限界を突破する真に堅牢で高速な非同期システムを構築できる。