こんにちは。PHPの裏側を覗く旅へようこそ。
他の言語（GoのGoroutineやNode.jsのAsync/awaitなど）で非同期並行処理をバリバリ書いてきた優秀なエンジニアほど、PHPのモダンな非同期機能、特に Fiber（ファイバー） に触れたとき、「おや？」と立ち止まる壁にぶつかりがちです。
「コールバック地獄にならずに協調的マルチタスクができるのは分かったけれど、これ、実際のZendエンジンやメモリ管理の観点でどう動いているの？」
「パフォーマンスを極限まで絞り出すには、どこをどうチューニングすればいいの？」
そんな疑問を持ったあなたは大正解です。表面的な構文を覚えるフェーズを抜けたエンジニアこそ、PHPの心臓部であるZend VMとメモリ空間（HashTable）の挙動に目を向けるべきタイミングにいます。
今回は、Fiberのパフォーマンスを極限まで引き出すための「スタックサイズ」「コンテキストスイッチのオーバーヘッド」「GC（ガベージコレクション）との関係」について、低レイヤの視点を交えながら、温かく、そして深く紐解いていきましょう。ここを理解すると、PHPの裏側が一枚の美しい絵のようにクリアに見えてきますよ。
—
1. Fiberの正体：Zend VMとコールスタックの分離
まず、PHPのFiberがエンジン内部でどう扱われているかをおさらいしましょう。
通常、PHPの関数実行はCのコールスタック上にZendのエグゼキューションデータ（`zend_execute_data`）を積み上げていくことで行われます。リクエストが来ると、メインの実行コンテキストが作られ、上へ上へと関数が積まれ、終われば巻き戻される。非常にシンプルで堅牢ですが、途中で処理を中断して「別の文脈の処理に一旦ジャンプし、あとで戻ってくる」ということは、従来のPHPでは極めて困難でした。
ここで登場するのがFiberです。Fiberは、PHPのユーザーランド（スクリプト）レベルで独自のコールスタックを持つ仕組みです。
[ 通常のPHPの実行フロー ]
Main Execution ──> Function A() ──> Function B() (終了まで一気通貫)
[ Fiberを使った非同期フロー ]
Main ──> [ Fiber #1 (スタック確保) ] ──(suspend)──> Main ──> [ Fiber #2 ]
│ │
└──────────────────(resume で復帰)──────────────────────┘
Fiberを生成すると、Zendエンジンはヒープ上にそのFiber専用の実行コンテキスト（スタック領域を含む）を割り当てます。この「スタックの独立」こそが、Fiberの強力さと、同時にパフォーマンス上の注意点の源泉になります。
—
2. スタックサイズのチューニング：メモリとオーバーヘッドのトレードオフ
Fiberをインスタンス化するとき、あるいはZendエンジンが内部でスタックを扱うとき、どれくらいのメモリが割り当てられているか意識したことはありますか？
実は、PHPのFiberは生成時に一定のメモリバッファ（スタック）を確保します。
もしスタックサイズが小さすぎると、深い再帰呼び出しや肥大化したローカル変数を持つ関数を実行した瞬間に、スタックオーバーフロー（Zendエンジンレベルでの致命的なエラー）を引き起こします。逆に、大きすぎると、数千・数万のFiberを並行稼働させるようなI/OバウンドなWebアプリケーション（例えばWebSocketサーバーやAPIゲートウェイ）において、一瞬でメモリを食いつぶし、OSのページングやCPUキャッシュヒット率の低下（キャッシュミスの多発）を招きます。
現場で使える：スタックをスリムに保つ設計パターン
PHP 8.1以降でFiberを扱う際、スタック消費を最小限に抑えるためには、「Fiberの内部で深いコールツリーを作らない」のが鉄則です。
/
$fiber = new Fiber(function (string $url): void {
// 1. 非同期でHTTPリクエストを飛ばす（ここでサスペンド）
$response = SuspendableHttpClient::get($url);
// 2. 結果をパースする（フラットな処理）
$data = json_decode($response, true);
Fiber::resume($data);
});
// Fiberを開始
$initialData = $fiber->start(‘https://api.example.com/data’);
このように、Fiberのコールバック内は「イベント待ち（Suspend）」「データ受け取り」「最小限の加工」に留め、ビジネスロジックの深部を何重もの関数呼び出しで包まないことが、スタック消費量を一定に保つ最大のコツです。
—
3. コンテキストスイッチの頻度：CPUキャッシュとオーバーヘッドの罠
「非同期処理だから、細かく刻んでスイッチさせれば効率が良いはずだ」というのは、往々にしてアンチパターンになります。
Fiberが `Fiber::suspend()` と `Fiber::resume()` を行うたびに、Zend VMは何を行っているでしょうか？
1. 現在のCPUレジスタ状態やZendのエグゼキューションポインタの退避
2. 次に実行するFiberのコンテキストへのポインタ切り替え
3. 仮想マシンの実行状態（`EG(current_execute_data)` など）の書き換え
これらはネイティブのOSスレッド切り替えよりは遥かに軽量ですが、それでもCPU命令レベルでのオーバーヘッドは確実に存在します。あまりにも高頻度（例えば、数行の処理ごとにサスペンドを繰り返すなど）でコンテキストスイッチを行うと、CPUのパイプラインやL1/L2キャッシュが頻繁にフラッシュされ、純粋なスループットが低下します。
理想的な協調的マルチタスクの粒度
イベントループ（AmpやReactPHPなどのエコシステム）とFiberを組み合わせる場合、「I/Oブロッキングが発生する瞬間のみ」にコンテキストスイッチを絞るのが最もパフォーマンスが出ます。
resume(“データ取得完了: {$uri}”);
});
// 処理を中断し、イベントループに制御を戻す
$suspend = Fiber::suspend();
return $suspend;
}
$fiber = new Fiber(function () {
echo “Fiber開始\n”;
$result = asyncOperation(‘/users’);
echo “{$result}\n”;
echo “Fiber終了\n”;
});
$fiber->start();
// イベントループを回して非同期タスクを消化する
EventLoop::run();
このコードでは、「本当に待つ必要がある瞬間」にだけ `Fiber::suspend()` を呼んでいます。CPUバウンドな処理（配列の大量ソートや複雑な文字列処理など）をFiberの中で細切れに実行するのではなく、I/O待ちの隙間を埋めるためにFiberを使う、という原点を忘れないことが大切です。
—
4. ガベージコレクション（GC）とFiberのメモリライフサイクル
ここが一番、実務でハマりやすいダークマターです。
PHPのメモリ管理は強力な参照カウント（Reference Counting）と、循環参照を回収するガベージコレクタによって支えられています。
Fiberの内部で大規模なオブジェクトや配列（例えば、数万件のレコードが入ったORMのコレクションなど）を保持したままサスペンドし、そのFiber自体がしばらくイベントループの参照キューに残り続けた場合、どうなるでしょうか？
そのFiberが保持しているローカル変数やスコープ内のすべての変数は、Fiberが生存している間、メモリから一切解放されません。
通常の同期スクリプトであれば、関数を抜けたちょっとしたタイミングで破棄されるはずのメモリが、Fiberがサスペンド（中断）しているがゆえに生き残り続け、PHP-FPMのワーカープロセスのメモリ使用量をじわじわと肥大化させます。結果として、OOM（Out of Memory）エラーの温床になります。
メモリリークを防ぐ設計の極意
Fiber内で大きなデータを扱うときは、以下の鉄則を体に染み込ませてください。
1. スコープを最小化する
重い変数はFiberのクロージャの外側で不必要にキャプチャしない。必要なデータだけを引数として渡し、処理が終わったら即座にスコープから外す（あるいは `null` を代入して参照を切る）。
2. 完了したFiberは速やかに捨て去る
一度死んだ（終端に達した）Fiberオブジェクトへの参照が、イベントループやグローバルな配列に残り続けていないか、ライフサイクルを厳密に管理する。
—
まとめ：PHPの裏側を美しく操るエンジニアへ
いかがでしたでしょうか？
Fiberは、単なる「書きやすいためのシンタックスシュガー」ではありません。Zend VMのメモリ空間、コールスタックの動的制御、そしてPHP-FPMのプロセスモデルと深く結びついた、非常にエキサイティングな低レイヤ機能です。
- スタックサイズとメモリ: 内部で深い関数ツリーを作らず、フラットかつスマートに保つ。
- コンテキストスイッチ: 高頻度なスイッチを避け、I/Oブロッキングのポイントに絞る。
- GCとライフサイクル: サスペンド中の変数保持によるメモリ肥大化に細心の注意を払う。
これらを押さえたあなたなら、もはや「PHPだから非同期は苦手」という偏見とは無縁の、極めて高パフォーマンスでスケーラブルなWebアプリケーションを設計できるはずです。
さあ、次のリクエストを処理するエンジンを、あなたの手で美しくチューニングしてみませんか？