Swoole/RoadRunner常駐型PHPにおける `static` の呪縛：Zend VMメモリ空間の真実とデータ汚染を防ぐ極限の設計論
コードレビューの場で、以下のようなコードを見かけたら、テクニカルリードであるあなたはどう反応するだろうか。
class OrderService {
private static array $cache = [];
public function getOrder(int $id): array {
if (!isset(self::$cache[$id])) {
// 重いDBクエリや外部APIコールを模した処理
self::$cache[$id] = $this->fetchFromDatabase($id);
}
return self::$cache[$id];
}
}
「お、キャッシュを使ってクエリ数を削減していて賢いね」と思ったとしたら、PHP-FPMの古い常識に囚われていると言わざるを得ない。
SwooleやRoadRunnerといった常駐型（Persistent）アプリケーションサーバーの文脈において、この `static` プロパティは、アプリケーションに致命的なメモリリークをもたらし、最悪の場合は「あるユーザーのリクエストデータが、別のユーザーに露出する（データ汚染）」という重大なセキュリティインシデントを引き起こす時限爆弾と化す。
今回は、Zend VMのメモリ管理、リクエストライフサイクル、そして常駐型PHPにおける `static` 変数の挙動を低レイヤの視点から解き明かし、実務で絶対に破綻しない堅牢な設計ルールを伝授する。
—
1. なぜ `static` は常駐型環境で牙をむくのか？
PHP-FPMと常駐型ランタイムの決定的な違い
伝統的なPHP-FPMアーキテクチャでは、1つのHTTPリクエストが到達するたびにプロセスが立ち上がり（あるいはプールから借用され）、リクエストの終了とともにZend Engineのプロセス空間は完全に破棄される。
つまり、グローバル変数や `static` 変数の寿命は「1リクエストの寿命」と同義であり、メモリリークがあってもプロセス終了時にOSへ返却されるため、ある種「逃げ切る」ことができた。
しかし、SwooleやRoadRunnerなどの常駐型ランタイムは違う。
PHPプロセスは起動したまま、メモリ上に常駐し続け、数万〜数百万の連続するリクエストを単一のプロセスで処理し続ける。
Zend VMのメモリ管理と `static` の永続化
Zend Engineの視点から見ると、クラスの `static` プロパティは、コンパイル時に生成される op_array や class_entry と共に割り当てられ、プロセスが生存している限り Request Startup (RINIT) を超えて Request Shutdown (RSHUTDOWN) を経ても解放されない。
つまり、`static` 変数は実質的に「プロセスライフサイクルのグローバル変数」として振る舞う。
ここにデータを蓄積し続けると何が起きるか。
1. メモリリーク（Memory Bloat）の加速：
リクエストごとに生成された巨大なオブジェクトや配列が `static` プロパティに蓄積され続けると、Zend Memory Manager（zend_alloc）のヒープ領域が肥大化し続け、最終的に `Allowed memory size exhausted` でプロセスがクラッシュする。
2. リクエスト間のデータ汚染（Cross-Request Pollution）：
マルチテナントやマルチユーザーの環境において、User Aのセッション情報や認可データが `static` キャッシュに残存した場合、次に同じプロセスに割り当てられた User B が User A のデータを閲覧・操作できてしまう。
—
2. 内部で何が起きているか？（概念的メモリモデル）
以下の図式は、常駐型ワーカープロセスにおけるメモリの保持状態を模したものである。
[ Swoole / RoadRunner Worker Process (Persistent) ]
│
├── Zend Engine Core
├── Opcodes (Read-only, Shared across requests)
└── class_entry (Persistent)
└── static properties ──> [ ⚠️ ここにデータが蓄積され続ける ]
├── Request #1: User A’s Secret Data (残存)
├── Request #2: User B’s Data (追加)
└── Request #3: Memory grows infinitely…
一度代入されたデータは、明示的にクリアされない限り、PHPのガベージコレクション（GC）の対象外（あるいはルートバッファにすら乗らない永続領域）として残り続ける。参照カウント（refcount）の概念を超越してプロセスにしがみつくため、非常に厄介なのだ。
—
3. 実務で耐えうる堅牢な設計とリファレンスコード
では、SwooleやRoadRunner上で安全にキャッシュやステートを管理するにはどうすればよいのか？
答えは明確だ。「リクエストスコープに依存するデータを `static` に持たせない」 こと。そして、アプリケーションコンテナ（DI Container）によるライフサイクル管理を徹底することである。
以下に、実務のAPIサーバーでそのまま使える、メモリ安全性を考慮したキャッシュレジストリの実装例を示す。
安全な依存性注入とスコープ管理の例
declare(strict_types=1);
namespace App\Core;
/
- リクエストスコープを安全に管理するためのレジストリ
- ※ static を一切排除し、DIコンテナ経由でリクエストごとにインスタンスを生成・破棄する
/
class RequestContext {
private array $store = [];
public function set(string $key, mixed $value): void {
$this->store[$key] = $value;
}
public function get(string $key, mixed $default = null): mixed {
return $this->store[$key] ?? $default;
}
/
- リクエスト終了時に必ずストアを空にする
/
public function flush(): void {
$this->store = [];
}
}
namespace App\Service;
use App\Core\RequestContext;
class SafeOrderService {
public function __construct(
private RequestContext $requestContext,
private DatabaseClient $db
) {}
public function getOrder(int $id): array {
// リクエスト内でのみ有効なローカルキャッシュとしてRequestContextを利用
$cacheKey = “order_{$id}”;
if ($cached = $this->requestContext->get($cacheKey)) {
return $cached;
}
// DBから取得
$order = $this->db->fetch(“SELECT FROM orders WHERE id = ?”, [$id]);
// リクエストスコープに保存（次のリクエストには持ち越されない）
$this->requestContext->set($cacheKey, $order);
return $order;
}
}
フレームワーク層（Swoole / RoadRunner連携）でのフック
RoadRunnerやSwooleを使う場合、「1つのリクエストの処理が完了した瞬間（Request Shutdown）」に、すべてのリクエストスコープのサービスやコンテナをリセット（あるいは再生成）するミドルウェアを必ず挟まなければならない。
namespace App\Http\Middleware;
use App\Core\RequestContext;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;
class RequestLifecycleMiddleware implements MiddlewareInterface {
public function __construct(
private RequestContext $requestContext,
private ContainerInterface $container
) {}
public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface {
try {
// リクエスト開始時の初期化処理が必要な場合はここに記述
// リクエスト処理の実行
return $handler->handle($request);
} finally {
// 【極めて重要】
// 例外が発生しようとも、必ずリクエスト終了時にステートを完全破棄する
$this->requestContext->flush();
// DIコンテナがリクエストスコープのオブジェクトを保持している場合はここでリセット
if (method_exists($this->container, ‘resetScope’)) {
$this->container->resetScope();
}
}
}
}
—
安易な `static` 変数の使用は、PHPを「マルチスレッド／常駐型ランタイム」として動かした際に最もデバッグが困難なバグ（幽霊バグ）を産む温床となる。
コードレビューを行う際は、以下のチェックリストを常に念頭に置いてほしい。
1. その `static` は本当にプロセス全体で共有すべき読み取り専用の定数データ（Lookup Table等）か？
2. 動的に変化するデータやユーザー固有のデータが `static` やグローバル空間に漏れ出していないか？
3. 常駐ワーカーのライフサイクル（RINIT/RSHUTDOWN相当）において、明示的なクリーンアップ機構が担保されているか？
Zend VMのメモリ構造を脳内に描き、1リクエストの重みとプロセスの尊さを理解した者だけが、SwooleやRoadRunnerの真のパフォーマンスを引き出すことができる。モグラ叩きのようなメモリリークに怯える日々を終わらせ、堅牢で美しいアーキテクチャを構築してほしい。