こんにちは。SwooleやRoadRunnerといった常駐型プロセス（Persistent Application Server）を用いたモダンなPHP開発の世界へようこそ。
JavaやGo、Node.jsといった他の高水準言語の経験がある方なら、「リクエストごとにプロセスやスレッドが破棄されない環境で、どうやってメモリリークやステートの汚染を防ぐのか」という課題に直面したことがあるはずです。従来のPHP-FPMであれば、1リクエストの終了とともにZend Engineのプロセス全体がOSに回収され、すべてのメモリ（HashTable）はきれいさっぱり消え去っていました。しかし、常駐型アプリケーションではそうはいきません。
今回は、SwooleやRoadRunner環境におけるリクエスト間メモリ分離のメカニズムと、それを制御するためのカスタムメモリマネージャー・サンドボックス化の極意について、PHPの内部構造（Zend VM）の視点を交えながら紐解いていきましょう。ここを理解すれば、PHPの裏側がとても綺麗に見えるようになりますよ。
—
1. 伝統的PHP-FPMと常駐型環境（Swoole/RoadRunner）のメモリモデルの差
まず、PHPの実行基盤であるZend Engineがメモリをどのように管理しているかを整理しておきましょう。
PHPの変数やオブジェクトは、内部で `zval`（Zend Value）という構造体として表現され、Zend Memory Manager（ZMM）によって効率的にアロケーションされます。PHP-FPMでは、このZMMのライフサイクルは完全に1リクエストと同期していました。
[PHP-FPMのリクエストライフサイクル]
HTTPリクエスト到着 -> ractorプロセス起動 -> Zend Engine初期化 -> スクリプト実行 (メモリ割当) -> レスポンス送信 -> プロセス終了 (全メモリ一括解放)
このモデルでは、開発者がメモリリーク（循環参照の切り離し忘れなど）を多少起こしたとしても、リクエスト終了時にOSレベルでページごと回収されるため、実害は表面化しにくかったのです。
しかし、SwooleやRoadRunnerのような常駐型ランタイムでは、マスタープロセス（またはWorkerプロセス）がメモリ上に常駐し続け、次々とやってくるリクエストに対してPHPスクリプト（コールバックやハンドラー）を繰り返し実行します。
[常駐型ワーカーのライフサイクル]
Worker起動 (ブートストラップ)
├── リクエスト1 ──> スクリプト実行 ──> レスポンス (メモリ解放漏れが累積！)
├── リクエスト2 ──> スクリプト実行 ──> レスポンス (メモリリーク拡大)
└── リクエストN ──> … 💥 Out of Memory (OOM)
ここで問題になるのが、「グローバルスコープや静的プロパティ（`static`）、あるいはサービスコンテナに保持されたステートが、次のリクエストへ持ち越されてしまう（クロスリクエスト汚染）」という現象と、「微細なメモリリークの蓄積によるOOM（Out of Memory）死」です。
—
2. リクエスト間分離を実現するアプローチ：サンドボックス化
常駐型環境で安全にPHPを動かすための王道アプローチは、「ワーカーのメインコンテキストと、個別のリクエストコンテキストを完全に分離し、リクエスト終了時に特定のメモリ空間を一括破棄するサンドボックス構造」を作る事です。
これを素朴に実装しようとすると、リクエストごとに `unset()` やデストラクタを地道に呼ぶことになりますが、人間に完璧なメモリ管理を期待するのは無理というものです。そこで、カスタムメモリマネージャー的な発想を取り入れ、「リクエストスコープで生成されたオブジェクトの参照をすべてトラッキングし、リクエスト終了時に一網打尽にするコンテナ（サンドボックス）」を設計します。
実践的なサンドボックス・メモリマネージャーの実装例
以下のコードは、SwooleやRoadRunnerのWorker内で動作する、リクエストスコープ特化型のメモリ・サンドボックスの概念実装です。
/
class RequestSandbox
{
/ @var array リクエスト内で生成された管理対象オブジェクトのリスト /
private array $scopedObjects = [];
/ @var WeakMap 循環参照を安全に検知・追跡するためのマップ /
private WeakMap $tracker;
public function __construct()
{
// WeakMapを使うことで、サンドボックス自体がオブジェクトへの強い参照を持たず、
// 意図しないメモリリークの発生源になるのを防ぎます
$this->tracker = new WeakMap();
}
/
- リクエストスコープ内でオブジェクトを安全に生成・登録する
- @template T of object
- @param class-string
$className - @param array $args
- @return T
/
public function make(string $className, array $args = []): object
{
$object = new $className(…$args);
// 管理リストとトラッカーに登録
$this->scopedObjects[] = $object;
$this->tracker[$object] = true;
return $object;
}
/
- リクエストの終了時に呼び出し、このスコープで確保されたリソースを完全に清掃する
/
public function destroy(): void
{
// 1. 登録されたオブジェクトの参照を逆順（依存関係の末端から）に切断
while (!empty($this->scopedObjects)) {
$object = array_pop($this->scopedObjects);
// オブジェクトが保持しているプロパティを強制的に初期化・解除
$this->purgeObjectProperties($object);
unset($object);
}
// 2. WeakMapのクリア
unset($this->tracker);
// 3. Zend Engineのガベージコレクタ（GC）を強制的に発火させ、循環参照のCyclesバッファを回収
if (gc_enabled()) {
gc_collect_cycles();
}
}
/
- オブジェクトのプロパティを再帰的に切り離し、参照カウントをゼロに近づける
/
private function purgeObjectProperties(object $object): void
{
$reflection = new \ReflectionClass($object);
foreach ($reflection->getProperties() as $property) {
// パブリック、プロテクテッド、プライベート問わず強制アクセス
$property->setAccessible(true);
if ($property->isInitialized($object)) {
// プロパティに格納されている値（zval）の参照を切断
$property->setValue($object, null);
}
}
}
}
—
3. 実際のアプリケーションフローへの組み込み（RoadRunner/Swooleの文脈）
では、このサンドボックスマネージャーを実際の常駐型サーバーのイベントループ（またはリクエストハンドラ）にどう組み込むべきでしょうか。
RoadRunnerやSwooleでは、次のようなPSR-15ミドルウェア、あるいはイベントディスパッチのライフサイクルパターンを利用して、リクエストの「入口」でサンドボックスを生成し、「出口」で確実に破棄（`destroy()`）します。
handle($request);
return $response;
} catch (Throwable $e) {
// 例外発生時も確実にメモリを掃除する必要がある
throw $e;
} finally {
// 【最重要】例外の有無に関わらず、リクエスト終了時に必ずメモリ空間を破棄
$this->sandbox->destroy();
}
}
}
このように、`try…finally` 構文の `finally` ブロックを厳格に利用することで、アプリケーションコード内で予期せぬ例外や致命的なエラーが発生した場合でも、ワーカープロセスが汚染されたまま次のリクエストを受け付ける最悪の事態を防ぐことができます。
—
4. 低レイヤ視点：Zend VMの参照カウントとGCの限界を知る
PHPのガベージコレクションは、基本的には「参照カウント法（Reference Counting）」をベースにしています。変数やオブジェクトが別の変数に代入されたり、オブジェクトのプロパティに格納されるたびに、内部の `zval` の参照カウンター（`refcount`）がインクリメントされ、スコープを抜けるなどして不要になるとデクリメントされます。
しかし、参照カウント法には致命的な弱点があります。それが「循環参照（Circular Reference）」です。
[オブジェクトA] ──(プロパティ)──> [オブジェクトB]
↑ │
└──────────(プロパティ)──────────┘
上記のように、オブジェクトAとBがお互いを参照し合っている場合、それぞれの `refcount` は外部からの参照がすべて切れた後も `1` が残ってしまいます。これがいわゆる「メモリリーク」の原因となり、常駐型アプリケーションでは致命傷になります。
PHPの標準GC（コンカレント・サイクル・コレクション）は、`refcount` が減ったもののゼロにならなかった `zval` を「ルートバッファ（Roots Buffer）」に溜め込み、バッファがいっぱいになったタイミング（または明示的に `gc_collect_cycles()` が呼ばれたタイミング）で、グラフ探索を行って孤立した循環参照を見つけ出し、解放します。
高速化のためのアーキテクトの知見
常駐型環境において、無計画なオブジェクト生成と破棄を繰り返すと、Zend EngineのGCが頻繁に走るか、あるいはルートバッファが溢れてパフォーマンス（スループット）が低下します。
それを防ぐための極意は以下の2点です：
1. ステートレスな設計を徹底する
ビジネスロジックを持つサービス層やユースケース層のオブジェクトは極力「ステートレス（インスタンス変数を保持しない）」にし、DIコンテナのシングルトンとしてメモリ上に常駐させます。これにより、リクエストごとにオブジェクトを生成・破棄するオーバーヘッドをゼロにできます。
2. 可変ステート（DTOやORMエンティティなど）のみをサンドボックスで厳格管理する
リクエスト特有のデータやEloquent/DoctrineなどのORMエンティティといった「重いステート」だけを先ほどの `RequestSandbox` の管理下に置き、リクエスト終了とともに一括してプロパティを断ち切る設計を採用します。
—
まとめ
SwooleやRoadRunnerを用いたモダンなPHP開発は、従来のPHP-FPMの「甘え（リクエスト終了時の全自動クリーンアップ）」を捨て、真の意味でメモリとプロセスのライフサイクルをエンジニアが掌握することが求められます。
しかし、それは裏を返せば、「PHPでありながらNode.jsやGoに匹敵する圧倒的な低レイテンシと高スループットを手に入れた」ということです。
Zend Engineのメモリモデル（`zval`、参照カウント、GCの挙動）を正しくイメージし、リクエスト間の境界線をコードで美しく引くこと。この技術をマスターすれば、あなたの書くPHPアプリケーションは、どんな高負荷なトラフィック環境でもビクともしない、極めて堅牢で美しいシステムへと生まれ変わります。
ぜひ、次のアーキテクチャ設計の現場でこの知見を活かしてみてください。