こんにちは。普段はNode.jsやGo、あるいはJavaといった「プロセス常駐型」のモダンな言語を触っていて、モダンなフレームワークの設計思想も熟知している――そんな優秀なあなたなら、PHPの世界に足を踏み入れたとき、最初にこう驚いたはずです。
「あれ、PHPってリクエストごとにプロセスが死んで、メモリもきれいにリセットされるはずじゃなかったっけ？」と。
伝統的なApache + mod_phpや、古き良きPHP-FPMの古典的なモデルであれば、その認識で100%正解でした。FPMは、1つのリクエストが終わるとプロセスそのものがOSに資源を返却するか、あるいはプロセスがリフレッシュされるため、グローバルな汚染やメモリリークの多くは「プロセス寿命の短さ」という力技によって自然治癒していたのです。
しかし、SwooleやRoadRunner、あるいはReactPHPといった非同期・常駐型PHPランタイム（Application Server）全盛の現代において、その前提は音を立てて崩れ去りました。Node.jsのメモリモデルと同じように、PHPのプロセスは一度起動したら何千、何万というリクエストをメモリ上に居座りながら処理し続けます。
今回は、この常駐環境における`static`変数の永続化と、PHPのガベージコレクション（GC）が引き起こすメモリリークの罠について、Zendエンジンの内部構造まで少し潜り込みながら、一緒に紐解いていきましょう。ここを理解すると、PHPの裏側が驚くほどクリアに見えるようになりますよ。
—
1. Zendエンジンから見た「static変数」とメモリの居場所
まずは、PHPがメモリをどう扱っているか、その低レイヤの挙動を少しだけ覗いてみましょう。
私たちが書くPHPのコードは、Zend VMによって「オペコード（Opcode）」という中間言語にコンパイルされ、実行されます。このとき、関数やメソッドの内部で宣言される `static $cache = null;` のような静的変数は、リクエストのたびに初期化されるわけではありません。
Zendエンジンのメモリ空間において、`static`変数は関数そのもののコンパイル済み構造体（`zend_function`）に紐づく永続的な領域に確保されます。
従来のPHP-FPMであれば、リクエスト終了時にプロセスごとメモリ空間が破棄されるため、この永続性は「高速化（キャッシュの保持）」という恩恵だけをもたらしていました。
しかし、SwooleやRoadRunnerの世界では話が違います。プロセスが生き続け、ワーカーがプールされ続けるため、「あるリクエストで書き換えられた `static` 変数の値が、次の全く関係ないリクエストの文脈に持ち越される」という現象が起きます。これが、常駐環境における最大の見落としポイントです。
意図しないデータ共有のイメージ
例えば、次のようなユーザー認証のコンテキストをキャッシュするコードがあったとしましょう。
BさんはAさんのプロフィールデータ（あるいはその残骸）を `getUser()` 経由で取得してしまうという、セキュリティ上の重大なリスク（データリーク）に直結します。
常駐環境における `static` は、「便利で高速なキャッシュ置き場」ではなく、「全リクエスト間で共有されるグローバルな危険地帯」として扱う必要があります。
—
2. 参照カウントと「解放されないメモリ」のメカニズム
「じゃあ、リクエストの終わりに `static` 変数を `null` で上書きすればいいよね？」
そう思ったあなた、非常に鋭い着眼点です。しかし、PHPのメモリ管理の仕組み（ガベージコレクション機構）の裏側を知ると、それだけでは不十分なケースがあることが見えてきます。
PHP（Zendエンジン）は、変数のメモリ管理に参照カウント方式（Reference Counting）と、それに伴う循環参照ガベージコレクタを採用しています。
Zendエンジンの内部では、すべての変数（値）は `zval` という構造体で表現されており、その値が何箇所から参照されているかを示す `refcount` というカウンターを持っています。
変数のスコープを抜ける、あるいは明示的に `unset()` されると `refcount` が減算され、0になった瞬間にメモリが解放されます。
なぜ `static` 変数は厄介なのか？
`static` 変数は、その性質上、プロセスのライフサイクル全体を通じて `zend_function` やクラスのエントリから常に参照され続けています。
つまり、`static` 変数の中に巨大な配列や、オブジェクトのインスタンス、あるいは無名関数（クロージャ）を格納してしまうと、それらの `refcount` は「絶対に0にならない（あるいはベースのカウントが常に1以上ある）」状態になります。
さらに恐ろしいのは、その `static` 変数の中に、複雑なオブジェクト同士の循環参照（AがBを指し、BがAを指す構造）が入り込んだときです。
「大元の親である `static` 変数自体がプロセスにアンカー（繋留）されている」ため、GCのルートバッファからうまく切り離せない、あるいは回収漏れが発生し、プロセス全体のメモリ使用量が右肩上がりに増え続ける 「メモリリーク（Memory Leak）」 を引き起こします。
これが、常駐型PHPアプリケーションで最も恐れられている現象の正体です。
—
3. 実践：常駐環境で安全に立ち回るためのアーキテクチャ対策
では、私たちはこの強力な「常駐環境のパフォーマンス」と「メモリ安全性の確保」をどのように両立させればよいのでしょうか？
ここからは、現場の設計で即座に使える具体的なアプローチをいくつかご紹介します。
対策①：リクエスト開始時の明示的な「クリーンアップ（リセット）」の徹底
SwooleやRoadRunnerを使う場合、フレームワーク層（あるいはPSR-15のミドルウェア層など）で、リクエストのライフサイクルの最初（あるいは最後）に、すべての静的状態を強制リセットするフックを挟むのが最も確実で王道なアプローチです。
/
private static array $reseters = [];
public static function register(callable $reseter): void
{
self::$reseters[] = $reseter;
}
/
- リクエスト終了時（または開始時）に必ず呼ぶ
/
public static function flushAll(): void
{
foreach (self::$reseters as $reseter) {
$reseter();
}
}
}
// ── 実際のドメイン側での利用例 ──
// サービスプロバイダや初期化スクリプトでクリーンアップ処理を登録する
StateManager::register(function() {
UserContext::reset(); // static $currentUser = null; に戻す
QueryLogger::clear(); // 蓄積されたクエリログ配列を空にする
});
このように、フレームワークのライフサイクルイベント（`onRequest` など）に連動させて `StateManager::flushAll()` を叩く仕組みを強制することで、静的変数の持ち越し事故を根絶することができます。
対策②：オブジェクトの「ライフサイクル」を依存性注入（DI）で厳格に管理する
モダンなPHPアプリケーションでは、サービスやハンドラーを `static` メソッドやグローバルな状態に頼るのではなく、DIコンテナ（Dependency Injection Container）を通して適切にスコープ管理することが求められます。
例えば、Laravelなどのモダンフレームワークでは、リクエストごとにコンテナが新しく生成される仕組み（Request Scope）が用意されています。
- シングルトン（Singleton）： アプリケーション起動中ずっと維持される（設定ファイルやDBコネクションなど、読み取り専用の安全なものに限定する）
- リクエストスコープ（Request）： 1リクエストの処理が終わるたびにインスタンスが破棄され、メモリが解放される
`static` 変数をむやみに自作するのではなく、DIコンテナの「リクエストスコープ」の仕組みに依存させることで、メモリリークのリスクをフレームワーク側に安全に肩代わりしてもらうことができます。
—
4. アーキテクトからのメッセージ
ここまで、SwooleやRoadRunnerといった常駐環境における `static` 変数の挙動と、Zendエンジンのメモリ管理の裏側についてお話ししてきました。
- `static` 変数は、プロセス生存期間中ずっとメモリに残り続ける。
- 古いリクエストのデータが次のリクエストに漏れ出す「データ汚染」と、参照カウントが落ちずに肥大化する「メモリリーク」の二重のリスクがある。
- 対策として、ライフサイクルに応じた明示的なリセット機構（あるいはDIのスコープ管理）を必ず設計に組み込むこと。
「PHPはリクエストごとに綺麗に忘れてくれる言語」という古い常識をそっと手放し、メモリのライフサイクルをコントロールする視点を持つこと。それこそが、モダンな常駐型PHPアーキテクチャを極めるための最大のカギとなります。
裏側のメカニズムがすっきりと見えたあなたなら、もうメモリリークに怯える必要はありません。ぜひ、次世代の高速なPHPアプリケーションの設計にこの知見を活かしてくださいね。