PHPメモリ管理の闇と真実：循環参照ガベージコレクションの低レイヤ解体新書
PHPのメモリ管理は、一見するとシンプルで、プログラマが明示的に `free()` を呼び出す必要のない安全な世界のように見える。しかし、ひとたび数百万リクエストを捌く高負荷なWebアプリケーションや、長時間常駐するデーモンプロセス（RoadRunnerやFrankenPHPなど）の設計に踏み込むと、この「安全な世界」は突如として牙を剥く。
Zend Engine（Zend VM）の内部構造、とりわけ「参照カウント（Reference Counting）」と「循環参照ガベージコレクタ（GC）」の挙動を熟知していないアーキテクトは、必ずと言っていいほどメモリリークの罠に沈む。本稿では、クロージャ、オブジェクトプロパティ、配列参照が複雑に絡み合い、Zend VMのメモリ空間を蝕むアンチパターンの核心を、低レイヤの視点から完全に解体する。
—
1. Zend VMのメモリ基盤：`zval` と参照カウントの限界
PHPのすべての変数、値、オブジェクトは、Zend VM内部において `zval`（Zend Value）と呼ばれるC言語の構造体として表現されている。PHP 7以降、`zval` のサイズは16バイトに最適化され、値自体をインラインで保持するか、ヒープ上に確保された実体（`zend_string`, `zend_array`, `zend_object` など）へのポインタを保持する構造となっている。
参照カウントの基本挙動と「削除のジレンマ」
PHPにおける代入や関数引数の受け渡しは、基本的に値渡し（Copy on Write: CoW）であるが、オブジェクトや配列の参照（`&`）を用いた場合、あるいはオブジェクト型自体が内部でポインタを保持する場合、`zval` の参照カウンタ（`refcount`）がインクリメントされる。
class Node {
public ?Node $child = null;
}
$parent = new Node();
$child = new Node();
// ここで $child のオブジェクト構造体の refcount が 2 になる
// 1つは $child 変数、もう1つは $parent->child プロパティからの参照
$parent->child = $child;
このコードにおいて、仮に `$parent` と `$child` のスコープが抜け、それぞれの変数が破棄された瞬間を考えてみる。
1. `$child` 変数が破棄されると、該当オブジェクトの `refcount` は `2 – 1 = 1` に減少する。
2. しかし、`$parent->child` がまだそのオブジェクトを指しているため、`refcount` は `0` にならない。
3. 同様に `$parent` 変数が破棄されても、オブジェクト自体はメモリ上に残り続ける。これが、「参照カウント方式の限界である循環参照（Circular Reference）」の物理的メカニズムである。
—
2. 循環参照を誘発する3大アンチパターン
実務において、この循環参照は単なる「親子のリンク」だけでは発生しない。クロージャ、オブジェクト、配列が三位一体となったとき、Zend VMのヒープ内には恐るべき迷宮が構築される。
アンチパターン A：クロージャ（Closure）と `$this` の密結合
PHPのクロージャ（無名関数）は、`Closure` クラスのインスタンスとして生成される。厄介なのは、クロージャが外部スコープの変数やオブジェクトメソッド内で作成された場合、暗黙的あるいは明示的に `$this` やローカル変数をキャプチャ（保持）する点にある。
class MemoryLeakMachine {
private $callback;
public function initialize() {
// クロージャが $this をキャプチャし、さらにプロパティに自身を保持させる
$this->callback = function () {
// $this を参照しているため、Closureインスタンスは $MemoryLeakMachine を指す
return $this;
};
}
}
// 1リクエスト内でこれを大量に生成・破棄すると…
for ($i = 0; $i < 10000; $i++) {
$machine = new MemoryLeakMachine();
$machine->initialize();
// $machine はスコープを抜けるが、オブジェクト間の循環参照により即座にメモリ解放されない
}
Zend VM内部の挙動:
`MemoryLeakMachine` インスタンスのプロパティ `$callback` が `Closure` を保持し、その `Closure` がバインドされたスコープを通じて `MemoryLeakMachine` のインスタンス（`$this`）を保持する。これにより、`Object A -> Closure -> Object A` という閉じた参照ループが完成する。
アンチパターン B：オブジェクトプロパティの相互参照（双方向グラフ）
ORMやドメインモデル（DDD）の設計において、双方向関連（Bidirectional Association）を安易に実装すると、GCの負荷を爆発的に高める原因になる。
class Department {
/ @var Employee[] /
public array $employees = [];
}
class Employee {
public ?Department $department = null;
}
$dept = new Department();
$emp = new Employee();
// 循環の構築
$dept->employees[] = $emp;
$emp->department = $dept;
この構造は、数千、数万のエンティティが入り乱れるバッチ処理やAPIリクエストにおいて、一網打尽にメモリリークを引き起こす。通常の参照カウントでは絶対に `refcount` が `0` にならないため、PHPのバックグラウンドGCが回収するまでメモリ空間を圧迫し続けることになる。
アンチパターン C：配列内の自己参照とリファレンスコンテナ
配列（`HashTable`）内で参照代入（`&`）を使用した場合、Zend VMの内部バッファは非常にトリッキーな挙動を示す。
$matrix = [];
// 配列が自身を参照する
$matrix[‘self’] = &$matrix;
// この配列を破棄しても、HashTable内部のポインタが自分自身を指しているため、
// 参照カウントは永続的に 1 以上を維持し、メモリリークする。
unset($matrix);
—
3. Zend VMのガベージコレクション（GC）の真実とアルゴリズム
PHP 5.3以降に導入され、PHP 7/8で高速化されたGCは、実は「すべてのメモリリークを瞬時に解決する魔法の仕組み」ではない。
同期回収メカニズムの限界
Zend VMのGCは、すべてのメモリ解放をリアルタイムで行っているわけではない。パフォーマンスを犠牲にしないため、参照カウントが減少したものの `0` にならなかった `zval`（Candidate: 候補）を、「根腐れバッファ（Buffer of roots）」と呼ばれる二重リンクリストに蓄積していく。
1. バッファの満杯（デフォルトで10,000エントリ）、または明示的な `gc_collect_cycles()` の呼び出しが行われた時のみGCアルゴリズムが発動する。
2. GCアルゴリズムの動作フェーズ:
- 色分け（Coloring）: 候補となった `zval` を巡回し、参照カウントから互いの参照分を減算してシミュレーションを行う。
- マーク（Marking Gray）: 参照ループによって孤立している（外部からの参照がないにもかかわらず `refcount` が残っている）グループを特定し、灰色にマークする。
- スイープ（Sweeping White）: 孤立したグループの `zval` を白（解放対象）とし、メモリ空間から切り離して一括解放する。
この一連の処理（Tri-color marking algorithm）は、CPUキャッシュを大量に消費し、高負荷時には明確なレイテンシのスパイク（プチフリーズ）を引き起こす。つまり、「循環参照を作ってからGCに回収させる」設計自体が、ハイパフォーマンス・アーキテクチャにおいてはアンチパターンなのである。
—
4. 極限の最適化：循環参照を断ち切る設計と防衛策
プロフェッショナルなWebシステムアーキテクトは、GCの自動回収に依存せず、ライフサイクルの終端でメモリを完全かつ瞬時に解放するコードを書く。
対策1: 弱参照（WeakReference）の活用
PHP 7.4以降で導入された `WeakReference` は、オブジェクトの参照カウントをインクリメントせずに、そのインスタンスを監視・保持する究極の武器である。先ほどの双方向関連やキャッシュ機構において、子から親への参照に `WeakReference` を採用することで、循環参照を物理的に発生させない。
class OptimizedEmployee {
public ?WeakReference $departmentRef = null;
public function setDepartment(OptimizedDepartment $dept): void {
// refcountを増やさずに保持する
$this->departmentRef = WeakReference::create($dept);
}
public function getDepartment(): ?OptimizedDepartment {
return $this->departmentRef?->get();
}
}
class OptimizedDepartment {
public array $employees = [];
}
この実装であれば、`OptimizedDepartment` を `unset()` した瞬間に、従業員側の `WeakReference` は自動的に無効化され、オブジェクトグラフ全体が瞬時にメモリから消え去る。GCのバッファを汚染することもない。
対策2: 明示的なデストラクタ（`__destruct`）での参照切断
特にデーモンプロセスや長期稼働するWorker（Swoole, RoadRunnerなど）において、オブジェクトが破棄される直前に不要なプロパティの結合を断ち切ることは、メモリ爆発を防ぐ防衛策として有効である。
class DatabaseConnectionHolder {
private ?array $connections = [];
public function __destruct() {
// 循環参照や巨大なHashTableのリンクを明示的に破壊する
$this->connections = null;
}
}
—
5. セキュリティハックへの応用：オブジェクトインジェクションとGadget Chainの恐怖
メモリ管理と循環参照の知識は、単なるパフォーマンスチューニングに留まらない。PHPにおける最悪の脆弱性の一つである「PHPオブジェクトインジェクション（PHP Object Injection）」においても、この内部構造が深く関わっている。
攻撃者が `unserialize()` を通じて悪意あるクラスのインスタンスを復元する際、そのクラスの `__destruct()` や `__wakeup()` マジックメソッドが自動実行される。
さらに高度な攻撃（Gadget Chainの構築）では、アプリケーションコード内に存在する「不要になったオブジェクトの破棄プロセス（GCやデストラクタ）」の連鎖を利用し、意図しないメソッド呼び出しを引き起こす。
循環参照によって予期せぬタイミングでオブジェクトが破棄され、その結果として予期せぬ順序で `__destruct()` が発火することが、セキュリティ上の致命的なトリガーになるケースが存在する。メモリのライフサイクルを完全に制御下におくことは、高可用性だけでなく、堅牢なセキュリティの担保そのなのだ。
—
結びにかえて：真のアーキテクトの視座
PHPは「初心者にも優しい言語」という評価を長年受けてきたが、それは言語の表層的な側面を見た時の話に過ぎない。Zend VMのメモリ空間、HashTableの挙動、そして参照カウントとGCのメカニズムを直視したとき、PHPは極めてシビアで、チューニングの余地が残された深淵なプラットフォームへと姿を変える。
コードを書くとき、あなたの脳内には常にZend VMのヒープメモリが展開されていなければならない。
「このクロージャのキャプチャは参照ループを生んでいないか？」
「この双方向関連は `WeakReference` に置き換えられないか？」
その細部への執着こそが、数千万リクエストを涼しい顔で処理し続ける、真に強靭なWebシステムの礎となるのである。