こんにちは。PHPの裏側で動いているZendエンジンや、常駐型の非同期サーバーにロマンを感じる素敵な開発者のみなさん。
普段、LaravelやSymfonyといったモダンなフレームワークで美しいコードを書いていると、「1リクエストごとにメモリが綺麗に解放される」というPHP伝統の安全ネットについ甘えてしまいがちですよね。
でも、SwooleやRoadRunner、ReactPHPといった「常駐型（Long-running）プロセス」の世界に足を踏み入れた途端、その前提は音を立てて崩れ去ります。リクエストが終わってもプロセスが死なない。つまり、メモリがリセットされないのです。
今回は、この常駐型環境において最も恐ろしい魔物である「グローバル変数汚染とメモリリークの連鎖」について、Zendエンジンのメモリ管理の仕組みまでグッと踏み込んで、一緒に紐解いていきシンフォニーを奏でていきましょう。ここを理解すれば、PHPの裏側が驚くほどクリアに見えますよ。
—
1. なぜ「常駐型PHP」ではメモリリークが起きるのか？
まず、従来のNginx + PHP-FPMのアーキテクチャを思い出してください。PHP-FPMは、1つのHTTPリクエストを受け取ると、OSのプロセスをフォーク（またはプールからアサイン）し、スクリプトを上から順に解釈・実行します。そして、レスポンスを返した瞬間にプロセスごと終了し、OSへメモリが全返却されます。極端な話、多少のメモリリークがあっても、リクエスト単位の短命な命だから実害が出にくかったわけです。
しかし、SwooleやRoadRunnerの世界は違います。
[Master Process]
├── [Worker Process 1] ── (起動し続け、数百万のリクエストをここで処理し続ける)
├── [Worker Process 2] ── (起動し続け、数百万のリクエストをここで処理し続ける)
└── [Worker Process 3] ── (起動し続け、数百万のリクエストをここで処理し続ける)
Workerプロセスは一度起動するとメモリ上に常駐し、ループを回しながら次々とやってくるリクエストをさばき続けます。
ここで何が起きるか？ PHPのスクリプト内で定義した「グローバルな状態（`static`変数、グローバル変数、シングルトンインスタンス、プロセスのメモリ上に保持されたキャッシュ等）」は、リクエストを跨いで生存し続けます。
ここに、意図しないデータの蓄積（グローバル変数汚染）と、GC（ガベージコレクション）が回収しきれない参照の鎖が組み合わさると、徐々にWorkerのメモリ消費量が跳ね上がり、最終的にOOM (Out of Memory) Killerにプロセスを惨殺されるという悲劇が起きるのです。
—
2. 内部構造で見る：Zendエンジンとメモリ管理の罠
PHPの根幹であるZendエンジンは、変数を管理するためにHashTableというデータ構造を多用しています。そして、すべての変数は「参照カウント（Reference Counting）」という仕組みで管理されています。
変数が別の変数に代入されたり、関数に渡されたりすると、その変数のzval（Zend Value）構造体が持つ参照カウンターが「+1」されます。スコープを抜けると「-1」され、カウンターが「0」になった瞬間にメモリから抹殺されます。
しかし、常駐型プロセスにおいて「グローバルスコープ」や「static領域」に置かれたデータは、プロセスが生存している限りルートスコープからの参照が切れません。
危険なコードパターン：静的プロパティへの蓄積
例えば、次のような「リクエストごとのログやコンテキストを保持しようとした」サービスクラスがあったとします。
リクエストAが来て、`RequestContext::set(‘user_id’, 123)` が呼ばれる。`self::$context` にデータが入る。
2. リクエストAが終わり、レスポンスを返す。しかしWorkerプロセスは生きているため、`self::$context` は消えない。
3. リクエストB（別のユーザー）が来る。認証ミドルウェアを通るのを忘れ、そのまま `RequestContext::all()` を呼んでしまうと……なんとリクエストAのユーザー情報が丸見えになる（グローバル変数汚染によるセキュリティインシデント）。
4. さらに、リクエストごとに新しいオブジェクトや大きな配列をこの配列にプッシュし続けると、参照カウントが減らないため、GCの対象外となり、確実にメモリリークが連鎖していきます。
—
3. 循環参照の悪夢：GCとメモリリークの本当の怖さ
Zendエンジンには、参照カウント方式の弱点である「循環参照（Circular Reference）」を解決するために、別個のガベージコレクタ（GC）が備わっています。
配列やオブジェクトが自分自身や互いを参照し合い、外部からの参照がなくなったとき、参照カウントは「0」になりません（お互いを指し合っているため、最小でも「1」のまま残ります）。ZendエンジンのGCは、この「怪しいルートバッファ」に溜まった循環参照を定期的にスキャンして回収します。
しかし、「グローバル変数や静的プロパティからぶら下がっている循環参照」は、外部からのルート参照が絶たれていません。 そのため、GCは「これはまだアクティブなデータに違いない」と判断し、一切回収してくれません。
メモリリークが連鎖する瞬間
常駐環境で、フレームワークのDIコンテナやロガー、データベースのコネクションなどが、グローバルなステート（状態）を持つオブジェクトを保持し続け、その中でクロージャや循環参照を含む巨大なオブジェクトグラフを構築してしまった場合……。
data = range(1, 10000000); // 膨大な配列
このコードがリクエストごとに実行されるとどうなるか？
`$container->data` は上書きされますが、もし古いデータが別の場所（クロージャのスコープや例外オブジェクトなど）から参照され続けていたら、メモリ上から永遠に消えません。これが「メモリリークの連鎖」です。数時間稼働させただけで、サーバーのメモリが数GBへと膨れ上がり、スワップアウトを起こしてシステム全体が沈黙します。
—
4. 極限の世界を生き抜くための実践的対策
では、この常駐型環境の魔物から身を守るには、どうすればよいのでしょうか。
私たちがコードを書く上で守るべき鉄則は、大きく分けて3つあります。
対策1: 「ステートレス（StatefulからStatelessへ）」の徹底
クラスのプロパティに「リクエストごとに変わる状態（ユーザー情報、入力値、クエリ結果など）」を持たせるのを一切やめましょう。データは必ずメソッドの引数やローカル変数として完結させ、スコープの終了とともに自然消滅するように設計します。
対策2: リクエスト終了時の明示的なクリーンアップ（Deinitialize）
どうしても常駐キャッシュやプール機構を使いたい場合は、Swooleの `onWorkerStart` で初期化したリソースや、フレームワークが提供する「リクエスト終了フック（Middlewareの終端や `Terminate` イベント）」を利用して、グローバル配列や静的プロパティを必ず初期化（`null`代入や `unset`）する習慣をつけてください。
対策3: フレームワーク固有のプール・常駐化機構を正しく理解する
Swooleベースのフレームワーク（Laravel Octane, Hyperf, Swoftなど）を使用する場合、フレームワーク側が用意している「スニペット（Hot ReloadやWorkerのリロード設定）」や「マニュアルの注意書き」には必ず目を通してください。
「どのサービスがシングルトンとしてメモリに常駐し、どのサービスがリクエストごとにスコープがリフレッシュされるのか」を把握することが、アーキテクトとしての最初の仕事です。
—
おわりに
PHPは、本来「リクエストごとにすべてを忘れる」という圧倒的な気楽さを持った言語でした。そのパラダイムから、SwooleやRoadRunnerによる「すべてを記憶し続ける」高パフォーマンス・非同期の世界へシフトするとき、私たちはメモリ管理のプリミティブな意識を呼び起こす必要があります。
「この変数は、どこから参照されていて、いつスコープが切れるのか？」
コードを書くときに、頭の中でZendエンジンのメモリ空間（HashTableと参照カウント）をスッとトレースできるようになれば、あなたはもうPHPの低レイヤを掌握した真のシニア・アーキテクトです。
メモリリークの恐怖に怯える必要はありません。裏側の仕組みさえ見えていれば、どんな常駐環境だって、美しく、極限まで高速にコントロールできるようになりますよ。
それでは、また次回の深淵なるPHPの世界でお会いしましょう。