こんにちは。普段は大規模なWebシステムのアーキテクチャ設計や、PHPのコアパフォーマンスチューニングに向き合っています。
JavaやGo、Rubyといった他の高水準言語を深く経験された方ほど、PHPの「1リクエストが終わればプロセス（厳密にはリクエストコンテキスト）ごとにメモリが全解放される」というシンプルさに驚き、同時に「なぜモダンなPHPフレームワークは数万のオブジェクトを生成しても高速なのか？」という疑問にぶつかることが多いのではないでしょうか。
特に、長期稼働するDaemonプロセス（Swoole、RoadRunner、あるいはReactPHPなど）を実戦投入し始めると、「メモリリーク」の二文字がエンジニアの夜を暗くします。
今回は、PHP 7および8を支えるZend Engineの心臓部——「世代別GC（ガベージコレクション）と参照カウントの協調動作」について、低レイヤのメモリ管理の視点から紐解いていきましょう。ここを理解すると、PHPが単なる「スクリプト言語」から、予測可能で堅牢な高スループットエンジンへと進化を遂げた理由が、綺麗に見えるようになりますよ。
—
1. そもそもPHPのメモリ管理の基本はどうなっているのか？
他の多くの言語（Javaなど）では、JVMが独自の巨大なヒープ領域を管理し、アプリケーションの実行とは非同期に「Stop-The-World（STW）」を引き起こして不要なオブジェクトを回収しますよね。
しかし、PHP（Zend Engine）のメモリ管理は、OSから見れば非常にプリミティブでありながら洗練されています。すべての変数は `zval`（Zend Value）というC言語の構造体として表現され、基本的には「参照カウント方式（Reference Counting）」によって寿命が管理されています。
/ 概念的なイメージ（実際のZend Engineの構造体とは異なります） /
typedef struct _zval_struct {
zend_value value; // 実際の値（int, string, array, objectなど）
union {
uint32_t type_info; // 型情報
} u1;
union {
uint32_t refcount; // 参照カウント
} u2;
} zval;
変数が代入されたり、関数に引数として渡されたりするたびに、この `refcount` がインクリメント（増加）され、スコープを抜けて変数が破棄されるとデクリメント（減少）されます。そして、この `refcount` が `0` になった瞬間、即座にメモリは解放されます。
この仕組みは非常に高速で、通常のWebリクエストのライフサイクル内であれば、複雑なGCアルゴリズムを走らせる必要すらないほど効率的です。
—
2. 参照カウントの致命的な弱点：循環参照
しかし、参照カウント方式には構造的な弱点があります。それが「循環参照（Circular Reference）」です。
例えば、オブジェクトAがプロパティとしてオブジェクトBを持ち、同時にオブジェクトBがオブジェクトAを参照しているようなケースを考えてみてください。
class Node {
public ?Node $child = null;
}
$a = new Node();
$b = new Node();
$a->child = $b;
$b->child = $a; // 循環参照の発生
// ここで変数をアンセットする
unset($a, $b);
このコードを実行すると、`$a` と `$b` のスコープ上の名前は消えますが、お互いに相手を指し合っているため、それぞれの `zval` の `refcount` は `1` のまま残ってしまいます。
結果として、「誰もアクセスできないのに、メモリ上に永遠に残骸として居座り続けるメモリリーク」が発生します。
従来のPHP 5.x時代、この問題に対処するため、エンジンはオブジェクトが破棄されるたびにすべての複雑な構造を総当たりでチェックしようとし、大規模なアプリケーションでは深刻なパフォーマンス低下を引き起こしていました。
—
3. Zend Engine 3.0以降の革命：バッファリングと「世代別GC」の協調
PHP 7で導入されたZend Engine 3.0、そして近年のPHP 8に至る過程で、この循環参照の回収メカニズムは劇的な進化を遂げました。それが「世代別GC（Concurrent/Generational GC）」の統合です。
Zend Engineは、すべての `zval` を逐一監視するような愚かな真似はしません。メモリ効率を極限まで高めるため、次のような巧妙なステップで動作しています。
① ルートバッファ（Root Buffer）への候補登録
変数の参照カウントが減った際、その値が「コンテナ型（配列やオブジェクト）」であり、かつ `refcount` が `0` にならなかった場合、Zend Engineは「こいつは将来、循環参照の孤島（Garbage）になるかもしれない」と推測し、ルートバッファ（Root Buffer）と呼ばれる固定長の二重linked listにそのアドレスを登録します。
このバッファがいっぱいになるか、一定の閾値を超えるまで、GCは本格的なスキャンを行いません。これがCPUサイクルの無駄遣いを防ぐ第一歩です。
② 世代別コンセプト（Buffered / Purple 状態）の導入
Zend EngineのGCアルゴリズムでは、オブジェクトや配列の状態を色（状態フラグ）で管理します。
- White（白）: 未訪問、または回収対象の候補
- Grey（灰色）: スキャン中
- Black（黒）: 有効な参照（孤島ではない）
- Purple（紫）: ルートバッファに登録された要監視状態
ここで世代別の最適化が効いてきます。多くのWebアプリケーションにおいて、「生成されてからすぐに破棄される一時的な配列やオブジェクト」と、「リクエスト中ずっと生き残り続ける長期的なコンテナ」には明確な偏りがあります（世代別仮説）。
Zend Engine 3以降のGCは、何度もルートバッファに送られてきながらも循環参照の一部と判定されなかった「生存期間の長いオブジェクト」を効率的にスキップ、あるいは最適化の対象外（あるいは低頻度スキャン対象）に追いやることで、スキャンコストを劇的に削減しています。
③ 3色マーキング法による回収アルゴリズムの実行
ルートバッファが溢れると、Zend EngineはついにGCサイクル（コンカレントなバースト処理）を発動します。
1. 第1段階（減少フェース）: バッファ内のすべてのルートから辿れるオブジェクトの参照カウントを一時的に減らし、循環参照によって「外部からの参照が本当にゼロか」をシミュレートします。
2. 第2段階（マークフェース）: 外部からの真の参照が残っているものを「Black（黒）」に戻し、完全に孤立している（循環参照の輪の中にしか存在しない）ものを「White（白）」としてマークします。
3. 第3段階（スイープフェース）: 白と判定されたメモリ領域を効率的に解放し、HashTableのインデックスを整理します。
—
4. 現場で活きる！メモリ効率を意識した実践的コード設計
この内部挙動を知ると、私たちが書くべきPHPコードの姿がより鮮明に見えてきます。例えば、大量のORMエンティティやDTOをバッチ処理で扱う際、次のようなコードはGCに無駄な負荷をかけます。
// ❌ 悪い例：巨大な循環参照の森を作ってしまうケース
class Order {
public array $items = [];
}
class Item {
public ?Order $order = null;
}
// 数万件のオーダーをメモリ上にロードし続けると、
// 相互参照の山がルートバッファを埋め尽くし、GCのスキャンコストが跳ね上がります。
もし数万件のデータを扱うバッチ処理や、常時稼働のSwooleワーカーを書くのであれば、以下のようなアプローチが極めて有効です。
// ⭕ 良い例：ライフサイクルを明確にし、不要になったら明示的に切断する
foreach ($largeDataset as $rawData) {
$order = new Order($rawData);
// 処理を実行
$order->process();
// 1. 循環参照の元凶となりうる相互リンクを明示的に断つ
$order->detachItems();
// 2. 意図的に変数を上書き・解放する
unset($order);
}
// 3. 必要に応じて、明示的にGCを強制実行することも可能
// （通常はエンジンが自動管理するため頻繁に呼ぶ必要はありません）
// gc_collect_cycles();
このように、フレームワークの背後でZend Engineがどのようにメモリの「孤島」を見つけ出し、効率的に掃除しているかをイメージできるようになると、メモリリークの予兆をコードレビューの段階で嗅ぎ取れるようになります。
—
まとめ
- PHPのメモリ管理の基本は参照カウント（Reference Counting）であり、スコープを抜ければ即座に解放される。
- しかし、オブジェクト同士が指し合う「循環参照」はこの仕組みの死角となる。
- Zend Engine 3以降では、ルートバッファと世代別の3色マーキング最適化により、循環参照の回収コストが劇的に削減されている。
- 常時稼働するモダンなPHP環境（Daemon/Workerモード）では、この仕組みを頭の片隅に置き、不要になったオブジェクトの相互リンクを断つ意識が、システム全体のパフォーマンスを支える鍵となる。
PHPは、ただ動くだけの言語ではありません。その裏側では、C言語レベルの極限まで洗練されたメモリ管理アルゴリズムが、あなたの書いたリクエストを静かに、そして高速に支えています。
この裏側の美しさを味方につければ、あなたの書くPHPコードは、より堅牢で、予測可能で、美しくスケールするものに変わるはずです。さあ、次のコード設計にこの知見を活かしてみてください。