はじめに：コードレビューで「動けばいい」を許さない理由
開発プロジェクトのコードレビューを行っていると、次のようなコードにしばしば遭遇する。
// 一見、綺麗に見えるオブジェクトの相互参照
class Node {
public ?Node $parent = null;
public array $children = [];
public function addChild(Node $child): void {
$this->children[] = $child;
$child->parent = $this; // 親子関係の構築
}
}
「リクエストが終わればプロセスごとメモリは解放されるのだから、多少のメモリリークなど問題ない」――そう考えていないだろうか。
数百万リクエストを捌くAPIサーバーや、長時間のバッチ処理において、この「些細なメモリリーク」は確実にFPMワーカーのメモリを食潰し、OOM Killerによる突然のプロセス強制終了、あるいはGC（ガベージコレクタ）の頻発によるレイテンシの劇的な悪化を招く。
Zend VMのメモリ管理モデルの本質、そして「参照カウント」と「循環参照コレクタ」が内部でどのようなステートマシーンとして動いているのか。その深層を理解していなければ、真に堅牢なPHPアプリケーションを設計することはできない。
今回は、PHPコアのメモリ管理の仕組みを丸裸にし、実務で絶対に踏むべき設計ルールを徹底的に解説する。
—
1. Zend VMのメモリ管理と参照カウントの限界
PHPの変数と値は、C言語レベルでは `zval`（Zend Value）という構造体として表現されている。PHP 7以降、`zval`のサイズは16バイトに最適化され、値の実体（文字列、配列、オブジェクトなど）はヒープ上に別アロケートされる。
`refcount` のインクリメントとデクリメント
各ヒープ上のデータ構造（`zend_refcounted`ヘッダを持つ構造体）には、そのデータを参照している変数の数を示す `refcount` が存在する。
- 変数が別の変数に代入されたり、関数の引数に渡されたり（参照渡しやコピーオンライト）すると、`refcount` がインクリメントされる。
- スコープを抜ける、あるいは `unset()` が呼ばれると、`refcount` がデクリメントされる。
- `refcount` が 0 に到達した瞬間、そのメモリは即座に解放される（Destructorの即時実行）。
この仕組みは非常に高速で予測可能だが、「致命的な構造的欠陥」を孕んでいる。それが循環参照（Circular Reference）だ。
なぜ循環参照は即座に解放されないのか？
冒頭の `Node` クラスの例を思い出してほしい。親が子を持ち、子が親を持つ構造を作ると、以下のような状態が生まれる。
1. 親オブジェクトの `refcount` は、親を指す変数 ＋ 子オブジェクトからの参照（`parent`プロパティ）により、少なくとも `2` 以上になる。
2. 子オブジェクトの `refcount` は、親の `$children` 配列からの参照により、少なくとも `1` 以上になる。
3. この状態で、親を指す変数を `unset()` しても、親の `refcount` は 「0にならない」（子から参照されているため）。
4. 同様に、子の `refcount` も親から参照されているため 「0にならない」。
結果として、スコープを抜けて外部からアクセスできなくなったにもかかわらず、`refcount` が 1 以上残るため、即時解放の網から漏れ落ちる。これがPHPにおけるメモリリークの根本原因である。
—
2. 循環参照コレクタ（Garbage Collector）の内部挙動
即時解放されないメモリに対処するため、Zendエンジンには 「循環参照コレクタ（Concurrent Cycle Collector）」 が組み込まれている。JavaやGoのような全自動のトレーシングGCとは異なり、PHPのGCは非常に特殊なヒューリスティック（推測的）アルゴリズムで動作する。
バッファリングと3つのカラー状態
循環参照の可能性がある複雑なデータ構造（配列やオブジェクト）が変更されると、Zendエンジンはそのポインタを「ルートバッファ（Root Buffer）」と呼ばれる二重連結リストにバッファリングする。バッファが一杯（デフォルトで10,000エントリー）になると、コレクションアルゴリズムが発動する。
コレクタは、バッファ内の各zvalに対して以下の 3色マーキングアルゴリズム を実行する。
1. Purple（紫 / 疑い）: 参照カウントがデクリメントされたが、まだ0になっていないコンテナ。ルートバッファに追加される。
2. Grey（灰色 / 減算スキャン）: 潜在的な循環参照を見つけるため、到達可能なすべてのメンバーの `refcount` を一時的に `-1` する。
3. White（白色 / 孤立判定）: 減算スキャン後、`refcount` が `0` になったもの。これらは「外部からの参照を失い、自分たち同士だけで参照し合っている（孤立した循環）」と断定される。
4. Black（黒色 / 生存）: `refcount` が `1` 以上残っているもの。外部からの健全な参照が存在するとみなし、`refcount` を元の値に戻して保護する。
白と判定されたコンテナ群は、最終的に一括して破壊（Destruct & Free）される。
なぜGCがパフォーマンスのボトルネックになるのか？
このGCアルゴリズムは、「すべての可能性のあるノードに対して `refcount` の増減シミュレーションを2回行う」ため、非常に重い処理である。
数万個のオブジェクトが複雑に絡み合うORMのエンティティなどを処理する場合、GCが頻発し、CPU時間を大幅に消費する。これが「PHPはメモリリークしにくいが、重い処理をさせると突発的にフリーズする」と言われる所以である。
—
3. 【実務リファレンス】メモリリークを回避する設計と実装パターン
では、実務の現場において、このZend VMの特性を理解した上でどのようにコードを書くべきか。
「循環参照を作らない設計」および「明示的なメモリ解放（Destruction）」を実装した堅牢なリコードを示す。
実装例：デストラクタ（`__destruct`）による循環の明示的切断
循環参照が避けられないドメインモデル（例えば、双方向グラフやDOMツリー構造）を扱う場合、スコープから抜ける前、あるいはオブジェクトのライフサイクルの終わりに、参照を明示的に断ち切るメソッド（`destroy()`など）を用意するのが最も確実でプロフェッショナルなアプローチである。
declare(strict_types=1);
namespace App\MemoryManagement;
/
- 堅牢な双方向ノード構造
- 循環参照によるメモリリークを自ら防ぐライフサイクル管理を持つ。
/
class ManagedNode
{
private ?ManagedNode $parent = null;
/ @var array
private array $children = [];
public function __construct(
private readonly string $name
) {
echo “Node [{$this->name}] が作成されました。\n”;
}
public function addChild(ManagedNode $child): void
{
$child->parent = $this;
$this->children[$child->getName()] = $child;
}
public function getName(): string
{
return $this->name;
}
/
- 【重要】循環参照を明示的に断ち切るディストラクターメソッド
- 親子間の相互参照をnullで上書きし、即座にrefcountを適正化する。
- これにより、Zend VMのGCの負荷を軽減し、即座にメモリを解放させる。
/
public function destroy(): void
{
// 子ノードを再帰的に破棄
foreach ($this->children as $child) {
$child->destroy();
}
// 参照を切断（ここでrefcountがデクリメントされる）
$this->children = [];
$this->parent = null;
echo “Node [{$this->name}] の参照が明示的に切断されました。\n”;
}
public function __destruct()
{
echo “Node [{$this->name}] のメモリが完全に解放されました。\n”;
}
}
// — 実行と検証のシミュレーション —
function runSimulation(): void
{
echo “— シミュレーション開始 —\n”;
$root = new ManagedNode(‘Root’);
$child1 = new ManagedNode(‘Child-A’);
$child2 = new ManagedNode(‘Child-B’);
$root->addChild($child1);
$root->addChild($child2);
// 通常、ここで $root を unset しても循環参照により即時解放されないケースがあるが、
// 明示的に destroy() を呼ぶことで安全にメモリを回収できる。
$root->destroy();
echo “— シミュレーション終了 —\n”;
}
// 実行
runSimulation();
実行結果のトレース
上記のコードを実行すると、次のような順序で出力される。
— シミュレーション開始 —
Node [Root] が作成されました。
Node [Child-A] が作成されました。
Node [Child-B] が作成されました。
Node [Child-A] の参照が明示的に切断されました。
Node [Child-B] の参照が明示的に切断されました。
Node [Root] の参照が明示的に切断されました。
Node [Child-A] のメモリが完全に解放されました。
Node [Child-B] のメモリが完全に解放されました。
Node [Root] のメモリが完全に解放されました。
— シミュレーション終了 —
このように、明示的な `destroy()` パターンを導入することで、Zend VMのGCサイクルの発動を待つことなく、決定論的（Deterministic）なメモリ管理を実現できる。長寿命なデーモンプロセスやLaravelのQueueワーカーなどにおいて、この設計はメモリ枯渇を防ぐ防壁となる。
—
4. チーフアーキテクトからの提言：実務で守るべき3つの鉄則
1. ORMの多段リレーションにおける「遅延ロードとメモリ肥大化」に警戒せよ
DoctrineやEloquentなどのORMを使用する際、エンティティ間で双方向リレーション（`BelongsTo` / `HasMany`）を安易に定義すると、数千件のレコードをロードした瞬間に巨大な循環参照グラフが生成される。バッチ処理では必ず `EntityManager::clear()` や、不要になったオブジェクトの明示的なアンセット・破棄を行え。
2. 静的プロパティ（`public static`）へのオブジェクトキャッシュに注意せよ
シングルトンパターンや静的プロパティにオブジェクトを保持し続けると、そのオブジェクトはアプリケーションライフサイクル全体にわたって `refcount >= 1` を維持し続ける。不要になったキャッシュは必ず明示的にクリアする仕組みを作ること。
3. GCの設定値（`zend_extension` / `memory_limit`）を過信しない
`gc_collect_cycles()` をコード内で手動実行することは最終手段に過ぎない。GCを頻繁に呼び出さなければならないアーキテクチャ自体が設計不良のシグナルである。メモリリークを起こさないクリーンな構造（非循環・単方向グラフの維持）こそが、高スループットなWebシステムの要諦である。
PHPは「捨てられる言語」ではない。その内部エンジン（Zend VM）の挙動を完全に掌握した者にとって、極めて高速で予測可能な、信頼性の高いプログラミングプラットフォームである。今日のコードレビューから、メモリのライフサイクルに対する意識を一段引き上げてほしい。