SwooleとRoadRunnerが暴くZend VMの呪縛：`static`変数の永続化とGCの限界領域
PHPの歴史において、長らく「1リクエスト＝1プロセス（またはスレッド）の完全な使い捨て」というパラダイムが支配的であった。Apache + mod_phpの時代からNginx + PHP-FPMに至るまで、PHPスクリプトはリクエストの終端とともにすべてのメモリ空間をOSに返却してきた。Zend Engineは、リクエスト開始時にメモリを割り当て、終了時にすべてを破壊する。この「安全な無知（Ignorance is safety）」こそが、PHPを最もバグに強いスクリプト言語たらしめてきた本質である。
しかし、SwooleやRoadRunnerといった常駐型（Persistent）アプリケーションサーバの台頭により、この前提は音を立てて崩れ去った。Zend VMは今や、数千のリクエストにまたがって同一のプロセス空間で稼働し続ける。
この環境下において、`static`変数は単なる「スコープを限定した永続ストレージ」という枠を超え、プロセス全体の寿命を持つグローバルな毒へと変貌する。本稿では、Zend VMの内部構造、参照カウントとガベージコレクション（GC）の仕様、そして常駐プロセスにおけるメモリリークのメカニズムを、極限の低レイヤ視点から解き明かす。
—
1. Zend VMにおける `static` 変数の物理的実態
PHPのソースコード上において、関数やメソッド内部で宣言される `static` 変数は、一見するとそのスコープに閉じ込められているように見える。しかし、Zend VMの内部データ構造を覗けば、その認識がいかに表層的なものであるかが分かる。
Zend VMがコンパイル（AST生成からOpcode生成）を行う際、関数内の `static` 変数は、関数ごとのエントリ（`zend_function`構造体）に紐づくコンパイル時変数テーブル（Static Variable Table）の静的領域にスロットとして割り当てられる。
PHP-FPM環境では、リクエストが終了するとプロセスが破棄されるか、またはZendリクエストシャットダウン（`RSHUTDOWN`）フェーズにおいて、リクエストプールに割り当てられたすべてのメモリが解放される。そのため、`static` 変数は次のリクエストの際には初期状態（あるいは再評価された状態）に戻る。
しかし、SwooleやRoadRunnerのような常駐型ランタイムでは、リクエストの境界線は「単なるPHPの関数呼び出しのネスト」に過ぎず、OSプロセスレベルの `RSHUTDOWN` は発生しない。
意図しないデータ共有の構造
次のコードを見てほしい。これは常駐環境において極めて危険なアンチパターンである。
execute($orderData);
}
}
このコードがSwooleのWorkerプロセス上で動作した場合、`self::$localCache` はプロセスが生存し続ける限りメモリ上に残り続ける。もしリクエストごとに異なる数千人のユーザーがアクセスすれば、この配列は無限に肥大化する。
さらに深刻なのは、テナント分離の崩壊（Cross-contamination）だ。認証ミドルウェアを通る前の初期化漏れや、非同期コンテキスト（Swoole Coroutineなど）の切り替えミスにより、前のリクエストで使われた `UserContext` が、全く別のユーザーのリクエストから参照可能になるという致命的なセキュリティホール（情報漏洩）に直結する。
—
2. 参照カウントとガベージコレクション（GC）の限界
「メモリが増え続けるなら、GCが回収してくれるのではないか？」という疑問を持つかもしれない。しかし、Zend Engineのガベージコレクション機構の仕組みを理解していれば、それが幻想であることが分かる。
Zend VMのメモリ管理の根底にあるのは参照カウント方式（Reference Counting）である。各変数やオブジェクトは `zval` 構造体として表現され、その中の `refcount` が0になった瞬間にメモリから即座に解放される。
しかし、オブジェクト同士が相互参照（Circular Reference）を持つ場合、参照カウントが0にならない孤立した循環グラフが形成される。PHPのGC（リサイクルバッファを用いたマーク＆スイープアルゴリズム）は、この循環参照を検知して回収するために存在する。
なぜ `static` 変数とGCは相性が悪いのか？
1. ルートバッファへの登録と生存期間
`static` 変数やグローバル変数に格納されたオブジェクトは、Zend VMのルートセット（Root Set）の常に最上位、あるいはそれに準ずる永続的なエントリとして扱われ続ける。
2. 「リーク」ではなく「意図的な保持」と判定される
GCから見れば、`static` 変数からたどれるオブジェクトは「現在もルートから参照されている（＝生きている）」と判定される。たとえそれがビジネスロジック上は「前回の古いリクエストの残骸」であったとしても、Zend Engineにとっては有効なデータであるため、GCの回収対象から外れる。
結果として、GCは一切機能せず、メモリは確実に枯渇していく。これが、常駐型PHPアプリケーションにおけるメモリリークの正体である。
—
3. Fiberとコンテキストスイッチの罠
現代のSwooleやAmp/ReactPHPベースの非同期アプリケーションでは、軽量スレッドである Fiber が多用される。Fiberは単一のOSスレッド上で複数の処理を協調的に切り替える（コンテキストスイッチ）ため、グローバルな状態や `static` 変数の扱いはさらに複雑化する。
start();
return $fiber;
}
// 同一プロセス内で複数のFiberを並行稼働させる
$f1 = handleRequest(“REQ-001”);
$f2 = handleRequest(“REQ-002”);
// コンテキストスイッチ発生
$f1->resume();
$f2->resume();
上記の疑似コードを実行すると、`REQ-002` の実行時に `RequestContext::get()` が `REQ-001` の値を上書きしてしまっているケース、あるいはレジューム後に意図しない変数の状態が混ざり合う現象が発生する。
Fiberはコールスタックを分離するが、静的変数（`static`）やグローバル変数はプロセス（あるいはスレッド）のヒープ領域に単一の実体として存在するため、すべてのFiber間で完全に共有される。非同期並行処理において `static` 変数を使用することは、マルチスレッドプログラミングにおける「同期処理を忘れたグローバル変数」と同じ致命傷をもたらす。
—
4. 極限の対策：常駐環境におけるメモリ安全性の確保
SwooleやRoadRunnerのパフォーマンスを最大化しつつ、メモリリークとデータ汚染を防ぐためには、Zend VMのライフサイクルに逆らわず、かつ厳密なスコープ管理を行うアーキテクチャが必要となる。
対策1: リクエスト終了時のクリーンアップフックの徹底
フレームワーク（Laravel OctaneやSwoole製フレームワークなど）が提供する `onWorkerStart` やリクエストごとのブートストラップフックを利用し、すべての `static` キャッシュやシングルトンコンテナを明示的にリセットする仕組みを構築する。
reset();
}
// 配列自体もクリアし、参照を切断する
self::$services = [];
}
}
各リクエストの終端（Swooleであれば `on$\\Swoole\\Http\\Server::request` コールバックの最後）で必ず `ApplicationContainer::terminateRequest()` を呼び出し、オブジェクトの参照を切断（`refcount` を強制的にゼロへ誘導）させる。
対策2: FiberLocalによるコンテキストの隔離
PHP 8.1以降で導入された Fiber を使用する場合、グローバルな `static` 変数の代わりに `Fiber::LocalStorage`（またはそれに類するオブジェクトグラフ管理）を利用し、Fiberのライフサイクルに完全に同期したスコープ変数を使用すべきである。
—
結びにかえて：Zend VMの支配者たれ
PHPは「手軽に動く言語」から「高スループットを極める非同期ランタイム」へとその姿を劇的に変えた。しかし、どれほどアーキテクチャがモダンになろうとも、Zend Engineがメモリをどのように割り当て、参照をどのように管理し、Opcodeがどのように実行されているかという低レイヤの物理法則が変わるわけではない。
`static` 変数の永続化という「仕様」を正しく把握し、参照カウントの裏側にあるメモリの流動を脳内で完全にトレースできる者だけが、常駐型PHPの荒海において一寸の狂いもない堅牢なシステムを構築できる。
言語に使われるな。Zend VMを掌中に収めよ。