こんにちは。普段はPHPのコアエンジンや大規模なWebシステムのアーキテクチャ設計をずっと見つめているエンジニアです。
JavaやGo、Node.jsといった他の高水準言語からPHPの世界に入ってきた優秀な開発者ほど、最初はこの事実にとまどいます。
「PHPって、リクエストごとにすべてが破棄されるクリーンな言語じゃなかったっけ？」と。
SwooleやRoadRunnerといった「常駐型（Persistent）アプリケーションサーバー」の普及により、PHPの実行モデルは劇的な進化を遂げました。毎リクエストごとにZendエンジンが起動・終了を繰り返していた従来のCGI/FPMモデルとは異なり、プロセスがメモリ上で生き続け、次々とリクエストを処理していく。これにより、フレームワークのブートストラップコストが消え去り、驚異的なスループットが手に入ります。
しかし、ここに「PHPの歴史的な前提」と「常駐型プロセスの現実」のギャップが潜んでいます。
今回は、SwooleやRoadRunner環境における「静的プロパティ（`static`）」や「グローバル変数」の生存期間、そしてそれが引き起こす致命的な状態汚染（クロスコンタミネーション）のメカニズムと、それを美しく防ぐためのアーキテクチャ設計について、Zend VMの裏側まで覗きながら一緒に解き明かしていきましょう。
—
1. Zend VMのメモリ空間と「変数の生存期間」の真実
まず、PHPの心臓部であるZend VMが、メモリをどのように管理しているかを知る必要があります。
従来のPHP-FPM環境では、1つのHTTPリクエストが来ると、Zendエンジンが初期化され、スクリプトがパースされてオペコード（Opcode）に変換され、メモリ上に変数空間（Symbol Table）が構築されます。そしてリクエストが終了した瞬間、OSによってプロセスごとのヒープメモリが丸ごと解放されます。つまり、私たちがコード内でうっかりグローバルな状態を残してしまっても、次のリクエストには一切影響が及ばなかったのです。PHPが「安全でバグの入り込みにくい言語」と言われてきた隠れた理由の1つがここにあります。
しかし、SwooleやRoadRunnerのプロセスモデルはどうでしょう？
これらは、一度PHPスクリプトをメモリ（Zend VMのヒープ）上に読み込んだ後、プロセスを生存させ続けます。HTTPリクエストが来ると、メインプロセスからフォークされるか、あるいはコルーチン（Coroutine）上でリクエストハンドラが呼び出されます。
ここで何が起きるか。
クラスの `static` プロパティや、関数・ファイルスコープのグローバル変数は、リクエストを跨いでメモリ上に残り続けます。
[Swoole/RoadRunner Master/Worker Process]
├── OPcache (共有メモリ / 読み取り専用)
└── Zend VM Heap (プロセス固有 / 常駐メモリ)
├── Class::$state ← 【危険】リクエスト A のデータが残る！
└── Global State ← 【危険】リクエスト B に引き継がれる！
この挙動を理解していないと、あるユーザー（Aさん）のリクエストで行った状態変更（例えば、認証情報やカートの保持など）が、次のリクエストを送ってきた全く別のユーザー（Bさん）に見えてしまうという、極めて重大なセキュリティインシデント（状態汚染）を引き起こすことになります。
—
2. なぜ「静的プロパティ」は汚染されるのか？（コードで見る現実）
言葉だけだと抽象的になってしまうので、実際にやってしまいがちな「危険なコード」を見てみましょう。
例えば、シンプルなリクエストカウンターや、現在のユーザーコンテキストを保持するロガーがあるとします。
リクエスト 1（ユーザー: Alice） が到達し、`RequestContext::setCurrentUser(‘Alice’)` が呼ばれます。
2. 何らかの処理が終わってリクエスト 1 が終了します（この時、`self::$currentUser` は ‘Alice’ のままメモリに残っています）。
3. リクエスト 2（ユーザー: Bob） が到達します。Bob は自分の名前をセットしていませんが、コード内で `RequestContext::getCurrentUser()` を呼び出すと……返ってくる値はなんと ‘Alice’ です。
Alice のプライベートなデータが、Bob に露出してしまいました。これが常駐型プロセスにおけるグローバル変数・静チックプロパティ汚染の正体です。
—
3. 汚染を防ぐためのアーキテクチャ設計：DIコンテナのスコープ管理
では、常駐型環境において私たちはどのように状態を管理すべきなのでしょうか？
答えはシンプルです。「グローバルな状態（Static）を排除し、すべての状態をリクエストスコープ（Request Scope）に閉じ込める」ことです。
モダンなフレームワーク（SymfonyのSwoole統合やLaravel Octaneなど）が裏側で何をやっているかというと、DIコンテナ（Dependency Injection Container）をリクエストごとにリフレッシュ、あるいは子コンテナ（Child Container）として生成する仕組みをとっています。
これを自前で設計する場合のアプローチを、概念的なコードで見てみましょう。
対策アプローチ: 状態をオブジェクトにカプセル化し、リクエストごとにインスタンスを生成する
`static` を使うのをやめ、インスタンスプロパティとして状態を持ちます。そして、ミドルウェアやブートストラップ層で、リクエストごとにコンテキストオブジェクトを新しく生成（New）し、依存性注入でサービスに渡します。
currentUser = $user;
}
public function getCurrentUser(): ?string
{
return $this->currentUser;
}
// リクエスト終了時に綺麗さっぱりクリアするメソッド
public function reset(): void
{
$this->currentUser = null;
}
}
そして、SwooleやRoadRunnerのイベントループ / リクエストハンドラのライフサイクルに合わせて、リクエストの開始時に生成し、終了時に必ず `reset()` を呼ぶ（あるいはインスタンス自体をGCの対象にする）仕組みを構築します。
on(“Request”, function (Request $req, Response $res) use ($requestContext) {
// — 【リクエスト開始時のフック】 —
// 前回のゴミが残っていないことを保証するために明示的にリセット
$requestContext->reset();
// ユーザー認証情報のセット（例）
if (isset($req->header[‘x-user’])) {
$requestContext->setCurrentUser($req->header[‘x-user’]);
}
// アプリケーションの実行
$controller = new SomeController($requestContext);
$responseContent = $controller->handle();
$res->end($responseContent);
// — 【リクエスト終了時のフック】 —
// （※Swooleなどのコルーチン環境では、確実にスコープを抜けるためのクリーンアップが必須）
});
—
4. フレームワークの裏側と、私たちが意識すべき鉄則
SwooleやRoadRunner上で動くモダンなPHPフレームワーク（Laravel Octane等）では、このメモリ汚染を防ぐために、以下のような高度な最適化とフックが自動で行われています。
1. フレームワーク自体のシングルトンコンテナの分離:
アプリケーション起動時（Boot時）にロードされるサービスと、リクエストごとにインスタンス化されるサービスが厳密に分離されています。
2. Framework Flush (フラッシュ機構):
リクエスト終了時に、EntityManager（Doctrine等）やログバッファ、セッションハンドラなどが自動的にクリアされ、内部状態が初期化されます。
しかし、私たちが自前で書くカスタムサービスや、サードパーティ製の古いライブラリ（内部で `public static` なキャッシュや状態を持っているもの）は、容赦なくメモリリークや汚染の原因になります。
常駐型PHPを設計・運用する際は、以下の鉄則をチーム全体で共有してください。
- 鉄則1: ドメインロジックやサービス層で `static` プロパティによる状態保持を絶対にしないこと。
（定数や、完全に不変な（Immutable）設定値の保持以外での `static` は禁止、というルールにするのが安全です）
- 鉄則2: サードパーティ製ライブラリを導入する際は「常駐型プロセス対応（Stateful Safe）」かコードを確認すること。
古いライブラリがグローバル変数やシングルトン内でリクエストデータを保持していないか、Zend VMのメモリ空間を汚染しないかを疑う目を持ちましょう。
- 鉄則3: 「リクエスト終了時のクリーンアップ処理」をアーキテクチャの必須要件に組み込むこと。
—
おわりに
いかがでしたでしょうか？
「PHPはリクエストごとにすべてを忘れてくれる」という優しい世界から、「プロセスが生き続け、メモリを共有する」というエキサイティングな世界へ足を踏み入れたとき、Zend VMのメモリモデルと変数の生存期間を理解しているかどうかが、プロダクトの安全性とスケーラビリティを分ける最大の分かれ道になります。
ここをクリアできれば、PHPは他のどの言語にも負けない爆発的なパフォーマンスと、書きやすいビジネスロジックの共存を実現してくれます。
裏側のメカニズムに思いを馳せながら、美しく堅牢なアーキテクチャを築き上げていってくださいね。応援しています。