こんにちは。PHPの裏側を覗く旅へようこそ。
普段、私たちは何気なく `$_GET` を受け取り、EloquentやDoctrineでモデルを叩き、美しいJSONを返していますよね。PHP-FPMの伝統的なリクエストライフサイクル、つまり「リクエストが来たらプロセスが立ち上がり、スクリプトが走り、レスポンスを返した瞬間に全メモリが綺麗にパージされる」という安全な砂場に慣れきっていると、SwooleやRoadRunnerといった常駐型（Persistent）PHP環境の世界に足を踏み入れた瞬間、激しい洗礼を受けることになります。
そう、「グローバル変数の汚染」という名の、見えない亡霊です。
今回は、SwooleのWorkerプロセスという特殊な空間でPHPの実行エンジン（Zend VM）がどう振る舞い、なぜグローバル変数が「時限爆弾」と化すのか。そして、それを防ぐためのIPC（プロセス間通信）とメモリ分離のアーキテクチャを、低レイヤの視点から紐解いていきましょう。ここを理解すれば、PHPの裏側が驚くほど美しく見えてきますよ。
—
1. 伝統のFPMから「常駐型Swoole」へのパラダイムシフト
まず、Zend VMのメモリ管理の前提を覆すところから始めましょう。
PHP-FPM環境では、1つのリクエストが終わると、Zend Engineは `request_shutdown` フェーズに入ります。ここでシンボルテーブル（変数や関数が格納されるHashTable）は破棄され、アロケータ（Zend Memory Manager）がメモリをごっそり解放します。だから、どれだけ雑にグローバル変数を汚しても、次のリクエストには一切影響しませんでした。PHPが「最も安全で下手なコードを書いても壊れない言語」と言われた所以です。
しかし、Swooleなどの常駐型アーキテクチャではこの前提が崩壊します。
[Swoole Master Process]
│
├── [Worker Process #1] (Zend VM起動 ── 一度きり)
│ ├── リクエストA処理 ──> グローバル変数にユーザー情報を保存！
│ └── リクエストB処理 ──> 【悲劇】次のリクエストで前のユーザー情報が漏洩する！
│
└── [Worker Process #2]
SwooleのWorkerプロセスは、起動時に一度スクリプトをメモリ（Zend VMのOPcacheとシンボルテーブル）にロードした後は、プロセスが生存し続けたまま、非同期またはコルーチンベースで無限にリクエストを処理し続けます。
これは何を意味するか？
「スクリプトのグローバルスコープで定義された変数や、クラスのstaticプロパティは、プロセスが生きている限り、すべてのリクエスト間で永続共有される」ということです。
—
2. 恐怖のグローバル汚染：Zend VMのメモリ空間で何が起きているか
具体例を見てみましょう。よくある「アクセスカウンター」や「認証情報の保持」を、Swoole上でうっかりやってしまったコードです。
0,
‘current_user’ => null,
];
$server->on(“Request”, function (Request $request, Response $response) use (&$globalContext) {
// リクエストごとにカウントアップ
$globalContext[‘request_count’]++;
// クエリパラメータからユーザー名を取得して設定（つもり）
if (isset($request->get[‘user’])) {
$globalContext[‘current_user’] = $request->get[‘user’];
}
// 意図せぬ動作の確認用レスポンス
$response->header(“Content-Type”, “text/plain; charset=utf-8”);
$response->end(sprintf(
“Worker内累積リクエスト数: %d\n現在のユーザー: %s\n”,
$globalContext[‘request_count’],
$globalContext[‘current_user’] ?? ‘ゲスト’
));
});
$server->start();
このコードをSwooleで動かしたとします。
クライアントAが `?user=Alice` でアクセスし、その直後にクライアントBがパラメータなしでアクセスしたとしましょう。
クライアントBの画面には何が表示されるでしょうか？
なんと、「現在のユーザー: Alice」と表示されてしまうのです。これが、マルチリクエスト環境におけるグローバル変数汚染の正体です。
Zend VMの内部では、`$globalContext` はグローバルシンボルテーブル（EG(symbol_table)）に登録されたエントリであり、ZVAL（PHPの変数を表現する構造体）のポインタが指す実体は、Workerプロセス全体のライフサイクルを通じて同じヒープメモリ領域に存在し続けます。リクエストを跨いでデータが「漏れ出す」のは、VMの挙動としては極めて正常（設計通り）なのです。
—
3. 防壁の構築：メモリ分離とSwoole TableによるIPC
では、この常駐環境で安全にステート（状態）を管理しつつ、高速な処理を実現するにはどうすればよいのでしょうか。
解決策は2つあります。
1. リクエストスコープの徹底（変数をリクエストごとに必ず初期化・破棄する）
2. プロセス間で安全に共有できる専用の共有メモリ（IPC）を使うこと
Swooleには、マルチプロセス環境下で安全にデータを読み書きするための強力な武器が用意されています。それが `Swoole\Table` です。
これは、PHPの通常の変数（Zend VMのヒープ）とは異なり、OSの共有メモリ（Shared Memory / mmap）上に構築された極めて高速なロックフリー（あるいは適切なスピンロック制御された）KVS（キーバリューストア）です。Zend VMのコンテキストの外側にあるため、Workerプロセス間で安全にデータを授受（IPC）できます。
実装パターン：Swoole Tableを用いた安全なセッション・カウンター管理
column(‘request_count’, Table::TYPE_INT, 4);
$table->column(‘last_user’, Table::TYPE_STRING, 64);
$table->create();
// グローバルスコープに生の配列を持つ代わりに、共有メモリテーブルを注入
$server->table = $table;
// プロセス起動時にアトミックなカウンターを初期化
$server->table->set(‘stats’, [
‘request_count’ => 0,
‘last_user’ => ‘None’
]);
$server->on(“Request”, function (Request $request, Response $response) use ($server) {
// 2. アトミックにカウンターをインクリメント（他Workerとの競合を防ぐ）
// Swoole\Tableは内部で排他制御を行っているため、レースコンディションが起きません
$server->table->incr(‘stats’, ‘request_count’);
$currentCount = $server->table->get(‘stats’, ‘request_count’);
$userName = $request->get[‘user’] ?? ‘ゲスト’;
// 3. 状態の更新
$server->table->set(‘stats’, [‘last_user’ => $userName]);
$stats = $server->table->get(‘stats’);
$response->header(“Content-Type”, “text/plain; charset=utf-8”);
$response->end(sprintf(
“安全な共有メモリ経由 – 累積リクエスト数: %d\n最後のユーザー: %s\n”,
$stats[‘request_count’],
$stats[‘last_user’]
));
});
$server->start();
このアプローチを取ることで、各Workerプロセスは「汚染されるような可変のグローバル状態」を自身のZend VMヒープ内に持たなくなります。状態の真実（Source of Truth）は、プロセス境界の外側にある `Swoole\Table`（共有メモリ）に一元化されるため、どのWorkerがどのリクエストを受けようとも、予期せぬデータ混入（汚染）は構造的に不可能になります。
—
4. アーキテクトからの提言：クリーンな常駐型PHPのために
SwooleやOpenSwoole、あるいはRoadRunnerを使ったモダンなPHP開発は、従来のFPMの限界を軽々と突破し、Node.jsやGoをも凌駕する圧倒的なスループットをもたらしてくれます。
しかし、それは「PHPにC言語やGoのようなメモリ管理の意識を持ち込むこと」と同義です。
- 「グローバル変数やクラスの `static` プロパティに、リクエスト依存のデータを保持しない」
- 永続化が必要なデータは、必ずリクエストスコープでインスタンスを生成し、終了時に破棄する（DIコンテナのスコープ管理の徹底）
- プロセス間で共有すべき状態は、通常のPHP変数ではなく、`Swoole\Table` や外部ミドルウェア（Redisなど）を通じたIPCによって厳格に分離する
この原則さえ守れば、PHPは常駐型環境においても驚異的な安定性とパフォーマンスを発揮します。
裏側のメカニズムを恐れず、むしろエンジンの挙動を手の上でコントロールするような感覚で、ぜひ次のモダンなアーキテクチャ設計に挑んでみてください。あなたの書くコードは、もっと強くなれますよ。