【テクニカル・上級編】PHP C APIにおける`efree()`と`zval_ptr_dtor()`の厳密な使い分けとメモリリーク防止：拡張開発者向け実践ガイド – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

PHPコア・内部エンジンの極意：`efree()`と`zval_ptr_dtor()`の厳密な使い分けとメモリリークの根絶

PHP拡張機能（Extension）の開発において、最も致命的であり、かつ最も頻発するバグの領域は「メモリ管理」である。

Zend Engine（Zend VM）のメモリ管理機構を熟知せず、ユーザランドの感覚のままC言語のプリミティブなアロケーションを持ち込むと、わずか数百万リクエストの往復でPHP-FPMのプロセスはメモリリークによって肥大化し、OOM Killerの餌食となる。あるいは、二重解放（Double Free）やUse-After-Freeを引き起こし、セグメンテーション違反（Segfault）による突発的なプロセス急死を招く。

本稿では、PHP C APIにおける最も重要な二大メモリ解放関数である `efree()` と `zval_ptr_dtor()` の決定的な違いを、Zend VMの内部構造、参照カウント（Reference Counting）、そして循環参照GCのメカニズムの観点から徹底的に解剖する。

—

1. Zend VMのメモリ管理の底流：なぜ `efree()` では不十分なのか

PHPの内部において、全ての変数は `zval`（Zend Value）という構造体として表現されている。この `zval` は、データ型（整数、浮動小数点、文字列、配列、オブジェクト等）のインフォメーションと、実際のペイロード、そして極めて重要な「参照カウント（`refcount`）」を内包している。

拡張機能の開発者が陥る最大の罠は、生データ（Cの文字列バッファや自作のカスタム構造体）に対して `emalloc()` でメモリを確保し、その解放に `efree()` を使うべき場面と、Zend Engineの管理下にある `zval` やそのペイロードに対して `zval_ptr_dtor()` を使うべき場面を取り違えることだ。

`efree()` の挙動

`efree()` は、Zend Memory Manager（ZMM）に対して、指定されたメモリアドレスのブロックを単に解放するよう指示するだけの、極めて低レイヤの操作である。

参照カウントのデクリメントを行わない。
内包する構造体（文字列のハッシュテーブルやオブジェクトのプロパティ）の再帰的な解放を行わない。
Zend VMの型システムやGCのメタデータを一切考慮しない。

もしあなたが `zval` 構造体、あるいはオブジェクトや配列を内包するメモリ領域に対して軽率に `efree()` を実行した場合、Zend Engineはその参照の存在を把握したまま基盤のメモリを剥ぎ取られるため、後続のオペコード実行時に確実にメモリ破壊（Memory Corruption）を引き起こす。

—

2. `zval_ptr_dtor()` の真髄：参照カウントとデストラクタの連鎖

一方、`zval_ptr_dtor()`（Destructor）は、Zend Engineの型システムと密結合した高レイヤのメモリ管理APIである。

ZEND_API void zval_ptr_dtor(zval zval_ptr)

この関数が呼び出されたとき、Zend VM内部では以下の厳密なシーケンスが実行される。

1. 参照カウントのチェック: 対象が参照カウントを持つ型（文字列、配列、オブジェクト、リソース等）である場合、`refcount` を `1` 減算する。
2. 寿命の判定: 減算後の `refcount` が `0` に達した場合のみ、実際のメモリ解放処理（Destructor）へと進む。
3. 再帰的解放（Deep Destruct）: 配列（HashTable）であれば含まれるすべての要素に対して `zval_ptr_dtor()` を再帰的に呼び出し、オブジェクトであればデストラクタメソッドの呼び出しとプロパティの解放を行う。
4. ZMMへの返却: 最終的に全ての依存関係が解消された段階で、内部的に `efree()` が安全に呼び出され、メモリがZMMプールへ返却される。

つまり、PHPの変数や `zval` を扱う文脈において、生の `efree()` を直接叩くべきではないケースがほとんどである。例外は、`emalloc()` で確保したプレーンなCのメモリチャンク（例: 独自のパース結果を格納する一時的なバイト配列など）を、Zendの型システムに載せることなく完全に自前で管理する場合のみである。

—

3. 拡張機能開発における実践：メモリリークを排除するコードパターン

ここで、拡張機能内でカスタムの配列や文字列を生成し、それを返す際の実装パターンを検証する。以下のCコード片は、拡張機能内での適切なメモリのライフサイクル管理を示している。

zend_extension.c (Conceptual Implementation)

PHP_FUNCTION(mine_process_data)
IK_UNUSED_parameters;

zval input_array;
HashTable target_hash;
zval new_val;

// パラメータの取得（配列を想定）
if (zend_parse_parameters(ZEND_NUM_ARGS(), “a”, &input_array) == FAILURE) {
RETURN_THROWS();
}

// 新しい配列をメモリ上に確保 (ZendのAPIを使用)
array_init(return_value);

// 内部で動的にメモリを確保する文字列の例
zend_string str = zend_string_init(“optimized_payload”, sizeof(“optimized_payload”) – 1, 0);

// zvalに文字列をラップ
ZVAL_STR(&new_val, str);

// return_value 配列へ要素を追加
// 注意: add_assoc_zval_ex は内部で zval の参照カウントをインクリメントする
zend_hash_add(Z_ARRVAL_P(return_value), str, &new_val);

// 【重要】
// 自身で作製した zval (new_val) の一時的な参照をデクリメントする。
// これを行わないと、zend_hash_add でインクリメントされた分と合わせて参照カウントがズレ、
// あるいはスコープアウト時の解放漏れによるメモリリークが発生する。
zval_ptr_dtor(&new_val);
}

このコードのアーキテクチャ的解説

`zend_hash_add()` は、追加する `zval` がコンテナ（この場合は配列）に格納される際、その `refcount` をインクリメントする。したがって、スタック上に一時的に作成した `new_val` は、追加が完了した時点で「自前のスコープにおける所有権」を放棄しなければならない。ここで `zval_ptr_dtor(&new_val)` を呼び出すことで、参照カウントの収支が完全に一致し、メモリリークが防がれる。

もしここで `efree(str)` などと安易に呼び出そうものなら、Zend Engineは既に存在しないメモリ領域を参照しにいき、FPMワーカープロセスは即座にクラッシュする。

—

4. 循環参照（Circular References）とGCのブラックホール

単純な参照カウント方式の最大の弱点は、自己参照を持つデータ構造（循環参照）である。例えば、配列が自分自身を要素として抱える場合、外部からの参照を全て断ち切っても、参照カウントが `1` 残り続けるため、通常の `zval_ptr_dtor()` では永遠にメモリが解放されない。

PHP 5.3以降に導入され、現代のPHP 8系に至るまで洗練され続けているガベージコレクション（Concurrent Cycle Collection Algorithm）は、この「バッファリングされた疑わしいルート（Root Buffer）」を定期的にスキャンし、参照カウントを一時的に仮想操作することで循環参照を検出し、一網打尽に解放する。

しかし、Cレベルの拡張機能でこのGC機構をバイパスするような不適切なメモリ操作を行った場合、GCのトラッキング対象外のメモリ空間で循環参照が発生し、如何なるGCアルゴリズムも介入できない完全なメモリリーク（Uncollectable Memory Leak）が完成する。

拡張機能内で複雑なグラフ構造やオブジェクトツリーを構築・操作する場合は、必ず `GC_ADDREF()` や `GC_DELREF()` といったZendの低レイヤマクロを直接叩くのではなく、可能な限り `Z_ADDREF_P()` や `zval_ptr_dtor()` といったハイレベルなAPIを介して参照カウントの整合性を保たなければならない。

—

5. 高速化の極意：OPcacheプリローディングとメモリ空間の共有

PHP 8以降のプロダクション環境において、メモリ管理の文脈はFPMのリクエストライフサイクルを超え、「OPcacheプリローディング（Preloading）」の領域へと突入している。

OPcacheのプリローディングが有効な場合、サーバ起動時（`php.ini` の `opcache.preload` に指定されたスクリプトの実行時）に、定義されたクラスや関数、さらには特定の構造体が共有メモリ（Shared Memory / SHM）上にコンパイルされ、永続的なZend OPcodesとしてマッピングされる。

ここで注意すべきは、共有メモリ上に配置されたデータは、個別のリクエストライフサイクルにおいて `efree()` や `zval_ptr_dtor()` を用いて変更・解放することが物理的に不可能（あるいは致命的なセグメンテーション違反を誘発）であるという点だ。

拡張機能やカスタム関数を設計する際、入力された `zval` がプリロードされた不変（Immutable）なデータである可能性を常に考慮し、書き込み操作（Write-On-Write / Copy-On-Writeの破壊的変更）を試みる前に、必ず `Z_ISREF()` や `Z_IMMUTABLE()` などのガード条件を挟む必要がある。これを怠ると、共有メモリ領域への不正書き込みとみなされ、OSカーネルによってプロセスが強制終了させられる。

—

6. セキュリティの深層：メモリ破壊からオブジェクトインジェクション（Gadget Chain）へ

メモリ管理のミス（特に `efree()` の誤用や、二重解放、Use-After-Free）は、単なるリソース枯渇（DoS）に留まらない。極めて高度なセキュリティ脆弱性の温床となる。

攻撃者がPHPのメモリ管理のほころびを突く代表例が、オブジェクトインジェクション（PHP Object Injection）を起点としたGadget Chainの構築である。

1. アプリケーションが不審なシリアライズデータを受け取り、`unserialize()` を実行する。
2. アンシリアライズの過程で、Zend Engineは動的にオブジェクトを生成し、そのプロパティを復元するためにメモリをアロケートする。
3. もし拡張機能側やPHPコアのバグにより、特定のマジックメソッド（`__destruct()` や `__wakeup()`）の実行前後でメモリの二重解放やUAF（Use-After-Free）が存在する場合、攻撃者はヒープ領域のレイアウトを綿密に制御（Heap Spraying等）する。
4. 解放されたはずのメモリ領域に任意のバイナリデータを書き込むことで、Zend VMの関数ポインタやオブジェクトの仮想メソッドテーブル（vtable相当の構造）をハイジャックし、最終的にリモートコード実行（RCE）の足がかりとする。

この種の攻撃を防ぐ防壁となるのは、まさに本稿で解説した厳密なライフサイクル管理に他ならない。メモリの所有権（Ownership）を明確にし、「誰が確保し、誰が責任を持って `zval_ptr_dtor()` を呼ぶのか」をコードの静的解析レベルで完全に証明できる状態に保つこと。それが、真に堅牢なPHPシステムを構築する唯一の道である。

—

結語

PHPは「動的言語」であり、プログラマを煩わしいメモリ管理から解放するための抽象化層が幾重にも積み重ねられている。しかし、その下層にあるZend Engineは、C言語によって書かれた極めてスパルタンな世界である。

拡張機能の開発者、あるいは極限のパフォーマンスと安全性を追求するシニアアーキテクトにとって、`efree()` と `zval_ptr_dtor()` の違いを曖昧にすることは、時限爆弾を抱えてプロダクション環境を運用することと同義である。

メモリの生態系を理解し、Zend VMの鼓動と同期したコードを書くこと。それこそが、PHPの限界を突破する唯一の技術的アプローチである。