【実務・中級編】PHP 8.x Fiberにおけるスレッドセーフティと共有リソースへのアクセス制御 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

PHP 8.x Fiberにおけるスレッドセーフティの幻影と、非同期協調動作における「見えない競合」の制圧

コードレビューの最中、ジュニアやミドルクラスのエンジニアからこんな質問をよく受ける。
「PHP 8で導入されたFiberを使えば、Node.jsやGoのように非同期処理でスレッドセーフな並行処理が書けますよね？」

私はその場で手を止め、静かにコードを閉じる。
――この瞬間こそ、PHPの実行モデルの本質を説き明かすべき最も重要なタイミングだ。

PHP 8.xにおける`Fiber`（ファイバー）は、スタックフルな協調的（Cooperative）マルチタスクを実現する強力なプリミティブである。しかし、Fiberはスレッドではない。OSスレッドを増やすわけでもなければ、Zendエンジンがプリエンプティブ（先占的）にコンテキストスイッチを行うわけでもない。

単一のOSスレッド（および単一のZend VMプロセス）のコンテキスト内で、実行のスタックを切り替えているに過ぎない。つまり、CPUコアレベルでの真の並列実行（Parallel）ではなく、I/O待ちなどを効率的にいなすための並行（Concurrent）実行である。

では、なぜ「スレッドセーフティ」や「共有リソースの競合」という問題が、単一スレッドのPHPで議論されなければならないのか？
答えはシンプルだ。「協調的マルチタスク特有の割り込みポイント」が存在するからだ。今回は、Zend VMのメモリ管理とイベントループの狭間で何が起きているのか、そして実務で踏み抜くべき地雷をどう回避するかを徹底的に解説しよう。

—

1. なぜ単一スレッドのFiberで「競合状態（Race Condition）」が起きるのか

C言語やJavaにおけるマルチスレッドプログラミングでは、複数コアが同時に同一メモリ領域（HashTableやZval）へ書き込むことでデータ破損が起きる。これはハードウェアレベルの排他制御（Mutexなど）で防ぐ。

一方、PHPのFiberは単一スレッド上で動く。そのため、「CPUコアが同時に同じ変数を書き換える」物理的な競合は起きない。しかし、「ロジカルな競合（Logical Race Condition）」が確実に発生する。

協調的マルチタスクにおける「サスペンドの罠」

Fiberは、任意の場所で`Fiber::suspend()`を呼び出すことで実行を一時停止し、呼び出し元（イベントループやスケジューラ）に制御を返す。

ここでエンジニアが陥る最大の勘違いがこれだ：
> 「`suspend()`するまでの間は同期処理なのだから、途中で他のFiberが割り込んで変数を書き換えることはないだろう」

大間違いだ。

もしあなたがイベントループ（ReactPHPやAmp、あるいは自製のイベントディスパッチ）上で複数のFiberを走らせており、あるFiberが外部APIのレスポンス待ち（I/Oブロック）の間に`suspend()`したとする。その瞬間、イベントループは別のFiberを再開（resume）させる。

もし、これら複数のFiberが同一の「グローバルな状態（シングルトンインスタンスのプロパティ、静的変数、あるいはデータベースのコネクションプール状のステータス）」にアクセスしていたらどうなるか？

[Fiber A] –(DBクエリ発行)–> suspend()
│
▼
[イベントループが介入]
│
▼
[Fiber B] ───────────────────> resume() (同じグローバルステータスを上書き！)
│
▼
[Fiber A] <─── resume() ── (自分が書き込んだつもりなのに、Bに書き換えられていた！) Zend VMのメモリ空間上では安全であっても、ビジネスロジックのコンテキストが意図せず破壊される。これが、PHP 8.xのFiber環境における最大の罠である。

—

2. 実務で耐えうる「アトミックな状態管理」の設計パターン

では、このロジカルな競合を防ぐにはどうすればよいか？
答えは、「状態の局所化（Immutability / Encapsulation）」と、Fiberコンテキストをまたぐ処理における「排他ロック機構（Mutex pattern）」の明示的な実装である。

以下に、実務のAPIサーバーやバッチ処理基盤においてそのまま流用できる、Fiberセーフなロック機構と排他制御を備えたコンテキストマネージャの実装コードを示す。

コピペで使える実用リファレンスコード

Fiber環境における協調的排他制御（Mutex）クラス

PHPの単一スレッドモデルにおいて、Fiber間のロジカルな競合を防ぐため、

クリティカルセクション（排他制御領域）への同時侵入を直列化する。

/
class FiberMutex
{
private bool $isLocked = false;

/ @var \SplQueue<\Fiber> 占有権を待機しているFiberのキュー /
private \SplQueue \Queue;

public function __construct()
{
$this->Queue = new \SplQueue();
}

クリティカルセクションに入るための非同期ロック取得
すでに他のFiberがロック中の場合、現在のFiberはここでsuspendし、
ロックが解放されるまで待機キューに積まれる。

/
public function acquire(): void
{
$currentFiber = \Fiber::getCurrent();

if ($currentFiber === null) {
// Fiberコンテキスト外からの呼び出しは単にスルー（通常同期実行）
return;
}

while ($this->isLocked) {
// 既にロックされている場合はキューに積んでサスペンド
$this->Queue->enqueue($currentFiber);
\Fiber::suspend();
}

// ロックを獲得
$this->isLocked = true;
}

ロックの解放と、待機中の次のFiberへのコンテキスト委譲

/
public function release(): void
{
$currentFiber = \Fiber::getCurrent();
if ($currentFiber === null) {
return;
}

$this->isLocked = false;

// 待機しているFiberがあれば、先頭のものを再開（resume）させる
if (!$this->Queue->isEmpty()) {
/ @var \Fiber $nextFiber /
$nextFiber = $this->Queue->dequeue();
// イベントループのスケジュールに載せるためのトリガー
// ※実際のイベントループ実装に合わせてコールバック等に置き換える場合があります
if (!$nextFiber->isTerminated()) {
$nextFiber->resume();
}
}
}

クリティカルセクションを安全に実行するための高階関数ラッパー
@template T
@param callable(): T $callback
@return T

/
public function synchro(callable $callback): mixed
{
$this->acquire();
try {
return $callback();
} finally {
$this->release();
}
}
}

この設計が堅牢である理由（コードレビューの視点）

1. `finally`ブロックによるデッドロック防止:
`synchro()`メソッド内で万が一例外（`Exception`や`Error`）が発生した場合でも、確実に`release()`が呼ばれ、ロックが解放される構造になっている。これを怠ると、待機キューにいるすべてのFiberが永遠に目を覚まさない（デッドロック状態）に陥る。
2. `\SplQueue`による公平な待機制御:
PHPの標準機能である`SplQueue`を用いることで、先着順（FIFO）でFiberを復帰させる。メモリ効率も高く、余計なオーバヘッドを生まない。
3. Zend VMのメモリ空間を汚さない:
グローバル変数やstatic変数を直接いじるのではなく、MutexオブジェクトをDI（依存性注入）等で共有することで、スコープが明確になり、テスト容易性（Testability）が劇的に向上する。

—

3. 実践：共有リソース（カウンター・キャッシュ）へのアクセス制御

上記のMutexを使った具体的な使用例を見てみよう。
複数のFiberが同時にインメモリのキャッシュストアやカウンターをインクリメントするシナリオを想定する。

mutex = new FiberMutex();
}

危険なインクリメント（競合状態が発生しうる例）
途中で suspend() が入ると、値が巻き戻る可能性がある。

/
public function unsafeIncrement(): int
{
$current = $this->counter;

// 擬似的なI/O待ち（APIリクエストやDB問い合わせをシミュレート）
if (\Fiber::getCurrent() !== null) {
\Fiber::suspend(); // ここで別のFiberが動く！
}

$this->counter = $current + 1;
return $this->counter;
}

安全なインクリメント（Mutexで保護された例）

/
public function safeIncrement(): int
{
return $this->mutex->synchro(function() {
$current = $this->counter;

// 擬似的なI/O待ち
if (\Fiber::getCurrent() !== null) {
// この区間は他のFiberは入れないため、
// suspendしても安全にアトミック性が保たれる（※実務ではI/O中はロックを外す設計が望ましい）
}

return $this->counter = $current + 1;
});
}

public function getCounter(): int
{
return $this->counter;
}
}

// — 実行シミュレーション —
$service = new SharedCounterService();

$fiber1 = new \Fiber(function() use ($service) {
echo “Fiber 1 開始\n”;
$service->safeIncrement();
echo “Fiber 1 終了\n”;
});

$fiber2 = new \Fiber(function() use ($service) {
echo “Fiber 2 開始\n”;
$service->safeIncrement();
echo “Fiber 2 終了\n”;
});

// イベントループの簡易エミュレーション
$fiber1->start();
$fiber2->start();

// 終了まで回す
while (!$fiber1->isTerminated() || !$fiber2->isTerminated()) {
if (!$fiber1->isTerminated() && $fiber1->isSuspended()) {
// 必要に応じて再開
}
}

echo “最終カウンター値: ” . $service->getCounter() . “\n”;

—

4. チーフアーキテクトからの最終提言

PHP 8.xのFiberは、これまでのPHPアプリケーションの限界を突破する素晴らしい機能だ。しかし、「手軽に非同期っぽく書けるから」という理由で、安易にグローバルな状態やフレームワークのコンテナ（LaravelのService Containerなど）を複数のFiber間で共有すると、デバッグが極めて困難なロジカルバグ（幽霊バグ）の温床となる。

システムを設計・レビューする際は、以下の鉄則をチームメンバーに叩き込んでほしい。

1. Fiberはスレッドではない。物理的なハードウェア競合は起きないが、「協調的割り込みによるロジカルな競合」は常に隣り合わせである。
2. 状態（State）を持つサービスは、極力リクエストスコープまたはFiberスコープで完全に分離し、共有すべきリソースには必ず本稿で示したような明示的な排他制御（Mutex）を挟め。
3. 非同期I/Oの最中に何が書き換わっているのか、Zend VMのメモリ空間と実行フローのタイムラインを常に脳内でトレースできるエンジニアであれ。

PHPの未来は、ただコードを書くだけの時代から、エンジニア自身がメモリと実行コンテキストを完全に「掌握」する時代へとシフトしている。その最前線に立つあなたにとって、この記事が羅針盤となれば幸いだ。