こんにちは。PHPの裏側でZendエンジンがどう息づいているか、その鼓動を感じたことはありますか？
Node.jsやGoの並行処理モデルに慣れ親しんだ優秀なエンジニアほど、「PHPでリアルタイムな非同期処理や高頻度なポーリングをやろうとすると、CPUが焼き切れるのではないか」「プロセスが爆発するのではないか」という壁にぶつかりがちです。C10K問題の文脈において、従来のPHPは1リクエスト1プロセス（あるいはスレッド）の重厚長大なモデルゆえに、こうしたリアルタイム制御の分野では少し敬遠されがちでした。
しかし、PHP 8.1でFiber（ファイバー）が導入されて以来、ゲームのルールは静かに、しかし劇的に変わりました。
今回は、外部APIやキュー、あるいはハードウェアの状態を高頻度で監視する「ポーリング処理」をテーマに、Fiberを使ってCPU使用率を極限まで抑え込みながら、美しく非同期を実現する極意を紐解いていきましょう。ここを理解すると、PHPが単なる「Webのテンプレートエンジン」から「洗練された並行処理ランタイム」へと昇華する瞬間が見えてきますよ。
—
1. なぜ「雑なポーリング」はZend VMとCPUを殺すのか
まずは、よくあるアンチパターンから見ていきましょう。外部のジョブ完了を待つために、次のようなコードを書いたことはありませんか？
// 悪い例：CPUをドカ食いするビジーウェイト（スピンロック）
while (!isJobFinished($jobId)) {
usleep(1000); // 1ミリ秒待つ
}
一見、`usleep(1000)`を入れているので優しそうに見えますが、内部レイヤ（OSのスケジューラ）の挙動を想像してみてください。このコードは、わずか1ミリ秒のウェイトを挟みながら、無限にCPUコアの時間を占有し続けます。
Zend VMはこのループの中でひたすらopcode（オペコード）を解釈し続け、OSのコンテキストスイッチを高速で発生させます。結果として、システム全体のCPU使用率が跳ね上がり、Webサーバー全体のスループットがガタ落ちする原因になります。
私たちが目指すべきは、CPUを無駄に空回りさせる「ビジーウェイト」ではなく、「イベント駆動的な協調動作（Cooperative Multitasking）」です。ここでFiberの出番になります。
—
2. Fiberの本質：Zend VMのコールスタックを「手動で握る」
PHPのFiberは、いわゆる「グリーン スレッド（ユーザーランド・スレッド）」です。C言語レベルのOSスレッドとは異なり、PHPのスクリプト実行コンテキスト（コールスタック、シンボルテーブル、実行ポインタ）をオブジェクトとしてPHPの空間に閉じ込めたものです。
Fiberの真骨頂は、「コードの任意の場所で実行を一時停止（Suspend）し、外側の世界（イベントループ）に制御を委譲し、後で再開（Resume）できる」という点にあります。
高頻度ポーリングにおいて、Fiberを使う目的は「マルチスレッドによる高速化」ではありません。「重いポーリングループを細切れにし、他のタスクにCPUを明け渡しながら、必要な時だけ賢く目を覚ますこと」です。
—
3. 実装：Fiberとイベントループによるスマート・ポーリング
では、実際にCPU使用率を極限まで抑制しつつ、ミリ秒単位の精度で状態を監視するポーリング機構を実装してみましょう。
ここでは、外部リソースのモックを監視するシナリオを想定します。
/
class PollingManager
{
private array $fibers = [];
/
- 監視タスクをFiberとして登録する
/
public function addTask(int $id, callable $conditionChecker, callable $onSuccess, int $intervalMs = 100): void
{
$fiber = new Fiber(function () use ($id, $conditionChecker, $onSuccess, $intervalMs) {
$attempts = 0;
$maxAttempts = 50; // 最大試行回数
while ($attempts < $maxAttempts) {
$attempts++;
// 1. 条件をチェックする
if ($conditionChecker($id)) {
$onSuccess($id, $attempts);
return; // 完了したらFiber終了
}
// 2. まだ完了していなければ、一度処理を中断（Suspend）し、
// イベントループ側に「○ミリ秒後にまた起こしてね」と伝える
// ここでCPUの占有を完全に手放します。
Fiber::suspend($intervalMs);
}
throw new RuntimeException("タスク ID: {$id} がタイムアウトしました。");
});
$this->fibers[] = [
‘fiber’ => $fiber,
‘next_run’ => microtime(true), // すぐに実行可能
‘interval’ => $intervalMs / 1000.0 // 秒単位に変換
];
}
/
- ミニマムなイベントループで全Fiberを調停・実行する
/
public function run(): void
{
while (!empty($this->fibers)) {
$now = microtime(true);
foreach ($this->fibers as $index => $task) {
/ @var Fiber $fiber /
$fiber = $task[‘fiber’];
// まだ再開タイミングに達していなければスキップ
if ($now < $task['next_run']) {
continue;
}
// Fiberが完全に終了しているかチェック
if ($fiber->isTerminated()) {
unset($this->fibers[$index]);
continue;
}
try {
// 初回スタート、またはサスペンドからの復帰
if (! $fiber->isStarted()) {
$intervalMs = $fiber->start();
} else {
// suspend() に渡された値（ミリ秒）を受け取る
$intervalMs = $fiber->resume();
}
// 次回実行すべき時刻を計算（タイマーのスケジュール）
if (!$fiber->isTerminated()) {
$this->fibers[$index][‘next_run’] = microtime(true) + ($intervalMs / 1000.0);
}
} catch (Throwable $e) {
// 例外処理（ログ出力やタスクの破棄）
echo “エラー発生: ” . $e->getMessage() . “\n”;
unset($this->fibers[$index]);
}
}
// CPUを焼き付けないための極小のインターバル（OSへの配慮）
// これにより、アクティブなタスクがない瞬間のCPU空回りを完全に防ぎます。
usleep(1000);
// 配列のインデックスを再整理
$this->fibers = array_values($this->fibers);
}
}
}
// — 実行・検証のシミュレーション —
$manager = new PollingManager();
// モック用の外部状態リポジトリ
$mockDatabase = [
101 => false,
102 => false,
];
// バックグラウンドで状態を変化させるタイマーの代わり（簡易的）
// 実際には別プロセスやAPIレスポンス、データベースの更新などを想定してください
$checker = function(int $id) use (&$mockDatabase) {
// 3回目くらいのポーリングで「true（完了）」になると仮定
static $counters = [];
$counters[$id] = ($counters[$id] ?? 0) + 1;
if ($counters[$id] >= 3) {
$mockDatabase[$id] = true;
}
echo “[ポーリング中] タスク ID: {$id} の状態を確認中… (試行: {$counters[$id]})\n”;
return $mockDatabase[$id];
};
// タスクを2つ登録（異なる間隔でポーリング）
$manager->addTask(101, $checker, function($id, $attempts) {
echo “=> 【成功】タスク 101 が完了しました！ (試行回数: {$attempts})\n”;
}, 200); // 200ms間隔
$manager->addTask(102, $checker, function($id, $attempts) {
echo “=> 【成功】タスク 102 が完了しました！ (試行回数: {$attempts})\n”;
}, 500); // 500ms間隔
// イベントループ開始
$startTime = microtime(true);
$manager->run();
$endTime = microtime(true);
echo “全処理完了にかかった時間: ” . round($endTime – $startTime, 4) . ” 秒\n”;
—
4. アーキテクトが解説する：このコードが優れている理由
上記のコードを眺めて、「おっ」と気づいたあなたは鋭い。このアプローチには、Zend VMとリソース管理の観点から明確な優位性があります。
1. イベントループによる「能動的スリープ」
従来のコードであれば、タスクごとに独立したループを回してCPUを占有していましたが、この実装では1つの親ループ（`PollingManager::run()`）がすべてのFiberのスケジュールを管理しています。次の実行タイミングまで余裕があるFiberは完全に無視され、ループは無駄な演算を行いません。
2. メモリ消費の極小化
PHPのFiberはオブジェクトであり、生成時のメモリオーバーヘッドは数キロバイト程度に抑えられています。数千、数万の同時接続を抱えるNode.jsのイベントエミッタに比べても、PHPのメモリ管理（ZMM: Zend Memory Manager）の恩恵を受けながら、非常にコンパクトにコンテキストを保持できます。
3. コールスタックの美しさ
例外が発生した際、Fiber内部で起きたエラーは通常のPHPの例外としてキャッチできます。非同期処理特有の「エラーがどこで起きたか分からない（コールスタックの消失）」という現象が起きにくく、デバッグが極めて容易です。
—
5. さらなる高みへ：実際のプロダクションでの注意点
もし、これを実際のプロダクション環境（Swoole, ReactPHP, あるいは純粋なCLIスクリプト）に持ち込む場合、以下のポイントを心に留めておいてください。
- I/Oブロッキングとの共存
今回紹介したのは「協調的な疑似イベントループ」ですが、もし条件チェック（`$conditionChecker`）の中で、ブロッキングな外部HTTPリクエスト（素の `file_get_contents` や同期的な `PDO` 接続など）を叩いてしまうと、その瞬間にプロセス全体が凍りつきます。プロダクションでは、ここを非同期I/O（CurlMultiやSwooleのコルーチンなど）と組み合わせることで、真の非同期モンスターシステムが完成します。
- メモリリークの防止
長期稼働するCLIプロセスでFiberを大量に生成・破棄する場合、循環参照やクロージャー内での巨大な変数のキャプチャ（変数のスコープ汚染）に注意してください。使い終わったFiberオブジェクトは速やかに参照を断ち切り、Zend Memory Managerに回収させることが鉄則です。
—
おわりに
PHPにおけるFiberの導入は、単に「トレンドの機能が入った」という話ではありません。私たちが長年諦めかけていた「PHPによる効率的な並行処理・イベント駆動設計」の扉をこじ開けた、歴史的なパラダイムシフトです。
「PHPだからポーリングは重い」という古い常識は、もう過去のもの。
Zendエンジンの挙動を深く理解し、Fiberのコンテキストスイッチを手の内でコントロールできるようになれば、あなたの書くPHPコードは、驚くほど軽快で、エレガントなシステムへと生まれ変わります。
さあ、次のデプロイでは、この極上の非同期ポーリングをあなたのプロダクトに組み込んでみませんか？
裏側で美しく調停されるCPUの波形を見るたび、きっとエンジニアとしての悦びを感じられるはずです。