こんにちは。普段から大規模なPHPアプリケーションのパフォーマンスチューニングや、フレームワークの深部で頭を悩ませていることと思います。JavaやGo、Rubyといった他の高水準言語を経験した優秀なエンジニアほど、「PHPのメモリ管理って、リクエストが終わったら全部消えるんでしょ？」というブラックボックス感にモヤモヤを抱えがちですよね。
でも、安心してください。ここを理解すれば、PHPの裏側が綺麗に見えるようになります。今回は、Zend VMがオブジェクトの生と死をどのように司っているのか、その核心である「オブジェクト構造体とGCフラグ」の低レイヤの仕組みを、一緒に紐解いていきましょう。
—
1. 1リクエストの裏側：PHPのメモリ管理の宿命
PHPは「シェアード・ナッシング（Shared-Nothing）」アーキテクチャを採用しています。つまり、1つのWebリクエストが飛んできた瞬間にZend Engineが立ち上がり、メモリ空間（Zend Heap）を確保し、リクエストが終了すれば問答無用でプロセスごと、あるいはリクエストコンテキスト単位でメモリが全解放されます。
「じゃあ、メモリリークなんて気にしなくていいのでは？」
そう思った方、鋭いです。短いライフサイクルのスクリプトであれば、それで逃げ切ることも可能でした。しかし、現代のPHPはどうでしょう。
- 長期間常駐する RoadRunner や OpenSwoole などの非同期・常駐型ランタイム
- 数万件のレコードを一括処理する巨大なバッチ処理
- 複雑なドメインモデルが絡み合う巨大なDDD/Clean Architectureのオブジェクトグラフ
これらを扱う現場では、リクエスト（あるいはタスク）の途中でメモリが枯渇したり、パフォーマンスがジリジリと低下していく現象に直面します。その原因の多くが、「循環参照（Circular Reference）」とGC（ガベージコレクション）のメカニズムのミスマッチです。
—
2. オブジェクトの核心：`zend_object` と参照カウントの正体
PHP（Zend Engine）において、スカラー値（整数や文字列など）は「Copy-on-Write（COW）」によって効率よく管理されていますが、「オブジェクト」だけは別格です。オブジェクトは常にヒープ上に存在し、変数コンテナ（`zval`）からはその「ポインタ」が保持されます。
C言語レベルのZend Engineのソースコードを覗くと、すべてのオブジェクトは `zend_object` という巨大な構造体として実体化されています。歴史的な変遷（PHP 5時代の `zend_object_value` から、PHP 7以降の統合された `zend_object` へ）を経ていますが、その本質は変わりません。
/ Zend/zend_types.h あたりをイメージした抽象表現 /
struct _zend_object {
zend_refcounted_h gc; // ★ここが今回の主役：参照カウントとGCフラグの塊
uint32_t handle; // オブジェクトを一意に識別するハンドル
zend_class_entry ce; // クラス定義へのポインタ
// … プロパティテーブルがここに続く
};
この先頭にある `zend_refcounted_h` こそが、オブジェクトの寿命を握る心臓部です。中身をさらに分解してみましょう。
typedef struct _zend_refcounted_h {
uint32_t refcount; // 参照カウント（このオブジェクトを指している変数の数）
union {
uint32_t type_info;
/ GC用のフラグや色分け（Coloring）のためのビットフィールド /
} u;
} zend_refcounted_h;
PHPのコードで `$a = new MyClass();` と書いた瞬間、この `refcount` は `1` になります。 `$b = $a;` と代入すれば、同じオブジェクトを指すポインタが増えるため、`refcount` は `2` にインクリメントされます。
そして、変数のスコープを抜けるなどして `refcount` が `0` になった瞬間、Zend VMは即座にデストラクタを呼び出し、メモリを解放します。これが基本のライフサイクルです。
—
3. なぜ循環参照は「普通の参照カウント」で解放できないのか？
ここで、次のようなよくあるコードを考えてみてください。親と子が互いを知り合っている（双方向関連）モデルです。
class Node {
public ?Node $parent = null;
public ?Node $child = null;
public function __destruct() {
echo “オブジェクトが消滅しました\n”;
}
}
// 1. オブジェクト生成
$parent = new Node(); // refcount(P) = 1
$child = new Node(); // refcount(C) = 1
// 2. 循環参照の構築
$parent->child = $child; // refcount(C) = 2 ($parentからの参照 + $childプロパティ)
$child->parent = $parent; // refcount(P) = 2 ($childからの参照 + $parent変数)
// 3. 変数のスコープ落ち（unset）
unset($parent); // parent変数を消す。しかし、childからまだ指されているため refcount(P) = 1
unset($child); // child変数を消す。しかし、parentからまだ指されているため refcount(C) = 1
お気づきでしょうか？ `$parent` も `$child` も、私たちが直接触れる変数は消去（`unset`）したにもかかわらず、お互いが互いを指し合っているため、それぞれの `refcount` が `1` のまま残ってしまっています。
普通の参照カウント方式であれば、「カウントが0にならない＝誰も使っていないことが証明できない」ため、メモリリークとして永遠に残り続けます。常駐型アプリケーションでこれをやると、リクエストを重ねるごとにメモリがドカンと破裂しますよね。
—
4. Zend GCの救世主：トリカラー・マーキング（三色標識法）とバッファ
この「参照カウントが0にならない循環参照の呪縛」を解くために、PHP 5.3以降、Zend Engineには本格的な循環参照ガベージコレクタが組み込まれています。
Zend VMは、すべてのオブジェクトの寿命を単純なカウントだけで監視していません。裏で次のような巧妙なアルゴリズム（三色標識法をベースにした疑いバッファリング）を回しています。
1. 紫のBUFFER（疑いリスト）への登録:
ある変数の参照カウントがデクリメントされたとき、もしその値が「0にならずに減った」場合、Zend VMは「こいつ、ひょっとして孤立した循環参照の輪の中にいるんじゃないか？」と疑います。そして、そのオブジェクトをGCのルートバッファ（紫色のバッファ）に放り込みます。
2. 根絶やしにするためのスキャン（バッファが溢れるか、明示的に呼ばれたとき）:
バッファが一定数（デフォルトでは10,000エントリ）に達するか、開発者が `gc_collect_cycles()` を叩くと、GCが発動します。
3. 三色のアルゴリズム:
- 白色（White）: ゴミの候補（未訪問）
- 灰色（Grey）: スキャン中（子孫をたどっている途中）
- 黒色（Black）: 正常に外から参照されている安全なオブジェクト
GCは、紫のバッファにいるオブジェクトからスタートし、辿れるオブジェクトの参照カウントを「仮想的に」1つずつ減らしていきます（模擬的減算）。
その結果、「外部からの参照がなく、内部の循環だけでカウントが保たれていたオブジェクト」は、最終的にカウントが `0`（白色のまま）になります。これが真の「ゴミ」です。
4. sweep（一掃）:
見つかったゴミオブジェクトを特定し、デストラクタを安全に実行した上で、ヒープメモリを回収します。
この仕組みを頭に入れておくと、なぜPHPで循環参照を放置するとGCのCPUコスト（オーバーヘッド）が跳ね上がるのかが、肌感覚で理解できるようになりますよね。
—
5. 現場で活きる！アーキテクト的・メモリ最適化の極意
このZend VMの挙動を踏まえると、モダンなPHP開発において私たちが取るべき設計上のアプローチが明確になります。
A. ライフサイクルの最後で「弱参照（WeakReference）」を活用する
PHP 7.4以降では、待望の `WeakReference` が導入されています。キャッシュ機構やツリー構造（親から子への所有は強く、子から親への逆流は弱く）を表現する場合、親への参照に `WeakReference` を使うことで、`refcount` を増やさずに参照を保持できます。
class Node {
public ?Node $child = null;
private ?WeakReference $parentRef = null;
public function setParent(Node $parent): void {
// refcountを増やさないため、循環参照の輪ができない！
$this->parentRef = WeakReference::create($parent);
}
public function getParent(): ?Node {
return $this->parentRef?->get();
}
}
この実装であれば、親を `unset` すれば即座に参照カウントが `0` になり、GCの厄介なスキャンを走らせることなくクリーンにメモリが解放されます。常駐型プロセスでは特に絶大な効果を発揮します。
B. 明示的な参照の切断（Danglingの防止）
複雑なオブジェクトグラフを構築するドメインモデル（例えば、Unit of Workパターンや巨大なORMのエンティティマネージャ）を扱う場合、リクエストの終端や処理の切れ目で、意図的に相互参照を切断（`$entity->parent = null;` など）するクリーンアップメソッドを用意することが、パフォーマンス維持の黄金律となります。
—
まとめ
- `zend_object`（内部の `zend_refcounted_h`）は、オブジェクトのライフサイクル管理の根幹。
- 通常の変数は参照カウント（`refcount`）で瞬時に管理されるが、循環参照だけはカウントが0にならず残る。
- それを救うのがZend VMのGCバッファと三色マーキングによる回収アルゴリズム。
- しかし、GCのコストや常駐型アプリでのメモリ肥大化を防ぐためには、`WeakReference` の活用や不要な循環を作らない設計がプロのアーキテクトとしての腕の見せ所。
PHPは「ただ動く言語」から、エンジンレベルの挙動をハックすることで極限まで高速化できる「深淵な言語」へと進化しています。この裏側の仕組みを武器に、ぜひ次の設計やパフォーマンスチューニングに挑んでみてください。あなたの書くコードが、一段と美しく、強靭なものになるはずです。