こんにちは。日々のモダンなWebアプリケーション開発、お疲れ様です。JavaやGo、あるいはNode.jsといった他言語の高水準な環境を経験されてきた方ほど、PHPの「1リクエストが終われば全メモリがきれいさっぱり解放される」というシンプルで潔いライフサイクルに、ある種の心地よさを感じていることでしょう。
しかし、ドメインモデルが複雑化し、DDD（ドメイン駆動設計）の戦術的パターンをフルに活かした巨大なオブジェクトグラフを構築し始めたり、長寿命なプロセス（RoadRunnerやOpenSwooleなど）を用いた非同期・常駐型のPHPアプリケーション運用に踏み出した途端、奇妙な現象に直面したことはありませんか？
「なぜかリクエストを重ねるごとにプロセスのRSS（Resident Set Size）がじわじわと肥大化していく……」
「ピークタイムを過ぎてもメモリが開放されず、OOM Killerにプロセスが強制終了させられる……」
その原因、実は「循環参照」と、PHPの心臓部であるZend VMの「参照カウント（Reference Counting）の罠」にあるんです。
今回は、他の言語のGC（ガベージコレクション）の挙動とは一味違う、PHP（Zend VM）のメモリ管理の裏側を覗きながら、ValgrindやXdebugといったプロファイリングツールを駆使してメモリリークの元凶を鮮やかに炙り出す極意を、順を追って紐解いていきましょう。ここを理解すれば、PHPの裏側が驚くほどクリアに見えるようになりますよ。
—
1. Zend VMのメモリ管理：参照カウントの限界と「バッファ」の正体
まず、PHPのメモリ管理の基本を押さえましょう。PHPの変数やオブジェクトは、C言語ベースのzval（Zend Value）という構造体としてメモリ上に存在します。
すべてのzvalには `refcount` という整数値（参照カウント）が備わっています。
- 変数が別の変数に代入されたり、関数の引数として渡されたりすると、`refcount` がインクリメント（+1）されます。
- 変数がスコープを抜けて破棄されたり、`unset()` されたりすると、`refcount` がデクリメント（-1）されます。
- そして、この `refcount` が 0 になった瞬間、即座にメモリから解放（efree）されます。
これが、PHPが「GCを意識せずに高速に動く」と言われる最大の理由であり、極めて効率的な仕組みです。……しかし、ここに致命的な死角が存在します。それが「循環参照（Circular Reference）」です。
オブジェクトグラフが描く「逃げ場のない輪」
例えば、親オブジェクトが子オブジェクトの参照を持ち、同時に子オブジェクトも親オブジェクトへの参照（バックリファレンス）を持っているケースを想像してください。
class ParentNode {
public ?ChildNode $child = null;
}
class ChildNode {
public ?ParentNode $parent = null;
}
// 循環の構築
$parent = new ParentNode();
$child = new ChildNode();
$parent->child = $child;
$child->parent = $parent;
// スコープの終わり、あるいは明示的なunset
unset($parent, $child);
このコードを実行したとき、何が起きるでしょうか？
`$parent` と `$child` の変数はスコープから消え去りますが、お互いに相手を指し合っているため、それぞれのオブジェクトの `refcount` は 「1」残ったまま になります。
`refcount` が 0 にならないため、Zend VMは「まだどこかから使われている」と判断し、メモリを解放できません。変数のスコープは消えているのに、アクセス不能なメモリ領域（ガベージ）がヒープ上にプカプカと浮いたまま残ってしまう。これが、PHPにおけるメモリリークの正体です。
—
2. 救世主「循環ガベージコレクタ（Concurrent Garbage Collector）」の仕組み
「ちょっと待って、PHPにはPHP 5.3から循環GCが入ったはずじゃ？」
その通りです。よくご存知ですね。
Zend VMには、この参照カウントのループを検知して回収するための「バッファリングGC」が備わっています。仕組みを簡単に言うと、こうです。
1. バッファへの蓄積: 変数の `refcount` がデクリメントされた際、もしそれが「0にはならなかったが、減った」場合、Zend VMはそのzvalを「もしかしたら循環参照の輪の一部かもしれない候補（Roots Buffer）」として専用の二重連結リストに記録します。
2. バッファの満杯化: バッファが一定数（デフォルトでは10,000エントリー）に達すると、GCアルゴリズムが発動します。
3. 色の塗り替え（シミュレーション）:
- 候補となったzval群を辿り、一度参照カウントを仮想的に減らすシミュレーションを行います（「灰色」にマーク）。
- もし外部からの参照がゼロで、自分たち同士の参照だけでカウントが保たれていることが判明した場合、それらは「本当に孤立した循環参照」であると判定されます（「黒色」にマーク）。
4. 解放: 黒色と判定されたzval群のメモリがまとめて解放されます。
なぜ、それでも大規模アプリでメモリリークが起きるのか？
「じゃあGCが勝手に片付けてくれるなら安心じゃないか」と思われるかもしれませんが、ここに落とし穴があります。
- バッファが溢れるまでのタイムラグ: バッファが10,000件に達するまではGCが走りません。大規模なフレームワークやバッチ処理では、この閾値に達する前にメモリが限界を迎えることがあります。
- 常駐型プロセス（Swooleなど）の罠: 1リクエストごとにプロセスが破棄されるFPMモデルであればリクエスト終わりに全メモリがOSに返還されますが、常駐型プロセスではプロセスが生き続けるため、GCの回収漏れが致命的な蓄積（累積リーク）につながります。
- C拡張やブラックボックス: 自社製やサードパーティのCエクステンションが絡む複雑なデータ構造では、ZendのGCがうまく追跡できないケースが存在します。
では、この目に見えない循環参照を、実際の開発現場でどうやって特定すればよいのでしょうか？ここからが実践編です。
—
3. 実践：Valgrindを用いたメモリリークの徹底解析
PHPのコアや拡張モジュールレベルでメモリリークを完全に暴く際、最強の武器となるのがLinuxのメモリデバッガ Valgrind（特にその中の `memcheck` ツール）です。
PHPをデバッグビルド（`–enable-debug`）してValgrindを実行することで、「どこで何バイトのメモリが解放されずに残ったか（Reachable / Definitely Lost）」をC言語レベルで正確に特定できます。
ステップ1: デバッグ用PHPのビルドと実行
ソースからPHPをビルドする際、Zendのメモリマネージャ（ZMM）をバイパスして直接OSの `malloc`/`free` を使わせることで、Valgrindが正確にリークを検知できるようにします。
環境変数を設定してZendMMを無効化し、Valgrindを実行する
USE_ZEND_ALLOC=0 valgrind –leak-check=full –show-leak-kinds=all –log-file=valgrind_report.txt php leak_script.php
ステップ2: レポートの読み解き方
生成された `valgrind_report.txt` には、次のようなC言語レベルのコールスタックが出力されます。
==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 10
==12345== at 0x4C2B1FB: malloc (vg_replace_malloc.c:299)
==12345== by 0x1A2B3C: zend_string_alloc (zend_string.h:135)
==12345== by 0x1F4E5A: zim_MyService_processData (myservice.c:88)
…
「おっ、どのPHP拡張やどの関数（この例では `zim_MyService_processData`）のどの行でメモリが確保されたまま放置されたか」が手に取るようにわかりますよね。これにより、疑わしいPHPのコードブロックをピンポイントで特定できます。
—
4. Xdebugとプロファイラを活用したオブジェクトグラフの可視化
「C言語レベルのValgrindは少しハードルが高い……」という場合は、アプリケーション層で Xdebug のガベージコレクション統計機能や、Memcached/APCu/Cachegrind を組み合わせたプロファイリングを活用しましょう。
XdebugによるGC統計の出力
`php.ini` でXdebugのGCトラッキングを有効にします。
[xdebug]
xdebug.mode = gcstats
xdebug.gcstats_output_dir = /tmp
スクリプトを実行すると、`/tmp/cachegrind.out.gcstats…` のようなファイルが生成されます。これを視覚化ツール（KCacheGrindやQCacheGrindなど）で読み込むと、「どのリクエストのどのタイミングでどれだけのzvalがGCバッファに蓄積され、回収されたか」のタイムラインがグラフ化されます。
もしグラフの右肩上がりが止まらない（GCが回収しきれていない）箇所があれば、そこに強烈な循環参照が潜んでいる確実な証拠です。
—
5. 循環参照を防ぐためのモダンな設計アプローチ
デバッグ手法を知ることも大切ですが、そもそも「循環参照を生みにくいコードベース」を設計することが、シニアエンジニアとしての真骨頂です。
1. 弱参照（WeakReference）の積極的な活用
PHP 7.4以降、待望の `WeakReference` クラスが導入されました。これを使うことで、参照カウントを増やさずにオブジェクトを指し示すことができます。
先ほどの親子関係の例を、`WeakReference` を使って安全に書き換えてみましょう。
class ParentNode {
public ?ChildNode $child = null;
}
class ChildNode {
// 親への参照はWeakReferenceにする
private ?WeakReference $parentRef = null;
public function setParent(ParentNode $parent): void {
$this->parentRef = WeakReference::create($parent);
}
public function getParent(): ?ParentNode {
return $this->parentRef?->get();
}
}
$parent = new ParentNode();
$child = new ChildNode();
$parent->child = $child;
$child->setParent($parent);
// この状態であれば、parentとchildをunsetした瞬間に
// refcountはスムーズに0になり、即座にメモリが解放されます！
unset($parent, $child);
ドメインモデルで双方向の関連（Bidirectional Association）を持たせざるを得ない場合、バックリファレンス側に `WeakReference` を採用することは、メモリリークを防ぐための極めてエレガントで現代的な解法です。
2. スコープとライフサイクルの明確な分離
サービスクラスやハンドラクラスの中に、リクエストをまたぐような大きな状態（State）をプロパティとして保持させない（いわゆるステートレスな設計の徹底）ことも、意図せぬメモリ肥大を防ぐための王道です。
DI（依存性注入）コンテナを使う際も、シングルトンとして登録されたオブジェクトの内部に、リクエストスコープのオブジェクト（リクエスト情報やユーザー情報など）を直接プロパティとして保持させないよう、ファクトリーやクロージャを通じて遅延評価・スコープ分離を行う設計を心がけましょう。
—
おわりに
いかがでしたでしょうか？
今回は、PHPの裏側で動くZend VMの参照カウントの仕組みから、循環参照が生まれるメカニズム、そしてValgrindやWeakReferenceを用いた実践的なデバッグ・回避アプローチまでを深く掘り下げて解説しました。
「PHPだからメモリ管理は適当でもいいや」という時代は終わり、モダンなWebアプリケーションや常駐型プロセスを支えるエンジニアにとって、メモリのライフサイクルをコードレベル、さらにはエンジンレベルで脳内トレースできる能力は、間違いなく強力な武器になります。
ぜひ、あなたのプロジェクトでも、プロファイラを片手にメモリの足音に耳を澄ませてみてください。PHPの裏側がより一層美しく、そして頼もしく見えてくるはずですよ。