【テクニカル・上級編】PHPの`register_shutdown_function`とメモリ解放のタイミング：リクエスト終了後のGC実行とリソースクリーンアップの課題 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

PHPコアの深淵：`register_shutdown_function`とリクエスト終端におけるメモリ解放の不可逆性

PHPのライフサイクルは、Webアプリケーションの文脈において極めてシンプルに見える。1つのHTTPリクエストが飛び込み、SAPI層（ApacheモジュールやFPM、CLIなど）がZend Engineを初期化し、スクリプトが走り、出力がバッファリングされてクライアントへ返り、そしてプロセスは破棄される――あるいはFPMであれば次のリクエストのために再利用される。

だが、この「リクエストの終端」において、Zend VMの内部ではどのような物理的悲喜劇が演じられているか。特に、開発者が安全弁として多用する `register_shutdown_function` の実行タイミングと、Zend Engineの参照カウント（Reference Counting）およびガベージコレクション（GC）の調停メカニズムは、極めて高度な低レイヤの同期を要求する。

今回は、Zend VMのメモリ空間、HashTableの構造、そして `zend_execute_data` の消滅プロセスを踏まえ、リクエスト終了時のメモリ解放の真実を暴く。

—

1. Zend VMの終端処理シーケンス：`request_shutdown` の正体

PHPのスクリプト実行が完了し、`main()` 関数を抜けた後、SAPI層は `php_request_shutdown()` を呼び出す。この関数の中で、Zend Engineは以下のような厳格な順序でリソースの解放を行う。

1. ユーザースクリプトのシャットダウン関数の実行（ここで `register_shutdown_function` が火を噴く）
2. オブジェクトのデストラクタ（`__destruct`）の強制実行
3. 永続化されていないリソース（ファイルハンドル、cURLハンドル、ソケットなど）の破棄
4. Zend Executorのグローバル変数のクリアとシンボルテーブルの破棄
5. Zend Memory Manager (ZMM) による残存アロケーションの一括解放

多くのエンジニアが勘違いしているのは、`register_shutdown_function` が「すべてのメモリが綺麗に掃除されたクリーンな状態」で動くという幻想だ。実際には、このシャットダウン関数が実行されている瞬間こそ、メモリリーク、循環参照、そしてダングリングポインタの危険性が最も高まるカオスな空間である。

シャットダウン時のメモリ空間の歪み

fp = fopen($filename, ‘r’);
echo “Resource allocated.\n”;
}

public function __destruct() {
if (is_resource($this->fp)) {
fclose($this->fp);
echo “Resource closed in __destruct.\n”;
}
}
}

// シャットダウン関数の登録
register_shutdown_function(function() {
echo “Shutdown function executed.\n”;
// この時点でZend VMのシンボルテーブルはどうなっているか？
});

$holder = new ResourceHolder(__FILE__);
// リクエストの強制終了（あるいはスクリプトの自然死）

このコードにおいて、`register_shutdown_function` に登録された無名関数が実行されるとき、`$holder` オブジェクトはまだメモリ上に存在している。しかし、グローバルシンボルテーブルは既に解体プロセスに入っており、変数の参照関係は非常に危ういバランスの上にある。

—

2. 循環参照とガベージコレクション（GC）の限界

PHP 5.3以降、循環参照（Circular References）に対処するため、ルートバッファを用いたコンカレント・ガベージコレクション（Concurrent Cycle Collection）が導入されている。これは、参照カウントがゼロにならないものの、他の変数から孤立した `IS_ARRAY` や `IS_OBJECT` の構造体を検出し、解放するための仕組みだ。

しかし、リクエスト終了時の `register_shutdown_function` のコンテキストにおいて、このGCがどのように振る舞うかを意識したことがあるだろうか？

ZMMとアリーナ構造の物理的現実

Zend Memory Managerは、パフォーマンスを最大化するため、システムコール（`malloc`/`free`）の頻度を極限まで減らし、独自のヒープ領域（Chunk / Page）をアロケートして管理している。

リクエストの終端において、Zend Engineは個々のメモリブロックを細かく `free` するような非効率なことはしない。`php_request_shutdown()` の最終段階（すべてのシャットダウン関数とデストラクタが火花を散らし終えた後）で、Zend Engineはリクエストに関連するすべてのZMMヒープチャンクを一括して解放（あるいはリクエストキャッシュプールへ返却）する。

つまり、`register_shutdown_function` の中でどれだけ巨大な配列やオブジェクトを生成・破棄しようとも、Zend Engineはそれを細かくトラッキングしてOSに返還するわけではない。すべてはリクエスト終了直後の「一括破棄（Mass Destruction）」の対象となる。

しかし、ここに落とし穴がある。「リソース（Resource）」の解放は、メモリの解放とは異なるという点だ。

—

3. リソース（File/Socket）クリーンアップのタイムラグ

ファイルハンドルやデータベース接続、cURLセッションなどの「リソース」は、Zendの値の型としては `IS_RESOURCE`（PHP 8以降では内部クラスやオブザーバーパターンに移行しつつあるが、概念は同じ）であり、対応する実体がZend Memoryの外（OSのファイル記述子や外部サーバーとのTCPコネクション）に存在する。

もし `register_shutdown_function` の中で外部APIへのログ送信や、データベースへの終了ステータス書き込みを行おうとした場合、以下の問題が発生する。

拡張機能（Modules）のシャットダウン（`RSHUTDOWN`）は、ユーザースクリプトのシャットダウン関数の「前」に起きるのか「後」に起きるのか？

答えは、「ユーザースクリプトのシャットダウン関数がすべて実行された『後』に、各拡張機能の `RSHUTDOWN` が走る」。
つまり、`register_shutdown_function` の実行時点では、`mysqli` や `PDO` などの拡張機能のリソースはまだ有効である。

しかし、これは「安全である」ことを意味しない。

順序依存性とクラッシュの罠

複数のシャットダウン関数が登録された場合、それらは登録された順序（FIFO）で実行される。ここで、Aというシャットダウン関数がデータベース接続リソースを勝手に閉じてしまい、Bという別のシャットダウン関数が同じリソースを使おうとすると、Segmentation Fault（セグメンテーション違反）を引き起こすか、予期せぬ `Error` がスローされる。

// 危険なコード例：シャットダウン関数間の暗黙の依存関係
register_shutdown_function(function() {
// データベース接続を明示的に閉じる
global $pdo;
$pdo = null; // デストラクタが走り、接続が切断される
});

register_shutdown_function(function() {
// 先ほどの切断に気づかず、アクセスしてクラッシュ
global $pdo;
$pdo->query(“INSERT INTO audit_log …”);
});

Zend VMのレイヤにおいて、グローバルスコープの変数がシャットダウンの過程でどのようにアンセットされていくかは、Zend Executorのシンボルテーブルの消滅順序に依存しており、完全にデダーム（決定論的）とは言えないケースがある。特に、例外やエラーがスローされた状態でシャットダウンに入った場合、Zend VMのエラーハンドラとシャットダウンキューのインタラクションは極めて複雑怪奇となる。

—

4. OPcacheプリローディングとシャットダウンのパラドックス

近年のPHP（7.4以降、8.xで深化）におけるパフォーマンスの要は、OPcacheのプリローディング（Preloading）である。`php.ini` の `opcache.preload` に指定されたスクリプトは、サーバーの起動時（`MINIT` フェーズ）にパースされ、Zend VMのオペコード（Opcode）として永続メモリ（SHM: Shared Memory）に焼き付けられる。

ここで重要なのは、プリロードされたクラスや関数は、リクエストごとのシャットダウン処理の影響を一切受けないという点だ。

もし、`register_shutdown_function` の中でプリロードされたクラスの静的プロパティ（Static Properties）を操作し、そこにリクエスト固有のオブジェクトやリソースを保持させてしまった場合、どうなるか？

class StateManager {
public static $instance;
}

register_shutdown_function(function() {
// 致命的な設計ミス：
// 永続化された共有メモリ上の静的プロパティに、
// リクエスト固有のオブジェクトを保持させてしまう
StateManager::$instance = new ResourceHolder(__FILE__);
});

このコードが実行されると、リクエスト終了間際にシャットダウン関数が動き、共有メモリ（OPcache SHM）上の静的プロパティに対してリクエストヒープ上のオブジェクトのポインタが書き込まれようとする。Zend Engineのメモリ保護機構（あるいはリクエスト境界のチェック）により、これはバグを生むか、最悪の場合、FPMのワーカープロセス全体がクラッシュ（SIGSEGV）する原因となる。

FPMプロセスがクラッシュすると、そのプロセスが担当していた次以降のリクエストは `502 Bad Gateway` を返すことになり、高負荷時に大規模な可用性低下を引き起こす。

—

5. 究極の防御的実装：シャットダウン関数におけるメモリとリソースの管理原則

プロフェッショナルなWebシステムアーキテクトとして、PHPの終端処理におけるリスクを完全にコントロールするためには、以下の鉄則をコードに落とし込む必要がある。

1. シャットダウン関数内でリソースの新規割り当てを行わない
シャットダウン時はすでにクリーンアップフェーズに入っており、新たなメモリ確保や外部接続の確立は予測不能な挙動を招く。
2. 外部I/O（ロギングや非同期通知）は非同期キューに委譲する
`register_shutdown_function` 内で重いDB書き込みやHTTPリクエストを行うべきではない。行うのであれば、確実に接続が閉じられる前に、ノンブロッキングなソケットや、OSレベルのプロセス分離（FastCGIの `fastcgi_finish_request()` の活用）を先に行うべきである。
3. `fastcgi_finish_request()` との正しい協調
PHP-FPM環境において、クライアントへのレスポンス送信を早期に完了させ、裏で重い処理を続けるために `fastcgi_finish_request()` が使われる。

‘accepted’]);
fastcgi_finish_request();
}

// この瞬間にリクエストのメインフローは終了し、
// クライアントとの通信は途絶えるが、バックグラウンド処理が継続する。
// この後、register_shutdown_function が発火する。
register_shutdown_function(function() {
// 重いログ処理や外部API送信
// 注意: ここでもZend Memory Managerのライフサイクルは継続しているため、
// メモリリーク（循環参照など）がある場合はこの段階でGCが働く。
gc_collect_cycles(); // 明示的なGCの強制実行
});

`fastcgi_finish_request()` 実行後のシャットダウンフェーズでは、クライアントを待たせることなく安全にバックグラウンドタスクを処理できるが、データベースやファイルハンドルの寿命がリクエストの終了とともに尽きるという事実には変わりがない。永続的なバックグラウンドワーカーが必要な場合は、PHP-FPMの枠組み（Webリクエストのライフサイクル）を捨て、CLIによる長寿命プロセス（Swoole、ReactPHP、あるいは純粋なCLI daemon）を採用すべきである。

—

結びにかえて

PHPは「リクエストごとにすべてを忘れる（Shared-Nothing Architecture）」という極めて強固な思想によって、メモリリークの恐怖からWebアプリケーションを長年守り続けてきた。しかし、`register_shutdown_function` や OPcacheプリローディング、そして高度な並行処理（Fiber等）の登場により、その境界線は曖昧になりつつある。

Zend VMのメモリ空間、ZMMのアロケーション戦略、そしてSAPIのライフサイクルを完全に理解した者だけが、予期せぬクラッシュやメモリ汚染のない、真に堅牢なエンタープライズPHPシステムを構築できる。コードの表面的な挙動に惑わされず、つねにオペコードとエンジンの鼓動を感じながら設計を続けよ。