こんにちは。普段はPHPのエンジン内部、Zend VMの挙動やメモリ管理と日々向き合っているアーキテクトです。
他の言語、例えばNode.jsやGo、あるいはJavaなどの経験があるエンジニアの多くが、SwooleやRoadRunnerといった「プロセス常駐型（非同期・マルチプロセス）PHP」の世界に踏み込んだとき、ある壁にぶつかります。
「あれ、リクエストを重ねるごとにメモリ使用量が右肩上がりに増えていくぞ……？」
そう、PHP-FPMの伝統的な「1リクエスト＝完全なプロセス破棄（シェアード・ナッシング）」の思想に毒されたコードは、常駐環境という永続世界の前に、いとも簡単にお漏らしを起こしてしまいます。
今回は、Swoole常駐環境下におけるグローバル変数や静的変数（`static`）が、Zend Engineのメモリ空間でどのように扱われ、なぜ「変数汚染」や「メモリリーク」を引き起こすのか。その低レイヤの仕組みと、私たちがとるべき静的解析の極意を、一緒に紐解いていきましょう。
ここを理解すれば、PHPの裏側が驚くほど綺麗に見えるようになりますよ。
—
1. PHP-FPMという「甘え」と、常駐プロセスの現実
私たちが長年慣れ親しんできたPHP-FPMの仕組みを思い出してください。
クライアントからHTTPリクエストが飛んでくると、Nginxから渡されたリクエストを処理するためにPHP-FPMの子プロセスが起動します。スクリプトが実行され、データベースに接続し、レスポンスを返した瞬間、プロセスは生存していますが、Zend Engineのヒープメモリ空間はきれいにリセット（あるいはプロセスごと解放）されます。
そのため、極端な話、次のようなコードを書いたとしても、FPM環境であれば次のリクエストには何の影響も残りませんでした。
// FPM環境では「その場限りの汚染」で済んでいた
function do_something() {
static $cache = [];
$cache[] = 1; // 汚染されてもプロセス終了時に消える
}
しかし、Swooleに代表される常駐環境では話が180度変わります。
SwooleのWorkerプロセスは、一度起動したら数万、数百万のリクエストを同じプロセス、同じメモリ空間上で処理し続けます。
つまり、スクリプト内で定義されたグローバル変数や、クラスの静的プロパティ（`public static $instance`）、関数内の静的変数（`static`）は、リクエストを跨いでメモリ上に半永久的に居座り続けることになるのです。これが「常駐環境におけるメモリリークと変数汚染」の正体です。
—
2. Zend VMの視点：静的変数はどこに生きているのか？
では、PHPのエンジン内部（Zend VM）では、静的変数はどのように管理されているのでしょうか？
PHPのソースコード中における静的変数は、コンパイル時に生成されるオペコード（Opcodes）のなかで、対応する関数やメソッドの構造体（`zend_function`）のなかに専用の領域、あるいはシンボルテーブル（`HashTable`）として紐づけられます。
FPMであればリクエスト終了とともにプロセスごと破棄されるため、この `HashTable` の寿命を気にする必要はありませんでした。しかし、SwooleのWorkerプロセス上では、最初のブートストラップ（あるいは最初のリクエスト）で初期化された `HashTable` が、プロセスが生存している限りずっとメモリ（Zend Memory Manager）のヒープ上にアロケートされ続けます。
ここに、ユーザーAのリクエストで取得した機密情報や肥大化した配列が格納されたとしましょう。もしリクエストごとにその配列をクリアする処理（リセット処理）を書き忘れたら……？ 次にやってきたユーザーBのリクエストが、その配列にアクセスできてしまうという深刻なセキュリティインシデント（変数汚染）すら引き起こします。
—
3. 実践：やってはいけないアンチパターンと、その対策
言葉だけではピンとこないかもしれないので、実際のコードで見てみましょう。Swoole環境で絶対にやってはいけない典型的な実装と、それをどうリファクタリングすべきかの例です。
❌ 危険な実装：静的変数やグローバルな状態保持
fetchFromDatabase($id);
// リクエストを跨いでキャッシュが蓄積され続け、
// 最終的にメモリが枯渇する（かつ別リクエストへデータが漏洩するリスク）
self::$identityMap[$id] = $user;
return $user;
}
}
このコードの問題点は、`$identityMap` がリクエストごとに解放されない点です。数万アクセスを処理するうちに、`$identityMap` の `HashTable` は巨大化し、OOM（Out of Memory）エラーでWorkerプロセスがクラッシュします。
⭕ 模範的な実装：コンテキストの分離とリクエストスコープの明文化
常駐環境で正しく状態を管理するための鉄則は、「状態をリクエストのライフサイクルに閉じ込める（Context Isolation）」ことです。Swooleには `Swoole\Coroutine\Context` という強力なコルーチンごとのストレージが用意されています。これを利用して、リクエスト（コルーチン）単位で変数の寿命を完全に制御しましょう。
fetchFromDatabase($id);
// データはこのリクエスト（コルーチン）の寿命と完全に同期する
// コルーチンが終了すれば、このデータが格納されたメモリは自動的に解放される
$context[‘identity_map’][$id] = $user;
return $user;
}
}
このように、グローバルな静的プロパティへの依存を断ち切り、コルーチンコンテキストや、DIコンテナのリクエストスコープ（DIのインスタンスをリクエストごとに生成する仕組み）に載せ替えることで、メモリリークと変数汚染を根絶することができます。
—
4. 静的解析で「うっかりミス」を完全包囲する
とはいえ、人間は忘れる生き物です。巨大なレガシーコードベースをSwoole対応させる際、すべての静的変数やグローバル変数を目視でチェックするのは不可能です。
ここで、私たちの武器となるのが静的解析（Static Analysis）です。
PHPStanやPsalmを駆使し、常駐環境における「禁忌」をCI/CDのパイプラインで自動検知させましょう。
PHPStanを活用したカスタムルールの思想
標準のPHPStanでも `disallowed-static-property` などのextensionを組み合わせることで、特定のクラス以外での静的プロパティの変更を厳しく制限できます。
さらに踏み込むなら、次のようなルールを意識して静的解析を設定します。
1. サービスクラス内での `static` キーワード（静的変数・静的プロパティ）の全面禁止
- 状態を持つステートフルな設計を強制的に排除し、サービス層は原則として「ステートレス（純粋関数的）」に保つ。
2. グローバルスコープにおける `$_GET`, `$_POST`, `$_SERVER` などの直接参照の禁止
- Swoole環境ではこれらはリクエストオブジェクト（`Swoole\Http\Request`）から安全に取得・カプセル化されるべきであり、グローバル変数への直接アクセスは変数汚染の温床になります。
—
アーキテクトからのエール
Swooleやコンテナ常駐型のPHPの世界は、従来の「PHPはリクエストごとにすべてを忘れてくれる優しい言語」という前提を覆します。しかし、それはPHPが「真のモダンWebアプリケーションサーバー」として、GoやJava、Node.jsに匹敵する圧倒的なパフォーマンスを手に入れた裏返しでもあります。
Zend Engineがメモリをどう抱え、どこで解放すべきか。そのライフサイクルを頭の中で美しくイメージできるようになれば、あなたはもう「なんとなく動かしているエンジニア」ではありません。PHPの低レイヤを掌の上で操る、真のアーキテクトです。
次回の記事では、このメモリ管理と深く関わる「コルーチン間のコンテキストリークとチャネルの正しい調停術」についてさらに深く掘り下げていきたいと思います。
あなたのコードが、今日もクリーンで高速なメモリ上にありますように。