こんにちは。PHPの裏側を覗く旅へようこそ。
普段、私たちはLaravelやSymfonyといったモダンなフレームワークを使い、洗練されたコードを書くことで、素晴らしいWebアプリケーションを素早く構築できていますよね。そこでは「リクエストが来たらインスタンスが生まれ、レスポンスを返せばすべてが消え去る」という、ある種の「使い捨ての美学」がプログラミングの前提になっています。
しかし、SwooleやRoadRunnerといった常駐型プロセス（Persistent Process）の世界に足を踏み入れた途端、その前提は音を立てて崩れ去ります。従来のPHP-FPMがやってくれていた「リクエストごとのプロセス初期化と完全なメモリ解放」という安全網が取り払われ、PHPという言語が本来持っている「実行エンジンとしてのメモリ管理の姿」が剥き出しになるからです。
今回は、常駐型環境におけるグローバル変数や静的変数の汚染問題の本質を、Zendエンジン内部のメモリ構造と照らし合わせながら解き明かしていきましょう。ここを理解すれば、PHPの裏側が綺麗に見え、どんな高負荷な非同期・常駐環境でも恐れることはなくなりますよ。
—
1. 伝統的なPHP-FPMの「甘え」と、常駐型環境の現実
まずは、私たちが長年慣れ親しんできたPHP-FPMの挙動を、Zendエンジンの視点から少しだけ振り返ってみましょう。
PHP-FPMモデルでは、1つのHTTPリクエストが来ると、OSプロセス（またはスレッド）がクローン、あるいは再利用され、`request startup` から `request shutdown` までのライフサイクルが完全にそのリクエスト単位で完結します。
スクリプト内でどれだけ巨大な配列を作ろうが、どれだけグローバル汚染をしようが、リクエストが終了してSAPI（Server Application Programming Interface）層が `php_request_shutdown()` を呼び出した瞬間、プロセスが保持していたZendメモリマネージャー（ZendMM）のヒープ領域は綺麗さっぱりOSへと返還されます。言い換えれば、私たちは「メモリリークや汚染を気にしなくてよいサンドボックス」に守られていたわけです。
しかし、SwooleやRoadRunnerに代表される常駐型PHPランタイムでは、マスタープロセス（あるいはworkerプロセス）がメモリ上に一度読み込んだスクリプトやオブジェクトを保持し続け、何千、何万というリクエストを同じプロセスで処理し続けます。
[常駐ワーカープロセス起動]
└─ クラス定義・定数・静的プロパティのロード（OPcache & グローバル空間）
├─ リクエストA処理 ──► 静的変数が汚染される！
├─ リクエストB処理 ──► 汚染された静的変数を読んでバグ発生！
└─ リクエストC処理 ──► メモリリークが蓄積し、やがてOOM Killerへ…
ここで何が起きるか。もしコードのどこかで「ユーザーごとのセッション情報」や「リクエスト固有の状態」をクラスの静的プロパティ（`public static $user;`）やグローバル変数に保持してしまうと、次にやってきた全く別のユーザーのリクエストが、前のユーザーの機密情報にアクセスできてしまうという、致命的なセキュリティインシデント（クロス・リクエスト・コンタミネーション）に直結します。
—
2. Zendエンジンのメモリ管理と「静的変数」の正体
では、なぜ静的変数やグローバル変数はリクエストを跨いで残ってしまうのでしょうか？ それは、Zendエンジンにおける変数のライフサイクルとシンボルテーブル（Symbol Table）の構造を知ることで明確になります。
PHPのスクリプト実行時、すべての関数やメソッド、そしてグローバルスコープにはシンボルテーブルという `HashTable` が割り当てられます。
関数内の `static $counter = 0;` のような静的変数は、一度評価されると、関数が属するオペコード配列（`zend_op_array`）のコンテキスト内、あるいは専用の永続的なヒープ領域に保持されます。つまり、リクエストが終了してシンボルテーブルの一部が破棄されても、グローバルなシンボルテーブルやクラスエントリ（`zend_class_entry`）に紐づく静的プロパティは、ワーカープロセスが生存している限り生き続けるのです。
これを防ぐための最も素朴なアプローチは、「リクエスト終了時に、自分で使った静적変数やグローバル変数を手動で初期化（null代入など）する」ことですが、人間は必ずミスをします。大規模なフレームワークやサードパーティ製ライブラリの隅々まで手動でクリーンアップするのは、実質的に不可能です。
だからこそ、「フレームワークやミドルウェア層で、リクエスト境界をまたぐ汚染源を自動的に検知・隔離・リセットする仕組み（カスタムメモリマネージャーとスコープ分離）」が必要になるのです。
—
3. 実装パターン：リクエスト分離とカスタムクリーンアップ戦略
ここからは、SwooleやRoadRunnerのような環境を想定し、リクエストごとのメモリ空間の論理的分離と、安全なクリーンアップを行うためのエンタープライズ向け実装パターンをコードベースで見ていきましょう。
今回は、リクエストごとに「状態を保持してよいスコープ」と「絶対にリセットすべきスコープ」を管理する、カスタムクリーンアップマネージャーの概念をPHPで表現します。
/
final class RequestContextManager
{
/ @var array
private array $registry = [];
/ @var array
private array $destructors = [];
private static ?self $instance = null;
private function __construct() {}
public static function getInstance(): self
{
if (self::$instance === null) {
self::$instance = new self();
}
return self::$instance;
}
/
- リクエストの開始時にコンテキストを初期化
/
public function initialize(): void
{
$this->registry = [];
$this->destructors = [];
}
/
- リクエスト固有のオブジェクトや変数を安全に登録
/
public function set(string $key, mixed $value): void
{
$this->registry[$key] = $value;
}
public function get(string $key): mixed
{
return $this->registry[$key] ?? null;
}
/
- クリーンアップが必要なリソース（コールバック）を登録
/
public function registerDestructor(callable $destructor): void
{
$this->destructors[] = $destructor;
}
/
- リクエスト終了時（onReceive / onRequest の最後）に必ず呼び出す
- これにより、次のリクエストへゴミを持ち越さない。
/
public function terminate(): void
{
// 登録されたデストラクタ（解放処理）を逆順に実行
while ($destructor = array_pop($this->destructors)) {
try {
$destructor();
} catch (\Throwable $e) {
// ログ出力などの例外処理
error_log(“Destructor error: ” . $e->getMessage());
}
}
// レジストリを完全に空にし、ZendのGCに回収を促す
$this->registry = [];
// 循環参照の強制回収（必要に応じて）
gc_collect_cycles();
}
}
ステートフルなサービスクラスでの静的汚染防止の具体例
では、このマネージャーを実際のビジネスロジック、例えば「リクエストごとにログインユーザーのコンテキストを保持するサービス」にどう組み込むかを見てみましょう。静的プロパティの代わりに、コンテキストマネージャー経由で状態を安全に隔離します。
/
final class AuthenticatedUserService
{
private RequestContextManager $contextManager;
public function __construct(RequestContextManager $contextManager)
{
$this->contextManager = $contextManager;
}
/
- 現在のユーザーを設定（静的変数やグローバル変数を使わない！）
/
public function setUser(UserDTO $user): void
{
$this->contextManager->set(‘current_user’, $user);
// 万が一、外部のシングルトンや静的プロパティに紐づけてしまった場合の保険として、
// デストラクタで明示的に参照を切る処理を登録する
$this->contextManager->registerDestructor(function () {
// ここでグローバルなキャッシュや静的プロパティの参照をクリアする
StaticCacheRegistry::clearUser();
});
}
public function getUser(): ?UserDTO
{
return $this->contextManager->get(‘current_user’);
}
}
常駐ワーカーのメインループ（Swoole/RoadRunnerのイメージ）
SwooleのHTTPサーバーやRoadRunnerのWorkerループを想像してください。実際の駆動部分は以下のようになります。各リクエストの入口で `initialize()` を呼び、例外が発生しようとも確実に `terminate()` でクリーンアップを行う「Try-Finally」の鉄則が、メモリ汚染とメモリリークを防ぎます。
on(“Request”, function (Request $request, Response $response) use ($contextManager) {
// 1. 【リクエスト開始】: メモリ空間のクリーンなコンテキストを構築
$contextManager->initialize();
try {
// 2. アプリケーションのルーティングと実行
$path = $request->server[‘request_uri’] ?? ‘/’;
if ($path === ‘/login’) {
// ログイン処理のシミュレーション
// AuthenticatedUserServiceを通じて安全に状態を管理
$response->end(“Logged in successfully.”);
return;
}
$response->end(“Hello from Persistent PHP World!”);
} catch (\Throwable $e) {
$response->status(500);
$response->end(“Internal Server Error: ” . $e->getMessage());
} finally {
// 3. 【リクエスト終了】: どんな例外やエラーがあっても確実に状態をパージする
$contextManager->terminate();
}
});
$server->start();
—
4. アーキテクトからのメッセージ：PHPの「裏側」を愛するということ
ここまで、常駐型環境におけるメモリ汚染のメカニズムと、それを防ぐためのカスタムクリーンアップ戦略について解説してきました。
他の言語（例えばJavaやGo、Node.jsなど）の経験があるエンジニアからすると、「なぜPHPでこんなにメモリ管理を意識しなきゃいけないんだ？」と最初は歯痒く感じるかもしれません。しかし、これはPHPが退化したのではなく、PHPが長年培ってきた「極限までリクエストごとにリソースをクリーンに保つ」という思想から、一歩進んだ次世代の領域（非同期・常駐）へ進化している証拠なのです。
Zendエンジンのメモリ管理、HashTableの挙動、そしてSAPI層とワーカーのライフサイクル。これらの「裏側の仕組み」を少しだけ解像度高く理解するだけで、あなたが書くコードの質は劇的に変わり、本番環境で予期せぬメモリリークやデータ混濁に怯える夜はなくなります。
PHPの裏側は、私たちが想像するよりもずっと美しく、論理的に動いています。ぜひ、この知見を武器に、より堅牢で高速なWebシステムを設計してくださいね。