こんにちは。PHPの表層的な文法を抜け出し、「リクエストの裏側でエンジンがどう呼吸しているのか」に興味を持つあなたへ。
他の言語（JavaやGo、Node.jsなど）を深く知っているエンジニアほど、PHPの「1リクエストごとにプロセスが（あるいはコンテキストが）完全に破棄される」というモデルに、独特の美しさと、同時に特有の難しさを感じるものですよね。
今回は、そのPHPのライフサイクルの最尾翼、つまりスクリプトの実行が終わり、死にゆく瞬間に何が起きているのかを解き明かしましょう。テーマは `register_shutdown_function` とメモリ解放のタイミング、そしてガベージコレクション（GC）の裏側の挙動です。
ここを理解すると、メモリリークの闇から完全に抜け出し、「なぜそのクリーンアップ処理がそこで動くのか」をZendエンジンの視座から俯瞰できるようになりますよ。
—
1. そもそもPHPの「リクエスト終了」とは何を意味するのか
Node.jsやGoのWebサーバーを想像してください。あちらはプロセスが常駐し、メモリ空間はリクエスト間で共有されます。そのため、GCはバックグラウンドで常に動き続け、メモリの枯渇を防ぎます。
一方、PHP-FPM（FastCGI Process Manager）のワーカープロセスは、1つのリクエストを処理すると、Zendエンジンは次のような破壊的なクリーンアップのシーケンスに入ります。
1. スクリプトの実行完了（あるいは致命的エラー）
2. `register_shutdown_function` に登録されたコールバックの実行
3. 出力バッファのフラッシュ（`ob_end_flush` など）
4. Zendエンジンによるリソースの解放（ファイルハンドル、DB接続、SAPI固有のシャットダウン）
5. リクエストメモリプール（Request Heap）の完全開放
ここで重要なのは、「`register_shutdown_function` は、Zendエンジンがメモリを更地にする直前の、最後の砦（ラストチャンス）」だということです。
—
2. `register_shutdown_function` と GC の絶妙なタイミング
多くの開発者が誤解しているのですが、`register_shutdown_function` が呼び出される時点では、まだPHPのメモリ空間（シンボルテーブルやグローバル変数）は完全に生存しています。
しかし、通常のスクリプト実行が終了した直後であるため、ここから新たな変数を作ったり、巨大なオブジェクトをアロケートしたりすることは、メモリ管理上非常に危険な行為になります。なぜなら、エンジンの脳内はすでに「お片付けモード」に入っているからです。
循環参照とGCのタイミング
PHPのメモリ管理は、基本的には参照カウント（Reference Counting）によって行われています。変数が別の変数に代イグされたり、スコープを抜けたりすると、Zendエージェントはその変数の zval 構造体の refcount を増減させ、ゼロになった瞬間にメモリを解放します。
ただし、厄介なのが循環参照（Circular Reference）です。オブジェクト同士が互いを参照し合うと、スコープを抜けても refcount が 1 残ってしまい、通常の参照カウント方式ではメモリリークを起こします。
これを回収するのが、PHP 5.3以降に導入された循環ガベージコレクタ（Concurrent Garbage Collector）です。
[親オブジェクト] <---> [子オブジェクト] (互いに参照し合い、refcount = 1 のまま孤立)
↓
バッファ（Root Buffer）に蓄積される
↓
GCが走る（または shutdown 時に強制回収）
通常、このGCはルートバッファ（root buffer）が一杯になった時などに自動で走りますが、スクリプトの実行終了時（正確には `register_shutdown_function` の実行前後）にも、残存する循環参照を一網打尽にするための最終GCサイクルが回ります。
—
3. 実践：shutdown とメモリ解放の順序をコードで脳内トレースする
百聞は一見に如かず。実際にコードを書いて、このライフサイクルの挙動を確認してみましょう。
/
class MemoryWatcher {
private $data;
public function __construct(string $name) {
// あえて大きな文字列を保持させ、メモリ消費を視覚化する
$this->data = str_repeat(“A”, 1024 1024 10); // 約10MB
echo “[INIT] {$name} が生成され、約10MBをアロケートしました。\n”;
}
public function __destruct() {
echo “[DESTRUCT] {$name} のデストラクタが呼ばれました。\n”;
}
}
// シャットダウン関数の登録
register_shutdown_function(function() {
echo “\n— [SHUTDOWN START] register_shutdown_function が発火しました —\n”;
// この時点でメモリ使用量を確認
echo “現在のメモリ使用量: ” . round(memory_get_usage(true) / 1024 / 1024, 2) . ” MB\n”;
// ガベージコレクションの状態を確認・強制実行
echo “GCの状態: “;
var_dump(gc_status());
echo “— [SHUTDOWN END] これからZendエンジンがすべてを完全に解放します —\n”;
});
// オブジェクトのインスタンス化
$watcher = new MemoryWatcher(“Watcher-A”);
// スクリプトのメイン処理はここで終了
echo “[MAIN] メインスクリプトの処理が終了します。\n”;
このコードの実行結果（裏側の挙動）はどうなるか？
出力順序を追ってみましょう。
1. `[INIT] Watcher-A が生成され…` （メモリプールに約10MB確保）
2. `[MAIN] メインスクリプトの処理が終了します。`
3. （ここで通常のスコープアウトによるデストラクタの呼び出し）
`[DESTRUCT] Watcher-A のデストラクタが呼ばれました。`
4. `— [SHUTDOWN START] register_shutdown_function が発火しました —`
`現在のメモリ使用量: 2.xx MB` （オブジェクトは破棄されているためベースメモリに戻っている）
`GCの状態: […]`
5. `— [SHUTDOWN END] —`
もしここで、`$watcher` が何らかの理由で他のグローバル変数や例外オブジェクトと循環参照を起こしていた場合、ステップ3のデストラクタは即座には呼ばれません。その代わり、シャットダウンの直前にGCが強制発動し、その過程でデストラクタが呼ばれるという挙動になります。
—
4. アーキテクトが知るべき「シャットダウン処理」の罠とベストプラクティス
この `register_shutdown_function` とメモリ解放の仕組みを理解していると、現場で遭遇する不可解なバグの理由がスッと見えてきます。
罠1: 例外とシャットダウン関数の順序
`register_shutdown_function` 内で未キャッチの例外が発生した場合、通常のエラーハンドラやtry-catchでは拾えないことがあります。なぜなら、すでにメインの実行コンテキストは巻き戻されているからです。シャットダウン関数内でのコードは、極力シンプルに、例外を投げない堅牢なもので組むのが鉄則です。
罠2: データベース接続や外部リソースのクローズ
よく「接続の切断忘れを防ぐために shutdown で db close を呼ぼう」というコードを見かけますが、Zendエンジンはスクリプト終了時に開いているリソース（PDO接続、ファイルポインタなど）を自動的にクローズします。
ただし、外部APIへの非同期的なログ送信や、トランザクションの明示的なロールバックなど、「アプリケーションの文脈としてどうしても保証したい後処理」においては、`register_shutdown_function` は非常に強力な武器になります。
—
さいごに
PHPは「遅い」「適当に書いても動く言語」という悪名高い誤解を受けがちですが、その実、Zendエンジンという極めて洗練された仮想マシン上で、リクエストごとに完全にメモリをリセットするという、メモリリークに対して最もアグレッシブで堅牢な設計を持った言語です。
`register_shutdown_function` とメモリ解放のタイミングを掌握したあなたなら、もう「なぜかメモリが溢れる」という現象に怯える必要はありません。エンジンの息づかいを感じながら、美しく堅牢なPHPコードを書き続けてください。