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

こんにちは。PHPの裏側で何が起きているのか、気になって夜も眠れない時期ってありますよね。

他の言語、例えばGoやJava、あるいはNode.jsあたりからやってきた優秀なエンジニアほど、PHPのメモリ管理の世界に足を踏み入れた瞬間に奇妙な違和感を覚えます。「なぜ、リクエストが終わるたびに全メモリが綺麗に消え去るのか？」「なぜ、C言語の拡張を書くときに、ただのメモリ解放（`free`）じゃなくて、変な関数を叩かなきゃいけないのか？」と。

今回は、PHP拡張機能開発（あるいはPHPのCソースコードリーディング）における最大の関門であり、極めて美しい仕組みである「`efree()` と `zval_ptr_dtor()` の厳密な使い分け」についてお話しします。

ここを完全に掌握できれば、あなたの書くコードはただ動くだけの代物から、Zend Engineと完璧に調和した「エリート級のシステム」へと生まれ変わりますよ。

—

1. そもそもZend Engineのメモリ空間はどうなっているのか

まず、私たちが普段書いているPHPコード、そしてそれを支えるC言語レベルの拡張機能が、どのようなメモリ空間で生きているのかをイメージしましょう。

PHPは、1つのWebリクエスト（あるいはCLIスクリプトの実行）が始まると同時に、Zend Memory Manager（ZMM）と呼ばれる独自のメモリプールをごそっとOSから確保します。変数が生まれ、配列が膨らみ、オブジェクトがインスタンス化されるたびに、このプールからメモリが割り当てられます。
そして、リクエストが終了した瞬間、ZMMは一括してそのプールを解放（あるいは次のリクエストのために再利用）します。これが、PHPが「基本的にはメモリリークを気にしなくていい言語」である所以です。

しかし、拡張機能（C言語ベース）を書くときは話が別です。ZMMの管理下に直接介入するため、あなたが確保したメモリは、あなたが責任を持ってライフサイクルを管理しなければなりません。

ここで登場するのが、すべてのPHPの値の根幹である `zval`（Zend Value）構造体と、そのメモリをどう扱うかという問題です。

—

2. `efree()` は「ただのメモリの塊」を捨てる道具

まずは、よりプリミティブな方から見ていきましょう。`efree()` です。

C言語を少しでもかじった方なら、`malloc()` と `free()` のペアをご存知でしょう。PHPの拡張開発の世界では、これが `emalloc()` と `efree()` に置き換わります。これらはOSに直接触るのではなく、先ほどお話したZend Memory Managerを経由して安全かつ高速にメモリを割り当てるためのマクロ（または関数）です。

`efree()` を使うべき場面

`efree()` は、「中身が何であれ、単なるバイト列（生データのバッファ）」を解放するときに使います。例えば、文字列を処理するために一時的に確保した作業用メモリや、特定の構造体そのものの領域（ポインタの器）を捨てる時です。

// 例：Zendのメモリプールから一時的なバッファを確保して解放する
char buffer = emalloc(1024);

// … 何らかの処理 …

// バッファを解放する（中身がPHPの変数構造体でなければ、これで十分）
efree(buffer);

【重要】 `efree()` は、そのメモリの中身がどうなっているか（内部に別のポインタを持っていないか、参照カウントがどうなっているか）を一切気にしません。
ただ指定されたアドレスの領域をZMMに返却するだけです。もし、その中身に他のメモリを指すポインタが含まれていた場合、それらは容赦なく置き去りにされ、致命的なメモリリークを引き起こします。

—

3. `zval_ptr_dtor()` は「PHPの魂（変数）」を還す儀式

では、私たちが普段PHP上で触っている「変数」の本体である `zval` や、その中にあるポインタ群を安全に片付けたいときはどうすればいいのでしょうか？

ここで主役になるのが `zval_ptr_dtor()`（Zend Value Pointer Destructor）です。

PHPの変数は、文字列、数値だけでなく、配列やオブジェクト、リソースなど、複雑な構造を持つことができます。これらはすべて `zval` という構造体に包まれており、さらに「参照カウント（`refcount`）」という概念によって管理されています。

なぜ `efree(zval)` ではダメなのか？

もし、配列の `zval` をそのまま `efree()` で捨ててしまったらどうなるでしょうか？
その配列の要素としてぶら下がっている文字列や、別のオブジェクトへのポインタが宙ぶらりんになり、メモリ空間の彼方に消え去ります。Zend Engineが管理する参照カウントの仕組みも完全に破壊されます。

だからこそ、`zval` を破棄するときは、必ず `zval_ptr_dtor()` を使わなければなりません。

// 例：zvalを安全に破棄する
zval my_var;
// … 何らかのzvalを生成・初期化 …

// 参照カウントをデクリメントし、0になったら内部のメモリも含めて再帰的に解放する
zval_ptr_dtor(my_var);

`zval_ptr_dtor()` の内部で何が起きているか、その脳内トレースをしてみましょう。

1. その `zval` の参照カウント（`refcount`）を1つ減らします。
2. もし参照カウントが 0 よりも上に残っている場合（他にもその変数を参照している場所がある場合）、何もしません（安全ですね！）。
3. もし参照カウントが 0 になった場合、その `zval` が保持している型に応じた適切なクリーンアップ処理（文字列の解放、配列なら全要素に対する再帰的な `dtor` の呼び出し、オブジェクトならデストラクタの呼び出し等）をすべて実行した上で、最後にメモリを解放します。

つまり、`zval_ptr_dtor()` は単なるメモリ解放関数ではなく、「PHPの変数のライフサイクルと参照整合性を守るための神聖な儀式」なのです。

—

4. 実際の拡張機能開発における「やってはいけない」罠

よくある現場のミスとして、C言語の癖で次のようなコード書いてしまうケースがあります。

// 【アンチパターン】絶対にやってはいけない例
zval val = emalloc(sizeof(zval));
ZVAL_STRING(val, “Hello Zend Engine”);

// … 処理 …

// やってしまった！ zvalの構造体そのものをただのメモリとして捨てている！
efree(val);

このコードの何が問題か分かりますか？
`ZVAL_STRING` は、内部で文字列用のメモリを別途ヒープ上に割り当て、それを `val` 構造体から指し示しています。`efree(val)` を呼ぶと `val` の外側の箱は消えますが、その内部で保持していた文字列のメモリが解放されずにその場に取り残されます。 これが、拡張機能開発で最もよくあるメモリリークの温床です。

正しい書き方はこうです。

// 【正しいパターン】
zval val; // あるいは適切に初期化したzval
ZVAL_STRING(&val, “Hello Zend Engine”);

// … 処理 …

// zval_ptr_dtor を使うことで、内部の文字列も含めて完璧に掃除される
zval_ptr_dtor(&val);

※もし `zval` 自体を `emalloc` で確保している場合は、中身をデストラクタで片付けた後に、箱を `efree()` する必要があります（または `zval_ptr_dtor` に対応するラッパー関数を使います）。このあたりの細かなハンドリングが、C拡張の難しさであり、醍醐味でもあります。

—

5. まとめ：美しいコードを書くために

ここまでの話を綺麗に整理しましょう。

PHPの裏側で動くZend Engineは、私たちが意識しなくても動くように非常に良くできています。しかし、一歩踏み込んで拡張機能を書いたり、コアの挙動に最適化を施したりする場面では、この「メモリの器を捨てるのか（`efree`）」それとも「PHPの変数としての魂を還すのか（`zval_ptr_dtor`）」という境界線を常に意識する必要があります。

ここをクリアに理解できると、PHPという言語が単なる「お手軽なスクリプト言語」ではなく、C言語の堅牢な基盤の上に緻密に設計された、極めて洗練された仮想マシンであることが実感できるようになります。

あなたの次のコードが、美しく、そしてメモリリークのない完璧なものになることを願っています。
それでは、また次の深淵でお会いしましょう。