Fiber内での参照カウントの挙動と循環参照検出の課題：メモリリークを回避する設計パターン
コードレビューを始めてくれ。目の前にあるそのコード、一見すると美しく非同期処理を抽象化できているように見えるだろう。しかし、Zend Engineのメモリ管理の裏側を覗いたとき、この実装は静かに、そして確実にアプリケーションを死に至らしめる時限爆弾を抱えている。
PHP 8.1で導入された Fiber（ファイバー） は、スタックレスではなくスタックフルな協的中断・再開（Cooperative Multitasking）をもたらし、I/OバウンドなWebアプリケーションのパラダイムを変えた。しかし、非同期処理の文脈に飛びつくエンジニアの多くが、PHPの根幹である 「参照カウント方式（Reference Counting）とガベージコレクション（GC）」 の挙動が、Fiberのコンテキストスイッチによってどう歪むのかを理解していない。
今回は、Fiber内部におけるメモリの迷宮、特に「クロスコンテキストの循環参照」が生むメモリリークのメカニズムと、それを完全に断ち切るための実務的設計パターンを解説する。
—
1. Zend VMのメモリ管理とFiberの内部構造
まず、Zend Engineがどのようにメモリを管理しているか、そのプリミティブな事実から確認しよう。
PHPの変数やオブジェクトは、すべて `zval` という構造体にラップされている。オブジェクトはヒープ上にアロケートされ、その構造体内部には `refcount`（参照カウント）というカウンタが存在する。これが `0` になった瞬間、`efree()` が呼ばれ、メモリは即座に解放される。これが基本だ。
では、Fiberはどう動いているか？
Fiberは、独自のコールスタック（Execution Context）を保持する。Fiberが中断（`Fiber::suspend()`）されるとき、Zend VMはその時点の実行スタックフレーム、ローカル変数、そしてレジスタ状態をヒープ上に退避させる。
ここで致命的な問題が発生する。
Fiberのクロージャや、Fiber内で生成されスタックフレームに捕捉（キャプチャ）されたオブジェクトは、Fiberインスタンスが生存し続ける限り、たとえ中断中であっても参照カウントが維持される。さらに、そのオブジェクトがFiberの外側の世界（グローバルなイベントループやDIコンテナなど）と複雑な参照関係を結んだとき、PHPの参照カウントの弱点である「循環参照（Circular Reference）」の罠に落ちる。
—
2. Fiberコンテキストが引き起こすメモリリークのメカニズム
言葉だけでは抽象的すぎる。コードレビューの現場で最もよく見る「やってはいけない実装」をベースに、何が起きているのかを解剖しよう。
危険なアンチパターン：ファイバーとイベントループの密結合
fiber = new Fiber(function () use ($task) {
// $this や $task のコンテキストがファイバーのスタックフレームに保持される
$data = $task($this);
Fiber::suspend($data);
// ファイバー内で自分自身（$this）を参照し続けるクロージャ
$this->result = “Completed: ” . $data;
});
$this->fiber->start();
}
public function getResult(): mixed {
return $this->result;
}
}
// — 実行コンテキスト —
$runner = new AsyncTaskRunner();
$runner->run(function (AsyncTaskRunner $r) {
// ここで $r（つまり $runner）をクロージャがキャプチャしている
// AsyncTaskRunner -> Fiber -> Closure -> AsyncTaskRunner という強力な循環参照が形成される
return “API Response”;
});
このコードの何が問題か？
1. `$runner` は `AsyncTaskRunner` のインスタンス。
2. `$runner` が保持する `$fiber` は、内部のクロージャ（スタックフレーム）を通じて `$this`（すなわち `$runner`）を強く参照している。
3. `Fiber::suspend()` によって処理が中断されたとき、この循環参照はZend Engineの通常の参照カウントでは絶対に解放されない。
4. PHPの循環ガベージコレクタ（`gc_collect_cycles()`）が動くまでメモリはゾンビのように残り続け、高スループットなAPIサーバであれば、数千リクエストでメモリ上限（`memory_limit`）に到達し、OOM（Out of Memory）でプロセスが強制終了する。
厄介なのは、Fiberが「完了（terminate）」せず、途中で放置されたり、例外によって中断されたままスコープ外に消えた場合、スタックに紐づくオブジェクト群が永遠にGCのルートから外れたまま宙に浮く点だ。
—
3. 回避策：ウィークリファレンス（WeakReference）とライフサイクル管理の徹底
この問題を解決するには、設計思想の転換が必要だ。
結論から言えば、「Fiberの内部から、外部のオーナーオブジェクトを強く参照してはならない」。ここでPHP 7.4以降で導入された `WeakReference` が決定的な切り札となる。
以下のコードを見てほしい。これが、実務のプロダクション環境に耐えうる、メモリリークを完全に排除したFiberベースの非同期タスクランナーの設計パターンだ。
実務向けリファレンス実装：メモリ安全なFiberタスクランナー
/
public function __construct(callable $task) {
// $this を直接useするのではなく、WeakReferenceでラップしてキャプチャさせる
$weakSelf = WeakReference::create($this);
$this->fiber = new Fiber(function () use ($task, $weakSelf) {
try {
// タスク実行中は弱参照経由で自身にアクセスする
$result = $task($weakSelf);
$this->isFinished = true;
return $result;
} catch (Throwable $e) {
$this->isFinished = true;
// 例外発生時も確実にファイバーコンテキストを破棄させるためのハンドリング
throw $e;
}
});
}
public function start(): mixed {
if ($this->fiber->isStarted()) {
throw new \LogicException(‘Job has already been started.’);
}
return $this->fiber->start();
}
public function resume(mixed $value = null): mixed {
if ($this->fiber->isTerminated()) {
throw new \LogicException(‘Cannot resume a terminated job.’);
}
return $this->fiber->resume($value);
}
public function isTerminated(): bool {
return $this->fiber->isTerminated();
}
/
- デストラクタで明示的にFiber参照を断ち切る
/
public function __destruct() {
// ファイバーがまだ生きている（中断中など）場合に、
// 循環参照の連鎖を断つためにインスタンス変数をnull化する
$this->fiber = null;
}
}
// ==========================================
// 使用例（イベントループやコントローラー層）
// ==========================================
function executeWorkflow(): void {
$job = new SafeAsyncJob(function (WeakReference $weakRunner) {
echo “Fiber started.\n” . PHP_EOL;
// 途中で外部オブジェクトの状態を確認したい場合
$runner = $weakRunner->get();
if ($runner === null) {
return “Owner already garbage collected.”;
}
// 非同期I/Oの模擬（中断）
$data = Fiber::suspend(“Waiting for I/O…”);
return “Processed: ” . $data;
});
// 1回目の実行（suspendまで）
$status = $job->start();
echo “Status: {$status}\n” . PHP_EOL;
// 再開
$finalResult = $job->resume(“Network Payload OK”);
echo “Result: {$finalResult}\n” . PHP_EOL;
}
executeWorkflow();
—
4. アーキテクチャ上の鉄則：コードレビューのチェックリスト
開発チームを率いるテクニカルリードとして、Fiberを導入するコードベースに対しては以下の項目を厳格にレビューに課してほしい。
1. Fiber内のクロージャで `$this` や親スコープのオブジェクトを無防備に `use ($this)` していないか？
- 対策: 常に `WeakReference::create($this)` を経由させ、処理の冒頭で `$self = $weakRef->get(); if (!$self) { return; }` のガード節を設ける。
2. Fiberのインスタンス変数が長寿命のサービスやDIコンテナに蓄積されていないか？
- 対策: 非同期処理が完了（`isTerminated() === true`）したファイバーオブジェクトは、速やかに配列やプロパティからアンセット（`unset($this->fibers[$id])`）し、Zend VMの参照カウンタを即座に `0` に落とせる状態を維持する。
3. 例外発生時のエスケープパスが確保されているか？
- 対策: Fiber内で未キャッチの例外が発生すると、そのスタックフレームは巻き戻されるが、外部から参照が残っているとメモリ上にゴミが残る。必ず `try-finally` 構文を用いて、リソースのクリーンアップを保証する。
—
結びにかえて
PHPは長年、「1リクエスト＝プロセス終了時に全メモリ一括解放」というシンプルで強靭な安全装置に守られてきた。FPMアーキテクチャの恩恵により、多少のメモリリークはリクエスト終了とともに消え去っていた。
しかし、Fiberの登場、そしてSwooleやReactPHP、Ampといった非同期・常駐型PHPアプリケーションの普及により、「プロセスが数日、数週間落ちないこと」が前提になりつつある。このモダンなパラダイムにおいて、Zend Engineの参照カウントとFiberのコンテキストライフサイクルの関係を理解していないコードは、時限爆弾でしかない。
メモリの寿命を支配せよ。Zend VMの挙動を脳内にトレースし、美しく、かつ極限まで安全な非同期アーキテクチャを君の手で構築してほしい。