こんにちは。日々のWebアプリケーション開発、本当にお疲れ様です。JavaやGo、あるいはNode.jsといった他言語のバックエンドを経験した後にPHPに触れると、「なぜPHPはこれほどメモリ管理を意識せずに動くのか」「それでいて、なぜ巨大なオブジェクトグラフを扱うと突然メモリリークやパフォーマンス低下が起きるのか」と、疑問に思う瞬間がありますよね。
フレームワークがよしなにリクエストを処理してくれる現代においても、その下でうごめくZend Engineの挙動――特にオブジェクトのライフサイクルとメモリ解放のメカニズムを理解しているかどうかで、書くコードの質、そしてトラフィックが増えたときの耐性が劇的に変わります。
今回は、PHPの内部エンジン（Zend VM）がオブジェクトをどのように産み落とし、どのように消し去っているのか。その核心である `zend_object`（旧仕様における`zend_object_value`の概念的系譜）と `gc` フラグの役割 について、低レイヤの視点から紐解いていきましょう。ここを理解すれば、PHPの裏側がまるで一枚の美しい絵画のようにクリアに見えてきますよ。
—
1. PHPのメモリ管理の基本：参照カウントという「光と影」
PHPの変数やデータ構造は、C言語レベルで実装された `zval`（Zend Value）という構造体によって表現されています。整数や文字列であれ、私たちが日々インスタンス化するクラスのオブジェクトであれ、すべてはこの `zval` をベースに管理されています。
PHPのメモリ管理の基本思想は 「参照カウント方式（Reference Counting）」 です。
ある変数が作られ、別の変数に代入されると、そのデータ構造を指し示す「参照カウンタ」の数値がインクリメントされます。そして、スコープを抜けるなどして変数が破棄されると、カウンタがデクリメントされます。このカウンタが `0` になった瞬間、即座にメモリ解放（`efree`）が走る――これがPHPの基本であり、非常に高速な理由です。
「循環参照（Circular Reference）」という魔物が潜んでいます。
親オブジェクトが子オブジェクトを持ち、その子が何らかの形で親を参照しているような構造を作った場合、お互いの参照カウントが `0` にならなくなります。変数としてのスコープが消滅しても、メモリ上にゾンビのように残り続ける。これが、長寿命のプロセス（長時間のCLIスクリプトや、Swoole、RoadRunnerなどの常駐型アーキテクチャ）において致命的なメモリリークを引き起こす原因となります。
この「参照カウントの隙間」を埋めるために、Zend Engineには高度なガベージコレクション（GC）機構が備わっています。そして、その主役こそが `gc` フラグ なのです。
—
2. オブジェクトのアイデンティティ：`zend_object` とハンドル
Zend VMの世界では、プリプレグな値（スカラー値）と、オブジェクトは扱いがまったく異なります。スカラー値は `zval` の中に直接値やポインタが格納されますが、オブジェクトは実体がヒープ領域の別の場所にあり、`zval` からは間接的に参照されています。
かつてのPHP（PHP 5時代など）では、このオブジェクトへの参照を表現するために `zend_object_value` という構造体が使われていました。これは「オブジェクトを指し示すポインタ」と「ハンドラ関数へのポインタ」をセットにしたものでした。
現在のモダンなPHP（PHP 7以降、そして最新のPHP 8系）では、エンジン内部の構造が洗練され、すべてのオブジェクトは `zend_object` という巨大な構造体をベースに構築されています。
- ハンドラ（Handle）: 各オブジェクトを一意に識別するための整数ID（これが実質的なオブジェクトのアイデンティティです）。
- プロパティテーブル: オブジェクトが持つ動的・静的なプロパティ群を格納する `HashTable`。
- GC情報: 後述する、循環参照を検知するためのメタデータ。
PHPで `new MyClass()` と書いた瞬間、Zend VMはヒープ上にこの `zend_object` の領域を確保し、変数側の `zval` にはその型情報（`IS_OBJECT`）と、オブジェクトへの参照（ハンドラ）を紐付けます。
—
3. `gc` フラグの正体と、Zend VMの「三色マーキング法」
では、本題である `gc` フラグの役割について深く掘り下げていきましょう。
Zend Engineのガベージコレクタ（バッファリングされた循環参照コレクタ）は、すべての変数を常時監視しているわけではありません。そんなことをすれば、Webリクエストのライフタイムごとの実行速度（スループット）が致命的に落ちてしまいます。
代わりに、エンジンは非常に巧妙な最適化を行っています。それが 「可能性のあるものだけをバッファに溜めて、後からまとめて掃除する」 というアプローチです。
`gc` フラグのライフサイクル
1. 通常の状態:
オブジェクトが生成された時点では、その `gc` フラグは特定の状態（非バッファ状態）にあります。
2. 「もしかして？」の検知（Buffered）:
ある変数の参照カウントがデクリメントされたとき、もしそのカウントが `0` にならず、かつ「配列やオブジェクトなどの複合型（コンテナ）」であった場合、Zend Engineは「もしかしたら、この中に他の要素と循環参照を作っているかもしれない」と推測します。
この瞬間、その構造体の `gc` フラグが 「GCバッファに追加された（Buffered）」 という状態に書き換えられ、エンジンの「GCルートバッファ（GC Buffer）」にアドレスが登録されます。
3. バッファの溢れ、あるいは明示的実行:
このGCルートバッファが一定数（デフォルトでは10,000エントリ）に達するか、あるいは開発者が明示的に `gc_collect_cycles()` を呼び出したとき、ガベージコレクションのアルゴリズムが発動します。
同期と「三色マーキング」の裏側
GCが走るとき、Zend Engineはバッファに溜まったオブジェクト群に対して、コンピュータサイエンスでお馴染みの「三色マーキング法（Tri-color marking）」の変形版を実行します。
- 白色（White）: ガベージ候補（デフォルト）
- 灰色（Grey）: スキャン中
- 黑色（Black）: 外部からの有効な参照が確認された生存者
エンジンは、疑わしいオブジェクト群の参照カウントを一時的に「仮想的に減算」してみます。もしその結果、参照カウントが `0` になれば、それは「自分自身（あるいは仲間内）で引っ張り合っているだけの孤立した輪っか（循環参照）」であると断定されます。
この判定を下すために、各 `zval` / `zend_object` が持つ `gc` フラグやカラー情報がフル活用されているのです。見事に循環参照が暴かれたオブジェクトは、安全にメモリプールから切り離され、`efree` によってクリーンアップされます。
—
4. 現場で活きる知見：メモリリークを防ぐための設計思想
ここまでお読みいただいたあなたなら、なぜ「常駐型アプリケーション（SwooleやReactPHPなど）」や「巨大なバッチ処理」においてメモリリークが起きるのか、そのメカニズムが手に取るようにわかるはずです。
次のようなコードを書いてしまったとしましょう。
children[] = $child;
$child->parent = $this; // ここで親 -> 子、子 -> 親の双方向参照（循環参照）が発生！
}
}
// バッチ処理のなかで何百万回もこれを呼び出すとする
function runBatch() {
$root = new Node();
for ($i = 0; $i < 10000; $i++) {
$root->addChild(new Node());
}
// ここで $root のスコープが切れても、
// 親子間の循環参照により即座にはメモリが完全に解放されないケースがある
}
通常のWebスクリプト（PHP-FPMの1リクエスト）であれば、リクエスト終了時にプロセスが保持していたヒープ領域はOSによって一括解放（リセット）されるため、そこまでシビアになる必要はありません。しかし、プロセスが常駐する環境や、数時間に及ぶ巨大なバッチ処理では、この「GCが回収しきれない、あるいはGCのタイミングが追いつかない」状況が蓄積し、メモリが枯渇（OOM: Out of Memory）します。
アーキテクトからの実践的なアドバイス
1. 親子関係を表現するときは「弱参照（WeakReference）」を検討する
PHP 7.4以降では `WeakReference` クラスが導入されています。子から親への参照を `WeakReference` にすることで、参照カウントを増やさずに親を指すことができます。これにより、循環参照そのものを根本から回避できます。
class Node {
public ?WeakReference $parent = null;
public function setParent(Node $parent): void {
$this->parent = WeakReference::create($parent);
}
}
2. 長寿命プロセスでは、必要に応じて `gc_collect_cycles()` を手動で叩く
数万件のレコードをループで処理するようなバッチスクリプトでは、キリの良いタイミング（例：1,000件ごと）で明示的に `gc_collect_cycles()` を呼び出し、GCバッファを強制的に清掃するロジックを組み込むのが、堅牢なアーキテクチャの鉄則です。
—
おわりに
PHPは「動かしやすい言語」であると同時に、その内部ではZend VMという極めて洗練された仮想マシンが、メモリの生死を緻密にコントロールしています。
普段何気なく使っている `new` や `unset`、そしてオブジェクトのプロパティ代入の裏側で、`zend_object` が生成され、`gc` フラグがその運命を静かに見守っている――。この低レイヤのストーリーを頭の片隅に置いておくことで、あなたの書くPHPコードは、より堅牢で、予測可能で、美しいものに進化するはずです。
「ここを知っていれば怖くない」。そう感じていただけたなら、アーキテクトとしてこれ以上の喜びはありません。さあ、次のコードをより誇り高く書いていきましょう。