こんにちは。PHPの裏側で何が起きているか、気になったことはありませんか？
普段私たちが何気なく書いているPHPのコードは、伝統的なApache + mod_phpやNginx + PHP-FPMの環境では、「1リクエスト＝プロセス（またはスレッド）の完全な使い捨て」という極めて安全な前提の元で動いていました。リクエストが終われば、Zendエンジンが抱えていたメモリはOSに一括返却され、グローバル変数や静的変数（`static`）の汚染など、メモリリーク以外のリクエスト間汚染は物理的に起こり得なかったのです。
しかし、SwooleやRoadRunnerといった常駐型（Persistent）アプリケーションサーバの登場によって、その前提は大きく覆されました。プロセスが生存し続けたまま、次のリクエスト、その次のリクエストを同じメモリ空間で次々と処理していく。この「Node.jsやGoに近い非同期・常駐モデル」をPHPに持ち込んだとき、私たちはPHPの歴史が隠してきた「グローバル変数と静的変数の魔物」と直面することになります。
今回は、SwooleやRoadRunner環境下において、なぜ変数の汚染が起きるのか、Zendエンジンのメモリ管理の観点からどう防ぎ、どうリクエストを分離すべきなのかを、低レイヤの視点を交えながら一緒に紐解いていきましょう。ここを理解すれば、PHPの裏側がぐっと綺麗に見えてきますよ。
—
1. なぜ常駐型PHPでは変数が汚染されるのか？
まず、PHPの実行モデルの根本を押さえましょう。
PHP-FPMでは、リクエストの開始時にZendエンジンが起動し、スクリプトのパース、コンパイル（オペコード生成）、実行を行い、レスポンスを返した瞬間にプロセスが終了するか、またはメモリコンテキストが綺麗にリセットされます。
しかし、SwooleやRoadRunnerでは、ブートストラップフェーズ（アプリケーションの起動時）に一度だけコードが読み込まれ、メモリ上にオペコードやクラス定義、さらにはグローバル空間が常駐します。
Zendエンジンのメモリ空間とシンボルテーブル
PHPの変数や関数は、内部的には`HashTable`というハッシュ構造（シンボルテーブル）で管理されています。常駐型環境では、この親となるシンボルテーブルや、クラスの静的プロパティ（`public static $foo`）がプロセス生存期間中ずっと同じメモリアドレスを指し続けます。
もし、あるリクエストAの処理中に、認証されたユーザー情報やリクエスト固有のデータをグローバル変数や静的プロパティに保存してしまい、処理の終わりにそれをクリアし忘れたとしたらどうなるでしょうか？
次に飛んできたリクエストBが、リクエストAのユーザー情報をそのまま読み取ってしまう。これが、常駐環境における「クロス・リクエスト・コンテキスト汚染（State Pollution）」の正体です。
—
2. 汚染源の特定：気付かづに踏み抜く3つの罠
実務で非常によくある、リクエスト汚染を引き起こすコードの典型例を見てみましょう。
localCache[$key] = $value; // リクエストを跨いでキャッシュが残る！
}
}
さらに、コード内のどこかで `global $appContainer;` や、ファイルスコープのグローバル変数にリクエスト固有のオブジェクトを代入してしまうと、Zendエンジンのガーベジコレクタ（GC）もそれをルート参照とみなして回収できず、メモリリークと汚染の二重苦を引き起こします。
—
3. 解決策：コンテキストの分離とリクエストライフサイクルの管理
では、この問題をどう防ぐべきでしょうか？
答えはシンプルです。「リクエストごとに独立したコンテキスト（DIコンテナやスコープ）を生み出し、リクエスト終了時に確実に破棄する」ことです。
RoadRunnerやSwooleを使用する場合、フレームワーク（Laravel OctaneやSpiralなど）の多くはこの問題をミドルウェアレベルで抽象化していますが、ピュアなPHPやカスタムフレームワークで構築している場合は、自前でライフサイクルを制御する必要があります。
実装アプローチ：PSR-15ミドルウェアとコンテキストバウンダリ
リクエストの侵入時に新しいコンテキスト（スコープ）を生成し、終了時（`try-finally`の確実な実行）にそれを消し去る設計を取り入れます。
/
class RequestIsolationMiddleware implements MiddlewareInterface
{
public function __construct(
private RequestContextContainer $container
) {}
public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
{
// 1. リクエスト開始：このリクエスト専用の独立した空間を初期化
$this->container->initialize($request);
try {
// 2. アプリケーションの実行
$response = $handler->handle($request);
} finally {
// 3. 【最重要】例外が発生しようとも、必ずリクエスト終了時にコンテキストをパージする
// これにより、次のリクエストへ変数が持ち越されるのを物理的に防ぎます。
$this->container->destroy();
}
return $response;
}
}
このアプローチの肝は、`finally`句の存在です。常駐型環境では、ビジネスロジックの途中で予期せぬ例外（`DomainException`など）がスローされることが多々あります。例外キャッチの有無に関わらず、必ずクリーンアップが走る構造にすることが、エンジニアとしての絶対の防衛ラインになります。
—
4. 型安全なデータ構造とイミュータブル（不変）な設計のすすめ
コンテキストの分離と合わせて行いたいのが、「状態を持たない（ステートレスな）サービス設計」と「イミュータブルなデータ構造の活用」です。
オブジェクトのプロパティを後から書き換えられる（ミュータブルな）設計にしていると、どこかで意図しない書き換えが発生しやすくなります。PHP 8.1以降で導入された `readonly` 修飾子や、PHP 8.2の `readonly class` を積極的に使いましょう。
/
readonly class ImmutableUserContext
{
public function __construct(
public int $userId,
public string $role,
public array $permissions
) {}
}
このようなイミュータブルなオブジェクトを、リクエストスコープを持つDIコンテナ（PSR-11準拠のコンテナなど）にリクエスト単位でバインドします。シングルトンとして登録されているサービスの中に、このスコープ付きオブジェクトを直接インジェクションして保持させない（メソッド引数として都度渡す）ことが、クリーンなアーキテクチャを保つ秘訣です。
—
5. まとめ：常駐型PHPを完全に掌握するために
SwooleやRoadRunnerといった常駐型環境は、PHPのパフォーマンスを極限まで引き出し、ミリ秒単位の応答速度を手に入れるための強力な武器です。しかしそれは同時に、「PHPはリクエストごとに綺麗にメモリを掃除してくれる」という甘い幻想を捨てる必要があることを意味します。
- グローバル変数や静的変数（`static`）は、プロセスを跨いで生存する。
- リクエスト固有のデータは、必ず専用のコンテナに閉じ込め、`try-finally` で確実に破棄する。
- ステートレスな設計と `readonly` によるイミュータブルなデータ構造で、バグの温床を断つ。
この3つを意識するだけで、あなたの書く常駐型PHPアプリケーションは見違えるほど堅牢になり、メモリリークやデータ混入といった悪夢のようなバグとは無縁になります。
PHPの裏側のメモリ構造に思いを馳せながら、美しく洗練されたシステムを一緒に創り上げていきましょう。それでは、また次回のアーキテクチャ談義でお会いしましょう！