こんにちは。普段から「どうすればPHPを限界まで速く、美しく動かせるか」を考えているあなたなら、フレームワークの背後にあるリクエストライフサイクルや、メモリの振る舞いについて一度は深く考えたことがあるはずです。
JavaやGo、Node.jsといった他のモダン言語の経験がある人ほど、PHPの「1リクエストが終われば全メモリがOSに一括返却される（Shared-nothingアーキテクチャ）」というシンプルさに驚き、そして同時に「なぜ長大なバッチ処理やAPIプロセスのループ内でメモリが膨れ上がるのか」という疑問にぶつかりますよね。
今回は、PHPのメモリ管理の心臓部である「ガベージコレクション（GC）」、特にその手動実行である `gc_collect_cycles()` が呼び出されたときに、Zend VMの内部で何が起きているのかを低レイヤの視点から解き明かしていきましょう。
ここを理解すると、PHPのメモリ挙動が完全に「見える」ようになりますよ。
—
1. PHPメモリ管理の基本：参照カウントと「穴」
PHPの変数は、Zendエンジン内部で `zval`（Zend Value）という構造体として管理されています。
変数がコピーされたり別の変数に代入されたりすると、その `zval` が持つ参照カウント（refcount）がインクリメントされ、不要になるとデクリメントされます。これが0になった瞬間、メモリは即座に解放されます。これがPHPの基本であり、非常に高速な理由です。
しかし、オブジェクトや配列が自分自身を内包するような「循環参照（Circular Reference）」が発生すると話が変わります。
child = $a; // 自分自身を参照する（循環参照）
unset($a); // $a の refcount は 0 にならない！
`unset($a)` を実行しても、$a が持っていた `zval` の参照カウントは、自己参照のせいで「1」残ってしまいます。この「誰もアクセスできないけれど、メモリ上に幽霊のように居座るゴミ」を回収するために、PHPにはGC（循環参照コレクター）が存在するのです。
—
2. `gc_collect_cycles()` 実行時のZend VM内部状態と3色マーキング
通常、PHPのGCはバッファ（デフォルトでは一定数の潜在的ルートが溜まったら）が溢れたタイミングで自動実行されますが、巨大なデータ構造を扱うバッチ処理などの文脈では、開発者が意図的に `gc_collect_cycles()` を叩く設計にすることがあります。
この関数が呼ばれた瞬間、Zend VMの内部では何が起きているのでしょうか。
エンジンは、PHPのソースコードからコンパイルされたオペコード（Opcode）の実行を一時中断し、C言語レベルのアルゴリズム（Concurrent Cycle Collection / 3色マーキング法に近いアプローチ）を走らせます。
内部の動きをステップ順に分解してみましょう。
ステップ1: バッファリングされたルートの検査（Purple色）
循環参照の疑いがある `zval`（コンテナ型である配列やオブジェクト）は、生成・代入の過程で自動的に「GCルートバッファ」に登録され、マーク（紫色の状態）されます。`gc_collect_cycles()` は、このバッファに溜まったエントリを起点にします。
ステップ2: 参照カウントの仮減算（Grey色）
エンジンは、バッファ内の各ルートからたどれるすべての `zval` の参照カウントを一時的に「1」だけ減算します（灰色に変更）。
これは、「もしこの循環参照が外部からの参照を一切失っていれば、カウントは0になるはずだ」という仮説を検証するためです。
ステップ3: 3色マーキングによる判定
- 白 (White): 完全に孤立している（ゴミである）可能性が高いノード。
- 黒 (Black): 外部からの有効な参照がまだ残っている（回収してはいけない）ノード。
- 灰 (Grey): 探索中のノード。
エンジンはグラフを走査し、外部から守られていない（＝白のまま残った）ノードを特定します。
ステップ4: スイープ（回収）とメモリの解放（Whiteの解放）
白と判定されたノード群に対してデストラクタを安全な順序で呼び出し、割当メモリを解放し、`zval` を `emalloc` プールに戻します。
—
3. 実践：巨大ループにおける手動GCのインパクト
では、この `gc_collect_cycles()` を実務のコードでどう扱うべきか。
例えば、数万件のレコードを処理するコンソールコマンド（Symfony ConsoleやLaravel Artisanなど）を想像してください。
parent = $container; // 意図せずとも複雑なオブジェクトグラフが構築される
// 処理…
// ループのスコープを抜けても、循環参照のせいでGCが追いつかずメモリが肥大化する
}
このループ内でメモリが枯渇（Allowed memory size of… exhausted）する場合、次のように手動で介入します。
4. アーキテクトが知るべき「手動GCのパフォーマンス影響」
「じゃあ、安全のためにすべての処理の最後や、細かいループの都度 `gc_collect_cycles()` を呼べば完璧じゃないか！」と思った方、ちょっと待ってください。ここが腕の見せ所です。
`gc_collect_cycles()` は決して「軽い」処理ではありません。
1. CPUキャッシュとグラフ探索のコスト
GCのアルゴリズムは、メモリ上のオブジェクトグラフをくまなく走査（トラバーサル）します。これはCPUのキャッシュメモリに対して優しくなく、ポインタ追跡によるキャッシュミスの嵐を引き起こします。頻繁に呼びすぎると、アプリケーション全体のスループット（CPU効率）が目に見えて低下します。
2. 同期的なブロッキング
PHPのGCはシングルスレッドで動作します。`gc_collect_cycles()` が実行されている間、そのFPMプロセス（またはCLIプロセス）はその処理に完全に占有され、新しいリクエストの処理や次の処理へ進むことができません。
3. 自動GCとの兼ね合い
PHPは標準で、GCバッファが一定量（デフォルトでは `zend.gc_threshold` 等で制御）を超えると自動的にバックグラウンド（正確にはVMの内部閾値到達時）で回収を行います。そのため、通常のWebリクエスト（短命なライフサイクル）において、開発者が自ら `gc_collect_cycles()` を書く必要はほぼ100%ありません。手動GCが必要になるのは、数分〜数時間稼働する長寿命のCLIプロセスやデーモンプロセスだけです。
—
まとめ：PHPのメモリと仲良くなるために
- Webリクエスト（FPM）では不要: 1リクエストごとにプロセス空間ごと破棄されるため、通常はPHPのデフォルトの参照カウントと自動GCに任せておけば十分です。
- 長寿命プロセス（CLI/Worker）では武器になる: キューワーカーやバッチ処理などでは、メモリリークの芽を摘むために「適切な粒度（例: 1000件ごと）」で `gc_collect_cycles()` を戦略的に配置する。
- 過信は禁物: 闇雲に呼ぶとCPUバウンドなボトルネックを生むため、必ず `memory_get_usage(true)` やプロファイラで計測しながら導入する。
PHPの裏側でZend VMがどうメモリを扱い、どうゴミを掃除しているのか。このイメージが頭の中に構築されていれば、どんなに複雑なデータ構造を扱うシステムであっても、メモリ枯渇の恐怖に怯えることはもうありません。
あなたのアーキテクチャに、ぜひこの知見を活かしてくださいね。