【実務・中級編】PHPのガベージコレクション（GC）サイクルとJITコードの生存期間：循環参照がJITに与える影響 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

2026.08.28

はじめに：コードレビューの現場から

「なぜ、この長寿命なデーモンプロセス型APIサーバーは、数日稼働すると徐々にRSS（Resident Set Size）を膨らませ、最終的にOOM Killerの餌食になるのか？」

コードレビューの最中、ジュニアエンジニアが自信満々に差し出したドメイン層のサービスファクトリー。そこには美しくカプセル化されたオブジェクトの依存関係が広がっていたが、PHPの内部エンジン（Zend VM）のメモリ管理とJIT（Just-In-Time）コンパイラの生存戦略を知る者の目には、それは「時限式メモリリークの温床」に映ったはずだ。

世の多くのチュートリアルは「PHPはリクエスト終わりにすべてを解放するからメモリリークを気にしなくてよい」と説く。しかし、それはCGI/FastCGIの短命なリクエストライフサイクルという過去の遺物にすぎない。現代の私たちには RoadRunner や Swoole といった常駐型PHPランタイムがあり、さらに PHP 8のJITコンパイラ がネイティブ機械語をメモリ空間に直接焼き付けている。

今回は、Zend VMの根幹をなすガベージコレクション（GC）のサイクルと、JITコードの生存期間が交差する領域において「循環参照が引き起こす隠れた破滅」について、低レイヤの視点から解き明かしていく。

—

1. Zendエンジン内部におけるメモリ管理の現実

PHPの変数やオブジェクトは、すべてC言語レベルの構造体である `zval`（Zend Value）として表現され、ヒープ上のメモリプールに割り当てられる。ここで避けて通れないのが、PHP 7以降で洗練された 参照カウント（Reference Counting）方式 と、PHP 5.3から導入された 循環参照コレクタ（Concurrent Cycle Collector） の挙動だ。

参照カウントの限界と「黒・白・灰色」のアルゴリズム

オブジェクトや配列が自分自身を指したり、相互に参照し合う「循環参照（Circular Reference）」が発生すると、参照カウントが「0」になることは永遠に訪れない。

[Object A] <---> [Object B]
(ref_count: 1) (ref_count: 1)

この状態のままスコープを抜けても、`zval` はヒープ上に残骸として残り続ける。これを回収するため、ZendのGCはバッファ（`gc_globals.buf`）に溜まった「疑わしいルート」をスキャンし、参照を一時的にデクリメントしながら三色マーキング法（White, Grey, Black）によって孤立した循環グラフを特定し、一網打尽に解放する。

しかし、ここに JITコンパイラが有効な環境（`opcache.jit`） における新たな影が潜んでいる。

—

2. JITが保持するメタデータとネイティブコードの生存期間

PHP 8のJIT（DynASMベースのトラッキングJIT）は、バイトコード（Opcode）をCPUが直接実行可能なマシン語に翻訳し、専用の割り当て領域（JIT Buffer：`opcache.jit_buffer_size`）に配置する。

ここで重要なのは、「JITが生成した機械語と、その実行に必要なメタデータは、一度ロードされると原則としてプロセス生存中は破棄されない」 という点だ。

メモリリークの二重構造

常駐型アプリケーションや長寿命のバッチ処理において、循環参照を持つ巨大なオブジェクトグラフが頻繁に生成・破棄されるとき、以下の現象が同時に進行する。

1. Zend HeapのフラグメンテーションとGCの遅延
循環参照の解決はCPUコストが高い。GCのルートバッファが溢れる（デフォルトでは10,000エントリ）まで回収が走らない場合、メモリ使用量は右肩上がりに上昇する。
2. JIT最適化とポリモーフィズムの罠（ガードの失敗）
JITは実行時の型情報（Type Guard）を元に最適化コードを生成する。もし動的な循環参照を持つオブジェクトが頻繁に型を変えて渡されると、JITはインラインキャッシュをミスし、インタプリタへのフォールバック（Deoptimization）や、最悪の場合は動的なトレース再生成を引き起こす。これにより、JIT Buffer内に不必要なネイティブコードの断片が蓄積し続ける。

—

3. 実践：循環参照を断ち切り、JIT効率を最大化する設計

この問題に対する最も確実な処方箋は、「ライフサイクルの明確な分離」 と 「明示的な循環の破壊（Destruction）」 である。

以下のコードは、常駐型APIサーバーやフレームワークの依存性注入コンテナ（DI Container）やオブザーバーパターンを模した、実務に耐えうる堅牢な実装例だ。親子関係を持つオブジェクトが循環参照を生みやすい典型的なアンチパターンを、ウィークリファレンス（WeakReference）を用いて美しく解決している。

コピペで使える堅牢なリファレンスコード

  • 依存性やオブザーバーの循環参照を防ぎ、JITおよびZend GCの負荷を最小化する
  • エコシステムを考慮した堅牢なコンポーネント基盤

    • /
    class NodeContext
    {
    private string $id;

    / @var array メモリ上に展開される一時データ /
    private array $payload = [];

    public function __construct(string $id)
    {
    $this->id = $id;
    }

    public function setPayload(string $key, mixed $value): void
    {
    $this->payload[$key] = $value;
    }

    public function getId(): string
    {
    return $this->id;
    }
    }

    class ServiceNode
    {
    private string $name;

    /

    • 危険な実装（循環参照の温床）:
    • private ?ServiceNode $parent = null;
    • private array $children = [];

    /

    / 親への参照を WeakReference で保持し、参照カウントをインクリメントさせない /
    private ?\WeakReference $parentRef = null;

    / @var array 子ノード群 /
    private array $children = [];

    private ?NodeContext $context;

    public function __construct(string $name, ?NodeContext $context = null)
    {
    $this->name = $name;
    $this->context = $context;
    }

    /

    • 親子関係を構築する（循環参照を完全に回避）

    /
    public function addChild(ServiceNode $child): void
    {
    $child->setParent($this);
    $this->children[$child->getName()] = $child;
    }

    public function setParent(ServiceNode $parent): void
    {
    // WeakReference::create() を使うことで、親から子への強い結びつきを断ち、
    // Zend VMのGCサイクルをバイパスして即座にメモリ解放可能なグラフ構造を保つ
    $this->parentRef = \WeakReference::create($parent);
    }

    public function getParent(): ?ServiceNode
    {
    return $this->parentRef?->get();
    }

    public function getName(): string
    {
    return $this->name;
    }

    /

    • 明示的なクリーンアップ（デストラクタに頼らない確実なメモリ解放）

    /
    public function destroy(): void
    {
    foreach ($this->children as $child) {
    $child->destroy();
    }
    $this->children = [];
    $this->context = null;
    $this->parentRef = null;
    }

    public function __destruct()
    {
    // デバッグ用：実際の解放タイミングをトレース
    // fprintf(STDERR, “Destroyed ServiceNode: %s\n”, $this->name);
    }
    }

    /

    • 【実行・検証シミュレーション】
    • 常駐型ワーカープロセスを想定したループ処理

    /
    function runWorkerSimulation(): void
    {
    // JITが有効な環境下で、動的型生成とガベージコレクションの挙動を確認
    for ($i = 0; $i < 1000; $i++) { $context = new NodeContext("ctx-{$i}"); $root = new ServiceNode("Root-{$i}", $context); for ($j = 0; $j < 10; $j++) { $child = new ServiceNode("Child-{$j}"); $root->addChild($child);
    }

    // 処理の終了時に明示的にリソースを破棄
    // 常駐プロセスでは、スコープアウトを待つだけでなく明示的破壊がJITとGCの友となる
    $root->destroy();

    if ($i % 200 === 0) {
    // 強制的にGCを走らせてメモリの断片化を防ぐ（実務的なチューニング手法）
    gc_collect_cycles();
    }
    }

    echo “Simulation completed safely without memory bloat.\n”;
    }

    // 実行
    runWorkerSimulation();

    —

    4. テクニカルリードからの設計ルールとまとめ

    実務の現場において、JITとGCの特性を無視したコードは、やがて「原因不明のメモリ肥大化」という形で開発チームに牙をむく。これを防ぐための鉄則をここに明記する。

    1. 常駐型アプリケーション（Swoole, RoadRunner, ReactPHP等）では `gc_collect_cycles()` の戦略的実行を怠るな
    自動GCに頼り切るのではなく、重いリクエスト処理の境界やバッチのイテレーション単位で明示的な回収ポイントを設けること。ただし、頻繁すぎる呼び出しはCPUキャッシュ効率を落とすため、カウンタ制御（例: 500回に1回）を入れるのが定石である。
    2. 親子関係・双方向参照には迷わず `WeakReference` を採用せよ
    ドメインモデルやDOMツリー構造、イベントリスナーの登録など、ポインタが循環しやすい箇所では、強参照（Strong Reference）の連鎖を断ち切る設計を強制すること。これにより、Zend GCのサイクルコレクタの稼働頻度そのものを劇的に減らすことができる。
    3. JIT Bufferのサイズと監視
    `opcache.jit_buffer_size` を過度に大きく設定すると、万が一のメモリリーク時にスワップアウトを引き起こす。アプリケーションの規模に応じた適切なサイズ（通常は64M〜128M程度）を見極め、定期的なメトリクス監視（Prometheus + Node Exporter等によるRSS監視）を怠らないこと。

    PHPはもはや「リクエストごとに全てを忘れるおもちゃの言語」ではない。その低レイヤのメモリ挙動を掌中に収めたとき、あなたの書くコードは極限まで高速で、かつ堅牢なエンタープライズシステムへと昇華する。

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