はじめに：常駐型PHPが突きつける「Zend VMの呪縛」
コードレビューの場で、次のようなコードを見かけたら、テクニカルリードとして即座にマージを止めるべきだ。
class UserService {
private static array $cache = [];
public function getUser(int $id): array {
if (!isset(self::$cache[$id])) {
// 重いDBクエリをシミュレート
self::$cache[$id] = [‘id’ => $id, ‘name’ => ‘User ‘ . $id];
}
return self::$cache[$id];
}
}
「リクエストごとにDBへ行かなくて済むから高速化になる」？
いや、それは伝統的なNginx + PHP-FPMのシェアードナッシング（Shared-nothing）アーキテクチャの幻影にすぎない。SwooleやRoadRunnerといった常駐型（Persistent）アプリケーションサーバーの文脈において、このコードは爆弾となる。
今回は、Zend VMの低レイヤにおけるメモリ管理、参照カウント、そしてガベージコレクション（GC）の挙動を解剖しながら、常駐環境における`static`変数の永続化がもたらす致命的なメモリリークとデータ汚染のメカニズム、そしてその防衛策を徹底解説する。
—
1. 内部構造：なぜ `static` 変数は消えないのか？
PHP-FPM環境では、1つのHTTPリクエストが完了するとZend Engineはプロセス終了、あるいはリクエストスコープのクリーンアップを行い、割り当てられたすべてのメモリ（ヒープ）を解放する。そのため、スクリプト内で定義された`static`変数もリクエストの終焉とともに消え去る。
しかし、SwooleやRoadRunnerのような常駐型ランタイムでは、PHPのプロセス（またはWorker）がメモリ上に常駐し続け、イベントループ上で数千・数万のリクエストを処理し続ける。
Zend VMにおける `static` の実体
Zend VMの視点から見ると、関数やクラスメソッド内の`static`変数、あるいはクラスプロパティとしての`static`変数は、プロセスライフサイクルを通じてシンボルテーブル（Symbol Table）に繋ぎ止められた `zval` 構造体である。
1. 初回実行（OPcache / 実行時）: `static`変数が初期化され、ヒープ上の特定のメモリ領域にアロケートされる。
2. リクエスト処理: コードが実行され、`static`変数にデータが蓄積される。
3. リクエスト終了: ワーカープロセスは生存し続けるため、シンボルテーブルはクリアされない。つまり、`zval`の参照カウント（`refcount`）は0にならず、メモリ空間に保持されたまま次のリクエストの到来を待つ。
結果として、「あるユーザーのためにロードされた機密データが、次の全く別のユーザーのリクエストで露出する（データ汚染）」という致命的なセキュリティインシデントや、リクエストを重ねるごとにメモリ消費量が増え続ける「スローリーク（Slow Memory Leak）」を引き起こす。
—
2. 循環参照とGCの限界
「じゃあ、PHPのガベージコレクション（GC）が勝手に回収してくれるのでは？」という疑問を持つかもしれない。だが、ここにもZend VMの仕様の罠がある。
PHPのメモリ管理の基本は参照カウント（Reference Counting）だ。`zval`が別の変数や配列、オブジェクトから参照されるたびにカウントが増え、0になった瞬間に即座に解放される。しかし、オブジェクトや配列が互いに参照し合う「循環参照（Circular Reference）」が発生した場合、参照カウント方式だけではカウントが0にならず、メモリに取り残される。
これを回収するのがPHPのGC（コンカレント・ガベージコレクション）だが、以下の点に注意しなければならない：
- GCはバッファ（Circular Buffer）が満杯になるか、明示的に発火しないと動かない。
- `static`変数に保持された巨大なオブジェクトグラフが循環参照を含んでいる場合、ワーカーのライフサイクルが続く限り、GCのルートバッファを圧迫し続け、最悪の場合はOOM（Out of Memory）Killerにプロセスが強制終了させられる。
—
3. 実務で耐えうる堅牢な設計：スコープ管理と明示的クリーンアップ
常駐環境で安全にキャッシュやステートを扱うための鉄則は、「永続化のスコープをフレームワークやランタイムのライフサイクルに完全に同期させること」である。
Swoole等では、リクエストの開始時（`onRequest` や Middlewareの入口）と終了時（`onFinish` や `defer`）にフックをかけることができる。この仕組みを使い、リクエスト終了時に静的キャッシュやコンテナ内のステートを必ず強制破棄（フラッシュ）させなければならない。
実装例：安全なリクエストスコープ・コンテナとメモリ防衛パターン
以下は、SwooleやRoadRunner環境を想定し、意図しないデータ保持を防ぐための堅牢なサービスクラスおよびミドルウェアの実装例だ。
declare(strict_types=1);
namespace App\Core;
/
- 常駐環境におけるリクエストスコープ管理クラス
- 静的プロパティの暴走を防ぐため、リクエスト終了時に全データを強制破棄する。
/
final class RequestContext {
/ @var array
private static array $storage = [];
/
- 値を保存する
/
public static function set(string $key, mixed $value): void {
self::$storage[$key] = $value;
}
/
- 値を取得する
/
public static function get(string $key, mixed $default = null): mixed {
return self::$storage[$key] ?? $default;
}
/
- 【極めて重要】リクエスト終了時に必ず呼び出すこと
- これにより、次のリクエストへのデータ持ち越し（データ汚染）とメモリリークを断ち切る。
/
public static function flush(): void {
// 配列の中身を再帰的に解放し、Zend VMのヒープからシュレッドする
foreach (self::$storage as $key => $value) {
if (is_object($value) && method_exists($value, ‘close’)) {
// リソースを保持するオブジェクトであれば明示的にクローズ
try {
$value->close();
} catch (\Throwable) {
// ログ出力等のフォールバック
}
}
unset(self::$storage[$key]);
}
self::$storage = [];
// 強制的にGCを促す（必要な高負荷バッチや特殊なケースのみ。通常はバッファに任せる）
// gc_collect_cycles();
}
}
/
- ミドルウェア / フレームワークのブートストラップ層での実行イメージ
/
class HttpWorkerKernel {
public function handleRequest(object $request, object $response): void {
try {
// 1. リクエスト処理の実行
$controller = new \App\Controllers\UserController();
$controller->execute($request, $response);
} finally {
// 2. 例外が発生しようとも、確実にリクエストスコープを破棄する
// ※ Swooleの defer() や RoadRunnerのworker->waitPayload() のループ脱出時に必ず呼ぶ
RequestContext::flush();
}
}
}
—
4. リードエンジニアからの最終提言
常駐型PHP（Swoole, RoadRunner, FrankenPHPなど）は、従来のPHP-FPMの数倍〜数十倍のスループットをもたらす強力な武器である。しかし、それは同時に「C言語やJavaのようなメモリ管理の意識」をPHPプログラマーに要求するものでもある。
「とりあえず `static` にキャッシュしておけば速くなる」という安易なアプローチは、マルチテナントなWebアプリケーションにおいて、他人のデータが見えてしまう致命的なセキュリティホール（データリーク）と、徐々にメモリを食いつぶすサイレントキラー（メモリリーク）を産む温床でしかない。
コードレビューの際は、以下の3点を徹底してチェックせよ：
1. クラスやメソッド内の `static` 変数、およびシングルトンパターンで保持されるプロパティが、リクエスト間で変更可能なステートを持っていないか？
2. キャッシュ機構を使用する場合、TTLや最大エントリ数の制限（Bounding）が実装されているか？
3. リクエストのライフサイクル終端において、確実にステートがクリアされる設計（`finally` ブロックやフレームワークのイベントフック）になっているか？
Zend VMの息づかいを感じ取れる者だけが、常駐型PHPの真のパフォーマンスを引き出すことができる。セキュアでスケーラブルなアーキテクチャをその手で構築してほしい。