PHPの限界を支配する：`memory_limit`とガベージコレクションの隠された因果律
PHPのメモリ管理機構は、その洗練されたAPIの裏腹に、Zend Engineの極めてプリミティブな参照カウント（Reference Counting）と、それを補完する循環参照ガベージコレクタ（Cyclic Garbage Collector）の二重構造によって成り立っている。
多くのエンジニアは、`memory_limit`を単なる「スクリプトが暴走した際に安全装置としてプロセスを強制終了させるための閾値」と誤認している。しかし、Zend VMの低レイヤ視点において、この設定値はガベージコレクションのトリガー頻度、Zend Memory Manager（ZMM）のチャンク確保戦略、そしてリクエスト終了時のメモリ解放遅延（Destruction Latency）に決定的な影響を与える物理的な制御変数に他ならない。
本稿では、`memory_limit`とGCの相互作用が生み出すピークメモリの跳ね上がりの正体を暴き、巨大なオブジェクトグラフを扱う高負荷Webシステムにおいて、PHPエンジンの限界を突破するための知見を提示する。
—
1. Zend VMのメモリ管理と参照カウントの限界
PHPのすべての変数、配列、オブジェクトは、Zend Engine内部で `zval`（Zend Value）構造体として表現されている。PHP 7以降、スカラー値は `zval` 内に直接インライン配置されるか、ポインタを介さずに値そのものが格納されるようになり、メモリ効率は劇的に改善された。しかし、オブジェクト（`zend_object`）や配列（`zend_array` / HashTable）などの複合データ型は、依然としてヒープメモリ上に動的にアロケートされ、`zval` の `refcount`（参照カウンタ）によって管理されている。
参照カウント方式の美しさは、変数がスコープを抜けた瞬間（あるいは `unset()` が呼ばれた瞬間）、`refcount` がデクリメントされ、それが0に達した瞬間に即座にメモリが解放される点にある。これにより、C/C++のような手動メモリ管理の地獄から解放されている。
しかし、この美しさは「循環参照（Circular Reference）」という致命的な構造的欠陥によって容易に崩壊する。
/
class Node {
public ?Node $child = null;
public ?Node $parent = null;
public function __construct(public string $name) {}
}
// 巨大なオブジェクトグラフの構築
$parent = new Node(‘Root’);
$child = new Node(‘Leaf’);
$parent->child = $child;
$child->parent = $parent; // 循環参照の成立
// 変数スコープを外れる、または上書きする
$parent = null;
$child = null;
// この瞬間、それぞれの refcount は「1」のまま残り続け、即座のメモリ解放は行われない
上記のコードにおいて、`$parent` と `$child` の変数を破棄しても、お互いを指し示すポインタが残っているため、それぞれの `zval` の参照カウントは `0` にならない。結果として、メモリはリークした状態のままヒープに留まり続ける。これを回収するのが、Zend Engineの循環参照ガベージコレクタ（GC）である。
—
2. `memory_limit` が GC の実行タイミングとバッファ戦略に与える影響
PHPのGCは、常にバックグラウンドで動作しているわけではない。パフォーマンスのオーバーヘッドを最小化するため、GCは「ルートバッファ（Roots Buffer）」と呼ばれる固定長（デフォルトでは通常10,000エントリ）のリングバッファが満杯になった瞬間にのみ起動する（Lazy Evaluation）。
ここで `memory_limit` がどのように絡んでくるか。Zend Memory Manager（ZMM）は、OSからメモリをチャンク単位（通常2MB）で一括取得し、それを細分化してPHPスクリプトに割り当てる。`memory_limit` は、このZMMが許容する最大ヒープサイズを規定するだけでなく、内部の阿鼻叫喚なアロケーション戦略のしきい値に影響を与える。
バッファフルと `memory_limit` の相関
1. 大量のアレイやオブジェクトを生成するバッチ処理やAPIレスポンス構築において、循環参照候補が次々とルートバッファに蓄積される。
2. `memory_limit` が十分に大きい（あるいは `-1` 無制限に設定されている）場合、バッファが溢れるか、明示的に `gc_collect_cycles()` が呼ばれるまでGCは発動しない。
3. 結果として、不要になったメモリ空間がヒープ内に長期間残留し続け、「ピークメモリ使用量（Peak Memory Usage）」が不必要に跳ね上がる。
4. 逆に `memory_limit` が厳しすぎる環境では、ZMMがメモリ限界を検知する閾値と、GCによる回収サイクルのバランスが崩れ、頻繁なGCの走査（Mark and Sweep）によるCPUキャッシュミスの多発（CPUバウンドなボトルネック）を引き起こす。
—
3. リクエスト終了時のメモリ解放遅延とFPMプロセスの寿命
多くの開発者が誤解している点として、「リクエストが終了すれば、PHPプロセスが保持していたメモリはすべて一瞬でクリーンアップされる」という神話がある。
確かに、OSの視点では、プロセスが終了（またはCGIリクエストのライフサイクルが完結）すれば、プロセス空間に割り当てられていた物理メモリは仮想記憶管理機構によって一括解放される。しかし、PHP-FPM（FastCGI Process Manager）のアーキテクチャ下では話が異なる。
PHP-FPMは、リクエストごとにプロセスをforkするのではなく、あらかじめ立ち上げておいたワーカープロセスを再利用（Keep-Alive / Persistent Process）する。つまり、リクエスト終了時のメモリ解放は、OSへの返却ではなく、Zend MM内での「フリーリストへの返却（Deallocation）」として処理される。
リクエスト終了時の隠れたオーバーヘッド
リクエストの終端（`request_shutdown` フェーズ）において、Zend Engineはスクリプト実行中に確保されたすべてのシンボルテーブル、リソース、そしてオブジェクトを破棄（Destruction）する。
もし、アプリケーション内で深すぎるオブジェクトグラフや膨大な循環参照が放置されている場合、リクエスト終了時のファイナライザ（`__destruct()` メソッドなど）の実行順序の解決や、参照カウントのデクリメント連鎖処理に莫大なCPUサイクルの遅延が発生する。
/
class HeavyResourceHolder {
private ?self $sibling = null;
private string $payload;
public function __construct() {
// 1MBのダミーペイロード
$this->payload = str_repeat(‘X’, 1024 1024);
}
public function link(self $sibling): void {
$this->sibling = $sibling;
$sibling->sibling = $this; // 循環
}
public function __destruct() {
// デストラクタ内での処理がリクエスト終了時に直列実行される
// ここに重い処理があるとFPMワーカーの解放が遅延し、スループットが低下する
}
}
この状態のスクリプトが大量のリクエストを処理すると、FPMワーカーの返却遅延が発生し、NginxやApache側のアップストリームキューが溢れ、システム全体のスループットが雪崩式に低下する。`memory_limit` はこの問題の直接の原因ではないが、「メモリ制限に達しないからといって、解放をサボり続けたツケがリクエスト終了時に一括して支払われる」という構造的爆弾を育てる温床となる。
—
4. OPcacheプリローディングとメモリ空間の共有メカニズム
現代のPHP（PHP 7.4以降）において、メモリ最適化の切り札となるのが OPcache Preloading である。
従来のOPcacheは、バイトコード（Opcode）を共有メモリ（SHM）上にキャッシュし、リクエストごとにパース・コンパイルコストを削減していた。しかし、クラスの定義やグローバルな定数はリクエストごとにシンボルテーブルにインポートされる必要があった。
プリローディングは、サーバー起動時（`php-fpm.conf` の `opcache.preload` で指定されたスクリプトの実行時）に、指定されたすべてのクラス、インターフェイス、トレイトをメモリ上に完全ロードし、永続的な共有メモリ領域にロックする。
; php.ini での設定例
opcache.enable=1
opcache.memory_consumption=256
opcache.preload=/var/www/html/config/preload.php
opcache.preload_user=www-data
プリローディング時のメモリとGCの罠
プリローディングされたクラスは、親プロセス（FPM Master）のメモリ空間に常駐し、`fork()` を通じて子プロセスにCopy-On-Write（COW）で継承される。
ここで注意すべきは、プリロードスクリプトの実行中に生成されたインスタンスや、意図しないグローバル状態は、そのまま共有メモリの永続領域に固定化される点である。
もし、プリロードスクリプト内で動的なデータ（例えば、データベースから動的に取得した設定値の配列など）を静的プロパティやオブジェクトとして保持させてしまった場合、それはすべてのリクエストプロセス間で共有され、かつ解放不可能なメモリリークの源泉となる。
プリロード対象のコードを書く際は、以下の鉄則を厳守しなければならない。
1. インスタンスの状態（State）をプリロードしない： クラス定義、メソッド、定数のみをロードする。静的プロパティに可変データを保持させてはならない。
2. 循環参照の排除： プリロードされるコード内に静的な循環参照が存在すると、そのメモリ領域はFPMプロセスのライフサイクル全体にわたって二度と回収されず、全ワーカーのベースメモリ使用量を圧迫し続ける。
—
5. 極限環境下におけるメモリ管理のベストプラクティス
高トラフィックなAPIサーバーや、巨大なペイロードを扱うマイクロサービスアーキテクチャにおいて、PHPのメモリ効率を極限まで高めるための設計指針を提示する。
① 意識的なGCのコントロールとバッファ管理
デフォルトのGC挙動に依存せず、バッチ処理や大量のデータ処理を行うループ内では、適切なタイミングで明示的なGC発動とルートバッファのクリアを行う。
② `memory_limit` の適正化
「大きければ安全」という思考停止を捨てよ。メモリリークを抱えたコードにおいて、`memory_limit = 512M` や `1G` といった巨大な値を設定することは、「メモリリークの発覚を遅らせ、FPMプールの全メモリを枯渇させた挙句にOOM Killer（Out of Memory Killer）によってOS全体を巻き込んでクラッシュさせる」という最悪のセキュリティリスクと可用性の低下を招く。
適切な監視メトリクスに基づき、1リクエストあたりの許容最大メモリを厳密にサイジングし、必要であれば `ini_set(‘memory_limit’, ‘128M’)` のようにエンドポイントごとに動的制御を行うべきである。
③ 参照（References）の排除
PHPにおける `&`（リファレンス代入）の多用は、Zend Engineの内部最適化（Copy-On-Write）を無効化し、メモリの不必要な複製や複雑な参照カウントの網を作り出す。
現代のPHPにおいて、パフォーマンス向上を目的としたリファレンスの使用は百害あって一利なしである。オブジェクトは常に値渡し（実際にはオブジェクトハンドルのコピー）として扱い、参照カウントの予測可能性を担保すること。
—
結び
PHPは「手軽に書けるスクリプト言語」というマイルドな外皮の裏に、Zend VMという極めてシビアなC言語製の仮想マシンを隠し持っている。`memory_limit` とガベージコレクションの相互作用を制する者は、PHPプロセスのメモリフットプリントを完全に掌握し、予測可能でスケーラブルなWebシステムを構築することができる。
コードの行数を減らすことよりも、ヒープ上の `zval` の生死に思いを馳せよ。それこそが、真のPHPコアエンジニアの視座である。