こんにちは。PHPの裏側で動いているエンジン、そしてWebリクエストという一瞬の命のやり取りにロマンを感じるエンジニアの皆さん。
他のモダンな言語、例えばJavaScript（V8）やPython、Javaあたりを深く触ってきた人ほど、PHPの世界に入ったときに「あれっ？」と引っかかるポイントがありますよね。それがメモリ管理、特にガベージコレクション（GC）と循環参照の罠です。
「PHPはリクエストが終わればメモリは全解放されるんだから、メモリリークなんて気にする必要ないでしょ？」
──もしあなたがそう思っているなら、大規模なSaaSや長期稼働するCLIデーモン（Worker）を扱う現場で、いつか静かなるメモリ枯渇（OOM Killerの悲劇）に足元をすくわれることになります。
今回は、PHPの内部エンジン（Zend VM）がメモリをどう扱い、なぜ「クロージャ・オブジェクト・配列」のコンボが最悪の循環参照を爆誕させるのか。そして、それをどう検知し、どう美しく断ち切るべきか。その極意を、低レイヤの視点を交えながら紐解いていきましょう。
—
1. Zend VMのメモリ管理の基本：参照カウントと「ルートバッファ」
PHPの根幹であるZend Engineでは、変数の値やオブジェクトはすべて `zval`（Zend Value）という構造体で管理されています。オブジェクトは `zend_object` としてヒープ上に確保され、その実体を指し示す `zval` のなかで 参照カウント（refcount） が管理されています。
[ zval ] —> (refcount: 1) —> [ zend_object (インスタンス) ]
通常、スコープを抜ければ `zval` の参照カウントはデクリメントされ、`0` になった瞬間に即座にメモリから消し去られます。これがPHPの基本であり、非常に高速な理由です。
しかし、「自分自身を指す、あるいは仲間同士で輪になって指し示す」 という歪な構造を作ってしまうと話が変わります。
循環参照の悪夢：refcountが「0にならない」
例えば、オブジェクトAがプロパティでオブジェクトBを持ち、オブジェクトBが何らかの拍子にオブジェクトAを参照しているとします。それぞれの参照カウントは `2` から始まります。
ここで、外部からの参照を断ってスコープ外に出たとしても、お互いがお互いを指し合っているため、参照カウントは「0」にならず「1」で踏みとどまってしまいます。
[外から捨てられたオブジェクトA] <---(参照)---> [外から捨てられたオブジェクトB]
(refcount: 1) (refcount: 1)
この「誰からもアクセスできないのに、メモリ上に居座り続けるゾンビ」を回収するために、PHP 5.3以降には循環ガベージコレクタ（Concurrent Garbage Collector）が搭載されました。
Zend Engineは、参照カウントが減ったもののゼロにならなかった `zval` を「もしかしたら循環参照のメンバーかもしれない」とみなし、いったんルートバッファ（Root Buffer）という特設リングに放り込みます。そしてバッファが溢れるか、明示的に `gc_collect_cycles()` が呼ばれたときに、グラフ探索（一度カウントを減らして、元に戻らないものを探すアルゴリズム）を行って一網打尽に解放します。
ここまでは教科書通りの話ですね。問題は、このGCを完全にハメてしまう「現代的なアンチパターン」が存在することです。
—
2. クロージャ、オブジェクト、配列が織りなす「最悪のコンボ」
実務で私たちが書くモダンなPHPコード、例えばDIコンテナ、イベントリスナー、あるいはドメイン駆動設計（DDD）のレイヤー構造のなかで、無意識にこの循環参照のコンボを炸裂させてしまっているケースがあります。
次のコードを見てください。一見、なんの変哲もないきれいなクラス設計に見えますよね。
callbacks[$name] = $callback;
}
public function setProcessor(object $processor): void
{
$this->processor = $processor;
}
}
// — 実際の利用シーン —
$context = new OrderContext();
// クロージャを定義
$logger = function () use ($context) {
// 2. クロージャが外側のスコープの $context をuse（キャプチャ）している
// ここで クロージャ -> $context への強力な参照が発生する
echo “Processing order in context…\n”;
};
// 3. $context にクロージャを登録
$context->registerCallback(‘log’, $logger);
// 4. さらに、クロージャが保持するレキシカル変数を介して、
// $context 自身がクロージャを所有するという「閉じた輪（環）」が完成する
内部で何が起きているか？
1. `$context` はプロパティの配列 `$callbacks` の中にクロージャ（`$logger`）を保持しています。（`$context` ⇒ クロージャ）
2. クロージャは `use ($context)` によって、レキシカルスコープの変数をキャプチャしています。Zend VMの内部では、クロージャオブジェクトが生成される際、キャプチャされた変数の参照がクロージャの内部構造体（`zend_closure`）にガッチリと結び付けられます。（クロージャ ⇒ `$context`）
結果として、「`$context` ⇒ 配列 ⇒ クロージャ ⇒ `use`スコープ経由 ⇒ `$context`」 という、完璧な循環の輪が形成されます。
これが1回や2回のスクリプト実行であれば、リクエスト終了時にOSプロセスごとメモリが吹き飛ぶため実害はありません。しかし、Worker型のプロセス（Swoole、RoadRunner、ReactPHP、あるいは長寿命なQueueワーカー）上でこれが数千、数万回とループで生成・破棄された瞬間、Zend EngineのGCが回収しきれないメモリリークの地獄が始まります。
—
3. なぜこの問題に気づきにくいのか？
言語仕様上、PHPはガベージコレクションを自動で行ってくれるため、開発者は普段メモリの「線引き」を意識する必要がありません。
しかし、クロージャが絡むと、PHPの静的解析や直感的なコードリーディングが非常に難しくなります。
「誰が誰を指しているか」の矢印が、オブジェクトのプロパティだけでなく、クロージャの「束縛（Binding）とスコープ（Scope）」という、コードの見た目からは追いにくいレイヤーに隠れてしまうからです。
特に、フレームワークのフック機構やミドルウェアのパイプライン処理などで、「とりあえず何でもクロージャで囲んで後から実行する」という設計を多用すると、知らず知らずのうちに巨大な循環参照の網の目を広げることになります。
—
4. 静幾解析ツール（PHPStan）による「見えない鎖」の検出
幸いなことに、現代のPHPエコシステムには強力な味方がいます。PHPStan や Psalm です。
これらを最高レベル（Level 8 または 9）で運用することで、コードの不審な結合をあらかじめ炙り出すことができます。
特にPHPStanでは、標準のルールに加え、メモリリークや循環参照の温床になりやすい記述を検知するための拡張や、独自のカスタムルールを組み込むことが可能です。
検出のための静的解析アプローチ
1. `use ($this)` や `use ($var)` の厳格な監視
クラスメソッド内でクロージャを作る際、安易に `$this` や重いオブジェクトを `use` していないか。PHPStanのコードスニペット解析（custom rules）を書き、`Closure` の `use` 句にオブジェクトが含まれている箇所を警告するように設定します。
2. アナライザーによるライフサイクルの追跡
依存性注入（DI）のコンテナ内で、サービスが自分自身を指すコールバックを登録していないか、静的解析の型推論（Type Inference）を用いて「循環の可能性のあるパス」を検知します。
例えば、以下のように PHPStan のカスタムルール（抜粋概念）を仕込むことで、クロージャ内での `$this` やコンテキストのキャプチャを厳しく制限できます。
// PHPStanのルール等で弾くべきアンチパターンの例
$this->on(‘event’, function() {
// $thisをそのままクロージャに巻き込むと循環参照の引き金になりやすい
$this->doSomething();
});
これを、「弱参照（WeakReference）」 を使って安全にキャプチャするように書き換えるのが、シニアエンジニアの作法です。
—
5. 循環参照を断ち切る「WeakReference」という名のメス
PHP 7.4以降、私たちは `WeakReference` という非常に強力な武器を手に入れました。
これを使えば、オブジェクトを参照しつつも、参照カウント（refcount）を増やさないという神業が可能になります。
先ほどのアンチパターンを、`WeakReference` を使って美しくリファクタリングしてみましょう。
callbacks[$name] = $callback;
}
}
$context = new OrderContext();
// WeakReferenceでラップして外側から持たせる
$weakContext = WeakReference::create($context);
$logger = function () use ($weakContext) {
// クロージャ内から安全にターゲットを取得する
// すでに元のオブジェクトが消滅していれば null が返る
$ctx = $weakContext->get();
if ($ctx === null) {
echo “Context has already been garbage collected.\n”;
return;
}
echo “Processing order safely…\n”;
};
$context->registerCallback(‘log’, $logger);
// ここで $context をアンセット、あるいはスコープアウトさせると、
// クロージャは WeakReference しか持っていないため、参照カウントが「0」になり、
// 迷うことなく即座にメモリから解放されます！
なぜこれがアーキテクチャ的に優れているのか？
`WeakReference` を挟むことで、オブジェクトグラフの「強い結合（Strong Reference）」が断ち切られます。
「あるオブジェクトが存在している間だけ動いてほしいけれど、お互いの生存期間を縛り合いたくない」という、非同期処理やイベント駆動設計における典型的なジレンマを、PHPの低レイヤ仕様に逆らわずに解決できるのです。
—
6. 先輩アーキテクトからのメッセージ
PHPは「簡単に書けて、すぐに動く」素晴らしい言語です。しかし、言語の進化とともに非同期ランタイム（Swoole, ReactPHPなど）や長期稼働プロセスが当たり前になった今、私たちは「メモリのライフサイクル」にほんの少しだけ自覚的になる必要があります。
- クロージャを書くときは、「何を `use` しようとしているか？」をコンテキストの矢印として脳内を描くこと。
- 長寿命なオブジェクトやコンテナにクロージャや配列を登録するときは、循環参照の罠がないかを疑うこと。
- どうしても結び付けたいときは `WeakReference` というスマートなメスを入れること。
ここを理解できれば、あなたの書くPHPコードは、ただ動くだけのスクリプトから、過酷な本番環境でも微動だにしない「堅牢なWebシステム」へと生まれ変わります。
さあ、今日のコードから、見えない鎖をスッキリと断ち切ってみませんか？