PHPコアの深淵：`memory_limit`とガベージコレクションが織りなすパフォーマンスの力学
PHPのパフォーマンスチューニングにおいて、`php.ini`の `memory_limit` ディレクティブは、単なる「スクリプトが暴走した際の安全弁」として片付けられがちである。しかし、Zend Engine（Zend VM）のメモリ管理、参照カウント、そして循環参照ガベージコレクタ（GC）の内部挙動を低レイヤから見つめ直すとき、この設定値がアプリケーションのスループット、CPUキャッシュ効率、そしてレイテンシの安定性にどれほどクリティカルな影響を与えているかが浮き彫りになる。
本稿では、`memory_limit` とGCの相互作用がZend VMのメモリ空間およびOSのメモリ管理に何をもたらすのか、その限界領域の知見を解き明かす。
—
1. Zend VMのメモリ管理と参照カウントの基礎構造
PHPのすべての変数は、シンボルテーブルを経て `zval`（Zend Value）構造体として管理されている。`zval` は、データ型とその実体（あるいはポインタ）、そしてGCのためのメタデータを保持する。
// 概念的なZend VMのzvalとGCルートバッファの関係
+——————-+ +———————–+
| zval (配列/obj) | —-> | 実際のヒープメモリデータ |
| refcount: 3 | | (HashTable等) |
+——————-+ +———————–+
|
(循環参照が発生)
v
+——————-+
| zval (相互参照) |
| refcount: 1 | —> ルートバッファ（GC Buffer）に登録される
+——————-+
スカラー値（整数や文字列の一部など）を除き、配列（`IS_ARRAY`）やオブジェクト（`IS_OBJECT`）などの複合型は、内部で `refcount`（参照カウンタ）を持っている。この `refcount` が `0` になった瞬間、Zend Memory Manager（ZMM）は即座にメモリを解放する。これがPHPにおける基本かつ最速のメモリ解放メカニズムである。
しかし、オブジェクトや配列が互いに参照し合う「循環参照（Circular Reference）」が発生した場合、親のスコープが消滅しても `refcount` は `1` などの非ゼロの値を維持し続ける。結果として、即時解放は行われず、メモリリークが発生する。このゾンビ化したメモリを回収するのが、Zend VMのガベージコレクタである。
—
2. `memory_limit` がGCのトリガーと挙動に与える物理的影響
PHPのGCは、デフォルトではバッファ（`gc_root_buffer`）が満杯になった時、あるいは明示的に `gc_collect_cycles()` が呼ばれた時にのみ実行される。このバッファのサイズは Zend Engine のソースコード（`zend_gc.c`）内で固定値（通常は10,000エントリ）として定義されているが、`memory_limit` の設定値は、ZMMがアロケーションを行う際の閾値や、プロセスのメモリプレッシャーを間接的に支配している。
バッファあふれと高頻度GCのトレードオフ
`memory_limit` を極端に小さく設定した場合、アプリケーションが大量のオブジェクトを生成・破棄する過程で、ZMMは頻繁にメモリ上限の緊張状態に晒される。
逆に、`memory_limit = -1`（無制限）や `1024M` のように過度に大きく設定した場合、バッファが満杯になるまでの時間が延びるため、GCの実行頻度が激減する。
一見すると「GCの回数が減る＝オーバーヘッドが減る」ように思えるが、これは大きな誤りである。
GCの実行頻度を下げてメモリ内に不要な循環参照オブジェクトを溜め込みすぎると、いざGCが走った際の走査コスト（Mark-Sweepアルゴリズムにおけるグラフ走査）が肥大化し、スチュアート・タイム（STWに近い現象）やCPUキャッシュのヒット率低下を引き起こす。
/
class Node {
public ?Node $child = null;
public ?Node $parent = null;
}
// memory_limit との兼ね合いでGCの挙動を監視する
for ($i = 0; $i < 100000; $i++) {
$parent = new Node();
$child = new Node();
$parent->child = $child;
$child->parent = $parent; // 循環参照の成立
// スコープを抜けても refcount は 0 にならない
}
// 蓄積された循環参照がメモリを圧迫し、GCのコストを跳ね上げる
—
3. OPcacheプリローディングとGCの空間効率
モダンなPHP環境では、OPcacheのプリローディング（`opcache.preload`）が常識となっている。スクリプト開始時にあらかじめスクリプト群を共有メモリ（SHM）にロードし、リクエストごとのパース・コンパイルコストをゼロにする技術だ。
しかし、プリロードされたクラスや関数が保持する静的プロパティ（Static Properties）に循環参照が含まれている場合、それはプロセス生存期間中、永久に解放されないメモリ領域と化す。
ここで `memory_limit` が適切に設定されていないと、FPM（FastCGI Process Manager）のワーカープロセスがリクエスト処理を繰り返すうちに、OPcache領域外のヒープ消費量と相まって、OSのOOM Killer（Out of Memory Killer）の標的となる。
高スループットを維持するシステムにおいて、`memory_limit` は「単一リクエストの安全装置」であると同時に、「FPMプロセスの寿命をコントロールする間接的なトリガー」として機能させなければならない。
—
4. Fiber（ファイバー）並行処理におけるメモリ視点
PHP 8.1で導入された Fiber により、ひとつのOSスレッド（PHPプロセス）内で協調的マルチタスキング（Cooperative Multitasking）が可能となった。非同期I/O待ちの間にコンテキストスイッチを行い、別の処理を実行する。
ここで注意すべきは、Fiberはスタックフレームやローカル変数をヒープ上に保持するという点である。
複数の中断されたFiberが同時にメモリ上に存在する場合、それぞれのFiberが保持する変数グラフの中に循環参照や未解放のリソースが潜んでいると、メモリ使用量は急増する。
start();
// 別処理…
$fiber->resume();
Fiberが多用される非同期アーキテクチャでは、単一のリクエストフローという概念が曖昧になるため、`memory_limit` に達するタイミングが予測しにくくなる。そのため、Fiberのライフサイクルと同期した明示的な `gc_collect_cycles()` のコントロールが必要とされる場面が出てくる。
—
5. 極限環境におけるメモリ・GCチューニングの指針
アーキテクトとして実務の現場に立つ際、`memory_limit` はアプリケーションの性格（バッチ処理型か、超高速Web API型か）に応じて厳密に設計・分割されなければならない。
1. APIサーバー（ステートレス・短命リクエスト）
- `memory_limit` は必要最小限（例: `128M` 〜 `256M`）に厳しく制限する。
- これにより、メモリリークを起こしたバグが早期にFatal Errorとして検知され、FPMプロセスが安全に再起動（`pm.max_requests` との連携）される。
2. バッチ処理・データインジェスト（長寿命プロセス）
- ループ処理の適切なイテレーションごとに、意図的に `gc_collect_cycles()` を呼び出す、あるいは不要になったオブジェクトの参照を明示的に切断（`$obj = null;`）する。
- `memory_limit` は大きめに取るか、あるいは無制限にしつつ自前でメモリ監視を行う。
セキュリティ面（オブジェクトインジェクション対策）からの考察
脆弱性（PHP Object Injection）を突き、悪意ある `gadget chain` が構築された際、攻撃者は意図的に複雑なオブジェクト構造を逆シリアライズし、Zend VMのメモリ空間を意図した命令実行の踏み台に利用しようとする。
このプロセスにおいて、異常なメモリ消費を引き起こすペイロードに対し、厳格な `memory_limit` は、サーキットブレーカーとして機能し、メモリ枯渇攻撃（Denial of Service）の被害を最小限に食い止める最後の砦となる。
—
結び
PHPは「書いて動く手軽な言語」から「極限まで最適化されたエンタープライズ・ランタイム」へと進化した。その心臓部であるZend VMのメモリ管理、参照カウント、そしてGCのメカニズムを解像度高く理解せずして、真の高パフォーマンス・高可用性システムを設計することはできない。
`memory_limit` は単なる設定項目ではなく、VMの呼吸を司るリミッターである。エンジニアは、その数値がプロセスの寿命、CPUキャッシュ、そしてシステムの安定性に直結している事実を常に念頭に置くべきである。