PHPの底を撃て：epollとZend VMが織りなす非同期I/Oの深淵
PHPは「リクエスト・ライフサイクル」の言語である。HTTPリクエストがSAPI（Server API）を叩き、Zend Engineが起動し、スクリプトを解釈してオペコードを焼き、終了時にすべてのメモリを焼き払う。この潔いまでの「共有しなき並行性（Shared-Nothing Architecture）」こそが、PHPを最もセキュアで予測可能なWeb言語たらしめてきた。
しかし、現代のWebアーキテクチャに求められるのは、数千の同時接続を抱えながら、外部APIやデータベースのレイテンシを完全に隠蔽する「真の非同期処理」だ。
本稿では、PHPがOSのI/O多重化（`epoll` / `kqueue`）とどのように対話し、Zend VMの文脈においてストリームラッパーが非同期イベントループと結びつくのか、その低レイヤの真実を解き明かす。
—
1. ZendストリームとOSカーネルの境界：なぜPHPはブロッキングするのか
PHPの標準関数（`fread`, `fwrite`, `stream_socket_client`など）は、デフォルトではブロッキングモードで動作する。これは、C言語レベルのシステムコール（`read()`や`write()`）が、カーネル空間のソケットバッファにデータが準備されるまでプロセスをスリープさせるためだ。
Zend Engineの内部において、これらすべてのI/O操作は `php_stream` という抽象化レイヤに包まれている。
/ main/streams/streams.h の概念的構造 /
typedef struct _php_stream {
php_stream_ops ops;
void abstract;
int mode;
/ … 内部バッファやフィルターチェイン … /
} php_stream;
`php_stream_ops` には、`read`, `write`, `flush`, `cast` といった関数ポインタのテーブルが定義されている。通常、ファイルディスクリプタ（FD）に対する読み込み要求が発生すると、Zend VMは処理を一旦停止し、OSカーネルからの応答を待つ。
非同期I/Oへの転換：ノンブロッキングモードと `select` / `poll`
PHPで非同期を実現する場合、開発者はしばしば `stream_set_blocking($stream, false)` を実行する。これにより、FDには `O_NONBLOCK` フラグが立ち、カーネルはデータが無くても即座に `EAGAIN` または `EWOULDBLOCK` を返すようになる。
しかし、ポーリングを自前で書くことはCPUの無駄遣い（ビジーウェイト）を意味する。ここで登場するのが、OSのイベント通知機構、すなわち Linuxの `epoll` と macOS/BSDの `kqueue` である。
ReactPHPやAmpといった現代の非同期PHPフレームワークの根底には、C拡張（`libuv` や `ev`）あるいは純粋なPHPによるループ機構が存在し、OSが提供する `epoll_wait()` システムコールに対して「このFDに読み込み可能イベントが発生したら教えてくれ」と登録を行っている。
—
2. Fiber（Zendファイバー）によるコンテキストスイッチの物理構造
PHP 8.1で導入された Fiber は、スタックを持つ協調的マルチタスク（Coroutine）の実行単位である。従来のコールバック地獄からPHPを救い出したこのFiberは、Zend VMの実行コンテキストをどのように書き換えているのか。
Zend VMは、現在実行中の関数フレーム（`zend_execute_data`）やローカル変数の状態をコールスタック（Cのスタックではなく、PHPがヒープ上に割り当てるVMスタック）で管理している。
Fiberの核心は、この 「VMスタックの退避と復元」 にある。
/
use Revolt\EventLoop;
function async_fread($stream): Fiber {
return new Fiber(function () use ($stream) {
$readBuffer = ”;
while (!feof($stream)) {
// イベントループに読み込み待機を登録し、Fiberを一時停止(suspend)する
$data = \Co::suspend($stream);
if ($data === false) {
break;
}
$readBuffer .= $data;
}
return $readBuffer;
});
}
内部での何が起きているか：
1. `Fiber::suspend()` の呼び出し: Zend VMは現在の `zend_execute_data` のポインタとVMスタックの状態を、ヒープ上に確保されたFiberオブジェクトの構造体に退避させる。
2. 制御の返却: コントロールフローは親スコープ（イベントループ）へと戻る。イベントループは `epoll_wait` を継続する。
3. イベント検知と再開: カーネルから「FDにデータが来た」と通知（`EPOLLIN`）を受けると、イベントループは該当するFiberの `resume()` を叩く。
4. VMステートの復元: Zend Engineは退避されていた `zend_execute_data` を復元し、恰もあたかも直前までそこで処理が続いていたかのようにVMの実行を再開する。
この一連の動作により、オペレーティングシステムのスレッドをブロックすることなく、単一のスレッド上で数万の並行リクエスト処理が可能になる。
—
3. OPcacheプリローディングとメモリ空間の不可逆性
非同期・高スループットなPHPアプリケーションを支えるもう一つの主役が OPcache である。
PHP 7.4以降で導入された OPcache Preloading（プリローディング） は、アプリケーションの起動時（`php-fpm` のマスタープロセス起動時）に、指定されたスクリプト群をパースし、Zend VMのオペコード（`zend_op_array`）に変換した上で、共有メモリ（Shared Memory: SHM）へ恒久的に焼き付ける技術だ。
; php.ini での設定例
opcache.enable=1
opcache.enable_cli=1
opcache.preload=/var/www/html/config/preload.php
opcache.preload_user=www-data
物理構造の真実：なぜプリロードは速いのか？
通常のライフサイクルでは、リクエストごとに以下のコストが発生する。
1. ディスクからのファイル読み込み（I/O）
2. 字句解析・構文解析（Lexer / Parser）
3. 抽象構文木（AST）の構築
4. オペコードへのコンパイル（`compile_file`）
OPcacheプリローディングが有効な場合、マスタープロセスがこれらを一度だけ実行し、共有メモリ上に `zend_op_array` のポインタツリーを構築する。その後、子プロセス（FPM worker）がフォーク（`fork()`）されると、Copy-on-Write（CoW） メカニズムにより、子プロセスはマスタープロセスが保持する共有メモリ上のオペコードをそのまま参照できる。
> 警告（アーキテクトの視点）:
> プリロードされたコードやオブジェクトは、マスタープロセスのライフサイクル全体にわたってメモリ上に常駐する。つまり、ここに「状態（State）」や「環境依存の動的データ」を埋め込むと、全ワーカープロセスでその汚染が永続化される。さらに悪いことに、コードを書き換えてもFPMを完全に再起動するまで反映されない。デプロイパイプラインには厳密なFPMリロード手順が必須となる。
—
4. セキュリティ・ハック：非同期環境におけるオブジェクトインジェクションの脅威
非同期I/OやFiberを用いた並行処理、そしてOPcacheによるメモリ共有が進むにつれ、PHPアプリケーションのセキュリティ境界はより複雑化している。その最たるものが PHP Object Injection（オブジェクトインジェクション） だ。
攻撃者が信頼できないデータを `unserialize()` に流し込める脆弱性が存在する場合、Zend VMのガベージコレクションやオブジェクト破棄のタイミングを悪用した Gadget Chain（ガジェットチェーン） が構築される。
低レイヤからの攻撃メカニズム
PHPのオブジェクトは、内部的には `zend_object` 構造体としてヒープ上に表現されている。
struct _zend_object {
zend_refcounted_h gc;
uint32_t handle;
zend_class_entry ce;
const zend_object_handlers handlers;
HashTable properties;
zval properties_table[1];
};
`unserialize()` が実行されるとき、Zend Engineはシリアライズされたストリームからクラス名（`ce`）を復元し、該当クラスが存在すればインスタンスを生成、プロパティを復元する。この過程で、特定のマジックメソッド（`__destruct()`, `__wakeup()` など）が自動的に呼び出される。
非同期・イベント駆動型のアプリケーションにおいて、この脅威はさらに深刻化する。
- 共有メモリ上の汚染: OPcacheプリロードやSwoole/RoadRunnerのような常駐型（Long-running）プロセスでは、一度インジェクションによってグローバルな状態や静的プロパティが書き換わると、その影響は単一のリクエストに留まらず、次以降のすべてのリクエスト（他ユーザーのセッションを含む）に伝播する。
- Race Condition（競合状態）: 非同期I/Oの文脈では、複数の一覧タスクが同一のメモリ空間（グローバルキャッシュや接続プール）へ同時にアクセスするため、シリアライゼーションの不備がそのまま「タイム・オブ・チェック・フォー・タイム・オブ・マユ（TOCTOU）」やメモリ破壊のトリガーとなり得る。
防御の極意：型安全とシリアライゼーションの廃止
1. `unserialize()` の完全排除: 外部からの入力に対して `unserialize()` を使うことは、現代のWebアーキテクチャにおいては自殺行為に等しい。構造化データのやり取りには、必ず厳密なスキーマ検証を持つ `json_decode()`（`assoc: true`）を使用する。
2. マジックメソッドの監査: コードベース内に `__wakeup()` や `__destruct()` を持つクラスが存在する場合、それらがプロパティの整合性をどのように検証しているか、低レイヤのライフサイクルを意識して静的解析（PsalmやPHPStanのstrictレベル）で徹底的に追い込むこと。
—
結び：PHPエンジンの限界を突破するために
PHPはもはや、単なる「HTMLを生成するテンプレートエンジン」ではない。
Zend VMの内部挙動を理解し、OPcacheのメモリ管理の物理構造を把握し、Fiberとepollによる非同期I/Oのメカニズムを掌握したとき、PHPはNode.jsやGoをも凌駕する圧倒的なスループットと開発効率を両立する究極のバックエンド言語へと変貌する。
コードの表面的な美しさにとらわれるな。常にオペコード、メモリ空間、そしてカーネルとの対話を意識せよ。それこそが、真のPHPアーキテクトに求められる唯一の資格である。