Zend VMの深淵：`zend_refcounted_value`と参照カウント原子操作の要塞
PHPの実行モデルは、一見するとリクエストごとに閉じたシンプルで安全な世界に見える。開発者はメモリリークの恐怖から解放され、スクリプトが終了すればZend Engineがすべての領域を綺麗に回収していく。しかし、高負荷なWebシステムや、常駐型の非同期・並行処理ランタイム、あるいはOPcacheプリローディングを活用する極限の環境において、この「お行儀の良さ」の裏側にあるC言語レベルのメモリ管理機構を理解していなければ、システムは突如として説明不能なセグメンテーションフォルト（Segmentation Fault）や、データ競合によるサイレント・コラプションの餌食となる。
本稿では、PHPのメモリ管理の根幹を成す `zend_refcounted_value` 構造体にメスを入れ、マルチスレッド/マルチプロセス環境における参照カウントの原子操作（Atomic Operations）がなぜ不可欠なのか、その低レイヤの真実を解き明かす。
—
1. `zend_refcounted_value` とは何か：Zend VMのメモリ最小単位
PHP 7以降、すべての複合データ型（文字列、配列、オブジェクト、リソース、クロージャ等）は、動的メモリ確保のオーバーヘッドを極限まで削ぎ落とすために、共通のヘッダ構造体を持っている。それが `zend_refcounted` であり、その実体が `zend_refcounted_value` である。
Zend Engineのソースコード（`Zend/zend_types.h`）を覗いてみよう。この構造体は、極限までパッキングされた物理メモリ上のプレフィックスに他ならない。
typedef struct _zend_refcounted_value {
zend_refcounted h;
} zend_refcounted_value;
typedef struct _zend_refcounted {
uint32_t refcount; / 参照カウント /
union {
uint32_t type_info; / 型情報とGCフラグ /
struct {
ZEND_ENDIAN_LOHI_3(
uint8_t type,
uint8_t flags,
uint16_t gc_info
)
} v;
} u;
} zend_refcounted;
物理メモリ上の配置と構造体のマジック
PHPで変数を作成し、それを別の変数に代入（コピー・オン・ライト: Copy-on-Write）すると、Zend VMはこの `zend_refcounted` の `refcount` をインクリメントする。
実際のzval（Zend Value）のメモリレイアウトは、この `zend_refcounted_value` がデータ本体の手前（上位アドレス）に配置される。
[ zend_refcounted_value (8 bytes) ] [ 実データ (HashTable / String Body 等) ]
^
|– zval が指し示すポインタはここか、あるいはデータ本体を指す
この設計により、Zend Engineはポインタのキャストだけで、任意の複合データの参照数を即座に知ることができる。だが、ここにモダンなコンピューティング環境における最大の罠が潜んでいる。
—
2. 非同期・並行処理とマルチスレッドにおける「参照カウントの危うさ」
PHPは伝統的にShared-Nothingアーキテクチャ、すなわち1リクエスト＝1プロセス（またはスレッドセーフ版ZTSにおけるリクエストごとの分離コンテキスト）を採用してきた。しかし、近年では状況が変わっている。
- OPcacheプリローディング：プロセス起動時にスクリプトをパースし、共有メモリ（SHM）上に永続化されたZend構造体（ASTやOPコード、定数）を生成する。これらは複数のワーカープロセスから同時に参照される。
- ZTS（Zend Thread Safety）とParallel拡張：同一プロセス内で複数のスレッドが同一のZend構造体や共有変数へアクセスする。
ここで発生するのが、「非原子的なインクリメント/デクリメントによるレースコンディション」だ。
データ競合のメカニズム
もし、2つのスレッド（あるいはプロセスからマップされた共有メモリ上のデータ）が同時にひとつの配列の参照カウントを操作しようとしたとき、C言語レベルの通常の加算処理（`refcount++`）は、以下の3つの機械語命令（Read-Modify-Write）に分解される。
1. メモリから `refcount` の値をCPUレジスタに読み込む（Read）
2. レジスタ上の値をインクリメントする（Modify）
3. レジスタの値を再びメモリ上の元の場所へ書き戻す（Write）
スレッドAとスレッドBが同時にこれを実行した場合、以下の悲劇が起きる。
初期状態: refcount = 1
[スレッドA] Read: 1 を取得
[スレッドB] Read: 1 を取得
[スレッドA] Modify: 1 + 1 = 2
[スレッドB] Modify: 1 + 1 = 2
[スレッドA] Write: 2 を書き込む
[スレッドB] Write: 2 を書き込む （本来なら 3 になるべきが、2で上書きされる）
結果として、実際の参照数は「3」であるべきところを「2」と誤認され、実際の参照が残っているにもかかわらず `refcount` が 0 に達したと判定され、メモリが二重解放（Use-After-Free / Double Free）を引き起こす。これは極めて深刻なセキュリティ脆弱性（リモートコード実行の踏み台）に直結する。
—
3. Zend VMにおける原子操作（Atomic Operations）の実装
このデータ競合を防ぐため、Zend Engineおよび現代のPHPコアは、ハードウェアレベルの原子操作（CPUのCAS: Compare-And-Swap命令やロックプレフィックス付き命令）を利用している。
Zendのソースコードでは、プラットフォーム固有の抽象化を経て、以下のようなアトミック操作マクロや関数が使われている。
/ 概念的なZendエンジン内部のアトミック操作のイメージ /
define ZEND_ADDREF(zv) _zend_addref(Z_COUNTED_P(zv))
static inline uint32_t _zend_addref(zend_refcounted p) {
/ プリローディングされた永続データでない場合のみカウント操作を行う /
if (!GC_IS_PERSISTENT(p)) {
/ アトミックなインクリメント（GCC/ClangのビルトインまたはCPU固有命令） /
return __atomic_add_fetch(&p->refcount, 1, __ATOMIC_RELAXED);
}
return p->refcount;
}
なぜ `__ATOMIC_RELAXED` なのか？
メモリバリアのコストを最小限に抑えるため、単純な参照カウントの増減にはしばしば緩和されたメモリ順序（Relaxed Memory Order）が使用される。これにより、マルチコアCPU上での性能低下を防ぎつつ、アトミック性を担保している。
しかし、オブジェクトの破棄や循環参照の検出時には、より厳密なアトミックセマンティクスが要求される。特にOPcacheのプリローディング環境下では、共有メモリ上の構造体に対する不正な書き込みを防ぐため、`GC_FLAGS` やパーシステントフラグのチェックが厳密に行われる。
—
4. 限界を突破する：PHPコードからのメモリ挙動の観測と防御
ここからは、この低レイヤの挙動が、実際のPHPアプリケーションの設計や脆弱性対策にどう影響するのかをコードベースで検証する。
以下のPHPスクリプトは、参照カウントとCopy-on-Writeの挙動を低レイヤ視点で模倣・確認するためのものである。
/
class MemorySentinel {
private string $payload;
public function __construct(int $sizeMB) {
// 指定されたサイズ（MB）の文字列を生成し、メモリ上にZend文字列として保持
$this->payload = str_repeat(‘A’, $sizeMB 1024 1024);
}
public function getPayloadSize(): int {
return strlen($this->payload);
}
}
// ガベージコレクションとメモリのベースライン
gc_collect_cycles();
$baseMemory = memory_get_usage(true);
echo “— 1. オブジェクト生成前ベースライン: ” . number_format($baseMemory) . ” bytes\n”;
// 50MBのペイロードを持つオブジェクトを生成
// この時点で zend_refcounted_value が付与された文字列とオブジェクトがヒープに展開される
$sentinel = new MemorySentinel(50);
$afterAlloc = memory_get_usage(true);
echo “— 2. 50MBオブジェクト生成後: ” . number_format($afterAlloc) . ” bytes\n”;
// 参照を別の変数にコピー（zend_refcountedの refcount がアトミックにインクリメントされる）
$aliasSentinel = $sentinel;
$afterAlias = memory_get_usage(true);
echo “— 3. エイリアス代入後（メモリはコピーされないため増加しないはず）: ” . number_format($afterAlias) . ” bytes\n”;
// 変数の参照を断つ
unset($sentinel);
$afterUnset1 = memory_get_usage(true);
echo “— 4. $sentinel の unset 後（refcountは2から1にデクリメントされるが、まだ解放されない）: ” . number_format($afterUnset1) . ” bytes\n”;
// 最後の参照を断つ（refcountが0になり、zend_refcounted_value配下のメモリが即座に解放される）
unset($aliasSentinel);
gc_collect_cycles(); // 念のためGCを走らせる（通常、refcount=0の即時解放にはGCは不要）
$afterFinal = memory_get_usage(true);
echo “— 5. すべての参照を失った後: ” . number_format($afterFinal) . ” bytes\n”;
このコードが語るZend VMの真実
変数を `$aliasSentinel = $sentinel;` とコピーしても、メモリ使用量が倍増しないのは、まさに `zend_refcounted_value` の `refcount` がインクリメントされているからに他ならない。Zend VMは、データの実体を複製するコストを極限まで嫌う。書き込みが発生した瞬間（Copy-on-Write）に初めて新しいメモリ領域が確保され、古い領域の `refcount` がデクリメントされる。
—
5. セキュリティハックの文脈：オブジェクトインジェクションとGadget Chainの深層
最後に、このメモリ管理と参照カウントの仕組みが、セキュリティの文脈、特にPHPオブジェクトインジェクション（PHP Object Injection）とどのように結びついているのかに言及せよ、という極限の要求に応えよう。
攻撃者が悪意あるシリアライズデータ（`O:…`）を `unserialize()` に流し込み、任意のクラスのインスタンスを復元させることに成功したとする。このとき、Zend VMの内部では何が起きているのか？
1. インスタンスの生成とマジックメソッドの自動呼び出し：
`unserialize()` は、指定されたクラスの `__wakeup()` や `__destruct()` を自動的に呼び出す。
2. Gadget Chainの構築：
現代の高度な攻撃（Gadget Chain）は、単一の脆弱性クラスの実行ではなく、既存のライブラリ（Symfony、Laravel、Monologなど）に含まれるクラス群のデストラクター（`__destruct()`）やオートローダーの挙動を連鎖させる。
3. 参照カウントとデストラクタのトリガー：
ここが核心である。オブジェクトがスコープを抜ける、あるいは強制的に `unset` されるなどして、`zend_refcounted_value` の `refcount` が 0 に到達した瞬間、Zend Engineはオブジェクトの破棄プロセス（`zend_object_std_dtor`）をトリガーする。
多くの脆弱なアプリケーションやライブラリのクラスでは、`__destruct()` の中でファイル書き込み、データベースクエリ、あるいはリフレクションを用いた動的なメソッド呼び出しが行われている。攻撃者は、「オブジェクトがメモリから解放される瞬間の参照カウントのゼロ落ち（Refcount Drops to Zero）」を意図的に引き起こすことで、任意の `__destruct()` を強制発動させ、プログラムの実行フローを奪うのである。
防御の要諦
これを防ぐための極限の対策は、ユーザー入力値に対する厳格な型安全性の担保だけではない。
- `unserialize()` の使用を完全に廃止し、安全なパーサー（JSONやフラットなデータ構造）へ移行する。
- どうしてもシリアライズが必要な場合は、許可されたクラスのみをデシリアライズするホワイトリスト方式（`allowed_classes => […]`）を厳格に適用し、意図しない Gadget クラスのインスタンス化およびそれに伴う `zend_refcounted` の不正なライフサイクル管理を根絶することである。
—
結びにかえて
PHPは「手軽なスクリプト言語」という古いレッテルを過去のものにし、Zend VMの最適化、OPcache、そしてJITコンパイラや並行処理ランタイムを内包した高度な仮想マシンへと進化を遂げた。そのすべての土台を支えているのが、今回解説した `zend_refcounted_value` と、その背後にある緻密なメモリ・参照管理のメカニズムである。
アーキテクトたる者、フレームワークのAPIの向こう側で、CPUキャッシュラインを意識しながらアトミックにインクリメントされる `refcount` の鼓動を感じ取れなければならない。この低レイヤの視点こそが、真に堅牢でスケールするWebシステムを構築するための唯一の羅針盤となる。