Zend Engineの深淵：C拡張開発におけるメモリ管理とリーク防止の極意
PHPのコードレビューにおいて、「なぜこの処理でメモリリークが起きるのか」「なぜこの解放順序ではセグメンテーション違反（Segfault）を引き起こすのか」をロジカルに説明できるエンジニアはどれほどいるだろうか。
我々が普段何気なく書いているPHPのコードは、Zend VM上で実行される際、すべてC言語（Zend Engine）のメモリ管理機構の庇護下にある。しかし、ひとたび独自のPHP拡張（C API）を開発する領域に踏み入れた途端、その安全ネットは消え去る。PHPの強力なGC（ガベージコレクション）と参照カウントのメカニズムの裏側で、C言語レベルのメモリリークや二重解放（Double Free）が、FPMプロセスの寿命を確実に蝕んでいくのだ。
本稿では、Zend APIにおけるメモリ管理のプリミティブを紐解き、リクエストスコープの寿命管理から、実務の拡張開発において絶対に踏んではならない地雷と回避策を、テクニカルリードの視点から徹底的に解説する。
—
1. Zend Engineにおけるメモリ管理のパラダイム
PHPの内部（Zend Engine）は、OSから直接`malloc()`や`free()`を頻繁に呼び出すことはしない。高トラフィックなWebリクエストをさばく上で、OSのメモリアロケータを直接叩くオーバーヘッドは致命的だからだ。
Zend Engineは、起動時にOSからまとまったメモリチャンクを確保し、独自のメモリアロケータ（ZendMM）によって管理する。
リクエスト指向メモリ管理（`emalloc` と `efree`）
PHP拡張や内部関数でメモリを確保する場合、標準の `malloc()` ではなく、必ず `emalloc()` を使用しなければならない。
- `emalloc(size_t size)`: 現在処理中のリクエストのメモリプールからメモリを割り当てる。
- `efree(void ptr)`: アロケートされたメモリをプールに戻す。
最大の特徴は、「リクエストが終了した瞬間、例えプログラマが `efree()` を忘れていたとしても、ZendMMが一括してそのリクエストプールのメモリを破棄する」という点だ。一見すると「リークしない安全な仕組み」に見えるが、これがデーモンプロセス（SwooleやRoadRunner、あるいは長期稼働するC拡張）において、最悪のメモリリークを引き起こす温床となる。
永続的メモリ（`pemalloc` と `pefree`）
リクエストのライフサイクルを超えて生存させたいデータ（例えば、共有設定やキャッシュ構造体など）を扱う場合は、`pemalloc(size_t size, int persistent)` を使用する。
- 第2引数の `persistent` に `1` を指定すると、OSの `malloc()` が直接呼ばれ、リクエスト終了後もメモリは解放されずにプロセス空間に残る。
- これを適切に `pefree()` で解放しない限り、FPMプロセスが終了するまでメモリはリークし続ける。
—
2. 拡張開発における致命的なメモリリークパターン
C拡張のコードレビューで最も多く見落とされるのが、「Zend変数（zval）の型変換・複製時における参照カウントの不整合」である。
パターンA: `zval` のコピーと `Z_ADDREF` の忘却
PHPの配列やオブジェクト、文字列を操作する際、`zval` を直接代入・複製すると、内部のポインタや参照カウント（`refcount`）の整合性が崩れる。
// 【危険なコード例】
zval my_var;
ZVAL_STRING(&my_var, “Zend Engine Internals”);
// 何も考えずに別のコンテナに突っ込む
add_assoc_zval(return_value, “key”, &my_var);
上記のようなコードは、`return_value`（PHPへ返す連想配列）とスタック上の `my_var` が同じ文字列ポインタを二重に指すことになり、リクエスト終了時の `efree` で二重解放（Double Free）を引き起こし、Apache/Nginxワーカーをクラッシュさせる。
正しくは、Zendが提供するマクロを通じて適切にゾンビ化を防ぎ、参照カウントをインクリメントする必要がある。
—
3. 実践：安全なZend APIメモリ管理と拡張コードの実装例
ここでは、PHPの内部関数（C拡張）として動作し、文字列を受け取って安全にメモリを確保・加工し、PHP側に返すモジュールのミニマムかつ堅牢な実装を示す。
このコードは、メモリリークやセグメンテーション違反を完全に排除するための作法を網羅している。
zend_include.h
include “php.h”
// 拡張機能が提供する関数のプロトタイプ宣言
PHP_FUNCTION(safe_string_process);
// 関数のエントリー定義
static const zend_function_entry safe_memory_functions[] = {
PHP_FE(safe_string_process, arginfo_safe_string_process)
PHP_FE_END
};
// モジュール情報の定義
zend_module_entry safe_memory_module_entry = {
STANDARD_MODULE_HEADER,
“safe_memory”,
safe_memory_functions,
NULL, NULL, NULL, NULL, NULL,
“1.0.0”,
STANDARD_MODULE_PROPERTIES
};
ifdef COMPILE_DL_SAFE_MEMORY
ifdef ZTS
ZEND_TSRLS_CACHE_DEFINE()
endif
ZEND_GET_MODULE(safe_memory)
endif
/
- 実装本体：安全なメモリ管理と文字列操作
/
PHP_FUNCTION(safe_string_process)
{
char input_str;
size_t input_len;
char processed_str;
size_t processed_len;
// PHP側から引数（文字列）を安全に取得
// ZEND_PARSE_PARAMETERS_START(min, max)
ZEND_PARSE_PARAMETERS_START(1, 1)
Z_PARAM_STRING(input_str, input_len)
ZEND_PARSE_PARAMETERS_END();
// 1. ゼロバイトチェックとバッファサイズ計算
if (input_len == 0) {
RETURN_EMPTY_STRING();
}
// 2. 処理結果用のメモリを ZendMM (emalloc) を用いて確保
// ※ OS直の malloc ではなく必ず emalloc を使うこと
processed_len = input_len 2; // 例としてバッファを倍増
processed_str = (char ) emalloc(processed_len + 1);
if (processed_str == NULL) {
// メモリ枯渇時のハンドリング
zend_error_noreturn(E_ERROR, “Out of memory in safe_string_process”);
return;
}
// 3. 安全な文字列操作（memcpyを利用し、バッファオーバーランを防ぐ）
memcpy(processed_str, input_str, input_len);
memcpy(processed_str + input_len, input_str, input_len);
processed_str[processed_len] = ‘\0’; // 終端ヌル文字の確実な付与
// 4. PHPのzval構造体へ安全に所有権を移行
// RETVAL_STRINGL は内部で文字列を複製しつつ、ZendMM管理下に置く。
// そのため、ここで確保した processed_str は直ちに efree する必要がある。
RETVAL_STRINGL(processed_str, processed_len);
// 5. テンポラリバッファの即座の解放（メモリリークの防止）
efree(processed_str);
return;
}
このコードのアーキテクチャ的解説
1. `emalloc` と `efree` の完全なペアリング:
拡張内で独自に確保した `processed_str` は、`RETVAL_STRINGL` が内部で文字列を複製（zval側で独自にメモリを持つ）するため、PHPへ値を返した直後に自前で `efree(processed_str)` を呼んで解放しなければならない。これを怠ると、同一リクエスト内であってもメモリリークが発生する。
2. 安全なパラメータパース（`ZEND_PARSE_PARAMETERS_START`）:
レガシーな `zend_parse_parameters` ではなく、PHP 7/8以降のモダンなAPIを使用することで、型安全性をコンパイル時および実行時で担保し、型の不一致による不正なポインタ参照を阻止する。
3. 境界チェック（Bounds Checking）:
文字列の結合や操作を行う際、`input_len` のオーバーフローを想定し、常に `+1`（ヌル終端分）の安全マージンを確保して `emalloc` を叩いている点に注目してほしい。
—
4. デバッグと検知：Valgrind と AddressSanitizer の活用
C拡張やZend Engineレベルのメモリ破壊・リークは、PHPのエラーログには出力されないことが多い。これらを検知するには、インフラストラクチャレベルのツールチェーンが不可欠である。
Valgrindによるリーク検知
PHPをデバッグビルド（`–enable-debug`）し、Valgrindを用いて拡張を走査する。
valgrind –leak-check=full –show-leak-kinds=all –track-origins=yes \
php -d extension=safe_memory.so -r ‘safe_string_process(“test”);’
もし `emalloc` した領域が解放漏れしている場合、ZendMM層ではなく、Cヒープ層でのリークとしてValgrindが正確なコールスタック（何行目のどの関数で確保されたか）を特定して教えてくれる。
AddressSanitizer (ASan) の導入
GCC/Clangのコンパイルオプションに `-fsanitize=address` を付与してPHP自体をビルドすることで、バッファオーバーフローやuse-after-free（解放済みメモリへのアクセス）をミリ秒単位で検出し、即座にプロセスをアボートさせることができる。本番前のステージング環境では、必ずこの検知機構を通すべきである。
—
5. テクニカルリードからの総括
PHPのメモリ管理は一見すると「開発者に意識させない全自動の楽園」に見えるが、その実態は、Zend Engineという極めて緻密なC言語の仮想マシン上に築かれた精巧な要塞である。
- リクエスト内の動的確保には必ず `emalloc` / `efree` を使うこと。
- 永続化が必要なデータには `pemalloc` / `pefree` を用い、ライフサイクルを完全にコントロールすること。
- Zend変数（`zval`）や文字列を扱う際は、所有権（Ownership）がどこに移動するのかを常にC言語のポインタの文脈で脳内トレースすること。
この鉄の掟を破った瞬間、あなたの書いたコードは静かに、しかし確実にサーバーのメモリを食い潰し、ピーク時にシステムを崩壊させる。コードレビューの際は、「この変数の `refcount` は今いくつで、誰が責任を持って解放するのか」をエンジニア全員が即答できるだけの厳格さを持って臨んでほしい。