PHPの終焉と再生：`register_shutdown_function`から覗くZend VMメモリ解放の深淵
PHPは「リクエストごとにすべてを忘却する」という極めて潔いライフサイクルを持つ。SAPI（Server API）がHTTPリクエストを受信し、Zend Engineが起動してスクリプトをコンパイル・実行し、最後に出力バッファをフラッシュしてプロセスを眠りにつかせる。この一連のライフサイクルにおいて、開発者が意識することは少ないが、極限の高負荷環境やメモリリークと隣り合わせの非同期処理において、プロセスの終端処理は生死を分ける境界線となる。
今回は、スクリプトの断末魔に実行される `register_shutdown_function` に焦点を当て、PHPのメモリ管理の根幹である参照カウント、循環参照のガベージコレクション（GC）、そしてリクエスト終了時におけるリソースクリーンアップの物理的な順序を、Zend VMの低レイヤの挙動から解き明かしていく。
—
1. Zend VMの終焉プロセスと `register_shutdown_function` の位置づけ
PHPスクリプトの実行が `exit()` や `die()` で強制終了された場合、あるいはメインスクリプトの末尾に到達した場合、Zend Engineは直ちにプロセスのメモリを全解放するわけではない。
内部的には、`php_request_shutdown()` という関数がコールされ、以下のフェーズが厳密な順序で実行される。
1. ユーザースクリプトの実行終了: メインの処理が完了し、VMの実行スタックが空になる。
2. シャットダウン関数の実行 (`register_shutdown_function`): 登録されたコールバックが、通常の変数の破棄プロセスの“直前”に呼び出される。
3. オブジェクトのデストラクター (`__destruct`) の発火: スコープ外に出た、あるいは未解放のオブジェクトの破棄。
4. 出力バッファのフラッシュ (`ob_end_all` 等): HTTPヘッダーとボディのクライアントへの送出。
5. リソース（リソース構造体）のクリーンアップ: データベース接続、ファイルハンドラ、cURLセッションなどの強制クローズ。
6. Zend Memory Manager (ZMM) によるヒープの全回収: アロケートされたすべてのメモリブロックがオペレーティングシステムに返還される（あるいはFPMプール内であればリクエストキャッシュとして保持される）。
ここで重要なのは、`register_shutdown_function` が実行される時点では、まだ変数はメモリ上に存在しているという点である。つまり、シャットダウン関数内であっても、グローバルスコープの変数やオブジェクトにアクセスし、その状態を検証・操作することが理論上可能である。
しかし、この「猶予時間」を誤って設計すると、メモリリークや意図しないリソースのロックを引き起こす。
—
2. 参照カウントと循環参照：GCはシャットダウン時にどう働くか
PHPのメモリ管理は、基本的には `zval`（Zend Value）構造体内部の `refcount`（参照カウント）によって行われている。変数が別の変数に代入されたり、関数の引数として渡されたりすると `refcount` がインクリメントされ、スコープを抜けるとデクリメントされる。これが `0` になった瞬間、ZMMによってメモリが解放される。
だが、厄介なのは循環参照（Circular Reference）だ。オブジェクトが互いをプロパティとして保持し合う構造を作ると、スコープを抜けてもお互いの `refcount` が `1` 残り続ける。これがいわゆる「メモリリーク」の温床となる。
PHPのガベージコレクタ（バッファリングGC）は、この循環参照を検知するために存在する。通常、`zend.enable_gc = On` の環境下では、`zval` の `refcount` が減少したにもかかわらずゼロにならなかった場合、その候補が「ルーツバッファ（Root Buffer）」にバッファリングされる。
シャットダウン時のGCの挙動
スクリプトが終了し、`php_request_shutdown()` に突入すると、Zend Engineは最後のクリーンアップとしてGCを強制起動する（`garbage_collect()`）。
/
class Node {
public ?Node $child = null;
public string $name;
public function __construct(string $name) {
$this->name = $name;
echo “Constructed: {$this->name}\n”;
}
public function __destruct() {
echo “Destructed: {$this->name}\n”;
}
}
// 循環参照の構築
$parent = new Node(“Parent”);
$child = new Node(“Child”);
$parent->child = $child;
$child->child = $parent; // 循環発生
// ここで $parent と $child のスコープを断つ
unset($parent, $child);
// この瞬間、refcount は 0 にならず、メモリ上に幽霊のように漂う。
// スクリプトが終了する直前のシャットダウン関数でどう振る舞うか？
register_shutdown_function(function() {
echo “— Shutdown Function Started —\n”;
// ここで明示的にGCの状態を確認・強制実行することも可能
$collected = gc_collect_cycles();
echo “GC collected cycles: {$collected}\n”;
});
echo “Script approaching end…\n”;
実行結果の深層
上記のコードを実行すると、次のような順序で出力される。
Constructed: Parent
Constructed: Child
Script approaching end…
— Shutdown Function Started —
GC collected cycles: 2
Destructed: Parent
Destructed: Child
注目すべきは、`register_shutdown_function` の内部、あるいはその直前のフェーズでGCが働き、循環参照が解決されて初めて `__destruct()` が呼ばれているという点だ。
もしシャットダウン関数内で「すでにすべてのオブジェクトが破棄されている」という前提でグローバルな依存関係にアクセスしようとすると、デストラクターの実行順序やタイミングによって予期せぬエラー（未定義のプロパティへのアクセスなど）を引き起こす原因となる。
—
3. OPcacheとプリローディング環境下でのシャットダウンの罠
現代のプロダクション環境において、OPcacheのプリローディング（`opcache.preload`）は常識となっている。PHP 7.4以降、スクリプトのパース・コンパイルコストを完全に排除するため、起動時にクラスや関数を永続メモリ（SHM: Shared Memory）へとロードし、リクエストをまたいで共有する。
ここで、`register_shutdown_function` とプリロードされたクラスの関係において、非常に危険な罠が存在する。
永続化された関数・クロージャとシャットダウン関数の衝突
プリロードされたコード内で定義された関数や、そこで無名関数（Closure）を生成してシャットダウン関数に登録した場合、Zend VMのメモリ空間の扱いが変わる。
リクエスト終了時のクリーンアップにおいて、リクエストローカルなヒープ（Request Heap）にアロケートされたデータと、OPcacheの共有メモリ（Persistent Memory）を指しているポインタが混在すると、メモリの二重解放（Double Free）やセグメンテーション違反（Segmentation Fault）を引き起こすリスクが跳ね上がる。
特に、SAPIがPHP-FPMである場合、ひとつのプロセスが何千ものリクエストを連続して処理する（`pm.max_requests` に到達するまで再起動しない）。シャットダウン関数内でグローバルな静的プロパティ（`static` 変数）やシングルトンインスタンスにリクエスト固有のデータを残したままにすると、次のリクエストへデータが汚染（Cross-request pollution）されるという、セキュリティおよび整合性の致命的なバグに直結する。
—
4. セキュリティインシデント：シャットダウン関数を悪用したGadget Chain
Webシステムアーキテクトとして、メモリ解放のライフサイクルは「防御」の観点からも極めて重要である。悪名高い「PHPオブジェクトインジェクション（PHP Object Injection）」の文脈において、攻撃者は `unserialize()` を通じて任意のクラスのインスタンスを復元する。
このとき、攻撃者が標的とするクラスに意図的なプロパティを仕込み、スクリプト終了時に自動的に実行されるマジックメソッド（`__destruct()` や `__toString()`）を連鎖させる技術を Gadget Chain と呼ぶ。
そして、このGadget Chainの終着点、あるいは実行のトリガーとして `register_shutdown_function` が悪用されるケースが存在する。
脆弱なコードパターンの解析
logFile = $file;
$this->logData = $data;
// 脆弱な設計：シャットダウン時にログを書き込む仕様
register_shutdown_function([$this, ‘flush’]);
}
public function flush() {
// 任意のファイル書き込みが発生する可能性
file_put_contents($this->logFile, $this->logData, FILE_APPEND);
}
}
// ユーザー入力がそのままデシリアライズされる脆弱なエンドポイント
if (isset($_POST[‘payload’])) {
unserialize($_POST[‘payload’]);
}
攻撃者が `Logger` クラスのプロフィールの書き換えや、別の悪意あるクラス（例えば、シャットダウン時にシステムコマンドを実行するクラス）をインジェクションした場合、メインスクリプトの処理が正常に（あるいは例外で）終了し、`php_request_shutdown()` が走るまさにその瞬間、攻撃者のコードが実行権を奪う。
防御の極意：シャットダウン関数の安全なカプセル化
このような脆弱性やメモリリークを根絶するため、アーキテクトはシャットダウン関数の登録に対して以下の鉄則を課すべきである。
1. 状態の完全な分離: シャットダウン関数には、オブジェクト全体（`$this`）を渡すのではなく、必要なプリミティブな値（スカラー値）のみを渡す。これにより、デストラクターの連鎖や不要なプロパティの参照を防ぐ。
2. 例外の捕捉: シャットダウン関数内で未キャッチの例外が発生した場合、SAPIの仕様によってはログ出力が不完全になるか、プロセスが異常終了する。必ず `try-catch` で囲むこと。
3. リソースの明示的解放: シャットダウン関数に頼るのではなく、ビジネスロジックの責任において `finally` 句などを活用し、リソースのクリーンアップは可能な限り早期に行う。
/
final class SafeShutdownHandler {
private static bool $registered = false;
private static ?string $criticalResourcePath = null;
public static function register(string $resourcePath): void {
self::$criticalResourcePath = $resourcePath;
if (!self::$registered) {
register_shutdown_function(self::class . ‘::execute’);
self::$registered = true;
}
}
public static function execute(): void {
// 例外を完全に捕捉し、プロセスのクラッシュを防ぐ
try {
if (self::$criticalResourcePath !== null && file_exists(self::$criticalResourcePath)) {
// 必要最低限の安全なクリーンアップ処理
// 例: ロックファイルの削除など
@unlink(self::$criticalResourcePath);
}
} catch (\Throwable $e) {
// エラーログへの記録（標準エラー出力や専用ロガー）
error_log(‘Critical shutdown error: ‘ . $e->getMessage());
}
}
}
—
結び
PHPの `register_shutdown_function` は、単なる「スクリプト最後の便利機能」ではない。それは、Zend VMのヒープメモリが解放され、SAPIがリクエストを消滅させる直前に残された、最後の制御可能なフックポイントである。
参照カウントの限界、循環参照のGCサイクル、OPcache環境下でのメモリ汚染、そしてオブジェクトインジェクションによるセキュリティリスク――これらすべては、PHPの低レイヤのメモリ管理モデルを理解しているか否かで制御の成否が決まる。
極限のパフォーマンスと堅牢性を両立するWebシステムを構築するためには、コードの表面的な文法だけでなく、Zend Engineが刻む一瞬一瞬の鼓動を脳内で完全にトレースできなければならない。