PHPを掌握する極限の知見：`memory_limit`とガベージコレクションの隠れた因果関係
コードレビューの現場で、こんな議論に遭遇したことはないだろうか。
「なんだかこのバッチ処理、メモリを食い潰すから `memory_limit` を `2G` に引き上げておこう」
一見すると、致命的な `Allowed memory size exhausted` エラーを防ぐための合理的な応急処置に見える。しかし、Zendエンジンがメモリ空間（ZendMM）とガベージコレクション（GC）をどのように管理しているかを知るリードアーキテクトの視点から言えば、これは「メモリリークを隠蔽し、ピークメモリ使用量をさらに跳ね上がらせる最悪の悪手」になり得ます。
今回は、`memory_limit` の設定値がPHPのガベージコレクション（GC）の自律的な発動タイミングにどう作用し、それがリクエスト終了時、あるいはロングランプロセスにおいてどのようなメモリ解放遅延を引き起こすのか。その低レイヤのメカニズムと、実務で絶対に守るべき設計ルールを徹底的に紐解きます。
—
1. Zendエンジンにおける参照カウントとGCのメカニズム
PHP（Zend VM）のメモリ管理の根底にあるのは、おなじみの 参照カウント（Reference Counting） と コピー・オン・ライト（Copy on Write: CoW） です。
すべての変数コンテナ（`zval` 構造体）は、自分を参照しているシンボルや他の構造体の数を `refcount` として保持しています。この `refcount` が `0` になった瞬間、その `zval` は即座にメモリから解放され、ZendMM（Zend Memory Manager）のプールへ返却されます。これが通常の高速なメモリ解放パスです。
循環参照という「ゾンビ」の誕生
しかし、オブジェクトや配列が自分自身や互いを参照し合う 循環参照（Circular Reference） が発生すると話が変わります。
例えば、親オブジェクトが子オブジェクトを持ち、子が親への参照を保持している構造を考えてみましょう。このコンテナ群を `unset()` したり、スコープを抜けたりして「外部からの参照」が消滅したとしても、お互いを指し示す `refcount` は `0` になりません（各 `refcount` が `1` 残る状態）。
結果として、メモリ上には誰からもアクセスできない「孤立したゴミの塊」が取り残されます。これがPHPのガベージコレクタが回収すべきターゲットです。
バッファリング機構（ルートバッファ）の正体
PHPのGCは、すべての変数を常に監視しているわけではありません。そんなことをすれば毎プロセスのCPUコストが破綻します。
Zendエンジンは、`zval` の中で「もしかしたら循環参照に含まれるかもしれない候補（コンテナの型が配列かオブジェクト）」を、ルートバッファ（Root Buffer）と呼ばれる固定長の二重linkedリストにせっせとバッファリングしていきます。
デフォルトでは、このルートバッファが 10,000エントリ に達した瞬間、あるいは明示的に `gc_collect_cycles()` が呼ばれた瞬間に、初めて本格的なGCアルゴリズム（グラフの走査と参照カウントの仮デクリメント）が発動する仕組みになっています。
—
2. `memory_limit` がGCの挙動とピークメモリを狂わせる理由
ここで本題である `memory_limit` との相互作用の話に入ります。
多くのエンジニアは、「`memory_limit` は、スクリプトが消費してよい上限値（リミッター）」と捉えています。しかし、Zendエンジンの内部実装において、この値は 「GCがどれくらいアグレッシブに、あるいは怠惰に振る舞うかの暗黙のトリガー」 の一部としても機能しています。
`memory_limit` を安易に引き上げたときに起きる悲劇
1. バッファの飽和遅延:
`memory_limit` を高く設定すると、ZendMMが割り当てられるヒープ領域の余裕が増えます。これにより、巨大なデータ構造や数万件のORMオブジェクトをループ内で生成・破棄する際、ルートバッファが10,000件の閾値に達するまでの「時間とメモリの猶予」が伸びてしまいます。
2. 解放遅延によるピークメモリの急増:
本来であればもっと早い段階で回収されるべき循環参照を含んだ `zval` 群が、ルートバッファの閾値が高いがためにメモリ上に居座り続けます。結果として、スクリプトが本当に必要としているメモリ量に加え、「既に不要だがまだGCに回収されていないゾンビメモリ」がヒープを圧迫し、ピークメモリ使用量が本来の数倍に膨れ上がります。
3. リクエスト終了時のシステム負荷:
Webアプリケーション（PHP-FPM）において、スクリプトの実行が終了し `SAPI` がシャットダウンする際、プロセスが保持していたすべてのメモリは最終的にOSに返却されます。しかし、大量の循環参照が未回収のままリクエスト終了を迎えた場合、PHP-FPMのシャットダウン処理（リクエストクリーンアップ）において、Zendエンジンはすべての残存 `zval` を強制的に走査・解放するコストを支払わされます。これが「レスポンスは返したのに、FPMワーカープロセスがCPUを掴んだまま次のリクエストを受け付けない（解放遅延）」という現象の正体です。
—
3. 実務で防ぐ：メモリ効率を極限まで高める設計とコード
この問題を解決するには、単に `memory_limit` をいじるのではなく、「PHPにGC頼みのメモリ管理をさせない設計」にシフトすることが不可欠です。特に数千件以上のレコードを処理するバッチ処理やAPIエンドポイントでは、以下の原則を遵守してください。
実装パターン：メモリ枯渇を防ぐ「明示的クリーンアップ」の実装例
以下に、大量のオブジェクトや配列を安全に処理し、ピークメモリを極小に抑えるためのリファレンスコードを示します。
/
class BatchDataProcessor
{
private const CHUNK_SIZE = 500;
public function executeHeavyProcess(\PDO $pdo): void
{
// 念のため、実行中のスコープでGCが有効か確認
if (!gc_enabled()) {
gc_enable();
}
$offset = 0;
// 大規模データセットをチャンク（分割）してフェッチ
while (true) {
$records = $this->fetchChunk($pdo, self::CHUNK_SIZE, $offset);
if (empty($records)) {
break;
}
foreach ($records as $record) {
// ドメインロジックの実行（オブジェクト生成等を伴う想定）
$this->processRecord($record);
}
// — 【極意】チャンク処理ごとの明示的メモリ防衛 —
// 1. 変数の参照を切断
unset($records, $record);
// 2. ルートバッファが溢れる前に、かつ不要な循環参照を即座に潰すために手動発動
// ※数千件単位のループであれば、数回に一度 gc_collect_cycles() を叩く方が
// ピークメモリを劇的に低く抑えられます。
$collected = gc_collect_cycles();
// ログなどで回収されたサイクル数を確認できるようにする（デバッグ用）
// error_log(“GC collected: {$collected} cycles”);
$offset += self::CHUNK_SIZE;
}
}
private function fetchChunk(\PDO $pdo, int $limit, int $offset): array
{
$stmt = $pdo->prepare(“SELECT FROM heavy_table LIMIT :limit OFFSET :offset”);
// PDO::PARAM_INTの明示による型安全性の確保
$stmt->bindValue(‘:limit’, $limit, \PDO::PARAM_INT);
$stmt->bindValue(‘:offset’, $offset, \PDO::PARAM_INT);
$stmt->execute();
return $stmt->fetchAll(\PDO::FETCH_ASSOC);
}
private function processRecord(array $record): void
{
// ここで複雑なオブジェクトグラフを構築する場合、
// 内部で循環参照（親子双方向の保持など）を作らない設計が最良です。
// やむを得ず作る場合は、処理終了時にプロパティに null を代入して参照を切る等の配慮を。
}
}
コードレビューの現場で使えるチェックリスト
1. ORMや巨大な配列のループ処理で `unset()` を怠っていないか？
- ループ内で生成されたローカル変数やオブジェクトは、スコープを抜けるまで（あるいは次の上書きまで）メモリに残り続けます。不要になった瞬間に `unset($variable);` を行う習慣をつけましょう。
2. 双方向参照（Bidirectional Reference）を安易に使っていないか？
- 「親から子、子から親」を参照する設計は、PHPのGCにとって最大の敵です。ID（スカラー値）による参照や、依存性注入のスコープを適切に設計することで循環参照自体を生み出さない構造にしてください。
3. 「とりあえず `memory_limit` を上げる」を禁止しているか？
- メモリエラーが出たときは、制限値を上げる前に必ず `memory_get_usage(true)` および `memory_get_peak_usage(true)` をロギングし、どこでメモリがリークしているか（あるいは解放が遅れているか）をプロファイルするフローをチームに徹底させてください。
—
結びにかえて
PHPは、リクエストごとにメモリ空間ごとすべてを綺麗に更地にしてくれる「お気楽な言語」という神話は、現代の長寿命なAPIサーバーや重厚長大なフレームワーク（SymfonyやLaravelなど）の運用においては過去のものとなりました。
Zendエンジンの内部構造、参照カウントの挙動、そして `memory_limit` がGCの自律性をどのようにマスクしてしまうのかを理解しているエンジニアだけが、予測不能なメモリ高騰やFPMプロセスの詰まりを起こさない、真にスケーラブルで頑健なWebシステムを構築できます。
次に「メモリが足りない」というアラートに直面したとき、あなたがすべきことは `php.ini` を開くことではありません。コード内のメモリのライフサイクルを見つめ直し、Zendエンジンと対話することです。