序章：常駐型PHPがもたらす「利便性と破壊」のトレードオフ
PHPという言語は、その歴史的背景から「1リクエスト＝1プロセス（またはスレッド）の完全な消滅」という前提に基づいて設計されてきた。Nginx + PHP-FPMのアーキテクチャでは、リクエストが終息した瞬間にZend Engineが保持していたすべてのヒープメモリ（HashTable、zval、オブジェクトインスタンス）はOSへと返還され、メモリリークの概念すら稀薄であった。
しかし、SwooleやRoadRunnerに代表される常駐型ランタイム（Long-running Application）の普及により、このパラダイムは劇的な変貌を遂げた。
1つのマスタープロセス（またはワーカープロセス）が数万、数百万のリクエストをメモリ上に保持し続ける。この環境下において、従来型の「グローバル変数」「static変数」「シングルトンパターンの安易な乱用」は、システム全体を致命的な崩壊へと導く時限爆弾に変貌する。
本稿では、Zend VMのメモリ管理モデルの深層に潜り込み、常駐環境下における状態汚染（State Pollution）のメカニズムと、それを完全に断ち切るためのカスタムメモリマネージャーによるリクエスト分離戦略を解説する。
—
1. Zend VMのメモリ管理と「常駐環境」の致命的なバグ
zvalとメモリコンテキストの永続化
PHP 7および8におけるZend Engineは、すべての変数を`zval`（Zend Value）と呼ばれる16バイトの構造体で管理している。変数がスコープを抜けると参照カウント（`refcount`）がデクリメントされ、0になった瞬間にメモリプール（Zend Memory Manager: Zend MM）へ返却される。
しかし、以下のスコープに存在するデータは、リクエスト終了後もワーカープロセスのメモリ空間に残留する。
1. `static` 変数：関数やメソッドのローカルスコープを超えて永続化される。
2. クラスの `static` プロパティ：一度ロードされたクラス定義と静的プロパティは、プロセスのライフサイクル全体で共有される。
3. `$_GLOBALS` またはグローバルスコープの変数：スクリプトのトップレベルで定義された変数は、リクエストハンドラーの外側（ブートストラップ層）でアロケートされた場合、次のリクエストへ持ち越される。
リクエスト汚染（Cross-Request State Pollution）の恐怖
もし、あるユーザー（User A）のリクエスト処理中に、認証情報やショッピングカートのインスタンスが何らかの理由で静的プロパティやシングルトンに格納されたとする。
Swooleのワーカーが次のリクエスト（User B）を処理する際、その静的プロパティがクリアされていなければ、User BはUser Aのメモリ空間（コンテキスト）にアクセスできてしまう。
これは単なるバグではなく、セッションハイジャックや情報漏洩を引き起こす深刻なセキュリティインシデントである。
—
2. 対策の核心：リクエスト境界の強制分離とライフサイクル管理
常駐環境で安全なアプリケーションを構築するための原則はただ一つ。
「ブートストラップ時にロードされる不変のサービス（DIコンテナの定義など）」と、「リクエストごとに生成・消滅すべき可変の状態（State）」を完全に分離すること。
これを実現するため、フレームワーク層（あるいは独自実装のミニマムなカーネル層）で、リクエストの「入口」と「出口」に厳密なクリーンアップフックを設ける必要がある。
—
3. 実装例：常駐環境に対応するカスタムメモリマネージャーとリクエストスコープコンテナ
以下のコードは、Swooleなどのイベントループ環境を想定し、リクエストごとにメモリ空間（スコープ）を仮想的に分離、管理するカスタムマネージャーの実装である。
/
final class RequestContextManager
{
private static ?self $instance = null;
/ @var array
private array $requestStorage = [];
/ @var array
private array $destructors = [];
private function __construct() {}
public static function getInstance(): self
{
if (self::$instance === null) {
self::$instance = new self();
}
return self::$instance;
}
/
- 新しいリクエストのスコープを開始する。
- ワーカーのイベントループからリクエスト受信時に必ずコールすること。
/
public function beginRequest(): void
{
// 前回の残骸が万が一存在する場合は強制フラッシュ
$this->terminateRequest();
$this->requestStorage = [];
$this->destructors = [];
}
/
- リクエストスコープ内に変数をバインドする。
/
public function set(string $key, mixed $value): void
{
$this->requestStorage[$key] = $value;
}
/
- リクエストスコープ内の変数を取り出す。
/
public function get(string $key): mixed
{
return $this->requestStorage[$key] ?? null;
}
/
- リクエスト終了時に実行されるクリーンアップ関数（デストラクター）を登録する。
/
public function registerDestructor(Closure $destructor): void
{
$this->destructors[] = $destructor;
}
/
- リクエスト終息時にコールされ、保持しているすべての参照を断ち切り、
- Zend MMの回収効率を最大化する。
/
urator: public function terminateRequest(): void
{
// 登録されたデストラクターを逆順（LIFO）で実行
while (!empty($this->destructors)) {
$destructor = array_pop($this->destructors);
try {
$destructor();
} catch (Throwable $e) {
// ログ出力などの例外処理（常駐プロセスをクラッシュさせないため）
error_log(“Destructor execution failed: ” . $e->getMessage());
}
}
// ストレージの参照を完全に切断
// zvalの refcount をデクリメントさせ、GCの負荷を軽減する
foreach (array_keys($this->requestStorage) as $key) {
unset($this->requestStorage[$key]);
}
$this->requestStorage = [];
// 循環参照ガベージコレクタの強制実行（必要に応じてコスト調整）
// gc_collect_cycles();
}
}
クリーンアップを強制するステートフルサービスの設計
次に、上記マネージャーと連携し、リクエストごとに状態をリセットするサービスクラスの実装例を示す。ここでは、あえて「シングルトンとして振る舞いながらも内部状態を持つ危険なサービス」を安全にラップするパターンを示す。
/
final class StatefulUserService
{
private ?array $userData = null;
public function __construct(private RequestContextManager $memoryManager)
{
// 自身のインスタンスが生成された際、自動的にリクエスト終了時のクリーンアップを登録
$this->memoryManager->registerDestructor(function () {
$this->reset();
});
}
public function setUserData(array $userData): void
{
$this->userData = $userData;
}
public function getUserData(): ?array
{
return $this->userData;
}
/
- 状態を完全に初期化（消去）する
/
public function reset(): void
{
$this->userData = null;
// 内部のキャッシュや一時オブジェクトへの参照もここで確実にnull化する
}
}
—
4. Swoole / RoadRunner 統合時のアーキテクチャパターン
実際のSwoole HTTPサーバー駆動スクリプト（`server.php`）における、リクエストライフサイクルのハンドリングモデルは以下のようになる。
on(‘Request’, function (Request $request, Response $response) {
// 1. シングルトンまたはDIコンテナからマネージャーを取得
$memoryManager = RequestContextManager::getInstance();
try {
// 2. リクエストスコープの初期化（前回のゴミの完全排除）
$memoryManager->beginRequest();
// — ここからアプリケーションの処理 —
// グローバルなミドルウェアやコントローラーの実行
// StatefulUserService 等がインスタンス化され、データがバインドされる
$response->header(‘Content-Type’, ‘text/html; charset=utf-8’);
$response->end(“Hello from Swoole Long-running Worker!”);
} catch (Throwable $e) {
$response->status(500);
$response->end(“Internal Server Error: ” . $e->getMessage());
} finally {
// 3. 【最重要】例外が発生しようとも、リクエスト終端で必ずメモリクリーンアップを実行
$memoryManager->terminateRequest();
}
});
$server->start();
—
5. チーフアーキテクトからの警鐘：見落とされがちな「静的キャッシュ」の罠
多くのPHPプログラマーが犯す最大の過ちは、「パフォーマンス最適化のための静的キャッシュ（Static Cache / Memoization）」の乱用である。
// 【アンチパターン】常駐環境でこれやると確実にメモリリークを起こす
class ConfigLoader {
private static array $cache = [];
public static function get(string $key): mixed {
if (!isset(self::$cache[$key])) {
// DBやファイルからロードして永続キャッシュ
self::$cache[$key] = self::loadFromDatabase($key);
}
return self::$cache[$key];
}
}
もし `ConfigLoader::get()` の内部で、リクエストごとに変化するデータ（テナント情報や動的な設定）をキャッシュしてしまった場合、ワーカープロセスのメモリは肥大化し続け、最終的に `Allowed memory size exhausted` を引き起こすか、別テナントへのデータ漏洩を引き起こす。
解決策：
1. 完全なイミュータブルデータのみを静的キャッシュの対象とする（例：アプリケーションの起動時に読み込まれる不変の設定ファイル）。
2. 動的なデータは、前述の `RequestContextManager` が管理するリクエストスコープ内（あるいはDIコンテナの `Request` スコープ）に閉ざし、リクエスト終了とともに破棄させる。
—
結びにかえて
常駐型PHP環境は、従来のFPM環境に比べて圧倒的なスループットと低レイテンシをもたらす。しかし、それは「PHPにC言語やJavaのような厳密なメモリ管理の思想を持ち込むこと」を強制されることに他ならない。
Zend Engineの内部構造を理解し、`zval`の寿命とプロセスのライフサイクルを一致させる設計思想——これこそが、エンタープライズ領域でSwooleやRoadRunnerを極限まで使い倒すための唯一にして最大の武器となる。コードレビューの場において、「このstatic変数、次のリクエストに残らないか？」と瞬時に見抜けるエンジニアであれ。