こんにちは。普段、他の高水準な言語（JavaやPython、あるいはJavaScriptなど）をバリバリと使いこなし、モダンなフレームワークの設計にも精通しているあなたなら、PHPのコードを書くことは朝飯前でしょう。
しかし、ふと立ち止まって「PHPのメモリ管理って、実はどうなっているんだろう？」と気になったことはありませんか？
「PHPはリクエストが終わればメモリは全解放されるから、細かいことは気にしなくていい」——そう教わってきたかもしれません。確かに単発のWebスクリプトであればそれで逃げ切れますが、長期稼働するCLIバッチ処理、あるいはSwooleやRoadRunnerといった常駐型のアプリケーションランタイムを導入した途端、じわじわとメモリを食いつぶす「あの悪夢（メモリリーク）」に直面し、頭を抱えた経験があるはずです。
今回は、PHPの心臓部であるZendエンジンがメモリとどう格闘しているのか、そして私たちが無意識に書いてしまう「循環参照のアンチパターン」が内部でどのような悲劇を生んでいるのかを、低レイヤの視点から紐解いていきましょう。ここを理解すると、PHPの裏側が驚くほどクリアに見えてきますよ。
—
1. Zendエンジンを支配する「参照カウント」の限界
PHPのメモリ管理の基本は、すべての変数やデータ構造（Zval構造体）に付随する「参照カウント（Refcount）」です。
ある変数が別の変数に代入されたり、関数の引数として渡されたりすると、そのZvalを指し示すポインタが増え、参照カウントがインクリメントされます。逆にスコープを抜けて変数が破棄されると、参照カウントがデクリメントされます。そして、このカウントが「0」になった瞬間、Zendエンジンは即座に`efree()`を呼び出し、ヒープメモリからその領域を解放します。この仕組み自体は非常にシンプルで、効率的です。
「ゾンビ」を生み出す循環参照
しかし、この美しくシンプルな仕組みには、致命的なアキレス腱があります。それが「循環参照（Circular Reference）」です。
例えば、オブジェクトAがプロパティを介してオブジェクトBを持ち、同時にオブジェクトBもプロパティを介してオブジェクトAを持っている状態を想像してください。
[オブジェクト A] ──(プロパティ)──> [オブジェクト B]
▲ │
└──────────(プロパティ)─────────────┘
ここで、外部からオブジェクトAとBへの直接の参照（通常の変数など）を断ち切ったとします。この時、何が起きるでしょうか？
1. 外部変数からの参照が消えたため、オブジェクトAの参照カウントは `1`（Bから指されている）になります。
2. オブジェクトBの参照カウントも `1`（Aから指されている）になります。
3. どちらの参照カウントも 0になりません。
結果として、誰からもアクセスできない「孤立した空間」であるにもかかわらず、お互いを指し合っているがために参照カウントが落ちず、メモリ上に幽霊のように居座り続けます。これが、PHPにおけるメモリリークの正体です。
—
2. 循環参照を誘発する「3大アンチパターン」
実務の現場で、私たちはどのようなコードを書いたときにこの罠にハマるのでしょうか。特にモダンなPHPコードで頻発する3つのアンチパターンを、内部構造のイメージとともに見ていきましょう。
アンチパターン A：クロージャによる自分自身のキャプチャ
PHPのクロージャ（無名関数）は非常に強力ですが、use構文や `$this` の自動バインドによって、簡単に循環参照を作り出します。
class TaskWorker {
private ?Closure $onComplete = null;
public function boot(): void {
// $this をキャプチャしたクロージャをプロパティに保持させる
$this->onComplete = function() {
// ここで $this を参照しているため、クロージャは $this を強く握りしめる
echo “Task completed by: ” . spl_object_hash($this) . “\n”;
};
}
}
// 実行例
$worker = new TaskWorker();
$worker->boot();
// $worker を破棄したつもりでも、クロージャが $worker ($this) を指し、
// $worker がクロージャ ($onComplete) を指しているため、メモリに残る
unset($worker);
内部の動き：
Zendエンジン視点では、`TaskWorker` オブジェクトのZvalの中にクロージャのZvalがあり、そのクロージャの内部構造体（`zend_closure`）が専用のスコープとして `$this` のポインタ（つまり元の `TaskWorker`）を保持しています。見事な閉じたループの完成です。
アンチパターン B：オブジェクトプロパティの相互参照（双方向関連）
ORM（Object-Relational Mapping）やドメインモデル設計でやりがちなミスです。「親から子へ、子から親へ」アクセスできるように双方向のプロパティを持たせると、容易に循環が起きます。
class Node {
public ?Node $parent = null;
public array $children = [];
public function addChild(Node $child): void {
$child->parent = $this; // 子から親への参照
$this->children[] = $child; // 親から子への参照（配列）
}
}
$parent = new Node();
$child = new Node();
$parent->addChild($child);
// 親子の変数をunsetしても、お互いに参照し合っているためメモリから消えない
unset($parent, $child);
アンチパターン C：配列内での自己参照・複雑な参照の絡み合い
配列（PHPの内部実装としては `HashTable`）の中でも、参照代入（`&`）を使うことで恐ろしい罠が仕掛けられます。
$matrix = [];
// 配列自身をその要素の中に参照として突っ込む（自己参照）
$matrix[‘self’] = &$matrix;
// この瞬間、$matrix の参照カウントは 2 になり、
// 変数 $matrix を unset しても、配列自身が自分自身を指しているためメモリリークする
unset($matrix);
—
3. Zendエンジンの救済措置：ガベージコレクタ（GC）の裏側
「じゃあ、PHPで循環参照を書いたら最後、プロセスが落ちるまでメモリを圧迫し続けるの？」と不安になったかもしれませんが、安心してください。PHP 5.3以降、Zendエンジンには「循環参照ガベージコレクタ（Concurrent Cycle Collector）」が搭載されています。
PythonやJavaが採用している「完全なトレーシングGC」とは異なり、PHPのGCは非常にユニークで軽量なアルゴリズムで動いています。そのアルゴリズムの全貌を、3つのステップで紐解きましょう。
1. バッファリング（Root Buffer）：
Zendエンジンは、参照カウントが減少したものの「0にはならなかった」Zval（コンテナ型、つまり配列やオブジェクト）を見つけると、それを「ガベージの候補（Root）」として専用のルートバッファに記録します。すべてを常時監視するのではなく、このバッファが一杯になったタイミング（デフォルトでは10,000件）でのみGCが発動します。
2. 色分けとカウントダウン（擬似的な参照減算）：
GCが走ると、バッファ内のルートからスタートし、子要素をたどって「もし外部からの参照を無視して、この内部の繋がりだけで参照カウントを1ずつ減らしたら、カウントはいくつになるか？」をシミュレーションします（疑似的に `refcount` をマイナスする）。
3. スイープと解放：
シミュレーションの結果、参照カウントが「0」に落ちたZvalこそが、真の「循環参照の迷子たち」です。エンジンはこれらをマークし、最終的にメモリから一網打尽に解放します（逆に、外部からまだ正当に参照されているものは、カウントを元に戻して見逃します）。
この仕組みがあるおかげで、通常のWebリクエストのように「短命なプロセス」であれば、GCが裏側でいい感じに後始末をしてくれます。
—
4. アーキテクトが知るべき「実践的な回避・対策の極意」
GCがあるからといって、循環参照を野放しにしていいわけではありません。GCのアルゴリズムは、バッファがいっぱいになるたびにツリーを走査するため、CPUサイクルを確実に消費（パフォーマンス低下）します。
特に、冒頭で触れたSwooleなどの常駐型プロセス（Long-running process）では、リクエストごとにメモリが回収しきれないと、数万リクエストを処理しただけであっという間にOOM（Out of Memory）を引き起こします。
以下のベストプラクティスを設計に組み込み、クリーンなメモリ空間を維持しましょう。
① スコープ抜けのタイミングで明示的にリンクを切る（Destructorの活用）
オブジェクトが不要になった際、相互参照しているプロパティに `null` を代入して意図的にリンクを切断するメソッド（`__destruct` や明示的な `close()` メソッド）を用意します。
class ConnectionHolder {
private ?Resource $res = null;
private ?Closure $callback = null;
public function cleanup(): void {
$this->res = null;
$this->callback = null; // クロージャや外部リソースの参照を断つ
}
}
② WeakReference（弱参照）を活用する（PHP 7.4〜）
モダンなPHP（7.4以降）の最大の武器の一つが `WeakReference` です。
これを使うと、「オブジェクトの参照カウントを増やさずに、インスタンスを監視・保持する」という離れ業が可能になります。先ほどの双方向関連の「子から親への参照」などに最適です。
class ParentNode {
// 通常のプロパティ
}
class ChildNode {
public ?WeakReference $parent = null;
public function setParent(ParentNode $parent): void {
// 参照カウントを増やさずに保持する
$this->parent = WeakReference::create($parent);
}
getPropertyFromParent() {
// アクセス時はラップを外して利用する
return $this->parent?->get();
}
}
`WeakReference` を使えば、親が破棄された瞬間に子は自動的に `null` を返すため、循環参照そのものが物理的に発生しなくなります。これは常駐型アプリケーションにおけるメモリリーク対策の強力な切り札です。
—
5. おわりに
いかがでしたでしょうか？
「PHPは言った通りに動く簡単な言語」という印象から、「ZendエンジンのZvalと参照カウント、そしてGCの挙動をコントロールして極限までパフォーマンスを引き出すべき奥深い言語」へと、見え方が少し変わったのではないでしょうか。
フレームワークが便利に隠蔽してくれている抽象化の裏側で、メモリ空間がどのように息をしているのかを想像できるようになると、あなたの書くコードの質は一段と研ぎ澄まされます。
常駐型アプリケーションに挑むとき、あるいは巨大なデータ構造を扱うバッチを書くときは、ぜひ今回の「循環参照のメカニズム」と「WeakReferenceの知見」を思い出してください。
あなたの背中を、この確かな低レイヤの知識が力強く支えてくれるはずです。それでは、また次のアーキテクチャの旅でお会いしましょう。