Swoole/RoadRunner時代におけるPHPメモリ管理の極意：Zend VMの暗部を暴く永続プロセス・クリーンアップ戦略
PHPは「1リクエストごとにプロセスが全消滅する」という甘美な前提のもとに設計された言語であった。SAPI（Server Application Programming Interface）がリクエストを受け取り、Zend Engineが起動し、`zend_execute_scripts`でスクリプトを走らせ、レスポンスを返した瞬間に`request_startup`の逆順で全てのメモリ空間がOSへ返還される——この「使い捨て」の哲学が、PHPを最も安全で、かつメモリリークに対して無頓着でいられる言語たらしめてきた。
だが、時代は変わった。Swoole、RoadRunner、そしてFrankenPHPといった常駐型（Long-running）アプリケーションサーバーの普及により、PHPは「リクエスト単位の死」を奪われた。Zend VMは同じプロセス空間のまま何万、何百万というリクエストを処理し続ける。
ここで発生するのが、「メモリの汚染」と「状態の持ち越し」という、伝統的なPHPプログラマにとって未知の悪夢である。今回は、Zend VMの内部構造（HashTable、参照カウント、GC）から切り込み、永続プロセス環境下における真のメモリ分離とクリーンアップの極意を、低レイヤの視点から解き明かす。
—
1. Zend VMのメモリ空間と永続プロセスの本質
PHPの変数は、C言語レベルの構造体 `zval`（Zend Value）としてヒープ上に確保される。そして配列やオブジェクトのプロパティは、PHP内部の連想配列実装である `HashTable` によって管理されている。
従来のFPM環境では、リクエストが終了するとZend Engineは割り当てたヒープ領域（正確にはZend Memory Manager: Zend MM）を丸ごとOS（あるいはプール）に返却していたため、多少のメモリリークがあってもプロセス寿命が短ければ実害は少なかった。
しかし、SwooleやRoadRunnerのワーカプロセス内では、一度ロードされたクラス定義、関数、そしてグローバルスコープ（あるいはそれに類する永続領域）のデータは、リクエストを跨いで生存し続ける。
リクエスト境界を超えて汚染される領域
1. 静的プロパティ（Static Properties）: クラスに紐づく静的変数は、プロセスが生存している限りメモリ上に居座る。
2. シングルトンインスタンス: コンテナやファクトリーパターンで静的に保持されたオブジェクト。
3. OPcacheプリローディング（Preloading）の領域: 共有メモリ（SHM）上に配置されるが、書き込み可能な構造体が含まれている場合の挙動には細心の注意が必要である。
ここに不適切な状態（例えば、あるユーザーの認証情報や、特定のテナントの設定値）が残留した場合、次のリクエストで全く別のユーザーにそれが露呈する。これは単なるバグではなく、極めて深刻なセキュリティインシデント（データ漏洩・セッションハイジャック）に直結する。
—
2. 参照カウントとガベージコレクション（GC）の限界
PHPのメモリ管理は、基本的には `zval` の `refcount`（参照カウント）に基づく決定論的な解放によって行われている。しかし、配列やオブジェクトが自身を参照し合う「循環参照（Circular Reference）」が発生した場合、参照カウントが0にならないため、通常の解放処理ではリークする。
ここでPHPのガベージコレクション（GCバッファ）が動くわけだが、永続プロセス環境においては、このGCの挙動すらもチューニングの対象となる。
child = $b;
$b->child = $a;
// $a と $b のスコープを外す（参照カウントは2のまま残る）
unset($a, $b);
// ここでGCが走るか、バッファが溢れるまでメモリは解放されない
gc_collect_cycles();
Swooleのコルーチン環境下やRoadRunnerのハンドラー内において、このような循環参照を含む複雑なオブジェクトグラフをリクエストごとに生成・破棄し続けると、GCの走査コスト（Mark-SweepフェーズのCPU負荷）が増大し、ワーカーのレイテンシがジリジリと悪化していく。
—
3. Swoole/RoadRunner環境におけるクリーンアップ戦略の設計
常駐型環境でメモリリークを防ぎ、リクエスト間の完全なアイソレーション（分離）を担保するためには、以下の3層の防衛線を構築しなければならない。
防衛線A: DIコンテナとサービスシングルトンのスコープ管理
フレームワーク（Laminas, Symfony, Laravel等）をSwoole上で動かす場合最大の罠が、「リクエストスコープ」と「シングルトン」の混同である。
従来はリクエストごとにインスタンス化されていたサービスクラスが、永続環境ではシングルトンとして振る舞い、内部にリクエスト固有の状態（リクエストオブジェクト、ユーザーモデルなど）を保持してしまうケースが後を絶たない。
対策:
サービスは完全に「ステートレス（状態を持たない）」に設計し、状態を持つ必要のあるデータは、必ずリクエストスコープのコンテナから取得し、リクエスト終了時に明示的に破棄する。
防衛線B: `defer` による確実な後始末（Swoole/OpenSwooleの活用）
Swooleのコルーチン環境では、リクエストのライフサイクルやコルーチンの終了時に処理をフックできる `defer` が強力な武器となる。
12345]);
// defer を使って、コルーチン終了時（リクエスト処理終了時）に確実にクリーンアップを実行
Coroutine::defer(function () {
RequestContext::clear();
// データベース接続の返却や、ローカルキャッシュのフラッシュ
EntityManagerRegistry::clear();
});
// — ここでビジネスロジックを実行 —
// 万が一例外がスローされても、deferは確実に実行される
});
});
防衛線C: メモリ使用量の監視とプロセスのリサイクル（Max Requests）
どれほどクリーンアップを慎重に行っても、サードパーティ製ライブラリの内部実装（C拡張モジュールや複雑な静的キャッシュ等）に起因する微細なメモリリーク（Zend MM外のリークやアロケータのフラグメンテーション）を完全にゼロにすることは困難である。
そのため、プロセスの寿命を管理する「サーキットブレーカー」的なアプローチが実運用では不可欠となる。
- RoadRunner: `worker.max_jobs` を設定し、一定数のリクエストを処理したらプロセスを安全に再起動（Graceful Restart）させる。
- Swoole: `max_request` 設定を入れ、ワーカプロセスがN回のリクエストを処理したら自動的にリロードする仕組みを必ず有効にする。
; RoadRunner (rr.yaml) の例
http:
pool:
num_workers: 8
max_jobs: 1000 # 1000リクエストごとにプロセスを安全にリサイクルし、メモリリークを根絶する
—
4. ガジェットチェーン（オブジェクトインジェクション）との交差点
メモリ管理の不備と永続プロセスの組み合わせは、セキュリティ面において致命的な脆弱性を生むことがある。それが PHPオブジェクトインジェクション（PHP Object Injection） との相乗効果である。
従来のFPM環境では、`unserialize()` に汚染された入力を渡してガジェットチェーン（Gadget Chain）を発動させ、RCE（リモートコード実行）に至ったとしても、その影響範囲は基本的に「そのリクエストのプロセス内」で完結し、プロセスが死ねば初期状態に戻った。
しかし、Swoole/RoadRunner環境においてオブジェクトインジェクションが成功した場合、攻撃者は永続プロセス内のメモリ空間を完全に掌握するリスクを負う。
静的プロパティやグローバルな状態管理機構に悪意あるオブジェクトを定着させられれば、単発のRCEにとどまらず、次以降にアクセスしてくる無関係なユーザーのリクエストをも巻き込んだ、永続的なバックドアやメモリ上のデータ改ざん基盤を構築されかねない。
したがって、永続プロセス環境における `unserialize()` の使用は、事実上の「アンチパターン」であり、JSONなどの安全なシリアライゼーションフォーマットへの置き換え、あるいは厳密なHMAC署名検証が必須となる。
—
5. チーフアーキテクトからの提言：クリーンアップのコード実装パターン
最後に、Swoole等の永続環境において、リクエストごとのメモリ汚染を完全に防ぐためのミドルウェアレベルのクリーンアップ実装例を示す。
handle($request);
return $response;
} finally {
// 3. 確実なクリーンアップ（例外スロー時も必ず実行）
// 静的コンテナやレジストリに残ったリクエスト固有データを破棄
\App\Support\Registry::resetRequestScope();
// データベースのトランザクションが残っていればロールバックしてコネクションをクリーンに
\App\Database\ConnectionManager::releaseConnections();
// 明示的に不要な大容量変数をunset
unset($request, $response);
}
}
}
結び
PHPは進化し、かつての「リクエスト毎のスクリプト言語」から、高スループットな「非同期・常駐型アプリケーションプラットフォーム」へと脱皮を遂げた。しかし、エンジニアがZend VMのメモリモデル、参照カウント、そしてスコープの寿命に対するリスペクトを欠いた瞬間、その高速性の代償として、メモリリークやセキュリティホールという牙を剥く。
低レイヤの構造を脳内に焼き付け、リクエストの境界線をコードによって厳格に引き直すこと。それこそが、Swoole/RoadRunner時代を制する最高峰のアーキテクチャである。