【入門編】Fiber内での参照カウントの挙動と循環参照検出の課題：メモリリークを回避する設計パターン – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

こんにちは。普段、他のモダンな言語（Node.jsやGo、Pythonなど）でバリバリと非同期処理やイベントループを組んできた優秀なあなたなら、PHPの「Fiber（ファイバー）」に初めて触れたとき、こう思ったかもしれません。

「お、ついにPHPでもスタックフルな協調的マルチタスク（コルーチン）がネイティブで使えるようになったのか。Nodeの `async/await` や Goのゴルーチンみたいに、I/O待ちの間に他の処理をサクサク回せるぞ」と。

……ええ、その通りです。PHP 8.1で導入されたFiberは、コールバック地獄（いわゆるピラミッド・オブ・ドゥーム）から私たちを解放し、非同期処理を同期的なコードの見た目のまま記述できるようにしてくれた素晴らしいエンジン拡張です。

しかし、ここで一つ、PHP特有の「メモリ管理の暗部」に足を踏み入れてしまう開発者が後を絶ちません。そう、「Fiberの実行コンテキストを跨ぐオブジェクトの参照と、ゾンビ化するメモリリーク」の罠です。

今回は、Zendエンジンが裏側でどのようにメモリを管理しているのか、そしてFiberという「中断・再開できるコンテキスト」がそのメモリ管理にどう牙を剥くのかを、低レイヤの視点から紐解いていきましょう。ここを理解すれば、PHPの裏側がぐっとクリアに見えてきますよ。

—

1. Zendエンジンと参照カウント（RC）の基本構造

まず、PHPのメモリ管理の基本を軽くおさらいしておきましょう。PHP（Zend VM）のすべての変数は、`zval`（Zend Value）という構造体で表現されています。

オブジェクト、配列、文字列などの複合データは、ヒープメモリ上に実体が確保され、`zval`はそのポインタを保持します。このとき、そのヒープ上のデータを何個の変数が指し示しているかを数えているのが、お馴染みの参照カウント（Reference Count: `refcount`）です。

`refcount` が `1` になれば、その変数がスコープを抜けた瞬間にメモリは即座に解放されます。
しかし、複数の変数やオブジェクトプロパティから相互に参照し合うと、お互いの `refcount` が `0` にならなくなります。これが循環参照（Circular Reference）です。

通常のスクリプト実行では、PHPには優秀な循環参照ガベージコレクタ（GC）が備わっています。バッファが一杯になるか、あるいは明示的に `gc_collect_cycles()` が呼ばれると、怪しい `zval` の輪を検出し、見事に回収してくれます。

……しかし、Fiberが絡むと、このGCのアルゴリズムをすり抜ける「厄介なコンテキストの閉じ込め」が発生するのです。一体どういうことでしょうか？

—

2. Fiberの中断・再開が生む「コンテキストを跨ぐ参照」の罠

Fiberの本質は、「独自のコールスタックを持ち、実行途中で実行権を親（呼び出し元）に返却（suspend）し、後から再開（resume）できる仕組み」です。

ここで重要なのは、Fiberが中断している間、そのFiberの内部スコープ（ローカル変数やクロージャのuse変えなど）に紐づくすべてのオブジェクトやリソースは、メモリ上に「生存したまま」保持され続けるという点です。

もし、Fiberの内部で生成されたクロージャやオブジェクトが、Fiberの外側のスコープ（例えばイベントループのマネージャなど）と双方向の参照関係を持ってしまったらどうなるでしょうか？

以下のコードを見てください。一見、何気ない非同期タスクのようですが、メモリリークの爆弾が仕込まれています。

fiber = new Fiber(function () {
// ローカル変数として巨大なデータを保持
$largeData = str_repeat(‘A’, 1024 1024); // 1MB

// ここで、Fiber自身（$this->fiber）や親のコンテキストをクロージャがキャプチャする
// ※「$this」をクロージャが保持することで、循環参照の輪が生まれる
$callback = function () use ($largeData) {
// 何かしらの非同期処理をシミュレート
return “Processed: ” . strlen($largeData) . ” bytes”;
};

// 中断（Suspend）
$this->result = Fiber::suspend($callback);
});

$this->fiber->start();
}
}

// リクエストやイベントループのライフサイクルを想定
$context = new TaskContext();
$context->run();

// Fiberは中断状態（Suspended）のまま、ここでスコープを抜けたとする
// 通常なら $context は不要になるはずだが……？

何が起きているのか？（Zend VMの視点）

1. `$context->fiber` は `Fiber` インスタンスを保持しています。
2. その `Fiber` の内部スタックには、実行途中のクロージャ（ `$callback` ）が存在し、それが `use ($largeData)` や外部の `$this`（ `$TaskContext` インスタンス）への参照を持っています。
3. 結果として、`TaskContext` -> `Fiber` -> クロージャ -> `TaskContext` という強固な循環参照の輪が完成します。
4. しかも、このFiberは「中断（Suspended）状態」です。Zendエンジンの視点から見ると、「まだ実行が完了しておらず、将来的に再開される可能性があるアクティブな実行コンテキスト」であるため、通常のガベージコレクションのスコープ外、あるいは参照の糸が複雑に絡み合った状態で宙ぶらりんになります。

結果、PHP-FPMの1リクエスト内（あるいは長寿命なReactPHPなどのDaemonプロセス）でこれが大量に生成されると、リクエストが終わってもメモリが解放されない（あるいはGCが追いつかず肥大化する）メモリリークを引き起こします。

—

3. 循環参照を回避する設計パターン：クリーンアップと参照の切断

では、Fiberを用いた非同期処理やイベントループの設計において、このメモリリークを完璧に回避するにはどうすればよいのでしょうか？

答えはシンプルです。「Fiberのライフサイクルが終了した（あるいは破棄されるべき）タイミングで、明示的に外部参照を断ち切る（nullを代入する）」ことです。

実務でそのまま使える、安全なタスクハンドラの設計パターンのコードを見てみましょう。

externalResource = str_repeat(‘X’, 512 1024);
}

public function start(): void {
$this->fiber = new Fiber(function () {
$localPayload = $this->externalResource;

try {
// 処理の中断
$res = Fiber::suspend(“Working…”);
return “Done: ” . $res;
} finally {
// 【重要】Fiberが終了・例外終了する際、確実に内部ステートをクリアする
// これにより、循環参照のアンカーを自ら外す
$this->cleanup();
}
});

$this->fiber->start();
}

public function resume(mixed $value): mixed {
if (!$this->fiber || !$this->fiber->isSuspended()) {
return null;
}

$result = $this->fiber->resume($value);

// もしFiberが終了（Terminated）したら、即座に参照を切断する
if ($this->fiber->isTerminated()) {
$this->cleanup();
}

return $result;
}

private function cleanup(): void {
// オブジェクト間の参照をすべて断ち切り、ZendのRCを即座に0にする
$this->fiber = null;
$this->externalResource = null;
}
}

// — 実行と検証 —
$worker = new SafeAsyncWorker();
$worker->start();

// 途中で再開して完結させる
$output = $worker->resume(“Next Step Data”);
// $worker はすでに終了しているため、$this->fiber や外部リソースの参照は null になり、
// メモリは即座に解放される（GCを待つ必要すらない）

設計上のキモ

1. `finally` 節の活用: Fiber内で例外が発生しようとも、正常終了しようとも、確実にクリーンアップメソッドが走るようにします。
2. ライフサイクルの監視: `isTerminated()` や `isDead()` を用いて、イベントループ側から Fiber の生死を常に監視し、死んだ瞬間にラッパーオブジェクト側のプロパティを `null` クリアします。
3. クロージャ内での `$this` のキャプチャを最小限にする: PHP 8.1以降、アロー関数や無名関数で `$this` を暗黙的にキャプチャしやすくなっていますが、不要な場合は静的クロージャ（`static function()`）を利用して、オブジェクトへの参照そのものを持ち込まない工夫が極めて有効です。

—

4. まとめ：PHPの裏側を支配する者

Fiberは、PHPにおける非同期処理のパラダイムシフトをもたらした強力な武器です。しかし、言語のランタイムが自動ですべてをよしなにやってくれるわけではありません。

Zendエンジンの `zval` と参照カウントの仕組みを頭の片隅に置く。
Fiberが「中断している」という状態は、メモリ上のオブジェクトが「時を止められて保持され続けている」と同義であると理解する。
ライフサイクルが終わったFiberコンテキストは、自らの手で参照を断ち切る（`null` を代入する）。

ここを意識できるようになれば、あなたの書くPHPコードは、単に「動く」だけでなく、長期間稼働するデーモンプロセスや高負荷なWebシステムであっても、メモリリークとは無縁の「美しく堅牢なアーキテクチャ」へと昇華されます。

さあ、次のリクエストやイベントループの設計では、ぜひこのメモリの潮流まで意識した美しいコードを奏でてみてください。PHPの裏側が、あなたにとってより一層コントロールしやすい素晴らしいエンジンに見えてくるはずです。