PHPガベージコレクションの深層：参照カウントの限界と循環参照回収メカニズムの低レイヤ解析
Zend VMが駆動するPHPのランタイムにおいて、メモリ管理は常にパフォーマンスとトレードオフの関係にある。特にWebアプリケーションの文脈では、1リクエストの終了とともにプロセスが保持するメモリ空間がOSへ返還される（Shared Nothing Architecture）ため、C言語のような手動メモリ管理の悪夢から解放されているように見える。
しかし、長大なバッチ処理、デーモンプロセスとしてのcli実行、あるいは複雑なドメインモデルを抱えるエンタープライズアプリケーションにおいて、メモリリークは静かに、そして確実にアプリケーションを蝕む。
今回は、PHP 7およびPHP 8の心臓部におけるガベージコレクション（GC）のアルゴリズム、とりわけ参照カウントの限界と「循環参照（Circular Reference）」が引き起こすメモリ枯渇のメカニズムを、Zend EngineのC言語レベルのソースコードの挙動を脳内トレースしながら解き明かす。
—
1. Zend VMにおけるメモリ管理の基礎：zvalと参照カウント
PHPの変数と値の実体は、C言語の構造体である `zval`（Zend Value）としてヒープ上に表現されている。PHP 7以降、`zval`のサイズは16バイトに最適化され、値そのものまたはポインタ、そして型情報と参照カウント（refcount）が格納される。
オブジェクト（`IS_OBJECT`）や配列（`IS_ARRAY`）などの複合型データ構造が代入されるたびに、その`zval`（正確にはオブジェクトの場合は`zend_object`構造体）の参照カウントがインクリメントされる。
「循環参照」である。
—
2. 循環参照の悪夢：なぜ参照カウントだけでは解放できないのか？
オブジェクトAがプロパティを介してオブジェクトBを保持し、同時にオブジェクトBがプロパティを介してオブジェクトAを指し示している状態を想像してほしい。
child = $b; // Bのrefcount = 2 (Aからの参照)
$b->child = $a; // Aのrefcount = 2 (Bからの参照)
unset($a, $b);
ここで何が起きるか。`$a`と`$b`の変数のスコープが消滅（unset）した際、それぞれの`zval`の参照カウントは `-1` される。
しかし、お互いを指し合っているため、双方の参照カウントは「1」のまま残存する。
参照カウントが0になっていないため、Zend VMはこれらが不要になったと判断できず、プロセスが生存し続ける限りメモリ上にゾンビのように残り続ける。これが、長期稼働するPHPプロセスにおけるメモリリークの主原因である。
—
3. Zend GCアルゴリズムの核心：ConCurent Cycle Collectionの仕組み
PHP 5.3以降に導入され、PHP 7/8で高速化されたガベージコレクション（ConConcurrent Cycle Collection）は、この循環参照を検出し、回収するために存在する。これはすべての変数を常に監視するわけではない。
Zend Engineは、以下の条件を満たす値（バッファ）のみを監視対象の候補（Root Buffer）とする。
- 複合型（配列またはオブジェクト）であること。
- 「参照カウントがデクリメントされたが、0にはならなかった」値。
GCの3色マーキングとバッファリングのフェーズ
Zend EngineのGCは、Cのソースコード（`zend_gc.c`）上で以下のライフサイクルで動作する。
1. バッファへの登録（Buffered）：
参照カウントが減少したものの0にならなかったオブジェクト／配列は、GCの「ルートバッファ（Root Buffer）」にプッシュされる。バッファが一定数（デフォルトでは通常10,000エントリ）に達すると、GCアルゴリズムが発動する。
2. 第1段階：根の減算（Simulated Deletion / Mark Grey）：
バッファ内の各ルートからたどれるすべてのコンテナに対し、再帰的に参照カウントから「1」を仮に引いてみる。これは、もし外部からの参照が切れて内部の循環だけで支えられているならば、カウントが0になるはずという仮説検証である。この時、色は `Grey`（灰色）にマークされる。
3. 第2段階：到達可能性の判定（Check / Mark White or Black）：
- もし仮の減算の結果、参照カウントが 0 になった場合、それは「外部から完全に孤立した循環（ゴミ）」であると断定され、`White`（白色：回収対象）にマークされる。
- もし参照カウントが 1以上 であれば、それはまだ外部の変数から参照されている健全なデータであるため、仮に引いた分を戻し、`Black`（黒色：生存）に復元する。
4. 第3段階：スイープと解放（Sweep / Destruction）：
`White`にマークされたオブジェクト群を走査し、デストラクタ（`__destruct()`）の呼び出し経由でメモリを安全に解放していく。
このアルゴリズムは、すべてのオブジェクトを毎回走査するのではなく、「怪しいもの（参照カウントが減ったが生き残ったもの）」のリスト（Root Buffer）に限定して動くため、非常に効率が良い。
—
4. 検出漏れが発生するシナリオ：エンジニアが陥る罠
しかし、この洗練されたGCであっても、設計上の限界や特定のイディオムによって「検出漏れ（メモリリーク）」を引き起こすケースがある。
シナリオA: クロージャ（Closure）と静的変数・オブジェクトの密結合
PHPのクロージャは、`use`構文や内部の `$this` バインドによって容易に循環参照を作り出す。
クロージャ -> $this の循環
$this->callback = function() {
return $this;
};
}
}
$context = new LeakContext();
$context->initialize();
unset($context); // LeakContextのインスタンスはGCのルートバッファに入るが…
クロージャがオブジェクトのインスタンス（`$this`）をキャプチャしつつ、そのオブジェクトのプロパティとしてクロージャ自身が保持される場合、Zend VMのスコープ解決とクロージャのコンテキスト保持構造（`zend_closure`）の複雑さから、GCのルートバッファへの登録タイミングや参照追跡において意図せぬリークが発生することがある。
シナリオB: 巨大な配列（Array）と循環参照の組み合わせ
PHPの配列（HashTable）は、内部で二重連結リストとハッシュテーブルのハイブリッド構造を持つ。配列同士が相互参照を持つ場合、Zend Engineはこれらをすべて「ルートバッファ」に溜め込む。
バッファのサイズ（`zend.max_accelerated_files` などのようにGCにもバッファ制限がある）を超過した場合、古い候補が溢れ、GCサイクルが追いつかなくなる。結果として、OOM（Out of Memory）エラーがFPMワーカーを直撃する。
—
5. 極限環境におけるGCのチューニングと制御
高スループットを要求されるWebAPIや、Swoole/RoadRunnerなどの常駐型PHPアプリケーション（Long-running process）では、デフォルトのGC挙動に身を委ねることはアーキテクトとして怠慢である。
明示的なGC制御
不要になった巨大なオブジェクトグラフを破棄する際、自動GCの周期（バッファフル）を待つのではなく、手動で回収を強制することが極めて有効な防衛策となる。
destroySelf();
// 2. 明示的にガベージコレクションを強制実行
$collectedCycles = gc_collect_cycles();
// ログやメトリクスに回収数を記録する設計がプロフェッショナルである
error_log(“GC collected cycles: ” . $collectedCycles);
php.iniによるGC挙動のチューニング
プロダクション環境の特性に合わせて、`php.ini` のGCパラメータを最適化すべきである。
; GCを完全に無効化し、メモリ管理のCPUオーバーヘッドをゼロにする（常駐型アプリでメモリリークが完全に制御されている場合のみ有効）
zend.enable_gc = On
; ルートバッファのしきい値を調整（メモリ消費量とGC頻度のトレードオフ）
; デフォルトは通常10000。大量のオブジェクトを扱う場合は増やすか、
; あるいは処理単位でこまめに gc_collect_cycles() を呼ぶ設計にする。
—
6. まとめ：アーキテクトが意識すべきメモリの美学
PHPのガベージコレクションは、エンジニアのコードの書き方、特に「オブジェクト間の関係性（グラフ構造）」に強く依存している。
- 参照カウントは「即時性」を提供するが、循環参照を防ぐことはできない。
- GCアルゴリズムは救世主ではなく、あくまで「取りこぼしたゴミを後から掃除する清掃車」に過ぎない。
- 最高のアーキテクチャとは、GCに頼る必要のないコード、すなわち「ライフサイクルが明確で、循環参照を最初から生まない設計（単方向の依存関係の徹底）」を貫くことである。
Zend VMのメモリ構造の底流を流れる仕組みを理解した者だけが、スケールに耐え、予期せぬメモリ枯渇から解放された堅牢なWebシステムを構築できる。コードの1行が、16バイトの `zval` とどのように戯れているか——その想像力を失ったとき、エンジニアの成長は止まる。