【実務・中級編】PHP C APIにおける`efree()`と`zval_ptr_dtor()`の厳密な使い分けとメモリリーク防止 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

PHPコアの深淵：`efree()`と`zval_ptr_dtor()`の境界線 — 拡張開発におけるメモリ管理の極意

コードレビュー中、緊迫した空気が流れる瞬間がある。ジュニアや中堅の開発者が良かれと思って書いたC言語ベースのPHP拡張モジュール（あるいは自作のZend C/C++連携レイヤー）のプルリクエスト。そこには、一見して美しく、しかしZend Engineの心臓部を確実に蝕む「時限爆弾」が埋め込まれている。

`efree(val);`

この1行が、どれほどの恐怖を孕んでいるかお分かりだろうか。
Webアプリケーションの1リクエストは、Zend VMのライフサイクルそのものだ。リクエストが終息した瞬間、OSへメモリが返還される（あるいはPHP-FPMのプールに回収される）ため、一見するとメモリリークなど起きていないように見えるかもしれない。しかし、高負荷なAPIサーバーや長期稼働するデーモンプロセスにおいて、この誤用は確実にプロセスを死に至らしめる。

今回は、PHPコア（Zend VM）のメモリマネジメント、参照カウント、そしてC APIにおける `efree()` と `zval_ptr_dtor()` の厳密な使い分けについて、私の知見のすべてを叩き込む。

—

1. Zend Engineのメモリ空間と`zval`の正体

PHPの変数とは、C言語レベルではすべて `zval`（Zend Value）という構造体に他ならない。この `zval` は、値の型（Integer, String, Array, Objectなど）と実際のデータ、そしてメモリ管理のためのメタデータを内包している。

Zend Engineは、通常のC言語標準関数である `malloc()` や `free()` を直接叩かない。PHPプロセス内のメモリ断片化を防ぎ、リクエスト単位での一括解放（Request-bound Memory Pool）を高速に行うため、専用のアロケータである `emalloc()`, `ecalloc()`, `erealloc()`, そして `efree()` を用意している。

ここで重要な前提がある。
「`efree()` は、単なるメモリブロックの物理的破棄（Deallocation）である」 ということだ。

`efree()` の本質

`efree(void ptr)` は、指定されたポインタが指すメモリ領域をZendのヒープから切り離し、アロケータの管理プールに戻すだけだ。その中身が何であるか、中に別のポインタや複雑なデータ構造が含まれているかなど、Zend Engineは一切関知しない。いわば「ブルドーザーで地ならしをするようなもの」である。

`zval_ptr_dtor()` の本質

一方、`zval_ptr_dtor(zval zv)` は論理的なライフサイクル管理の中枢だ。
`zval` が保持する参照カウント（`refcount`）をデクリメントし、もしそのカウントが `0` に達した場合、その `zval` が内包するリソース（文字列、配列のバケツ、オブジェクトのプロパティ、リソースハンドルなど）を 再帰的に解放した上で、最終的に内部で `efree()` を呼び出してメモリを回収する。

つまり、`zval` を扱う文脈において、直接 `efree()` を呼ぶことは原則として「禁忌」 なのである。

—

2. なぜ `efree()` の直接呼び出しは死を招くのか？

以下のCコード（PHP拡張のイメージ）を見てほしい。コードレビューで私が即座にリジェクトするアンチパターンだ。

// 【危険なアンチパターン】
zval my_val;
// 何らかの処理でzvalを生成し、内部ヒープを確保したとする
my_val = ecalloc(1, sizeof(zval));
ZVAL_STRING(my_val, “extremely important data”);

// … 処理の途中で不要になったため、解放する
efree(my_val); // <-- ここで大惨事が起きる何が起きているか？ `ZVAL_STRING` は、内部で文字列実体を保持するために追加のメモリをヒープから確保（emalloc）し、それを `zval` 構造体の `zend_string` ポインタで保持している。

`efree(my_val)` を実行すると、`my_val` 自体の構造体領域は消えるが、内部の `zend_string` が指していたメモリ領域は誰にも解放されずに宙に浮く（メモリリーク）。これが数百万回繰り返された瞬間、PHP-FPMのワーカープロセスはOOM Killerの餌食となる。

さらに恐ろしいのは、これが配列やオブジェクトの場合だ。内部のハッシュテーブル（`HashTable`）やバケツ（Bucket）が保持する数々のポインタがすべて野晒しになり、メモリリークの嵐となる。

—

3. 正しい使い分けの黄金律（Golden Rules）

拡張開発やZend C APIを扱う際、以下の鉄則を脳裏に焼き付けておいてほしい。

—

4. 実務で直面する複雑なシナリオ：安全なカスタム関実装例

では、実務においてC APIをどのように扱い、メモリリークを完璧に防ぐべきか。
以下のC言語によるPHP拡張のコード片（関数実装のイメージ）を見てほしい。ユーザーランドから渡された引数を受け取り、内部で一時的なメモリを安全に操作して返す堅牢な実装パターンだ。

zend_include_once

PHP_FUNCTION(safe_memory_process_sample)
{
zval input_arg;
zend_string processed_str;
char raw_buffer;
size_t buffer_len = 1024;

// 1. ユーザーランドからの引数を安全に取得（パース）
// パラメータの解析に失敗した場合は即座にreturn（例外や警告はZendが処理）
if (zend_parse_parameters(ZEND_NUM_ARGS(), “z”, &input_arg) == FAILURE) {
return;
}

// 2. 生のメモリバッファが必要な場合は emalloc() を使用する
// ここで確保するのは純粋なバイト列なので、後ほど efree() で解放する対象となる
raw_buffer = emalloc(buffer_len);
if (!raw_buffer) {
zend_throw_error(NULL, “Memory allocation failed”);
return;
}

// バッファへの書き込み処理（安全性を考慮したモック）
memset(raw_buffer, 0, buffer_len);
snprintf(raw_buffer, buffer_len, “Processed via safe buffer management”);

// 3. zend_stringの生成（内部で適切にメモリ管理される）
processed_str = zend_string_init(raw_buffer, strlen(raw_buffer), 0);

// 4. 生メモリバッファの役割が終えたため、速やかに efree() で解放
// zend_string_init は文字列を複製するため、元の raw_buffer は不要になる
efree(raw_buffer);
raw_buffer = NULL; // ダングリングポインタ対策の鉄則

// 5. 戻り値として zend_string を zval にセット
// ZVAL_STR は内部で参照カウントを適切にインクリメント・設定する
RETVAL_STR(processed_str);

// 【重要】
// ここで input_arg を直接 efree() してはならない。
// input_arg は Zend VM が管理するスコープ内のポインタであり、
// 変数のライフサイクル管理は VM の管轄であるため。

return;
}

このコードの美しさと強靭さ

1. 生メモリの適切なライフサイクル: `emalloc()` で確保した一時バッファ（`raw_buffer`）は、用が済んだ瞬間に `efree()` で即座に解放し、さらにポインタを `NULL` クリアして二重解放（Double Free）の脆弱性を物理的に遮断している。
2. `zval` や `zend_string` の分離: ユーザーランドから受け取った `input_arg` には一切触れず、Zendの参照管理システムに委ねている。
3. 戻り値の安全な返却: `RETVAL_STR` を用いることで、Zend Engine側が責任を持って参照カウントを管理できる形に昇華させている。

—

5. テクニカルリードからの最終メッセージ

PHPは「初心者にも優しい言語」という文脈で語られがちだが、その下層にあるZend Engineは、極めて緻密で容赦のないC言語の世界で動いている。

Webアプリケーションのパフォーマンス低下、突如発生するメモリリーク、あるいは本番環境でのパニック（Segmentation Fault）。その多くは、「メモリを確保した責任」と「それを解放する正しい作法（ルール）」のミスマッチに起因している。

`zval` やそのコンテナを扱うときは、必ず `zval_ptr_dtor()`（あるいは高レイヤーのAPI）を使い、Zend Engineの参照カウント機構を信じろ。
自前で確保した生のエフェメラルバッファにのみ、`efree()` の刃を向けよ。

この境界線を一歩でも踏み外せば、あなたの書いたコードは静かに、しかし確実にサーバーのメモリを食いつぶしていく。
プロフェッショナルであればこそ、メモリの「産声」から「消滅」までの全ライフサイクルをコード上で完全に支配し抜け。それができるエンジニアだけが、極限まで最適化された堅牢なPHPシステムを構築する資格を持つ。