共有メモリとGCの交差点：Swoole/RoadRunner環境におけるZend VMメモリ管理の極限と防衛
PHPは長年、「1リクエスト＝1プロセス（またはスレッド）で完結し、レスポンス返却と共に全メモリがOSへ返還される」という強力なランタイムモデルの上に成り立ってきた。この「使い捨て」の前提があったからこそ、私たちはメモリリークの恐怖から一定程度解放され、効率的なWebアプリケーションを構築できた。
しかし、SwooleやRoadRunnerといった非同期・常駐型PHPランタイムの普及により、その前提は完全に崩れ去った。Zend Engineは、数千、数万のリクエストにわたりプロセスを維持し続ける。そして、この常駐化モデルにおいて最も深刻な脅威となるのが、「共有メモリ（Shared Memory / APCu / Swoole Table等）」とZend VMのガベージコレクション（GC）および参照カウント機構との競合である。
本稿では、Zend VMの低レイヤメモリ構造（`zval`、`HashTable`）の挙動から出発し、常駐型ランタイムにおけるメモリ破壊・リークのメカニズム、そしてそれを完全に制御するための実践的アプローチを解き明かす。
—
1. Zend VMのメモリ管理モデル：`zval` と参照カウントの物理構造
PHPのすべての変数は、C言語レベルでは `zval`（Zend Value）構造体として表現される。Zend VMは、メモリの効率的な割り当てと解放を行うために、独自のヒープマネージャ（Zend Memory Manager: Zend MM）を介して `emalloc()` や `efree()` を実行している。
`zval` と循環参照の罠
スカラー値（整数や文字列など）は単純な値持ちだが、配列（`Array`）やオブジェクト（`Object`）などの複合型は、内部で `HashTable` や `zend_object` を保持する。
// 概念的な zval の構造（一部簡略化）
typedef struct _zval_struct {
zend_value value;
union {
uint32_t type_info;
/ … /
} u1;
union {
uint32_t next;
uint32_t cache_slot;
uint32_t references; // 参照カウント
} u2;
} zval;
リクエストライフサイクル型PHPでは、プロセス終了時にZend MMが一括してOSへメモリを返却するため、循環参照（Circular Reference）によるメモリリークが発生しても、プロセス生存期間が短いため実害は少なかった。
しかし、SwooleやRoadRunnerのようにプロセスが数日、数週間稼働し続ける環境では、循環参照や不適切なメモリ共有が致命的なメモリ肥大化（OOM Killerによるクラッシュ）を引き起こす。
—
2. Swoole / RoadRunner における「共有メモリ」の構造的矛盾
常駐型ランタイムでは、複数のリクエスト（あるいはSwooleのWorker/Coroutne）間でデータを高速に共有するため、`Swoole\Table`（ロックフリーな共有メモリ構造体）や、APCu、あるいはプロセス間でシリアライズ・デシリアライズを伴うメモリ共有が行われる。
ここで問題となるのは、「PHPのオブジェクトやクロージャ、参照（`&`）をそのまま共有メモリ領域や永続化コンテキストに保持しようとした瞬間」に発生する。
構造的矛盾のメカニズム
1. ポインタの不整合: PHPのオブジェクトはZend MMのヒープ上のメモリアドレスを指している。プロセス間でメモリ空間（またはプロセス境界）をまたいでポインタをそのまま渡すことはできない（Swoole Tableは内部でSHMを使用するが、格納できるのはスカラー値かシリアライズされた文字列のみ）。
2. GCバッファの汚染: 常駐プロセスにおいて、グローバルスコープや静的プロパティ（`static`）、あるいはSwooleの `Table` に紐づくデータ構造内に循環参照が含まれている場合、Zend VMのルートバッファ（GCが監視する循環参照候補のリスト）が徐々に汚染されていく。
child = $child;
$child->parent = $parent;
// 常駐プロセスの静的プロパティに格納されることで、
// リクエスト終了後もメモリに残存し、GCのルートバッファを圧迫し続ける
self::$sharedRegistry[] = $parent;
}
}
このコードがSwoole Worker内で何万回も実行されると、Zend VMのGCは毎回この巨大化したグラフ構造の走査を強いられ、CPU使用率が跳ね上がり（GCスパイク）、最終的にメモリが枯渇する。
—
3. OPcacheプリロード（Preloading）と共有メモリの深い関係
PHP 7.4で導入され、現代の常駐型ランタイムでも不可欠なOPcacheプリロードは、スクリプトのパース結果（Opcode）を共有メモリ（SHM）上に展開し、全プロセスで共有する仕組みである。
しかし、ここにも罠がある。プリロード時に `opcache.preload` で読み込まれるスクリプト内で、オブジェクトのインスタンス化やデータのキャッシュ（定数的な配列やオブジェクトの生成）をグローバルスコープで行うと、それらは親プロセス（Server起動前）のメモリ空間に固定化（Permanent）される。
‘mysql:host=localhost;dbname=core’,
// この配列内にクロージャや複雑なオブジェクトを含めると予期せぬ挙動を招く
];
}
}
DatabaseConfig::init();
コピー・オン・write（COW）の破綻
OPcacheによって共有メモリ上に展開されたOpcodeやデータは、基本的にはCopy-on-Write（COW）によって各Workerプロセスから参照される。しかし、プリロードされたオブジェクトや配列に対して、Workerプロセス側で「書き込み」や「参照の変更」が発生した瞬間、Zend Engineはその構造体をプロセス固有のローカルヒープへコピーし直す（Detach）。
これにより、共有メモリのメリットが消失するだけでなく、Zend MMの管理外や予期せぬヒープ断片化（Fragmentation）を引き起こし、パフォーマンスの急激な劣化を招く。
—
4. 解決策：メモリ境界の厳格な封鎖とガベージコレクションの手動制御
SwooleやRoadRunnerを極限までチューニングし、数ヶ月無停止で稼働させるためのアーキテクチャ上の鉄則は以下の3点に集約される。
1. 常駐スコープでの循環参照の完全排除
2. セッション/リクエスト境界でのメモリ解放の明示化
3. Zend GCの強制実行（`gc_collect_cycles()`）の戦略的配置
実装パターン：安全なSwoole Workerライフサイクル管理
以下は、SwooleのWorkerプロセス内において、メモリリークとGC競合を防ぐための堅牢なハンドラの実装例である。
processWithIsolatedContext($request, $response);
} \Throwable $e {
$response->status(500);
$response->end(“Internal Server Error”);
} finally {
// 【極めて重要】リクエスト終了時のクリーンアップ
// 意図的に循環参照を切断する、または巨大なローカル変数を強制破棄する
$this->purgeLocalContext();
}
}
private function processWithIsolatedContext(Request $request, Response $response): void {
// 1. リクエストごとのオブジェクトグラフを構築
$processor = new RequestProcessor($request);
$result = $processor->run();
// 2. Swoole Table等への書き込みは、必ずスカラー値または純粋な配列（Array）に限定する
// オブジェクトやクロージャの格納は厳禁
// \Swoole\Table::set() の使用例
$response->header(‘Content-Type’, ‘application/json’);
$response->end(json_encode($result));
}
private function purgeLocalContext(): void {
// Zend VMのGCバッファに溜まった循環参照をリクエスト単位でクリアする
// ※毎リクエスト実行するとオーバーヘッドになるため、必要に応じてカウンタ制御する
if (gc_enabled() && gc_status()[‘runs’] > 1000) {
// 強制的に循環参照の回収を実行
$collected = gc_collect_cycles();
if ($collected > 0) {
// ログに回収数を記録し、メモリの肥大化をモニタリングする
error_log(“[GC] Collected {$collected} cyclic references in worker.”);
}
}
}
}
—
5. セキュリティ的観点：共有メモリ領域におけるオブジェクトインジェクションの脅威
常駐型ランタイムにおけるメモリ共有（Swoole Table、Redis、Shared Memory Segment等）を設計する際、最大のセキュリティリスクとなるのが「シリアライズされたデータのデシリアライズ時におけるPHPオブジェクトインジェクション（PHP Object Injection）」である。
もし攻撃者が、外部から入力可能なパラメータ（HTTPリクエストボディやWebSocketメッセージなど）を通じて、不適切にシリアライズされたデータを共有メモリ領域やキャッシュに注入（Injection）できた場合どうなるか？
ガジェットチェーン（Gadget Chain）の爆発
1. 攻撃者は、デシリアライズ時に自動実行されるマジックメソッド（`__wakeup()` や `__destruct()`）を持つ既存クラス（Gadget）を利用して、不正なオブジェクト構造を構築する。
2. そのペイロードがSwooleの共有メモリやワーカー間で共有されるデータストアに格納される。
3. 別個のリクエスト、あるいはバックグラウンドタスク（Swoole Task Worker）がそのデータをデシリアライズした瞬間、Zend VM上で任意のコード実行（RCE）のガジェットチェーンが発火する。
防御策：セキュアな直列化フォーマットの強制
オブジェクトのポインタやクラス構造をそのまま保持する `serialize()` / `unserialize()` を、常駐型ランタイムの共有領域で扱うことはセキュリティ上の重大な脆弱性に直結する。
$userObject->getId(),
‘roles’ => $userObject->getRoles(),
], JSON_THROW_ON_ERROR);
// 共有メモリやタスクキューへ渡す際は常にこの形を維持する
—
結びにかえて
SwooleやRoadRunnerを用いたハイパフォーマンス・アーキテクチャの構築は、PHPを真の「エンタープライズ・コンカレント・ランタイム」へと昇華させる。しかしそれは同時に、プログラマがこれまでZend Engineに無意識に委ねてきた「メモリ管理の安全網」を取り払うことを意味する。
`zval` のライフサイクル、参照カウントの増減、GCと共有メモリの競合、そしてプロセス境界を越えるデータ授受のルール。これらを完全に見切り、Zend VMの内部挙動を脳内で完全にトレースできる者だけが、真に堅牢で秒間数万リクエストを捌くWebシステムを架构（アーキテクト）することができる。妥協なきコードと低レイヤへの深い理解こそが、エンジニアの武器である。