PHP 8.x Fiberと並行処理の罠：Zend VMの裏側でうごめく共有リソースの競合と排他制御の極意
PHP 8.1で導入されたFiber（ファイバー）は、多くのPHPエンジニアに「シングルスレッドでありながら協調的マルチタスク（Cooperative Multitasking）を実現する画期的な非同期機構」として迎えられた。I/O待機時間を隠蔽し、アベレージレスポンスタイムを劇的に改善するポテンシャルを秘めたこの機能は、確かにモダンなPHPアプリケーションのアーキテクチャを一変させた。
しかし、ここでエンジニアリングの根底を揺るがす問いを投げかけよう。
「Fiberはスレッドを生まない。では、グローバルステートや静的プロパティ、あるいは外部リソースへのアクセスにおいて、我々は完全に安全だと言えるのだろうか？」
ネット上の浅薄な解説記事では「PHPのFiberは非プリミティブであり、同一プロセス内で順次実行されるため、スレッドセーフティやMutex（排他制御）は不要である」とまことしやかに語られることが多い。だが、Zend VMのメモリ空間、Zend Executorのスタック管理、そしてOPcacheによるプリローディングの物理構造まで踏み込んだ者であれば、それが致命的な誤認であることを知っているはずだ。
本稿では、Fiberのコンテキストスイッチのメカニズムを低レイヤから解き明かし、共有リソースへのアクセス競合が引き起こす破壊的挙動、そしてPHPエコシステムにおいて真に堅牢な排他制御とアトミック操作を実装するための極限の知見を授ける。
—
1. Zend VMのコンテキスト管理とFiberの物理実態
まず、PHP 8のZend EngineがどのようにFiberを扱っているのか、その内部構造（C言語レベルの挙動）を直視しなければならない。
従来のPHPリクエストは、単一のコールスタック（`zend_execute_data`のリンクリスト）の上で線形に処理されてきた。しかしFiberが導入されると、Zend VMは複数のコールスタックを同一プロセス（PHP-FPMのワーカープロセス等）のヒープメモリ上に保持できるようになった。
コンテキストスイッチの正体
Fiberの `Fiber::suspend()` と `Fiber::resume()` がコールされたとき、OSレベルのスレッド切り替え（Context Switch）は発生しない。代わりに何が起きているか？
1. 実行コンテキストの退避: 現在の `zend_execute_data` ポインタ、およびZend VMの実行状態（OPアレイの位置、ローカル変数テーブルなど）が、ヒープ上に確保された `zend_fiber_context` 構造体へ退避される。
2. コンテキストの復元: 移行先のFiberが保持する `zend_fiber_context` からスタックフレームがロードされ、Zend Executorのポインタが書き換わる。
この「同一プロセス・同一スレッド内での仮想的なスタックの切り替え」は、一見すると競合など起きようがないように見える。なぜなら、CPUコアレベルで同時に2つのコードパスが走るわけではないからだ。
しかしここに、「協調的マルチタスク特有の落とし穴」が存在する。
—
2. 非プリミティブ特有の「見せかけの原子性（Atomicity）」と競合状態
スレッドプロセスのプリエンプティブ（強制割り込み）なマルチスレッドとは異なり、Fiberはプログラマが明示的に `suspend` を呼び出さない限り、制御権が勝手に切り替わることはない。
では、なぜ共有リソースの競合が起きるのか？
それは、「非同期I/O待ちや外部イベントのハンドリングを挟むことで、処理の途中で別のFiberが同一のグローバル／静的ステートに介入する余地が生まれるから」である。
以下のコードを見てほしい。一見すると何の問題もないカウンターインクリメント処理だが、Fiber環境下では致命的な論理破綻（Race Condition）を引き起こす。
resume(42);
};
// 実際の非同期イベントループ（Ev, Amp, ReactPHPなど）ではここでサスペンドが起きる
return Fiber::suspend();
}
}
このコードでは、`$current = self::$counter;` を実行した直後にFiberがサスペンドし、別のFiberが同じ `SharedCounter::$counter` を操作した場合、後から書き込んだ方のデータが先の発足を上書きしてしまう（ロストアップデート）。マルチスレッドの世界で言う「Read-Modify-Write」の競合が、シングルスレッド上のFiber空間でも発生するのだ。
—
3. OPcacheプリローディングと共有メモリ空間の罠
さらに問題を複雑化させるのが、PHP 8のOPcacheプリローディング（Preloading）である。
`opcache.preload` によって、アプリケーション起動時にスクリプトはパースされ、不変のOPアレイ（オペコードの配列）としてShared Memory（共有メモリ / SHM）上に配置される。これによりすべてのFPMワーカープロセスが同一のOPコード群を共有し、プロセス間でメモリ効率が劇的に向上する。
しかし、ここで定義された「クラスの静的プロパティ（Static Properties）」の扱いに細心の注意が必要となる。
- プリロードされたクラスの静的プロパティは、FPMプロセスの起動時に初期化される。
- 子プロセス（ワーカー）はこれらをCopy-on-Write（CoW）で共有するため、初期状態では同一のメモリ領域を参照している。
- ワーカープロセス内で値が変更されると、そのプロセス固有のメモリ空間にコピーされるが、「同一プロセス内で稼働する複数のFiber間」においては、その静的プロパティは完全にグローバルな共有変数として機能する。
結果として、異なるHTTPリクエストや、同一リクエスト内で並行稼働する複数のFiberが、静的プロパティやシングルトンインスタンスを経由して状態を汚染し合うという、極めて追跡が困難なバグ（あるいはセキュリティホール）の温床となる。
—
4. 対策：Fiber環境におけるアトミック操作と排他制御の実装
この競合状態を防ぐためには、Fiberベースの非同期処理において明示的なロック機構、あるいはアトミックな操作を担保するアーキテクチャを構築しなければならない。
PHPコアにはJavaの `AtomicInteger` のような言語レベルのプリミティブなアトミッククラスは標準では存在しない（一部拡張機能を除く）。そのため、ユーザーランド、あるいは低レイヤの仕組みを応用して排他制御を実装する必要がある。
以下に、Fiber環境下での競合を防ぐための「セマフォ / ミュージックス・パターン」の実装例を示す。
/
class FiberMutex {
private bool $locked = false;
/ @var Fiber[] 待ち行列（キュー） /
private array $queue = [];
public function acquire(): void {
$currentFiber = Fiber::this();
// 現在のFiberが存在しない（メインコンテキスト）場合はそのままスルー
if ($currentFiber === null) {
return;
}
// 既にロックされている場合はキューに入り、サスペンドする
while ($this->locked) {
$this->queue[] = $currentFiber;
Fiber::suspend();
}
// ロックを取得
$this->locked = true;
}
public function release(): void {
$this->locked = false;
// 待機中のFiberがあれば、FIFOで次の1つを再開（resume）させる
if (!empty($this->queue)) {
/ @var Fiber $nextFiber /
$nextFiber = array_shift($this->queue);
// 非同期イベントループの次のティックで安全に復帰させる
// （ここでは簡略化のため直接resumeをコール）
if (!$nextFiber->isTerminated()) {
$nextFiber->resume();
}
}
}
}
// ── 使用例 ──
class SafeSharedCounter {
private static int $counter = 0;
private static ?FiberMutex $mutex = null;
private static function getMutex(): FiberMutex {
return self::$mutex ??= new FiberMutex();
}
public static function increment(string $fiberName): void {
$mutex = self::$mutex ??= new FiberMutex();
// クリティカルセクションに入る前にロックを取得
$mutex->acquire();
try {
echo “[$fiberName] クリティカルセクション侵入\n”;
$current = self::$counter;
// 模擬的な非同期処理（この間、他のFiberはacquireでブロックされる）
usleep(1000);
self::$counter = $current + 1;
echo “[$fiberName] カウンター更新: ” . self::$counter . “\n”;
} finally {
// 例外が発生しても必ずロックを解放する
$mutex->release();
}
}
}
この実装により、Fiber間で共有される静的変数へのアクセスは直列化され、コンテキストスイッチの狭間で発生するデータ破損を完全に防ぐことができる。
—
5. セキュリティハックの視点：ガジェットチェーンへの応用リスク
アーキテクトとして、この「Fiberのメモリ共有と排他制御の欠如」がセキュリティ上どのような脅威をもたらすかについても言及しておかねばならない。
PHPアプリケーションにおいて、ユーザー入力が `unserialize()` に渡されることで発生するPHPオブジェクトインジェクション（Object Injection）は古典的な脆弱性である。攻撃者は、既存のクラス群のデストラクタやマジックメソッド（`__destruct`, `__toString`, `__wakeup` 等）を連鎖させ、悪意あるコードを実行するGadget Chain（ガジェットチェーン）を構築する。
もし、非同期・Fiberベースで動作するモダンなPHPフレームワーク（AmpやReactPHPをベースにしたもの）の内部で、このインジェクション脆弱性が存在し、かつ共有リソース（セッションデータ、グローバルキャッシュ、ORMのIdentity Mapなど）が適切にロックされていない場合、攻撃者は以下のような高度な攻撃を仕掛けることが可能になる。
1. 状態汚染の並行流し込み: 複数のFiberが並行して走るイベントループ空間において、悪意あるオブジェクトが共有プロセスのグローバルステートやキャッシュストアを不正に書き換える。
2. レースコンディションを利用した権限昇格: 認証チェックとデータ処理の間に生じる非同期の「隙（Gap）」を狙い、セッションのコンテキストを別ユーザーのものへとすり替える。
シングルスレッドだから安全、という神話は、非同期I/OとFiberが交差した瞬間によく音を立てて崩れ去るのだ。
—
6. チーフアーキテクトからの提言
PHP 8.xのFiberは、I/Oバウンドなワークロードにおいてアプリケーションのパフォーマンスを極限まで引き上げる強力な武器である。しかしそれは、Zend VMの実行モデル、メモリ管理、そして「協調的マルチタスクにおける隠れた競合状態」を正しく理解しているエンジニアの手に委ねられて初めて真価を発揮する。
設計において以下の鉄則を遵守せよ：
1. グローバル・静的ステートの排除: Fiber環境下で動作するコードにおいて、クラスの静的プロパティによる状態保持は原則として禁止せよ。状態はすべてスコープ内（インスタンス変数やローカルコンテキスト）に閉じ込めろ。
2. 明示的な排他制御の実装: 非同期処理を挟むクリティカルセクションでは、必ずMutexやセマフォパターンを用いてアトミック性を担保しろ。
3. OPcacheとメモリ共有の意識: プリロードされたコードベースが各プロセス・各Fiberからどのように参照されているかを常に脳内トレースし、CoW（Copy-on-Write）の挙動に起因する予期せぬデータ共有を警戒せよ。
PHPはもはや単なる「リクエストごとに破棄されるスクリプト言語」ではない。その低レイヤの挙動を掌握した者だけが、真に堅牢で爆速な次世代Webアーキテクチャを構築できる。コードの裏側でうごめくZend VMの鼓動を感じ取れ。