Zend Engineの深淵：循環参照というメモリリークの亡霊と、静的解析によるその駆逐
PHPのメモリ管理は、表向きは極めてシンプルに見える。変数がスコープを抜け、あるいは`unset()`によって参照カウントがゼロになった瞬間、Zend Engineは即座にその領域を解放する。しかし、この美しき「参照カウント方式（Reference Counting）」の裏側には、オブジェクトと配列が織りなす「循環参照（Circular Reference）」という致命的な死角が存在する。
本稿では、Zend VMのメモリ空間における`zval`と`zend_object`の構造に踏み込み、循環参照がなぜ通常の参照カウントでは回収されないのか、その低レイヤのメカニズムを解き明かす。さらに、この亡霊がFPM（FastCGI Process Manager）のプロセスライフサイクルにおいてどのような悪影響を及ぼすのか、そして静的解析とGC（Garbage Collector）のチューニングによってこれを完全に制圧する方法論を提示する。
—
1. Zend VM内部におけるメモリ管理と循環参照の正体
PHPのすべての値は、C言語レベルの構造体である `zval`（Zend Value）として表現されている。オブジェクト型（`IS_OBJECT`）の場合、`zval`の内部ポインタはヒープ上に確保された `zend_object` を指し示している。この `zend_object` 自体が、プロパティを保持するための `HashTable`（シンボルテーブル）を内包している。
通常、あるオブジェクトAが別のオブジェクトBを参照すると、Bの `zval`（厳密にはBの `zend_object` が持つ参照カウンター）のカウントがインクリメントされる。
[ Object A ] —> 参照 —> [ Object B ]
(RefCount: 1) (RefCount: 2) <--- Aからの参照 + 変数からの参照
ここで、オブジェクトBが逆方向にオブジェクトAを参照した瞬間、循環が完成する。
[ Object A ] <--- 相互参照 ---> [ Object B ]
もし、この状態で外部からの変数スコープが消滅し、変数からオブジェクトA、Bへの直接のポインタが失われたとしても、それぞれの `zend_object` はお互いを指し合っているため、参照カウントは「1」のまま残存する。
外部スコープからの変数ロスト
↓
[ Object A ] (RefCount: 1) <---> [ Object B ] (RefCount: 1)
↑
【メモリリークの発生】（誰もアクセスできないが、解放もされない）
これが、Zend Engineの単純な参照カウント機構の限界である。この孤立した循環構造を回収するために、PHP 5.3以降には「循環ガベージコレクタ（Concurrent Garbage Collector）」が組み込まれている。
バッファリングとルートバッファ（Root Buffer）
Zend EngineのGCは、すべての変数を常時監視しているわけではない。もしそうであれば、パフォーマンスは致命的に低下する。
代わりに、GCは「参照カウントが減少し、しかしゼロにならなかった（＝潜在的な循環参照のルートとなり得た）」複合型（配列およびオブジェクト）の `zval` を、ルートバッファ（Root Buffer、デフォルトサイズ約10,000エントリ）に一時的に記録する。
ルートバッファが満杯になるか、あるいは明動的に `gc_collect_cycles()` が呼び出されると、Zend VMは以下の3ステップのアルゴリズムを実行する。
1. 色分け（Greyling / Marking）： バッファ内のルートからグラフをたどり、各要素の参照カウントを一時的にデクリメントする（擬似的な切断）。これにより、循環参照内部だけで閉じている参照はカウントがゼロになる。
2. 探索（Scanning）： 再びグラフをたどり、カウントがゼロになったノードを「灰色（Garbage candidate）」にマークする。
3. 回収（Sweeping）： マークされたノードのメモリ領域を解放し、`HashTable`の破棄とデストラクタの呼び出しを行う。
この一連の処理は、Webアプリケーションの1リクエスト内、特に数千のオブジェクトを生成・破棄するバッチ処理やORMの多重ロードにおいて、無視できないCPUコスト（GCパウゼ）を発生させる要因となる。
—
2. 循環参照を誘発する典型的なアンチパターン
実務の現場において、循環参照は意図しない設計ミスや、ドメインモデルの安易な双方向関連の構築によって引き起こされる。典型的な悪例を見ていこう。
アンチパターン：親子関係の双方向ブリッジ
ドメイン駆動設計（DDD）やアクティブレコードパターンにおいて、親エンティティが子コレクションを持ち、子が親への参照を持つ構造は頻出する。これをPHPで素朴に実装すると、即座に循環参照の罠に落ちる。
children[] = $child;
// 親から子、子から親への双方向参照がここで確立される
$child->setParent($this);
}
public function __destruct()
{
// デバッグ用：このメソッドが呼ばれるタイミングを確認する
echo “ParentNode destroyed.\n”;
}
}
class ChildNode
{
private ?ParentNode $parent = null;
public function setParent(ParentNode $parent): void
{
$this->parent = $parent;
}
public function __destruct()
{
echo “ChildNode destroyed.\n”;
}
}
// — 実行スコープ —
function runMemoryLeakScenario(): void
{
$parent = new ParentNode();
$child = new ChildNode();
$parent->addChild($child);
// スコープ終了時に $parent と $child の変数シンボルは消滅するが、
// 相互参照のため参照カウントは 1 のこり、即座には解放されない。
}
runMemoryLeakScenario();
// 出力なし（即座には __destruct が走らず、PHPプロセスの終了時またはGC発動時までメモリに残る）
このようなコードがFPMのロングランプロセスやワーカープロセス（Swoole / RoadRunnerなど）のコンテキストで実行された場合、リクエストを処理するたびにメモリが肥大化し、最終的に `Allowed memory size exhausted` を引き起こす。ワーカー型アーキテクチャにおいて、この種のリークは致命傷となる。
—
3. 静的解析（PHPStan / Psalm）による循環参照の検出と限界
実行時のGCに頼るのではなく、静的解析の段階でメモリリークの火種を検知することは、プロフェッショナルなアーキテクトにとって必須のプラットフォーム要件である。
PHPStanによる検出のアプローチ
残念ながら、標準のPHPStanやPsalmは「循環参照によるメモリリーク」を直接検出する専用のLinterをデフォルトでは持っていない（グラフ理論的な動的ライフサイクルを静的に完全証明することは停止問題に帰着するため困難である）。
しかし、「強すぎる結合（Coupling）」や「コールバック、クロージャによる外部スコープのキャプチャ」を検出することで、循環参照の温床をあらかじめ排除することは可能である。
例えば、クロージャ（無名関数）が `$this` を暗黙的にバインドし、かつそのクロージャをオブジェクトのプロパティに保持させた場合、これも強力な循環参照を引き起こす。
class LeakByClosure
{
private $callback;
public function __construct()
{
// $this をキャプチャしたクロージャをプロパティに保持
// Closure オブジェクトが $this を保持し、$this が Closure を保持する循環
$this->callback = function() {
return $this;
};
}
}
このようなコードを検知するためには、PHPStanのカスタムルール（Custom Rule）を記述し、`Expr\Closure` 内での `$this` の使用と、それがオブジェクトのプロパティに代入されるパターンを抽象構文木（AST）レベルで走査・禁止する必要がある。
ASTレベルでの静的解析アプローチ（概念コード）
PHPStanの `Rule` インターフェースを実装し、ノードの型をチェックするカスタムアナライザの設計思想は以下の通りだ。
use PhpParser\Node;
use PHPStan\Analyser\Scope;
use PHPStan\Rules\Rule;
class ClosureThisAssignmentRule implements Rule
{
public function getNodeType(): string
{
return Node\Expr\Assign::class;
}
public function processNode(Node $node, Scope $scope): array
{
// 代入の右辺がクロージャであり、かつその内部で $this が使われており、
// それが自身のプロパティに格納される構文木構造を検知するロジックをここに構築する。
// これにより、CI/CDパイプライン上で循環参照の危険性を機械的にブロックできる。
return [];
}
}
—
4. 根本的解決：弱参照（WeakReference）によるアーキテクチャの刷新
PHP 7.4以降、Zend Engineには待望の `WeakReference`（弱参照） が導入された。これにより、参照カウントをインクリメントすることなく、オブジェクトへのポインタを保持することが可能となった。
前述の親子関係のアンチパターンは、子から親への参照を `WeakReference` に置き換えることで、循環参照そのものを物理的に発生させなくなり、GCの介入すら不要なクリーンなメモリ解放を実現できる。
`WeakReference` を用いた堅牢な実装
children[] = $child;
$child->setParent($this);
}
public function __destruct()
{
echo “Optimized ParentNode destroyed immediately.\n”;
}
}
class ChildNode
{
/ @var WeakReference
private ?WeakReference $parentRef = null;
public function setParent(ParentNode $parent): void
{
// 参照カウントを増やさずにWeakReferenceを生成
$this->parentRef = WeakReference::create($parent);
}
public function getParent(): ?ParentNode
{
// WeakReferenceから実体を取得する（すでに親が破棄されていればnullを返す）
return $this->parentRef?->get();
}
public function __destruct()
{
echo “Optimized ChildNode destroyed immediately.\n”;
}
}
// — 実行スコープ —
function runOptimizedScenario(): void
{
$parent = new ParentNode();
$child = new ChildNode();
$parent->addChild($child);
// スコープを抜ける時点で、相互参照が存在しないため、
// 参照カウントは即座にゼロになり、オブジェクトは即時破棄される。
}
runOptimizedScenario();
// 出力:
// Optimized ChildNode destroyed immediately.
// Optimized ParentNode destroyed immediately.
このアプローチを採用した場合、Zend VMのガベージコレクタに頼る必要が一切なくなるため、GCの走査コスト（CPUサイクル）をゼロに抑えることができ、高スループットが要求される非同期・常駐型アプリケーション（Swoole、ReactPHPなど）において圧倒的なパフォーマンス上のアドバンテージを生む。
—
5. 高速化とメモリ効率の極限：OPcacheプリローディングとの関係
PHP 7.4で導入された OPcacheプリローディング（Preloading） は、サーバ起動時に指定したスクリプト群をパースし、永続的なメモリ空間（SHM: Shared Memory）にバイトコード（opcode）およびクラス定義をロードする機能である。
ここで重要な低レイヤの事実がある。プリロードされたクラスの構造体や、そこに定義された定数・staticプロパティは、すべてのFPMワーカープロセス間で共有される。
もし、プリロード対象のクラスやstaticプロパティの初期化フェーズにおいて、意図せず循環参照が含まれるデータ構造が構築された場合、それは全プロセスの共有メモリ空間上に固定化され、リクエストライフサイクルを超えて永続的なメモリリーク（あるいは回収不可能なゴミ構造）としてシステム全体に悪影響を及ぼす。
したがって、長時間稼働するモダンなPHPシステムアーキテクチャにおいては、以下の鉄則を遵守しなければならない。
1. ドメインモデルやインスタンスプロパティの初期化コードをプリロードスクリプトに含めない。（プリロードするのは純粋なクラス定義、関数、インターフェースのみに限定する）
2. staticプロパティでの複雑なオブジェクトグラフの保持を避ける。（どうしても保持する場合は、`WeakReference` または起動時の初期化・終了時の明示的な破棄ロジックを担保する）
—
総括
PHPは「動的言語の皮をかぶった高度な仮想マシン（Zend VM）」である。そのメモリ管理の裏側にある `zval`、参照カウント、ルートバッファ、そして循環参照のメカニズムを理解しているか否かで、書くコードの質、そして大規模Webシステムの安定性は根本から変わる。
循環参照は単なる「行儀の悪いコード」ではない。それは、エンジンレベルの挙動を無視した設計が生み出す、システムの寿命を削る時限爆弾である。`WeakReference` を駆使し、静的解析の網の目を潜り抜け、Zend Engineが最も愛する「美しく、かつ即座に解放されるメモリフロー」を構築すること。それこそが、真のPHPアーキテクトに求められる極限の知見である。