Fiber内での参照カウントの挙動と循環参照検出の課題：メモリリークを回避する設計パターン
PHP 8.1で導入されたFiber（ファイバー）は、PHPにおける非同期プログラミングのパラダイムを根本から書き換えた。スタックフルな協調的マルチタスキング（Cooperative Multitasking）を言語コアに持ち込んだことで、コールバック地獄に陥ることなく、手続き型の直感的なコードでイベントループ駆動の非同期処理を記述できるようになった。
しかし、Zend VM（Zend Engine）のメモリ管理モデル、すなわち「参照カウント（Reference Counting）」と「コピーオンライト（Copy-on-Write）」、そして「循環参照ガベージコレクタ（GC）」の挙動を深く理解せずにFiberを酷使すれば、プロダクション環境のメモリ空間は不可解なリークの海と化し、FPMプロセスのRSS（Resident Set Size）は肥大化の一途をたどる。
本稿では、FiberのコンテキストスイッチがZend VMのメモリ構造と参照カウントにどのような不可逆的影響を与えるのかを低レイヤから解き明かし、循環参照の罠を回避するための実践的な設計パターンを提示する。
—
1. Zend VMのメモリ管理とFiber実行コンテキストの物理構造
PHPのすべての変数は、シンボルテーブルという名の `HashTable` に格納され、値の実体は `zval`（Zend Value）構造体としてヒープ上にアロケートされる。オブジェクトや配列といった複合データ型は、`zval` の内部からさらにヒープ上の専用構造体（`zend_object` や `zend_array`）を指し示す。
従来の関数・メソッド呼び出し（スタックフレーム）は、コールスタック（`zend_execute_data`）の積算と破棄によって自動的にローカル変数の寿命が管理されていた。関数がリターンすれば、そのスコープ内の `zval` の参照カウントはデクリメントされ、0になった瞬間に `dtor`（デストラクタ）が走ってメモリが解放される。
Fiberスタックのヒープ退避
しかし、Fiberは違う。Fiberはコールスタックをコールスタックのまま、ヒープ上にアロケートされた専用のスタック領域（`zend_fiber_context`）に保存する。
[Main Request Context]
│
├─► Global Symbol Table
└─► Fiber Instance (Heap)
│
└─► Stack Buffer (Heap)
├─► zend_execute_data (Suspended)
└─► Local Variables / zvals (Reference Counted)
Fiberが `Fiber::suspend()` を呼び出すと、現在の実行コンテキスト（CPUレジスタの状態に相当するZend VMの実行ポインタやローカル変数へのポインタ群）がヒープ上のスタックバッファに凍結される。この時、サスペンド状態の `zend_execute_data` が保持しているすべてのローカル変数や引数の `zval` は、参照カウントが維持されたまま、イベントループの次のオプコードディスパッチまで宙ぶらりんの状態で生存し続ける。
この「生存期間の非同期化」こそが、従来のPHPアプリケーションには存在しなかったメモリリークの温床となる。
—
2. Fiberを跨ぐオブジェクト参照と循環参照のメカニズム
非同期処理において、Fiberのクロージャ（`Closure`）内に外部のオブジェクトやサービスコンテナへの参照をキャプチャすることは日常茶飯事である。ここで、以下のような構造を考えてみてほしい。
- イベントループを管理するマネージャクラスが存在する。
- マネージャがFiberを生成し、その中で非同期タスクを実行する。
- タスクのコンテキスト（Fiberのローカル変数やクロージャのuse句）が、マネージャ自身や、マネージャが保持する他のリソースを指している。
循環参照（Circular Reference）の罠
PHPのガベージコレクタは、`zval` の参照カウントが 0 にならずとも、「自分自身を間接的に指し示す閉じたグラフ構造（循環参照）」を検知するため、バッファ（`gc_globals.buffered`）にオブジェクトを溜め込み、周期的にルートバッファの走査を行って回収する。
しかし、Fiberのサスペンド中に形成された循環参照は、GCの通常のバッファリングタイミングやエントロピーを狂わせる。
Zend VMのopcode最適化やOPcacheのプリローディング環境下において、サスペンドされたFiberのスタック内に閉じ込められたオブジェクトは、Fiberインスタンス自体が破棄されるか、明細に `Fiber::resume()` が呼ばれて最後まで実行しきってコールスタックが解消されるまで、通常のガベージコレクションの射程外（あるいは回収遅延の対象）になりやすい。
以下のコードは、Fiber内で意図せず循環参照を発生させ、メモリをリークさせる典型的なアンチパターンである。
fiber = new Fiber(function (): void {
// クロージャが $this ($AsyncWorker) をキャプチャしているため、
// Worker -> Fiber -> Closure -> Worker という強烈な循環参照が形成される。
$this->contextData = “heavy payload running in fiber…”;
// サスペンド
$received = Fiber::suspend(‘paused’);
echo “Resumed with: {$received}\n”;
});
$this->fiber->start();
}
public function getFiber(): Fiber {
return $this->fiber;
}
}
// リクエストライフサイクル内でループ生成
for ($i = 0; $i < 1000; $i++) {
$worker = new AsyncWorker();
$worker->run();
// $worker を捨てても、Fiber, Closure, Worker間の循環参照により
// 即座にメモリが解放されないケースが発生する
unset($worker);
}
// 意図的なGCの強制発動が必要になるが、非同期ループ内ではタイミングがシビア
gc_collect_cycles();
このコードでは、`AsyncWorker` が `Fiber` を持ち、その `Fiber` の内部クロージャが `$this` を束縛（Binding）している。PHPのオブジェクトはデフォルトで強参照（Strong Reference）として扱われるため、この三すくみの状態は参照カウントを崩壊させ、明示的な `unset` や `gc_collect_cycles()` を呼ばない限りメモリ上に残存する。
—
3. 脆弱性・セキュリティの観点：Fiberとオブジェクトインジェクションのコンテキスト汚染
メモリ管理の不備は、単なるリソース枯渇（DoS）にとどまらない。悪意ある攻撃者がオブジェクトインジェクション（Object Injection）やガジェットチェーン（Gadget Chain）の構築を試みる際、Fiberの非同期コンテキストは「デストラクタの実行タイミングを意図的に遅延・操作するアタックサーフェス」として悪用され得る。
PHPでは、オブジェクトがスコープを抜けて参照カウントが0になった瞬間に `__destruct()` が発火する。しかし、Fiberのサスペンドによってオブジェクトの寿命が人為的に引き延ばされた場合、攻撃者は「どのリクエストフェーズでデストラクタが走るか」をイベントループの制御権を奪うことでコントロールできるようになる。
OPcacheプリロード環境下において、グローバルに常駐するサービスや非同期プール内でこのような寿命の長いオブジェクトが汚染された場合、後続の並行リクエスト間でメモリ空間（あるいはシリアライズされた状態）が意図せず共有され、セッション情報の混濁や権限昇格のトリガーになり得る。低レイヤを触るエンジニアは、Fiberのライフサイクルを厳密に制御し、「不要になったコンテキストは即座にパージする」鉄則を守らなければならない。
—
4. 解決策：弱参照（WeakReference）と構造的デカップリングによる設計パターン
このメモリリークと循環参照の呪縛から逃れるためには、Zend Engineの参照カウンタに依存しない設計、すなわち `WeakReference`（弱参照） の徹底活用と、コンテキストの完全なカプセル化（イベントループとタスクの疎結合化）が求められる。
パターン1: `WeakReference` による循環参照の断ち切り
Fiberのクロージャ内でオブジェクトにアクセスする必要がある場合、強参照ではなく `WeakReference::create()` を用いることで、参照カウントをインクリメントせずにオブジェクトを指すことができる。
以下に、Fiber内でのメモリリークを完全に排除した実用的な非同期ワーカーの設計パターンを示す。
context = $context;
}
public function startTask(): void {
// WeakReferenceを用いて、$this や $context への強参照を避ける
$weakSelf = WeakReference::create($this);
$weakContext = WeakReference::create($this->context);
$this->fiber = new Fiber(function () use ($weakSelf, $weakContext): void {
// Fiber実行開始時にターゲットが生きているか検証
$context = $weakContext->get();
if ($context === null) {
return; // 既に親オブジェクトが破棄されていれば早期リターン
}
$context->state = ‘running’;
echo “Task running with state: {$context->state}\n”;
// 処理を中断（サスペンド）
$valueFromEventLoop = Fiber::suspend(‘yield_point’);
// レジューム後の処理
$self = $weakSelf->get();
if ($self !== null) {
$self->onResumed($valueFromEventLoop);
}
});
$this->fiber->start();
}
private function onResumed(mixed $data): void {
echo “Worker successfully resumed with data: {$data}\n”;
}
public function getFiber(): ?Fiber {
return $this->fiber;
}
public function destroy(): void {
// 明示的な参照の切断
$this->fiber = null;
$this->context = null;
}
}
// — 実行検証 —
$context = new TaskContext();
$worker = new SafeAsyncWorker($context);
$worker->startTask();
// Fiberがサスペンド中であっても、Worker側から明示的に参照を切り離し、
// WeakReferenceにより循環参照が形成されていないため、クリーンアップが確実に行われる
$worker->destroy();
unset($worker, $context);
// ガベージコレクションを強制しなくても、参照カウントは即座に0に収束する
echo “Memory successfully cleaned up without leaks.\n”;
パターン2: イベントループ・マネージャにおけるFiberライフサイクル管理
イベントループ（ReactPHPやAmpの内部構造に類似する設計）を自作、あるいは運用する場合、終了したFiber（`$fiber->isTerminated()` が `true` を返すもの）や、例外によって異常終了したFiberのインスタンスをイベントループのキュー（`SplObjectStorage` や配列）から速やかに削除することが絶対条件となる。
/
private \SplObjectStorage $registry;
public function __construct() {
// SplObjectStorageはオブジェクトをキーとしたハッシュテーブルであり、
// オブジェクトが破棄された際に自動的にエントリがパージされる特性を持つ
$this->registry = new \SplObjectStorage();
}
public function add(Fiber $fiber, mixed $metadata = null): void {
$this->registry->attach($fiber, $metadata);
}
public function tick(): void {
foreach ($this->registry as $fiber) {
if ($fiber->isTerminated()) {
// 終了したFiberは即座にストレージから切り離し、
// Zend VMのメモリ解放フェーズへ引き渡す
$this->registry->detach($fiber);
continue;
}
if ($fiber->isSuspended()) {
// イベントループの進行に伴いレジューム
// try-catchで囲み、例外発生時も確実にメモリリークを防ぐ
try {
$fiber->resume(‘next_tick_signal’);
} catch (\Throwable $e) {
// エラーログの出力と強制デタッチ
error_log(“Fiber execution failed: ” . $e->getMessage());
$this->registry->detach($fiber);
}
}
}
}
}
この `SplObjectStorage` を用いた管理手法は、Zend Engineの内部ハッシュテーブルの挙動に完全に調和しており、オブジェクトのライフサイクルとイベントループの管理を完全に同期させることができる。
—
結びにかえて
PHPのFiberは、もはや単なる「実験的な機能」ではなく、高スループットなWebアプリケーションやリアルタイムAPIを構築するための強力な武器である。しかし、その強力さはZend VMのメモリモデルと参照カウントのメカニズムを正確に把握しているという前提のうえにのみ成り立つ。
非同期処理のコードを書くときは常に、「このクロージャは誰にキャプチャされているか」「サスペンド中に参照カウントはいくつで固定されるか」「イベントループの終了時にインスタンスは確実にパージされるか」を脳内でZendオプコードのディスパッチと重ね合わせながら設計してほしい。その領域に到達したとき、あなたの書くPHPコードは、言語の限界を凌駕する極限のパフォーマンスと堅牢性を手に入れることになる。