Zend MMとFiberの共存戦略：数千の並行世界を支えるメモリ管理の極意
PHP 8.1で導入された `Fiber` は、私たちの非同期処理に対する認識を根本から覆した。コールバック地獄（Pyramid of Doom）を強要された従来の非同期プログラミングから解放され、同期的な記述スタイルのまま協力型マルチタスキング（Cooperative Multitasking）を実現できる。
しかし、プロダクション環境で数千、数万のFiberを同時並行で駆動させるシステムを設計したとき、多くのエンジニアが「理由のわからないメモリリーク」や「プロセスの急激な肥大化」という壁に直面する。
その原因は、アプリケーションコードのミスだけではない。Zend Memory Manager（Zend MM）の割り当て戦略と、Fiberがスタックフレームをメモリ上で保持し続けるライフサイクルとの衝突にある。
本稿では、Zend VMの低レイヤメモリ構造に踏み込み、大規模Fiber環境におけるメモリフラグメンテーションを完全に制御するための設計原則を紐解く。
—
1. Zend MMの裏側：なぜFiberはメモリを爆発させやすいのか
Zend MMは、PHPプロセス（SAPI）が起動した際に、オペレーティングシステムから巨大なメモリブロック（Chunk）を一括して取得し、それを独自のアルゴリズムで細分化して管理する。これにより、システムコール（`malloc`/`free`）のオーバーヘッドを極限まで削減している。
スタックレスからスタックフルへ
従来のPHP（コールスタック）は、関数が呼び出されるたびにCのコールスタック上に変数が積まれ、リターンと共に解放される。メモリのライフサイクルは完全に「LIFO（Last In, First Out）」であり、Zend MMにとって最も効率的にキャッシュヒットを狙える構造だった。
しかし、Fiberは「スタックフル（Stackful）」なコンテキストを持つ。
Fiber内部で中断（`Fiber::suspend()`）された瞬間、その実行コンテキスト（ローカル変数、引数、評価スタック）はヒープ上にアロケートされた `zend_fiber_context` 構造体の中に保持される。
[Zend MM Heap]
├── Chunk A (通常のPHPリクエスト用ヒープ)
└── Chunk B (Fiber固有のスタック領域)
├── Fiber #1 (中断中: 2MB確保・保持)
├── Fiber #2 (中断中: 2MB確保・保持)
└── Fiber #3 (実行中)
この「中断状態の長期化」と「不規則なライフサイクル」が、Zend MMのヒープ管理に致命的なフラグメンテーション（断片化）を引き起こす。
フラグメンテーションのメカニズム
数千のFiberが異なるタイミングで生成され、異なるタイミングで破棄されると、Zend MMのフリーリスト（Free List）に「細かい空きメモリの隙間」が無数に生まれる。結果として、新しい大きなオブジェクトや別のFiberスタックを割り当てようとした際、連続した空き領域が見つからず、Zend MMはOSから追加のChunkを要求せざるを得なくなる。これが「プロセスはメモリを解放しているはずなのに、RSS（Resident Set Size）が減らない」現象の正体だ。
—
2. 大規模Fiber環境における設計の4大鉄則
コードレビューの現場で、私はチームメンバーに次の4つのルールを厳守させている。これらを無視したFiberの乱用は、システム全体のメモリ効率を悪化させる時限爆弾となる。
鉄則1: Fiber内のスコープ変数は「即座に破棄・unset」する
Fiberが中断している間、そのスコープ内に存在する巨大なオブジェクトや配列は、ガベージコレクション（GC）の対象外となり、ヒープ上に居座り続ける。不要になったデータは、中断する前に明示的に `unset()` し、参照を切断しなければならない。
鉄則2: プレアロケーション（事前割り当て）とプーリングの概念を導入する
リクエストごとに無秩序にFiberを `new Fiber()` するのはアンチパターンだ。イベントループと連携し、一定数のFiberインスタンスやコンテキストを再利用（プール）するアーキテクチャを構築せよ。
鉄則3: イベントループとの協調によるメモリの自発的解放
Zend MMは、連続した大きなメモリブロックが解放されたときに、OSへメモリを返還（`munmap`）する処理を行う。Fiberの処理の区切り（バッチの境界など）で、意図的にアイドル状態を作り、Zend MMがデフラグメンテーションを行う隙を与えるべきだ。
—
3. 【実装例】メモリフラグメンテーションを抑制するFiberプール基盤
実務のAPIサーバーやデータ処理ワーカーを想定し、数千のタスクを安全に処理するための「メモリセーフなFiberワーカープール」の設計コードを提示する。
/
final class MemorySafeFiberWorkerPool
{
/ @var \Fiber[] 待機中のFiberプール /
private array $pool = [];
/ @var int 最大同時実行数 /
private int $concurrency;
/ @var int 処理済みタスクカウンター（メモリ再同期用） /
private int $processedTasks = 0;
/ @var int デフラグメンテーションを促す閾値 /
private const GC_THRESHOLD = 500;
public function __construct(int $concurrency = 100)
{
$this->concurrency = $concurrency;
}
/
- タスクを安全にエンキューし、並行実行を制御する
/
public function execute(iterable $tasks, callable $taskHandler): void
{
$activeFibers = [];
foreach ($tasks as $taskData) {
// プールに余裕があり、かつ同時実行数に達していない場合は新規作成
if (count($activeFibers) < $this->concurrency) {
$fiber = $this->createFiber($taskHandler);
$activeFibers[] = $fiber;
$fiber->start($taskData);
} else {
// イベントループの簡易シミュレーション：アクティブなFiberの進行を待つ
$activeFibers = $this->tick($activeFibers, $taskData, $taskHandler);
}
// 定期的なメモリ管理の最適化
$this->triggerMemoryOptimization();
}
// 残ったアクティブなFiberが完全に終端するまで回収
while (count($activeFibers) > 0) {
$activeFibers = array_filter($activeFibers, static function (\Fiber $fiber): bool {
if (!$fiber->isTerminated()) {
if ($fiber->isSuspended()) {
$fiber->resume();
}
return true;
}
return false;
});
}
}
/
- Fiberインスタンスを生成し、ライフサイクル全体でのメモリリークを防ぐラップを行う
/
private function createFiber(callable $handler): \Fiber
{
return new \Fiber(function ($data) use ($handler) {
try {
// ハンドラーの実行
$result = $handler($data);
// 【重要】処理結果を返却した直後、ローカル変数の影響範囲を限定するため
// 不要になった巨大データはここで確実に破棄する
unset($data);
return $result;
} catch (\Throwable $e) {
// エラーログの出力など
error_log(“Fiber Execution Error: ” . $e->getMessage());
throw $e;
}
});
}
/
- アクティブなFiberの状態を進め、終了したものを回収する
/
private function tick(array $activeFibers, mixed $newTaskData, callable $handler): array
{
foreach ($activeFibers as $index => $fiber) {
if ($fiber->isTerminated()) {
// 終了したFiberはプールへ戻すか、完全に破棄してZend MMに回収を促す
unset($activeFibers[$index]);
$this->processedTasks++;
// 新規タスクがあれば、空いたスロットに割り当てる
$newFiber = $this->createFiber($handler);
$activeFibers[] = $newFiber;
$newFiber->start($newTaskData);
return array_values($activeFibers);
}
if ($fiber->isSuspended()) {
$fiber->resume();
}
}
return array_values($activeFibers);
}
/
- 大規模処理の合間にZend MMのフラグメンテーションを緩和する
/
private function triggerMemoryOptimization(): void
{
if ($this->processedTasks >= self::GC_THRESHOLD) {
// 循環参照の回収
gc_collect_cycles();
// Zend MMの統計情報を確認し、必要に応じたログ出力や
// 極端なメモリ肥大化時のプロセス安全停止をここで検討する
$this->processedTasks = 0;
}
}
}
// — 実行・利用例 —
/
$pool = new MemorySafeFiberWorkerPool(50);
$tasks = (function () {
for ($i = 0; $i < 5000; $i++) {
yield ["id" => $i, “payload” => str_repeat(“A”, 1024)]; // 1KBのダミーデータ
}
})();
$pool->execute($tasks, function (array $task) {
// 非同期処理をシミュレート
\Fiber::suspend();
// 処理完了
return $task[‘id’] 2;
});
/
—
4. テクニカルリードからの最終提言
FiberはPHPに真の非同期をもたらす強力な武器である。しかし、それは「メモリ管理の責任をフレームワークや言語エンジンから、完全に開発者へシフトさせた」ことを意味する。
C10K問題（1万人の同時接続）をPHPでスマートに解決したいのであれば、単に `Fiber` の構文を覚えるだけでは不十分だ。Zend VMがどのようにメモリを確保し、どのタイミングでフラグメンテーションが起きるのかを脳内でトレースできるかどうかが、プロフェッショナルとアマチュアを分ける境界線となる。
コードレビューにおいて、長期稼働するワーカープロセス内でFiberを生成・破棄している箇所があれば、必ず「そのスコープ内のメモリは誰が、いつ解放するのか」を問い質してほしい。低レイヤの物理メモリの息遣いを感じられるエンジニアだけが、極限まで最適化された堅牢なPHPシステムを構築できるのだ。