Swoole/RoadRunner常駐型環境における静的プロパティの生存期間とグローバル変数汚染の防壁
PHPの歴史において、長らく「共有ードナッシング（Shared-Nothing）」アーキテクチャが絶対の真理であった。1リクエストが来ればプロセスが立ち上がり、Zend Engineが初期化され、スクリプトが実行され、応答を返した瞬間にプロセスは死滅する――この強固な原則のおかげで、PHPプログラマはCやJavaのようなメモリリークやマルチスレッド起因の状態汚染の悪夢から守られてきた。
しかし、SwooleやRoadRunnerの登場により、その前提は完全に崩れ去った。
プロセスがメモリ上に常駐し、数万件ものリクエストを単一のZend VMインスタンスが処理し続ける。このパラダイムシフトにおいて、従来の「PHPの常識」でコードを書くことは、時限爆弾を抱えたまま爆走するようなものだ。今回は、常駐型プロセスにおけるメモリの挙動、Zend VMの内部構造、そしてグローバル変数や静的プロパティが引き起こす致命的なバグを防ぐための防壁設計について、低レイヤの視点から徹底的に解説する。
—
1. Zend VMのメモリ空間と「静的プロパティ」の生死
まず、リクエストのライフサイクルがどう変化したのかをZend Engineの内部から理解しよう。
従来のPHP-FPM環境では、リクエスト毎にプロセスがフォーク（または生成）され、終了時にはプロセス空間ごとOSによってメモリが解放される。そのため、スクリプト内でどれだけグローバル変数を汚染しようが、静地プロパティにデータを溜め込もうが、リクエスト終了と共にすべてが無かったことになった。
しかし、SwooleやRoadRunnerなどの常駐型ランタイムでは、一度ブートストラップ（`composer autoload` やフレームワークの初期化）でロードされたクラス定義、関数、そして「staticプロパティ」は、プロセスの生存期間中ずっとメモリ（Zend Engineのヒープ領域）に常駐し続ける。
危険なコード：静 polluting State
以下のコードを見てほしい。一見、何の問題もない一般的なシングルトンパターンやキャッシュ機構に見えるかもしれない。
同じWorkerプロセスに割り振られた際、もしコントローラー側で `UserData` を明示的に上書きし忘れたらどうなるか？
ユーザー200にユーザー100の機密データがレスポンスとして返却される。これが、常駐型環境における「クロスリクエスト・データ汚染（State Pollution）」の正体である。セキュリティ上の重大な脆弱性（情報漏洩）に直結する。
—
2. OPcacheとJITの文脈における「書き換え可能なメモリ」
OPcacheが有効な環境では、スクリプトのバイトコードは共有メモリ（SHM）に配置され、複数のWorkerから読み取り専用（Read-Only）として共有される。これにより高速化が図られている。
しかし、クラスの `static` プロパティやグローバル変数が保持する値は、OPcacheの共有メモリ上ではなく、各Workerプロセスのプライベートヒープ（プロセス固有のRAM）上に展開される。したがって、あるWorkerプロセスで行った静的プロパティの変更は、他のWorkerプロセスには波及しないが、「そのWorkerが次に処理する未来のリクエスト」には確実に引き継がれる。
この「前回のゴミ」が残る現象を防ぐためには、フレームワークのライフサイクルイベント（リクエストの開始時および終了時）を利用し、メモリの状態を強制的に初期化（Destruct / Reset）するアーキテクチャが必要不可欠となる。
—
3. 実践：RoadRunner/Swoole環境に耐える堅牢なステート管理アーキテクチャ
では、どのようにしてこのメモリ汚染を防ぐべきか。
結論から言えば、「リクエストスコープに依存するデータを、グローバルや静的プロパティに保持させてはならない」。どうしても保持する必要がある場合は、リクエストの終端（Terminate）で必ず明示的なクリーンアップを行うか、DIコンテナのスコープ機能を活用するべきである。
以下に、実務のコードレビューでそのまま合格を出せる、堅牢なリクエストスコープ・コンテキスト管理の実装例を示す。
リクエストスコープを完全に分離するContextManagerの実装
/
-class RequestContext
{
/
- @var array
- 各Workerプロセスのヒープ上に存在するが、
- リクエストライフサイクル毎に必ずflushされる設計にする。
/
private static array $storage = [];
/
- データをコンテキストに格納する
/
public static function set(string $key, mixed $value): void
{
self::$storage[$key] = $value;
}
/
- コンテキストからデータを取得する
/
public static function get(string $key, mixed $default = null): mixed
{
return self::$storage[$key] ?? $default;
}
/
- 【極めて重要】リクエスト終了時に必ず呼び出すこと
- これにより、次のリクエストへのデータ持ち越しを物理的に遮断する。
/
public static function destroy(): void
{
// 参照を切断し、Zend VMのガベージコレクション（GC）へ回収を促す
self::$storage = [];
}
}
フレームワークのライフサイクルへのフック（RoadRunnerの例）
RoadRunnerやSwooleのPSR-7ミドルウェア、あるいはフレームワーク（Laminar, Symfony, Laravel等）のミリ秒単位のライフサイクルイベントを捉え、リクエストの入口と出口で防壁を張る。
getHeaderLine(‘X-Request-ID’) ?: bin2hex(random_bytes(16)));
RequestContext::set(‘attributes’, $request->getAttributes());
// 次のミドルウェア / コントローラーへ処理を委譲
$response = $handler->handle($request);
return $response;
} catch (Throwable $e) {
// 例外発生時も確実にステートを破棄する必要がある
throw $e;
} finally {
// === [事後フック] リクエスト終了時の確実な防壁 ===
// 例外発生の有無に関わらず、必ずこのブロックが実行されメモリがクリーンアップされる
RequestContext::destroy();
}
}
}
—
4. コードレビューの視点：これだけはやってはいけないアンチパターン
チームの開発メンバーが書いたコードをレビューする際、以下のシグネチャを見つけたら即座にリジェクト（差し戻し）しなさい。
1. キャッシュやレジストリとしての `static` 変数の多用
- NG: `class Foo { public static $cache = []; }`
- 対策: 永続化が必要なキャッシュはRedisやAPCuを使い、リクエスト内の使い捨てデータであればDIコンテナのRequest Scope（あるいは上記の `RequestContext`）に閉じ込める。
2. シングルトンクラス内でのリクエスト固有値の保持
- NG: シングルトンインスタンスのプロパティに `$currentUser` や `$currentOrder` を保持させる設計。
- 対策: シングルトンは「ステートレス（状態を持たない）」でなければならない。状態を持つべきオブジェクトは、リクエスト毎にインスタンスが生成される「トランジェント（Transient）」ライフサイクルとして設計する。
3. グローバルスコープ（`global` キーワードや関数の外側の変数）の汚染
- NG: インクルードされたファイル内でグローバル空間の変数を書き換える古いタイプのレガシーコード。
—
5. チーフアーキテクトからの総括
SwooleやRoadRunnerを用いた常駐型PHPアプリケーションは、PHP-FPMの数倍から数十倍という圧倒的なスループットと低レイテンシをもたらす。しかしそれは、「PHPはプロセスが勝手にメモリを掃除してくれる」という甘えを完全に捨て去る代償のうえに成り立っている。
Zend VMのメモリ構造を脳内に描き、1つの変数がどこにアロケートされ、いつ解放されるべきかを意識すること。それこそが、モダンなハイパフォーマンスPHP開発において、プロとアマを分かつ最大の境界線である。
次にコードを書くとき、あるいはレビューするときに自問してほしい。
「この静的プロパティは、次のリクエストのユーザーに漏洩しないか？」
そのわずかな慎重さが、大規模システムの障害を防ぐ唯一にして最強の防壁となる。