こんにちは。PHPの表層のフレームワークを使いこなし、「なんだか最近、ループ処理やバッチ処理でメモリがジワジワと肥大化するな…」という壁にぶつかっていませんか？
他のモダンな言語（JavaやGoなど）を経験している方ほど、PHPの「1リクエストが終われば全メモリがOSに一括返却される（Shared-nothingアーキテクチャ）」という気楽さに慣れているはずです。しかし、現代のPHPは、長寿化するAPIサーバーやCLIでの常駐プロセス（Swoole、ReactPHP、RoadRunnerなど）が当たり前になりつつあります。ここで問題になるのが、PHP内部のメモリ管理、そしてガベージコレクション（GC）の挙動です。
今回は、PHP 8.xのZendエンジン内部で、オブジェクトの生誕から消滅までがどのように最適化され、管理されているのか。その核心である「世代別GC（Generational GC）」の仕組みを、低レイヤの視点から紐解いていきましょう。ここを理解すると、あなたの書くPHPコードのメモリ効率は劇的に変わりますよ。
—
1. Zendエンジンにおけるメモリ管理の基礎：参照カウントの限界
PHPのメモリ管理の基本は、皆さんもご存知の参照カウント（Reference Counting）です。
すべての変数やオブジェクトは、C言語の構造体（PHP 8では `zend_value` や `zend_object` など）としてZendエンジンのヒープ上に生成されます。この構造体には、自分自身が「今いくつから指されているか」を示すカウンタ（`refcount`）が常駐しています。
例えば、次のようなコードを考えてみましょう。
循環参照という「悪夢」
しかし、この仕組みには致命的な弱点があります。それが循環参照（Circular Reference）です。
child = $child;
$child->parent = $parent;
// 変数スコープを破棄しても、お互いを指し合っているため refcount は 0 にならない！
unset($parent, $child);
この状態になると、`refcount` が「1」のまま永遠に落ちず、メモリリークが発生します。これを救出するためにPHPに備わっているのが、ルートバッファ（Root Buffer）を用いた従来のサイクル回収型GCです。
しかし、毎秒数千リクエストを処理するモダンなバックエンドや常駐プロセスにおいて、すべてのオブジェクトを同じようにこの「重いバッファ」で監視・走査するのは、CPUキャッシュ効率の観点からパフォーマンスの大きなボトルネックになっていました。
—
2. PHP 8.xにおける革命：「世代別GC（Generational GC）」の正体
PHP 7.0以降、そしてPHP 8.xでさらに洗練されたのが、世代別GC（Generational Garbage Collection、通称 Generational GC）の概念の導入です。これは、かの有名なJavaのHotSpot VMやV8エンジンなどでも採用されている、「大半のオブジェクトはすぐに死ぬ（Weak Generational Hypothesis）」という経験則をPHPのZendエンジンに応用したものです。
オブジェクトの「若年世代」と「成人世代」
Zendエンジンは、新しく生成されたオブジェクトを「若年世代（Young Generation）」として扱います。
バックグラウンドで何が起きているかというと、PHPの実行中、頻繁に生成されては数ステップで消えていく一時的なオブジェクト（DTO、イテレータ、クロージャのコンテキストなど）は、わざわざ複雑な循環参照の検査対象（ルートバッファ）に入れる必要性が極めて低いです。
PHP 8の内部実装（Zend GCのソースコード `zend_gc.c` を覗くと見えてきますが）では、オブジェクトのライフサイクルを次のように分類・最適化しています。
1. 新規生成: オブジェクトはまず「若年世代」としてマークされ、通常の高速な参照カウント増減のみで管理されます。
2. バッファへの登録（疑い）: `refcount` が直接減ったものの、まだ0になっていない複雑な構造を持つコンテナ型（オブジェクトや配列）の候補だけが、GCの「ルートバッファ」に一時的にプッシュされます。
3. 世代の昇格（Promotion）: 何度かのGCサイクルを生き延びたオブジェクトは、「成熟世代（Old Generation）」へと昇格します。
これにより、「寿命の短い無数のオブジェクトの検査コスト」を劇的に削減し、GCが走った際のCPU停止時間（Stop-the-world的なオーバーヘッド）を極限まで小さくしているのです。
—
3. 現場で活きる！メモリ効率を最大化するコーディングの極意
ここまでの内部構造を踏まえると、「PHPでメモリ効率の良いコードを書く」とはどういうことか、鮮明に見えてきますよね。ZendエンジンのGCと仲良くなるための実践的なアプローチをいくつかご紹介します。
① 巨大な循環参照を自ら断ち切る（Destructorの活用）
常駐型プロセス（SwooleやRoadRunnerなど）で最もやりがちなのが、サービスコンテナやグローバルなレジストリに、ドメインモデルやPDO接続、リクエスト情報を循環させたまま保持し続ける設計です。
ZendエンジンのGCは優秀ですが、循環参照の検出にはコストがかかります。不要になったタイミングで、明示的にプロパティを `null` にクリアするか、`__destruct()` を用いて参照の糸を断ち切る習慣をつけましょう。
parentContext = $parent;
}
// 処理完了後に明示的に循環を断ち切るメソッドを用意する
public function dispose(): void {
$this->parentContext = null;
$this->items = [];
}
public function __destruct() {
// デストラクタが意図したタイミングで呼ばれるようにする
// （※循環参照があると、ここがGCの回収時まで呼ばれないため注意）
}
}
② `gc_collect_cycles()` の神話と現実
「メモリが心配だから、ループの毎に `gc_collect_cycles()` を呼ぼう！」――これは最悪のアンチパターンです。
世代別GCが導入されたPHP 8.xにおいて、ルートバッファが溢れていない段階で強制的にGCをフルスキャンさせると、Zendエンジンは全オブジェクトのヒープを舐め回すことになり、かえってCPUのキャッシュヒット率を落とし、パフォーマンスが急低下します。
GCの実行はZendエンジンに自動で任せ、どうしても必要な場合（数百万件のバッチ処理のイテレーションの切れ目など、一定のまとまった処理の終了時）に限定して呼び出すのがプロの作法です。
—
4. 最後に：PHPの裏側を知るということ
PHPは「初心者向けの簡単な言語」から、内部のZend VMとJITコンパイラ、そして洗練された世代別メモリ管理を持つ「極めてモダンで合理的な実行エンジン」へと進化を遂げました。
コードを書くとき、「この配列のコピーはZendのメモリ上でどのようにシャローコピー（浅いコピー）されるか」「このオブジェクトの参照はGCのルートバッファを汚さないか」といった低レイヤの脳内トレースができるようになると、あなたのエンジニアとしての武器は圧倒的なものになります。
「ここを理解すれば、PHPの裏側が綺麗に見えますよ」
今日の知識を武器に、ぜひ明日のコードのメモリ効率を見つめ直してみてください。エンジニアリングの深淵を覗く旅を、これからも楽しんでいきましょう！