Swoole常駐環境下におけるグローバル変数汚染とメモリリークの静的解析手法
PHPは、本来「1リクエスト＝1プロセス（またはスレッド）の完全なエフェメラル（一時的）」を前提として設計されてきた言語である。Webの黎明期からApache + mod_php、そして現代のPHP-FPMに至るまで、リクエストの終端における`zend_request_startup()`から`zend_request_shutdown()`までのライフサイクルは、Zend Engineがすべてのメモリ（`emalloc`）を容赦なく解放し、ゾンビのようなリソースの持ち越しを物理的に遮断してきた。
しかし、SwooleやRoadRunnerに代表される「常駐型（Long-running）PHPプロセス」の登場により、この鉄の掟は崩れ去った。
プロセスがメモリ上に常駐し続けるということは、Zend VMのヒープ空間、シンボルテーブル、そしてグローバルな状態が、リクエストを跨いで永続化されることを意味する。ここでPHPエンジンの内部構造、特に`HashTable`の挙動や参照カウントの仕組みを誤認していれば、システムは確実に「メモリリーク」と「グローバル変数汚染（クロスリクエスト汚染）」という名の致命的な崩壊へと向かう。
本稿では、Swoole常駐環境下におけるPHPメモリの深層構造を解き明かし、静的解析によって静的変数やグローバル汚染を検知・根絶するための極限の知見を提示する。
—
1. Zend VMのメモリ空間と常駐プロセスのパラダイムシフト
PHP-FPM環境下では、リクエスト処理中にどれほど粗雑なコードを書こうとも、リクエストが終了した瞬間にOSレベルでプロセスが破棄されるか、FPMのマネージャープロセスによってメモリプールが全解放されるため、リリースのし忘れは実質的に隠蔽されてきた。
しかし、Swooleの `Swoole\Server` が起動した瞬間、マスタープロセスからフォークされたワーカープロセスは、無限イベントループ（EpollベースのReactor）に入る。
[Swoole Worker Process] (Long-running)
├── Zend Engine Startup (OPcache, Preloading) -> 永続メモリ (Persistent Allocation)
└── Event Loop (Master Loop)
├── Request 1 ──> emalloc (ヒープ) ──> リクエスト終了時に解放漏れ ──┐
├── Request 2 ──> emalloc (ヒープ) ──> 蓄積 (Memory Leak) ├─> OOM Killerへ直行
└── Request N ──> 共有シンボルテーブルの汚染 (State Pollution) ┘
永続メモリ（Persistent Allocation）とリクエストメモリ（Request-bound Allocation）
Zend Engineは、メモリ確保において `pemalloc()`（永続的）と `emalloc()`（リクエスト単位）を明確に区別している。
常駐環境において、`static` 変数、グローバルスコープのオブジェクト、あるいはOPcacheのプリロード（Preloading）によって読み込まれたクラス定義は、すべてワーカープロセスの生存期間中、ヒープ上に固定化される。
ここに、Swoole開発者が陥る最初の罠がある。
リクエスト処理内で生成されたデータが、意図せずして `static` プロパティやシングルトン、あるいはグローバル変数へバインドされた場合、そのデータは次のリクエストに引き継がれる。これが「グローバル変数汚染」である。認証情報やテナントIDが他人のリクエストに露出するセキュリティインシデントの温床となる。
—
2. メモリリークと汚染を引き起こすコードの解剖
まずは、常駐環境において何が致命的なバグを引き起こすのか、具体的なコードとその内部挙動を見てみよう。
/
class RequestContextContainer
{
private static ?self $instance = null;
// リクエスト固有のデータを保持するハッシュテーブル
private array $storage = [];
private function __construct() {}
public static function getInstance(): self
{
if (self::$instance === null) {
self::$instance = new self();
}
return self::$instance;
}
public function set(string $key, mixed $value): void
{
// $storage は static なインスタンスに紐づくため、
// リクエストが終了してもメモリ上に残り続ける。
$this->storage[$key] = $value;
}
public function get(string $key): mixed
{
return $this->storage[$key] ?? null;
}
}
このコードをSwooleのワーカー内で実行した場合何が起きるか。
1. リクエスト A が `RequestContextContainer::getInstance()->set(‘user’, $userA)` を実行する。
2. リクエスト A が終了する。通常のPHPであればここで `$userA` は消滅するが、Swooleワーカーは生存しているため、`self::$instance` は保持され続ける。
3. リクエスト B（別ユーザー）が処理される際、`RequestContextContainer::getInstance()->get(‘user’)` を呼び出すと、リクエスト A の `$userA` がそのまま返却される。
これがクロスリクエスト汚染の物理的メカニズムである。さらに、リクエストごとに巨大な配列やクロージャを `$storage` に蓄積し続けた場合、Zend Engineの `emalloc` プールは肥大化し続け、最終的にLinux KernelのOOM Killerによってプロセスは強制終了（SIGKILL）させられる。
—
3. コンテキスト分離とクリーンアップのアーキテクチャ
この問題を解決するには、「リクエストのライフサイクルとオブジェクトのライフサイクルを完全に分離する（Context Isolation）」必要がある。
Swoole環境における正しいアプローチは、グローバル状態を一切排除し、リクエストの開始（`onRequest` イベント等）時にコンテキストホルダを初期化し、リクエストの終了時に必ず破棄（Destruction）することである。
/
class CoroutineContext
{
/ @var array
private static array $contextPool = [];
public static function set(string $key, mixed $value): void
{
// 現在のコルーチンIDを取得し、プロセス全体のグローバル汚染を防ぐ
$cid = \Co::getCid();
if ($cid < 0) {
// コルーチン外（メインスレッド等）の場合のフォールバック
return;
}
self::$contextPool[$cid][$key] = $value;
}
public static function get(string $key): mixed
{
$cid = \Co::getCid();
if ($cid < 0 || !isset(self::$contextPool[$cid])) {
return null;
}
return self::$contextPool[$cid][$key] ?? null;
}
/
- リクエスト終了時に必ず呼び出すこと（メモリリーク防止の要）
/
public static function destroy(): void
{
$cid = \Co::getCid();
if ($cid >= 0 && isset(self::$contextPool[$cid])) {
// 配列の参照を完全に切断し、Zend VMのGCと参照カウントに回収させる
unset(self::$contextPool[$cid]);
}
}
}
Swooleのサーバーフックにこれを組み込む。
$server = new \Swoole\Http\Server(“0.0.0.0”, 9501);
$server->on(“Request”, function (Request $request, Response $response) {
try {
// — リクエストスコープの開始 —
// ユーザー情報をコンテキストにバインド
CoroutineContext::set(‘request_uri’, $request->server[‘request_uri’] ?? ”);
// ビジネスロジックの実行
$controller = new \App\Controllers\IndexController();
$controller->handle($request, $response);
} catch (\Throwable $e) {
$response->status(500);
$response->end(“Internal Server Error”);
} finally {
// — リクエストスコープの強制終了とクリーンアップ —
// これを怠ると、コルーチンが破棄されても静的プロパティに残骸が残り続ける
CoroutineContext::destroy();
}
});
$server->start();
—
4. 静的解析（Static Analysis）によるメモリリーク・汚染の自動検出
人間はミスをする。どれほど優れたアーキテクトであっても、大規模なコードベースにおいて「うっかりクラスプロパティに `public static` を付けてしまった」「クロージャの中で外側の変数を `use` し、それが原因で循環参照（Circular Reference）を引き起こした」というヒューマンエラーを完全に防ぐことはできない。
そのため、CI/CDパイプラインにおいて静的解析（Static Analysis）による自動検知システムを構築することが極限の信頼性を担保する絶対条件となる。PHPStanやPsalmを拡張し、Swoole常駐環境特有のアンチパターンをコード片レベルで検知するカスタムルールの実装手法を解説する。
PHPStanカスタムルールによる `static` プロパティの検出
常駐環境において、状態を持つ（Mutableな）`static` プロパティの宣言は原則として禁止されるべきである（イミュータブルな定数やキャッシュインスタンスを除く）。以下のPHPStanルールは、クラス内の `static` プロパティの存在を検知し、ビルドを失敗させる。
/
class DisallowStaticPropertyInWorkerRule implements Rule
{
public function getNodeType(): string
{
return Property::class;
}
public function processNode(Node $node, Scope $scope): array
{
// プロパティが static であるか判定
if (!$node->isStatic()) {
return [];
}
// 読み取り専用（readonly）かつプリミティブ、または特定の安全なクラスであれば除外するロジックをここに挟むことも可能
// クラス名を取得
$className = $scope->getClassReflection()?->getName() ?? ‘Unknown’;
return [
sprintf(
‘Swoole常駐環境において、[%s::$%s] のような static プロパティの保持はクロスリクエスト汚染およびメモリリークの原因となります。コンテキストホルダまたはコルーチンストレージを利用してください。’,
$className,
$node->props[0]->name->toString()
),
];
}
}
このカスタムルールを `phpstan.neon` に登録する。
services:
–
class: System\Architecture\PHPStan\DisallowStaticPropertyInWorkerRule
tags:
- phpstan.rules.rule
これにより、開発者が誤って `public static $userInfo;` のようなコードをコミットした瞬間、CI（GitHub Actions等）が検知し、プルリクエストを物理的にブロックすることが可能となる。
—
5. 循環参照（Circular Reference）とZendガベージコレクタの限界
メモリリークのもう一つの大きな要因は、「循環参照」である。
PHPのメモリ管理は基本的には「参照カウント方式（Reference Counting）」で行われている。変数やオブジェクトが参照されるたびに `refcount` がインクリメントされ、スコープを抜けるとデクリメントされる。`refcount === 0` になった瞬間にメモリは `efree()` される。
しかし、オブジェクト A がオブジェクト B を指し、オブジェクト B がオブジェクト A を指すような「循環参照」が発生した場合、スコープを抜けてもそれぞれの `refcount` は `1` のまま残る。
[Object A] (refcount: 1) ──> holds ──> [Object B] (refcount: 1)
▲ │
└────────────── holds ─────────────────┘
PHPにはこれを解決するための「循環ガベージコレクタ（Circular Garbage Collector）」が存在し、バッファがいっぱいになると（あるいは明示的に `gc_collect_cycles()` を呼ぶと）巡回して回収を行う。
しかし、Swooleの常駐環境においては以下の問題が発生する。
1. ワーカープロセスの寿命の長さ: ガベージコレクションの実行頻度やタイミングが追いつかず、メモリ消費量が緩やかに右肩上がりになる。
2. クロージャ（Closure）の罠: クロージャが外部変数を `use ($this)` や大きなオブジェクトとしてキャプチャし、それが常駐するオブジェクトのプロパティに代入された場合、極めて複雑な循環参照ツリーが形成され、GCの検知網をすり抜けて永続的なメモリリークへと発展する。
対策：明示的な参照の切断（Destructorの活用）
常駐環境で動作するサービス層やコントローラー、あるいは重いオブジェクトを扱う場合は、__destruct() や明示的なクリーンアップメソッドを用意し、循環参照の端点を自らの手で断ち切る設計が求められる。
/
public function release(): void
{
$this->largeDataset = null;
$this->callback = null;
}
public function __destruct()
{
$this->release();
}
}
—
結び：常駐型PHPにおけるエンジニアの覚悟
SwooleやFiberを活用した非同期・常駐型PHPシステムの構築は、従来のPHP-FPMのパラダイムを完全に破壊する。高スループット、極限まで削ぎ落とされたレイテンシ、そして接続維持（WebSocketなど）の容易さは、PHPを全く新しいステージへと引き上げた。
だが、それは同時に、「Zend Engineのメモリ管理のメカニズムをエンジニア自身が完全に支配していなければならない」という重い代償を伴う。
「リクエストが終われば勝手にきれいになる」という甘美な幻想は、常駐環境においては通用しない。すべての変数、すべてのプロパティ、すべてのクロージャがどこに属し、いつ生成され、いつ破棄されるべきか。そのライフサイクルの全貌を頭脳の中でトレースし、静的解析ツールとコードの構造によってガチガチに統制すること。それこそが、過酷なプロダクション環境を無停止で支え続ける、本物のWebシステムアーキテクトの仕事である。