【テクニカル・上級編】Swoole/RoadRunner常駐環境下でのグローバル変数汚染とメモリリークの連鎖 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

2026.09.04

Swoole/RoadRunner常駐環境下におけるメモリリークの深淵：グローバル変数汚染とZend VMの物理構造

PHPは本来、Shared Nothingなリクエストライフサイクルを前提に設計された言語である。1つのHTTPリクエストが飛来すればZend Engineが起動し、シンボルテーブルを構築し、スクリプトを実行し、応答を返した瞬間にプロセス空間のメモリは綺麗に解放される。この「使い捨ての美学」が、PHPを最もセキュアでメモリリークから無縁な言語たらしめてきた。

しかし、SwooleやRoadRunnerに代表される常駐型（Long-running）PHPプロセスの普及により、このパラダイムは完全に崩壊した。プロセスがメモリ上に常駐し続けるということは、リクエストを跨いでZend VMのグローバルステートやシンボルテーブルが永続化されることを意味する。

今回は、常駐環境下で発生する「グローバル変数汚染」と「メモリリークの連鎖」について、Zend VMの内部構造、参照カウント、そしてOPcacheプリローディングの物理構造の観点から徹底的に解剖する。

—

1. Zend VMのメモリ管理とシンボルテーブルの永続化

PHPの変数は、C言語レベルでは `zval` という構造体として表現され、その実体は `zend_execute_data` が管理するスタックフレーム上のシンボルテーブル（`HashTable`）に格納される。

通常のリクエストであれば、リクエスト終了時に `shutdown_op_array` やシンボルテーブルの破棄（`zend_clean_module_rsr_and_dtors` 等）が走り、アロケータを通じてOSにメモリが返還される（あるいはZendMMのヒープ内にプールされる）。

しかし、Swooleの `onWorkerStart` コールバックや、RoadRunnerのワーカー初期化フェーズでロードされたオブジェクトや配列は、リクエストスコープを超越したグローバル（あるいはプロセス）スコープのシンボルテーブルに陣取る。

一切破棄されない点にある。

参照カウントと循環参照の罠

Zend VMのメモリ管理は基本的には `zval` の参照カウント（`refcount`）方式で行われる。しかし、アプリケーション層で構築された巨大なオブジェクトグラフに循環参照（Circular Reference）が含まれている場合、通常の参照カウントデクリメントではメモリが解放されない。

PHPには `gc_collect_cycles()` による循環参照ガベージコレクタが存在するが、常駐プロセスにおいてこれが適切に機能しない、あるいは高頻度でバッファが溢れると、ZendMM（Zend Memory Manager）のヒープフラグメンテーションが加速し、プロセスは確実にOOM（Out of Memory）へと突き進む。

—

2. OPcacheプリローディングと「書き込み時コピー（COW）」の破壊

パフォーマンスを極限まで高めるために導入されるOPcacheのプリローディング（`opcache.preload`）は、マスタープロセス起動時にスクリプトをパースし、共有メモリ（SHM）上にオペコード（Opcode）として展開する技術である。

ここで深刻な問題が発生する。もしプリロードされたクラスのプロパティや、常駐プロセスのグローバルスコープで定義された静的プロパティ（`public static`）に対して、リクエスト処理中に動的な代入を行った場合、何が起きるか。

class StateManager {
public static array $cache = [];
}

// リクエスト処理中
function process($userData) {
// 静的プロパティへの蓄積は、プロセス空間のヒープを汚染する
StateManager::$cache[$userData[‘id’]] = $userData;
}

Zend VMにおいて、共有メモリ上にあるOPcacheのデータは本来読み取り専用であるべきだが、静的プロパティの実体はプロセス固有のヒープ上にコピーされるか、あるいはグローバルなHashTableへのポインタとして操作される。

ここに「データの混入（Data Pollution）」と「メモリリークの連鎖」が成立する。
あるユーザーのリクエストで汚染されたグローバルキャッシュや静的プロパティは、次のリクエストを処理する全く別のユーザー（あるいはマルチテナント環境における別テナント）から参照可能になってしまう。これは単なるメモリリークを超えた、致命的な情報漏洩（セキュアコンテキストの崩壊）である。

—

3. Fiberによる並行処理とコンテキストスイッチの代償

SwooleやCo\\run、あるいはPHP 8.1以降のFiberを活用した非同期・並行処理環境では、一つのOSスレッド（またはワーカープロセス）上で複数の軽量スレッドが協調動作する。

ここで最も恐ろしいのは、「グローバル変数やstatic変数が、Fiber間で共有されてしまう」という事実である。

use Smalot\Cupcake\Fiber;

// グローバルな状態管理
class RequestContext {
public static ?string $userId = null;
}

// Fiber A
Co\go(function() {
RequestContext::$userId = ‘user_A’;
Co::sleep(0.1); // コンテキストスイッチ発生
echo RequestContext::$userId; // ここで ‘user_B’ に書き換わっている可能性がある！
});

// Fiber B
Co\go(function() {
RequestContext::$userId = ‘user_B’;
Co::sleep(0.05);
});

Zend VMの実行コンテキスト（`zend_execute_data`）はFiberごとに分離されるが、アプリケーション層のグローバル変数やクラスの静的プロパティはプロセス空間に単一のインスタンスとして存在する。

Fiberのコンテキストスイッチが走った瞬間、非同期に動く別のタスクが同じ静的変数を上書きし、データ競合（Data Race）や意図しないセッションの混交を引き起こす。これはメモリリークの範疇を超え、アプリケーションの論理破壊そのものである。

—

4. 防御と克服：常駐環境におけるアーキテクチャの極意

SwooleやRoadRunnerの恩恵を安全に受け取りつつ、Zend VMのメモリ空間をクリーンに保つためには、以下の鉄則をアーキテクチャレベルで強制しなければならない。

① グローバルスコープへの書き込みの完全な排除

アプリケーションコード内での `$GLOBALS`、`$_SERVER` への動的代入、およびクラスの静的プロパティ（`public static`）へのデータキャッシュを静的解析（PHPStan等）で完全に禁止する。

② リクエスト境界での明示的なクリーンアップ（Deconstructorの徹底）

リクエスト終了時には、必ずオブジェクトグラフのルートから参照を断ち切り、明示的にnullを代入する。必要であれば `gc_collect_cycles()` を適切なタイミングで明示的にコールし、循環参照のバッファを強制解放する。

③ スコープ分離パターンの採用

依存性注入（DI）コンテナをプロセスグローバルではなく、リクエストごとにビルド・破棄するスコープモデルに変更する。

以下に、常駐環境下で安全にリクエストを処理するための堅牢なワーカープロセスの設計コードを示す。

  • 安全なリクエストコンテキスト管理クラス
  • グローバル変数の汚染を防ぎ、リクエスト終了時に確実にメモリを解放する

    • /
    final class RequestContextContainer {
    private array $registry = [];

    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 destroy(): void {
    foreach ($this->registry as $key => $value) {
    if (is_object($value) && method_exists($value, ‘close’)) {
    // リソースの解放（DBコネクション等）
    $value->close();
    }
    unset($this->registry[$key]);
    }
    $this->registry = [];
    }
    }

    /

    • Swoole/RoadRunnerワーカーのエントリポイント模擬

    /
    class SafeWorkerServer {
    public function run(): void {
    // [プロセス起動時] 変更不可の静的リソースのみを初期化
    $appConfig = require ‘/path/to/config.php’;

    echo “Worker started. Listening for requests…\n”;

    while (true) {
    // リクエストの模擬取得
    $request = $this->fetchNextRequest();
    if (!$request) break;

    // [リクエスト開始] リクエストごとに完全に独立したコンテナを生成
    $container = new RequestContextContainer();

    try {
    $this->handleRequest($request, $container);
    } catch (\Throwable $e) {
    // 例外発生時も確実にログ出力とメモリクリーンアップを行う
    error_log($e->getMessage());
    } finally {
    // [リクエスト終了] 厳格なメモリ解放
    $container->destroy();
    unset($container);

    // 必要に応じて循環参照GCを強制実行
    if (gc_enabled()) {
    gc_collect_cycles();
    }
    }
    }
    }

    private function fetchNextRequest(): ?array {
    // ダミーのリクエスト取得ロジック
    return [‘uri’ => ‘/’, ‘payload’ => ‘…’];
    }

    private function handleRequest(array $request, RequestContextContainer $container): void {
    // リクエストスコープ内でのみ安全に動作する処理
    $container->set(‘db’, new \PDO(‘sqlite::memory:’));

    // 処理の実行…
    }
    }

    —

    結びにかえて

    PHPを常駐型プロセスで運用するということは、Zend VMのライフサイクル管理という「言語の本来の安全網」をエンジニア自身がハンドリングすることを意味する。

    メモリリークやグローバル変数汚染は、単に「コードの書き方が悪い」のではなく、「Zend Engineの物理メモリ構造とシンボルテーブルの永続化モデルを理解していないこと」に起因する。

    低レイヤの挙動から目を背けず、リクエスト境界の美学を常駐環境に再構築することこそが、真のハイパフォーマンス・Webシステムアーキテクチャの到達点である。

    スポンサーリンク
    " "
    タイトルとURLをコピーしました