序章：Zend VMの「常駐」というパラダイス・ロスト
PHPは歴史的に「1リクエスト = 1プロセス（またはスレッド）の完全なエフェメラル（使い捨て）」という前提のもとに設計されてきた。Nginx + PHP-FPMのアーキテクチャでは、リクエストが到達した瞬間にZend Engineが初期化され、グローバル空間（`$_GET`, `$_POST`, `$_SERVER` およびユーザー定義のグローバル変数）がゼロから構築される。そしてスクリプトの実行が終われば、プロセスごとOSにメモリが解放されるか、少なくともZend VMのシンボルテーブル（HashTable）はきれいにパージされる。
しかし、SwooleやRoadRunnerといった非同期・常駐型PHPランタイムの登場によって、この「安全神話」は崩壊した。
これらの環境では、PHPプロセスは一度起動するとメモリ上に常駐し続け、数万、数百万ものリクエストを単一のプロセスで処理し続ける。これはI/O待機時間を極限まで削ぎ落とし、従来のFPMでは到達不可能なスループット叩き出す一方で、Zend VMの内部構造を理解していない開発者にとっては「地獄のメモリリークとリクエスト間汚染（Cross-Request Pollution）」の温床となる。
今日のコードレビューで、もしあなたが「とりあえずstatic変数にキャッシュしておけば高速化するだろう」「グローバルなDIコンテナにリクエスト固有のデータを突っ込んでおこう」といったコードを書いているなら、今すぐその手を止めてほしい。内部で何が起きているのか、Zend VMのメモリ空間の動きから紐解いていこう。
—
1. 内部構造の理解：なぜ `$_GET` や static変数は「消えない」のか
Zend VMのシンボルテーブルとメモリの寿命
PHPの変数や関数、クラスは、内部では `Bucket` 構造体として `HashTable` に格納されている。通常のPHP-FPM環境では、リクエストの終了（`request_shutdown`）に伴い、EG（Executor Globals）やCG（Compiler Globals）に関連するシンボルテーブルが破棄され、アロケータ（Zend Memory Manager）によってメモリプールがリセットされる。
しかし、SwooleやRoadRunnerのワーーカープロセス上では、メインのスクリプト（Worker）が一度ロードされた後、各リクエストはループやイベントリスナーのコールバックとして実行される。
ここで以下のコードを見てほしい。
class BadAuthenticator {
private static ?User $currentUser = null;
public static function authenticate(Request $request): void {
// 前のリクエストのユーザーオブジェクトが残っている可能性がある！
self::$currentUser = TokenParser::parse($request->getHeader(‘Authorization’));
}
public static function getUser(): ?User {
return self::$currentUser;
}
}
このコードがFPM環境であれば何の問題もない。しかし、Swoole環境でリクエストA（User: Alice）の処理が終わった後、メモリ上に `self::$currentUser`（Aliceのインスタンス）が保持されたまま、リクエストB（User: Bob。認証ヘッダーを送り忘れた）が同じプロセスにアサインされたとする。
なんと、リクエストBはAliceの権限でシステムにアクセスできてしまう。これが「リクエスト間汚染」の正体である。Zend VMの視点から見れば、`static` 変数はプロセスライフサイクルにバインドされているため、リクエスト境界を越えて生存し続けるのだ。
—
2. アーキテクチャパターン：リクエストスコープの分離と「Context」の設計
常駐環境で安全なアプリケーションを構築するための原則はただ一つ。
> 「グローバル領域およびクラスの静的プロパティ（static）に、リクエスト依存のデータを保持してはならない」
これを強制するために、リクエストのライフサイクルと完全に同期する `Context`（コンテキスト）オブジェクト を設計し、コルーチン（Swoole）またはリクエストコンテキスト（RoadRunner）のスコープに閉じ込める必要がある。
SwooleにはコルーチンID（`Coroutine::getCid()`）が存在し、RoadRunnerには PSR-7 互換のリクエストオブジェクトがある。これらを利用して、現在の実行コンテキストに安全にデータをバインドする仕組みを作らなければならない。
—
3. 実装：Swoole/RoadRunnerに耐えうる「Contextマネージャ」の美しきリファレンス
ここでは、スレッドセーフならぬ「コルーチンセーフ」なコンテキスト管理を実現するプロダクションクオリティのコードを提示する。Swooleの `Co\Context` またはそれに類するストレージ機構を抽象化したものだ。
declare(strict_types=1);
namespace App\Core\Context;
use Swoole\Coroutine;
use RuntimeException;
/
- クラス名: RequestContextManager
- 役割: Swoole/RoadRunner環境におけるリクエストスコープの汚染を防ぐためのコンテキストホルダー。
- Zend VMのプロセス空間内において、コルーチンIDをキーに安全にリクエスト固有のデータを隔離する。
/
final class RequestContextManager
{
/
- リクエストスコープのデータを保持するストレージ
- Swoole環境ではコルーチン単位のストレージを利用し、
- 同期環境（RoadRunner等）ではリクエスト毎にインスタンスを生成してDIで回す。
/
private static array $globalFallbackStorage = [];
/
- コンテキストに値を設定する
/
public static function set(string $key, mixed $value): void
{
if (self::isSwooleCoroutineEnvironment()) {
$cid = Coroutine::getuid();
if ($cid < 0) {
// コルーチン外（メインスレッド）での実行
self::$globalFallbackStorage[$key] = $value;
return;
}
$context = Coroutine::getContext($cid);
if ($context === null) {
throw new RuntimeException("Swoole coroutine context is not available for CID: {$cid}");
}
$context[$key] = $value;
return;
}
// Swoole以外（RoadRunner等のPSR-15ミドルウェアベース）の場合は
// リクエスト毎にスコープオブジェクトをスレッドセーフにバインドする設計をとる
self::$globalFallbackStorage[$key] = $value;
}
/
- コンテキストから値を取得する
/
public static function get(string $key, mixed $default = null): mixed
{
if (self::isSwooleCoroutineEnvironment()) {
$cid = Coroutine::getuid();
if ($cid < 0) {
return self::$globalFallbackStorage[$key] ?? $default;
}
$context = Coroutine::getContext($cid);
if ($context === null || !isset($context[$key])) {
return $default;
}
return $context[$key];
}
return self::$globalFallbackStorage[$key] ?? $default;
}
/
- リクエスト終了時に必ず呼び出し、メモリリークとデータ残留を防ぐ
- ※ Zend VMのガベージコレクションを補助する極めて重要なクリーンアップ処理
/
public static function clear(): void
{
if (self::isSwooleCoroutineEnvironment()) {
$cid = Coroutine::getuid();
if ($cid >= 0) {
$context = Coroutine::getContext($cid);
if ($context !== null) {
// ArrayObjectであるSwoole\Coroutine\Contextの中身をクリア
// これを行わないと、巨大なオブジェクトグラフがコルーチン消滅までメモリに残り続ける
$context->exchangeArray([]);
}
}
}
self::$globalFallbackStorage = [];
}
/
- 実行環境がSwooleコルーチン上かどうかを判定
/
private static function isSwooleCoroutineEnvironment(): bool
{
return extension_loaded(‘swoole’) && Coroutine::getuid() !== -1;
}
}
この設計が優れている理由（コードレビューの視点から）
1. コルーチン境界の隔離: Swooleは非同期I/Oを行う際、複数のリクエストが同一プロセス内で並行（または並列）して走る。`Coroutine::getContext($cid)` を用いることで、リクエストAのメモリ領域とリクエストBのメモリ領域が混ざることを物理的に防いでいる。
2. 明示的な `clear()` の義務化: リクエストのライフサイクルの終端（HTTPレスポンス送出直後）で必ず `RequestContextManager::clear()` を叩くこと。これをサボると、Zend VMのメモリ空間（Heap）上で参照が切れずに残り続け、典型的なメモリリーク（Memory Leak）を引き起こす。
3. 静的変数（static）の排除: アプリケーションロジック層では、`$_GET` や `$_POST` に直接触れるのを禁止し、必ず上記のようなマネージャー経由、あるいはDIコンテナをリクエストスコープでインスタンス化してアクセスする設計を強制する。
—
結び：常駐PHPのコードを書くということの覚悟
PHPは「簡単にかける言語」としてスタートしたが、SwooleやRoadRunnerを用いたモダンな常駐アプリケーションの開発は、もはやC言語やJava、Go言語に近い「メモリ管理とスコープに対する厳密な規律」が求められる。
「動けばいい」という甘い認識で書かれたコードは、高負荷時に突如として別人のデータが混ざる致命的なセキュリティホール（データ漏洩）や、数時間でサーバーのメモリを食いつぶすクラッシュを引き起こす。
Zend VMの挙動を脳内に描け。アロケータの息づかいを感じろ。
リクエストの境界線を守り抜くアーキテクチャこそが、あなたの組むシステムを真の「エンタープライズ・グレード」へと昇華させる唯一の道である。