Swoole常駐環境下におけるグローバル変数汚染とメモリリークの静的解析手法
PHP-FPMの「1リクエストごとにプロセスが破棄され、メモリが完全クリーンアップされる」というお気楽なライフサイクルに慣れきった脳のまま、SwooleやRoadRunnerといった非同期・常駐型のランタイムに踏み込むと、必ず地雷を踏む。
FPMの世界では、どれだけ雑にグローバル変数を汚染しようが、リクエストの終端（`request_shutdown`）と共にOSへメモリ空間が返還されるため、アプリケーション層でのメモリリークは「少し行儀が悪い」程度で済んでいた。しかし、Swooleのマスター・ワーカープロセスモデルにおいて、メモリはリクエストをまたいで永続化する。
今回は、常駐環境下におけるグローバル変数汚染とメモリリークのメカニズムをZend VMのメモリ管理の観点から解き明かし、静的解析によってこれを完全に封殺するための極限の設計論を授けよう。
—
1. なぜ常駐環境ではグローバル変数が「毒」になるのか
PHPの実行実体であるZend VMにおいて、すべての変数、関数、クラスはシンボルテーブル（`HashTable`構造体）によって管理されている。
通常、関数内で宣言されたローカル変数は、そのスタックフレーム（`zend_execute_data`）の消滅と共にZendメモリマネージャー（ZMM）によって解放される。しかし、以下の領域に配置されたデータは、明示的に破棄しない限りワーカープロセスの寿命と同化する。
1. `global` 宣言された変数、またはファイルスコープのグローバル変数
2. クラスの `static` プロパティ
3. 関数の `static` 変数
4. クロージャの `use` による静的バインド
Swooleのサーバー起動後、最初の数リクエストは正常に処理されるように見えるかもしれない。しかし、リクエストごとに増加する配列への `append` や、ユーザーセッション情報の静的キャッシュが蓄積されていくと、ZMMのチャンクは膨れ上がり、最終的に `Allowed memory size of … bytes exhausted` を叩き出すか、OOM Killerによってワーカーが強制暗殺される。
—
2. 実務で起きる最悪のアンチパターン
まずは、コードレビューで即座に差し戻すべき典型的なメモリリークのコードを見てほしい。
on(‘Request’, function (Request $request, Response $response) {
// ユーザーからの入力をグローバルな静的コンテキストに保存
DirtyContainer::set(‘current_user_ip’, $request->server[‘remote_addr’] ?? ‘unknown’);
DirtyContainer::set(‘payload’, $request->rawContent());
// 他のリクエストのデータが混ざり合う汚染（Data Race / 汚染）が発生する
$ip = DirtyContainer::get(‘current_user_ip’);
$response->end(“Hello, your IP is: {$ip}”);
// 【致命的】リクエスト終了時に $requestContext をクリアする処理が存在しない
});
$server->start();
このコードの何が問題か。
単なるメモリリークに留まらず、「前のリクエストのコンテキスト（他人のセッション情報や機密データ）が、次のリクエストの処理中に露見する」という深刻なセキュリティ脆弱性（データ汚染）を引き起こす。マルチスレッド・マルチコルーチン環境において、グローバルステートの共有は百害あって一利なしだ。
—
3. コンテキスト分離設計による解決
常駐環境で安全にアプリケーションを動作させるための鉄則は、「リクエストスコープのオブジェクトは、必ずコルーチンコンテキストまたはリクエストライフサイクル内に閉じ込める」ことだ。
Swooleには、コルーチン（Coroutine）ごとに独立した領域を提供する `Swoole\Coroutine\Context` が用意されている。これを利用し、リクエストごとのDIコンテナを完全に分離する実装例を示す。
/
final class RequestContext
{
private static array $registry = [];
public static function set(string $key, mixed $value): void
{
$cid = Coroutine::getCid();
if ($cid < 0) {
// コルーチン外（メインスレッド）での実行フォールバック
return;
}
self::$registry[$cid][$key] = $value;
}
public static function get(string $key): mixed
{
$cid = Coroutine::getCid();
return ($cid >= 0 && isset(self::$registry[$cid][$key]))
? self::$registry[$cid][$key]
: null;
}
/
- 【極めて重要】リクエスト（コルーチン）終了時に必ずメモリを解放する
/
public static function destroy(): void
{
$cid = Coroutine::getCid();
if ($cid >= 0 && isset(self::$registry[$cid])) {
// 循環参照の切断とHashTableの解放を促す
unset(self::$registry[$cid]);
}
}
}
この `RequestContext` をミドルウェア層で制御し、`defer`構文（コルーチン終了時に必ず実行されるコールバック）を用いて確実にクリーンアップを行う。
on(‘Request’, function (Request $request, Response $response) {
// Coroutine::defer は、現在のコルーチンが終了する瞬間に確実に実行される
Coroutine::defer(function () {
RequestContext::destroy();
});
// リクエストごとの安全なスコープにデータをバインド
RequestContext::set(‘request_id’, uniqid(‘req_’, true));
RequestContext::set(‘client_ip’, $request->server[‘remote_addr’] ?? ‘127.0.0.1’);
// ビジネスロジックの実行
$requestId = RequestContext::get(‘request_id’);
$response->header(‘X-Request-ID’, $requestId);
$response->end(“Processed under isolated context.”);
});
$server->start();
—
4. PHPStanを活用した静的解析による「人災」の防止
どれほど優れた設計ドキュメントを書いても、ジュニアや外部のコントリビューターが `public static $cache;` のような禁忌コードを書き込むリスクはゼロにならない。したがって、CIパイプラインの静的解析（PHPStan / Psalm）で構造的な違反を検知・ブロックする仕組みが不可欠である。
PHPStanのカスタムルール、または既存の拡張ルール（`phpstan-strict-rules` や `slam/phpstan-extensions`）に加え、以下のポリシーを静的解析で強制する。
1. サービスクラスにおける `static` プロパティの完全禁止
アーキテクチャ上、ドメインサービスやアプリケーションサービス、コントローラー内での `static` プロパティの宣言は、例外なくバグの温床となる。
PHPStanの設定ファイル（`phpstan.neon`）を用いて、特定の命名規則やレイヤーにおける `static` プロパティの利用を静的に弾く。
parameters:
ignoreErrors:
–
message: ‘#Static property \$[a-zA-Z0-9_]+ in non-singleton class is prohibited in常駐 environment.#’
paths:
- src/Controllers/
- src/Services/
- src/Handlers/
より厳密に行う場合は、カスタムPHPStanルール（`PHPStan\Rules\Rule` を実装したクラス）を作成し、AST（抽象構文木）レベルで `Stmt_Property` の `isStatic` フラグを検知した瞬間にエラーをスローさせるのがプロフェッショナルなアプローチだ。
/
class NoStaticPropertyInServicesRule implements Rule
{
public function getNodeType(): string
{
return Property::class;
}
public function processNode(Node $node, Scope $scope): array
{
if (!$node->isStatic()) {
return [];
}
$className = $scope->getClassReflection()?->getName() ?? ”;
// Services や Controllers 名前空間配下での static プロパティを厳禁とする
if (str_starts_with($className, ‘App\Services’) || str_starts_with($className, ‘App\Controllers’)) {
return [
‘Static properties are strictly prohibited in services/controllers for Swoole/resident environments to prevent memory leaks and data contamination.’
];
}
return [];
}
}
—
5. テクニカルリードからの総括
Swooleや常駐型PHPランタイムの導入は、アプリケーションのパフォーマンスを限界突破させる一方で、PHPという言語が長年隠蔽してくれた「メモリ管理の生々しい現実」を開発者の目の前に突きつける。
- グローバル変数や静的プロパティは、ワーカーの寿命と運命を共にする毒である。
- コンテキストの分離には `Coroutine::getCid()` と `defer` を組み合わせた確実なクリーンアップメカニズムを構築せよ。
- ヒューマンエラーに頼るな。静型解析（PHPStan）のAST解析を拡張し、CIでルール違反を物理的に排除せよ。
この3点を守り抜くことだけが、数百万リクエストを無停止で裁き続ける堅牢な非同期PHPシステムの礎となる。コードレビューで妥協するな。アーキテクチャの美しさと厳格さこそが、プロダクトの寿命を決定づける。