こんにちは。普段からPHPのフレームワークを使いこなし、数々のWebアプリケーションを高速に仕立て上げてきたあなたなら、一度はこう思ったことがあるはずです。
「PHP 8.1で導入されたFiber（ファイバー）って、Node.jsの非同期やGoのGoroutineみたいなものなの？ なぜPHPで非同期処理っぽく書けるんだろう？」
そして、実際にFiberを触ってみて、あるいはその内部構造の謎に直面して、少し立ち止まっているかもしれませんね。
多くの解説記事は、「Fiberを使えば中断と再開ができますよ」「コールバック地獄から解放されますよ」といった、表面的な使い方に終始しがちです。しかし、私たちアーキテクトが本当に知るべきなのは、「あの華麗なコンテキストスイッチの裏側で、Zend VMとハードウェア（CPU）がどれほどの重労働を強いられているか」という点です。
今回は、Fiberがメモリ空間でどう管理され、CPUキャッシュやTLB（Translation Lookaside Buffer）にどのような爪痕を残すのか。そのハードウェアレベルの真実を、一緒に紐解いていきましょう。ここを理解すると、PHPの裏側が驚くほどクリアに見えてきますよ。
—
1. Fiberの正体：Zend VMにおける「もう一つの実行スタック」
まず、PHPの実行モデルの基本を思い出してください。通常、1つのHTTPリクエスト（FPMプロセスまたはWorker）は、単一のコールスタック（関数呼び出しの履歴を積む領域）の上で直線的に動きます。関数Aが呼ばれればスタックが積み上がり、抜けたら消える。極めてシンプルですね。
しかし、Fiberはこの常識を書き換えます。Fiberを生成すると、PHPのコア（Zendエンジン）は、通常のメインスタックとは別に、独立した専用のメモリ領域（スタックバッファ）をヒープ上に割り当てます。
[ メインのリクエスト処理空間 ]
└── Global Scope -> main() -> HTTP Controller -> Service
[ Fiber専用のヒープ領域 ] <-- (新規アロケーション) └── Fiber::start() によって切り離された「もう一つの実行コンテキスト」 ├── ローカル変数 ├── 実行ポインタ (zend_execute_data) └── コールスタック Fiberが `Fiber::suspend()` を呼ぶと、Zendエンジンは「今どこを実行していて、ローカル変数は何を持っていて、コールスタックがどうなっているか（`zend_execute_data` の状態）」を、そのFiber専用の領域に丸ごと退避させます。そして、制御を元のメインの実行フローに戻す。これが、PHPにおけるコンテキストスイッチの正体です。 ---
2. 実践コードで見るFiberのライフサイクルと「隠れたコスト」
百聞は一見にしかず。まずは、典型的なFiberのコードを見てみましょう。あえて低レイヤの動きを意識したコメントを添えています。
/
$fiber = new Fiber(function (string $name): void {
echo “[$name] Fiber内: 処理を開始しました。\n”;
// 最初のサスペンド（ここでメインフローに制御が戻る）
$received = Fiber::suspend(“[$name] 最初のサスペンド：データを待っています…”);
echo “[$name] Fiber内: 再開しました！ 受け取った値 -> {$received}\n”;
Fiber::suspend(“[$name] 2回目のサスペンド：終了直前です…”);
echo “[$name] Fiber内: すべての処理が完了しました。\n”;
});
// — メインフロー側からの制御 —
echo “メイン: Fiberを起動します。\n”;
$output1 = $fiber->start(“Worker-A”);
echo “メイン: Fiberから受け取ったメッセージ -> {$output1}\n”;
echo “メイン: 別処理を挟む間にCPUやメモリのキャッシュ状態が変化…\n”;
echo “メイン: Fiberにデータを送って再開させます。\n”;
$output2 = $fiber->resume(“【特急データ】”);
echo “メイン: Fiberから受け取ったメッセージ -> {$output2}\n”;
echo “メイン: 最後にFiberを完全に終了させます。\n”;
$fiber->resume(“【最終指示】”);
echo “メイン: すべてのプロセスが終了しました。\n”;
このコードの実行結果は想像通りになるはずです。しかし、この数行の `suspend()` と `resume()` の往復の裏で、CPU内部では何が起きているでしょうか？ 次が本題です。
—
3. CPUキャッシュ汚染とTLBミスのメカニズム
ここからが、他の言語のアーキテクトとも差がつく極限の知見です。
私たちが書いたPHPコードは、Zend VMによってバイトコード（オペコード）にコンパイルされ、最終的にCPUが理解する機械語（ネイティブコード）として実行されます。この時、CPUは高速にアクセスするために、以下の2つのハードウェア機構をフル活用しています。
1. CPUキャッシュ（L1/L2/L3キャッシュ）: 頻繁にアクセスするメモリ上のデータや命令を、CPUコアのすぐ近くに保持する。
2. TLB（Translation Lookaside Buffer）: 仮想アドレス（ソフトウェアが見ているメモリ番地）を、物理アドレス（実際のCPUが触るメモリチップ上の位置）に高速変換するためのキャッシュ。
コンテキストスイッチが引き起こす「キャッシュミスの嵐」
Fiberの `suspend()` と `resume()` が発生すると、何が起こるでしょうか？
メインの処理フローから、別のFiberが持つ独立したヒープ領域（スタック）へと実行コンテキストがジャンプします。これは、CPUから見ると「全く異なるメモリ空間への突然のワープ」を意味します。
- L1/L2キャッシュの無効化（スラッシング）:
これまでメインフローが温めていた（キャッシュに乗っていた）変数やZend VMの内部構造体のデータが、Fiber空間の新しいデータに置き換わってしまいます。再びメインに戻るとき、あるいは別のFiberに切り替わるとき、CPUはキャッシュミスを起こし、低速なメインメモリ（DRAM）へアクセスし直さざるを得なくなります。これがCPUキャッシュの汚染（またはスラッシング）です。
- TLBミスの発生:
プロセスやスレッドの切り替え（OSレベルのコンテキストスイッチ）ほどではありませんが、Fiber間でメモリの参照先（ヒープ上のスタック領域）が大きく変わると、CPUのTLB（ページテーブルのキャッシュ）にヒットしなくなるTLBミスが発生します。仮想アドレスから物理アドレスへの変換コストが跳ね上がり、CPUのパイプラインが一時的にストップします。
—
4. アーキテクトはどう設計に落とし込むべきか？
「じゃあ、PHPのFiberはパフォーマンスに悪影響だから使わないほうがいいの？」
いいえ、そんなことはありません。重要なのは、「どのようなユースケースでFiberを使うべきか」というトレードオフを正しく理解することです。
Fiberが輝く場所（適材適所）
Fiberの本質は、CPUの演算処理を高速化すること（Parallelism）ではなく、I/O待ちの時間を有効活用する協調的マルチタスク（Concurrency）です。
例えば、外部APIへのHTTPリクエスト、データベースからの応答待ち、ファイルの非同期読み込みなど、「CPUが仕事をやめて、ひたすら外部からのレスポンスを待っている時間（数ミリ秒〜数秒）」が存在する環境であれば、CPUキャッシュの入れ替えコスト（数マイクロ秒オーダー）など、完全に無視できるほどの微小なオーバーヘッドです。
逆に、CPUバウンドな処理（複雑な計算や配列の大量操作など）を、細切れのFiberに無理やり分割して切り替えまくるとどうなるでしょう？
キャッシュミスとTLBミスのペナルティが、純粋な演算処理の速度を激しく相殺し、「シングルスレッドで素直に書いた方が圧倒的に速かった」という悲惨な結末を迎えます。これが、低レイヤを知るエンジニアが陥らないための最初の関門です。
—
5. まとめ：PHPの裏側を掌握して、次のステージへ
今回は、PHPのFiberというモダンな機能の裏側で、メモリ空間とハードウェア（CPUキャッシュ・TLB）がどのように動いているかを深く掘り下げてみました。
- Fiberは独立したヒープ上のスタック領域を消費する。
- 頻繁なコンテキストスイッチは、CPUキャッシュの汚染やTLBミスを引き起こす。
- だからこそ、I/O待ちを伴う非同期処理（AmpやReactPHPなどのエコシステム、あるいは自製の非同期ループ）に絞って適用すべきである。
PHPは「手軽に書けるスクリプト言語」から、「内部構造を理解し、ハードウェアの限界を引き出す高効率なWebプラットフォーム」へと進化しました。その裏側を綺麗に見渡せるようになったあなたなら、もうフレームワークの挙動に戸惑うことはないはずです。
ぜひ、実際のプロダクトのアーキテクチャ設計にこの知見を活かしてみてください。きっと、ワンランク上の美しいコードが書けるようになるはずですよ。