Zend VMの深淵：`zend_refcounted_value`と参照カウントの原子操作が支配するメモリ管理の極意
PHPは「手動でメモリ管理をしなくていい気楽な言語」として語られがちだ。しかし、Webシステムアーキテクトとして大規模トラフィックをさばき、数千万リクエストを処理する基盤を設計・運用する者にとって、PHPのメモリ管理機構はブラックボックスではなく、完全に掌握すべきZend Engineの物理的挙動そのものである。
1つのHTTPリクエストがZend VMに飛び込み、スクリプトが実行され、レスポンスが返ってプロセスが解放されるまでの間、メモリ上では何億回もの参照カウントのインクリメントとデクリメントがアトミックに行われている。この機構の根幹をなすのが、`zend_refcounted_value` 構造体と、マルチスレッド（ZTS）やFiber環境下における原子操作（Atomic Operations）の制御である。
本稿では、PHPのソースコード（C言語）レベルの低レイヤからZend VMの挙動を解剖し、メモリの生死を握る中枢の仕組みを徹底的に解説する。
—
1. `zend_refcounted_value` 構造体の物理レイアウト
PHPのすべての複合データ型（配列、オブジェクト、リソース、クロージャ、文字列等）は、Zend Engine内部において必ず特定のヘッダ構造体を伴ってヒープ上にアロケートされる。その共通の基盤となるのが `zend_refcounted_value` である。
Zend Engine（PHP 8系）のソースコード（`Zend/zend.h`）を覗くと、この構造体は次のように定義されている。
struct _zend_refcounted_value {
zend_refcounted h; // 実質的な参照カウントと各種フラグ
};
さらにその実体である `zend_refcounted` や関連する共用体（`zval` の構造体内部）をたどると、メモリ効率を極限まで高めるためのパディングと、CPUキャッシュラインを意識した設計が見えてくる。
typedef struct _zend_refcounted {
uint32_t refcount; // 参照カウント (32ビット符号なし整数)
union {
struct {
ZEND_ENDIAN_LOHI_3(
uint32_t type:4,
uint32_t flags:ConstrainedFlags,
uint32_t gc_info:24
)
} v;
uint32_t type_info;
} u;
} zend_refcounted;
参照カウントの限界とオーバーフロー
`refcount` は `uint32_t` で表現されているため、理論上の最大値は $2^{32} – 1$（約42億）である。通常、この値を超えることはアプリケーションコードレベルでは稀だが、不正な循環参照やバグ、あるいは意図的なメモリ破壊攻撃（オブジェクトインジェクション等におけるガジェットチェーンの構築過程での参照操作の異常など）により、このカウントが意図せず操作された場合、エンジンは深刻なセグメンテーション違反（Segmentation Fault）を引き起こすか、あるいは早期解放（Use-After-Free）の脆弱性へと直結する。
—
2. 参照カウントの原子操作（Atomic Operations）と競合状態の排除
PHPは伝統的にシェアード・ナッシング（Shared-Nothing）アーキテクチャを採用しており、1つのリクエストは1つのプロセス（またはスレッド）の独立したメモリ空間で完結する。そのため、通常のWebリクエスト処理において、単一のZVALに対する参照カウントの増減に排他制御は不要であった。
しかし、以下のモダンな環境においては話が全く異なる。
1. ZTS（Zend Thread Safety）環境: マルチスレッドでPHPを稼働させる場合、グローバルなデータやOPcache上の共有メモリに対するアクセスが並行して発生する。
2. Fiber（ファイバー）による非同期並行処理: 単一スレッド内であっても、コンテキストスイッチが協調的に発生するため、非同期に実行されるタスク間で同一のヒープオブジェクトへの参照が共有されるリスクが生じる。
Ｃ言語レベルでのアトミック操作の実装
Zend Engineは、マルチスレッドや共有メモリ（OPcacheのSHMなど）における参照カウントのインクリメント・デクリメントの際、CPUのハードウェアレベルでのアトミック命令（GCCの `__atomic_add_fetch` やプラットフォーム固有のロックプリミティブ）を利用して、レースコンディション（競合状態）を防いでいる。
概念的には、Zend VM内部では次のような安全な操作が担保されている。
/ 擬似的なZend Engine内部の参照カウント操作（アトミック） /
static inline uint32_t zend_gc_addref(zend_refcounted_value p) {
// 参照カウントが無限ループやオーバーフローを起こさないようガードしつつ、
// CPUのバスロックを伴うアトミック加算を実行
return __atomic_add_fetch(&(p->refcount), 1, __ATOMIC_RELAXED);
}
static inline uint32_t zend_gc_delref(zend_refcounted_value p) {
// アトミック減算を実行し、結果が0になった瞬間に解放キューへ送る
return __atomic_sub_fetch(&(p->refcount), 1, __ATOMIC_RELEASE);
}
もし、この原子操作が通常のインクリメント演算（`p->refcount++`）であった場合、コンテキストスイッチやマルチスレッドの割り込みによって「読み込み・加算・書き込み」の間に別スレッドが介入し、参照カウントが実際よりも少なく記録される。これがUse-After-Free（UAF）の温床となり、最終的にはリモートコード実行（RCE）のガジェットチェーンへと結びつくセキュリティ・クリティカルな脆弱性を生む。
—
3. OPcacheプリローディングと物理メモリの共有
PHP 7.4以降で導入されたOPcacheのプリローディング（Preloading）は、パフォーマンスを極限まで引き上げるための強力な武器である。しかし、これもまた `zend_refcounted_value` とメモリ管理の深い理解なしには正しく運用できない。
`php.ini` で `opcache.preload` を指定すると、サーバー起動時に指定スクリプトが読み込まれ、AST（抽象構文木）からコンパイルされたOpcode、そしてそこで定義されているクラスや関数、さらにはグローバルな定数や一部の不変な配列構造が共有メモリ（SHM: Shared Memory）上に永続化される。
共有メモリ上の参照カウントの罠
プリロードされたデータは、複数のWorkerプロセスから読み取り専用（Read-Only）としてマップされる。ここで重要なのは、共有メモリ上にあるオブジェクトや配列の `zend_refcounted_value->refcount` の扱いである。
もし、プリロードされたクラスのプロパティや静的変数に、リクエストごとに変化する可変データを誤ってバインドしようとすると、Zend VMはCopy-on-Write（COW）を発動させようとする。しかし、共有メモリ上のアドレス空間は各プロセスから共通で見えているため、安易な書き込みはセグメンテーション違反を引き起こすか、あるいはプロセス間で予期せぬデータの混入（データ競合）を招く。
そのため、Zend Engineはプリロード時に共有メモリへ配置するデータ構造の参照カウントを特殊な状態（永続フラグ: `IS_STR_PERSISTENT` や `GC_IMMUTABLE`）に設定し、通常のガジェットによる解放対象外としてマークしている。
—
4. 循環参照ガベージコレクタ（GC）の調律と実践的最適化
参照カウント方式の最大の弱点は「循環参照（Circular Reference）」の検知と解放ができない点である。例えば、オブジェクトAがオブジェクトBを指し、オブジェクトBがオブジェクトAを指している状態（`A <-> B`）では、外部からの参照をすべて断ち切っても、それぞれの `refcount` は `1` のこる。この「孤立した循環メモリ」を回収するのが、PHPの循環参照ガベージコレクタである。
GCバッファの仕組みと「色塗り」アルゴリズム
Zend VMは、参照カウントが1つ減ったものの、まだ0になっていない複合データ型（配列やオブジェクト）を「可能であれば循環参照の一部かもしれない候補（Buffered）」として、GCのルートバッファ（Circular Buffer）に登録する。
バッファが満杯（デフォルトでは10,000エントリ）になるか、あるいは `gc_collect_cycles()` が明示的に呼び出されると、以下の3色法（Three-color marking）に基づくアルゴリズムが発動する。
1. Purple（紫）: バッファに投入された候補。
2. Grey（灰色）: 減算スキャン中。循環参照内のカウンタを一時的にデクリメントしていく。
3. White（白）: スキャン結果、外部からの参照が完全に存在せず、孤立していると判定された領域。これらが最終的に一網打尽に解放（Destruction）される。
実践：高負荷WebシステムにおけるGCのチューニング
高スループットなAPIサーバーや、数万件のオブジェクトをループ内で生成・破棄するバッチ処理において、デフォルトのGC挙動はボトルネックになり得る。無駄なGCスキャンはCPUキャッシュを汚染し、レイテンシのスパイクを引き起こす。
以下のコードは、Zend VMのGC挙動をプログラムから制御し、メモリ効率を極限まで最適化する実践的なアプローチである。
/
class MemoryIntensiveProcessor
{
private array $buffer = [];
public function executeHeavyWorkload(): void
{
// 1. 大量のオブジェクト・配列生成フェーズでは、GCを一時的に無効化する
// これにより、毎回のrefcount減算時のバッファリングコストを完全に排除する
$wasEnabled = gc_enabled();
if ($wasEnabled) {
gc_disable();
echo “[Zend VM] GCを一時停止しました。CPUバウンドな処理を加速します。\n”;
}
try {
for ($i = 0; $i < 100_000; $i++) {
// 循環参照が発生しうる複雑なデータ構造を模擬
$node = new \stdClass();
$node->id = $i;
$node->self = $node; // 意図的な循環参照
$this->buffer[] = $node;
// メモリ使用量が一定を超えたら手動でチャンクごとに破棄
if ($i > 0 && $i % 20_000 === 0) {
$this->flushBuffer();
}
}
} finally {
// 2. 処理完了後、確実にGCを元の状態に戻す
if ($wasEnabled) {
gc_enable();
}
}
}
private function flushBuffer(): void
{
// 配列をクリアしてメモリを解放
$this->buffer = [];
// 溜まった循環参照を一括回収
$collected = gc_collect_cycles();
echo sprintf(“[Zend VM] 手動GC実行: %d 個の循環参照サイクルを解放しました。\n”, $collected);
}
}
// 実行
$processor = new MemoryIntensiveProcessor();
$processor->executeHeavyWorkload();
このコードの肝は、「大量のオブジェクト生成が予想されるフェーズではあらかじめ `gc_disable()` でバッファリングを止め、処理の節目で一気に `gc_collect_cycles()` を叩く」という設計思想にある。これにより、Zend VMがバックグラウンドで無駄なスキャンを行うコストを排除し、予測可能なパフォーマンス（Predictable Latency）を維持できる。
—
5. オブジェクトインジェクションと `zend_refcounted_value` の破壊
セキュリティの文脈において、Zend VMのメモリ管理構造の理解は、攻撃手法の理解と防御の両面で不可欠である。
PHPオブジェクトインジェクション（`unserialize()` の脆弱性利用）において、攻撃者はシリアライズされた文字列を巧妙に細工し、意図しないクラスのインスタンス化や、`__destruct()`、`__wakeup()` マジックメソッドの連鎖（Gadget Chain）を引き起こす。
このメカニズムの本質は、「シリアライズデータからZend Engineがヒープ上に `zval` および `zend_object`（その先にある `zend_refcounted_value`）を再構築する際のパース処理の隙をつくこと」にある。
攻撃者は、型情報を偽装した不正なストリームを入力することで、Zend VMに存在しないプロパティや、解放済みのメモリ領域（UAF）を指すポインタを無理やりデリファレンスさせようとする。PHP 8以降では、プロパティの型宣言や内部の厳密な型チェック（`Z_TYPE_P` の検証など）が強化されているものの、依然としてレガシーなC拡張モジュールや、安全に配慮されていないマジックメソッドの実装が存在する場合、メモリの参照カウントの不整合をついた任意コード実行（RCE）の危険性が残る。
—
結びにかえて
PHPはもはや「単なるお気楽なスクリプト言語」ではない。Zend VM、Opcode、`zend_refcounted_value` を軸とした精密なメモリ管理、そしてマルチスレッド・ファイバー環境下でのアトミック操作の調律。これらすべての低レイヤの挙動を完全に脳内トレースできる者だけが、真にスケーラブルで安全なエンタープライズWebシステムを架构（アーキテクト）することができる。
コードの1行、配列の1つの代入が、Zend Engine上でどのような構造体の変化と参照カウントの増減を引き起こしているか――その視点を常に持ち続けることこそが、一流のPHPチーフアーキテクトの条件である。