こんにちは。普段、他の高水準な言語（GoやNode.js、Javaなど）でバリバリと非同期処理やイベント駆動のアーキテクチャを設計しているあなたなら、PHPの「常駐型アプリケーション（SwooleやRoadRunner）」の世界に足を踏み入れたとき、ある強烈な違和感を覚えたはずです。
「――あれ、リクエストを跨いでも、staticプロパティの値が消えない……？」
そう、これこそが、従来の「リクエストごとにプロセスが破棄される（シェアード・ナッシング）」というPHPの常識を根底から覆す、常駐型アプリケーションの現実です。さらにそこに Fiber（ファイバー） による協調的マルチタスク（緑の糸）が加わると、状態管理の難易度は一気に跳ね上がります。
今回は、PHPの内部エンジン（Zend VM）とメモリ空間の挙動にまで踏み込みながら、Fiberと常駐型環境が交錯する世界で「状態汚染（State Pollution）」を完璧に防ぐための設計戦略を、一緒に紐解いていきましょう。ここをクリアできれば、PHPは驚異的なスループットを叩き出す最強の非同期ランタイムに変貌しますよ。
—
1. なぜ「静的プロパティ」と「グローバル変数」が魔窟と化すのか
まず、PHPの実行モデルの根底を整理しておきましょう。
従来のPHP-FPM環境では、1つのHTTPリクエストが来ると、OSプロセス（またはスレッド）が立ち上がり、Zendエンジンが初期化され、スクリプトが実行され、レスポンスを返した瞬間に すべてのメモリが解放（ゼロクリア） されます。そのため、`static` 変数やグローバル空間 (`$GLOBALS`) は、そのリクエストのライフサイクル内だけで完結する「使い捨てのキャッシュ」として安全に使えました。
しかし、SwooleやRoadRunnerといった常駐型ランタイムでは話が全く異なります。
[Master Process]
└── [Worker Process (長寿命)]
├── リクエストA ──► Fiber 1 ┐
├── リクエストB ──► Fiber 2 ┼── 同一の Zend VM メモリ空間・シンボルテーブルを共有！
└── リクエストC ──► Fiber 3 ┘
プロセスは一度起動したら死にません。メモリ上に展開されたクラス定義、関数、そして `static` プロパティは、プロセスが生存している限りずっと残り続けます。
ここにFiber（PHP 8.1で導入されたスタックレスに近い協調型コルーチン）が組み合わさると、さらに事態は複雑化します。Fiberは「同一スレッド（同一プロセス）」内で実行コンテキストを切り替えます。つまり、複数の非同期リクエストが、同じプロセスの、同じクラスの、同じ静的プロパティを同時に読み書きする という状況が生まれるのです。
これは、マルチスレッドプログラミングにおける最悪のアンチパターン、「データ競合（Data Race）による状態汚染」そのものですよね。
—
2. 実際のコードで見る「状態汚染」の恐怖
百聞は一見にしかず。典型的なアンチパターンをコードで見てみましょう。認証情報を保持するつもりで、うっかり `static` プロパティを使ってしまったケースです。
ユーザーA のリクエスト（Fiber A）が来て、`RequestContext::setUserId(‘user_A_123’)` が呼ばれる。
2. 処理の途中で、I/待ち（DBクエリや外部APIコールなど）が発生し、Fiber Aは一旦サスペンド（中断）する。
3. その隙に、ユーザーB のリクエスト（Fiber B）が飛び込んできて、`RequestContext::setUserId(‘user_B_999’)` が上書き実行される。
4. Fiber Aがレジューム（再開）し、`RequestContext::getUserId()` を呼び出すと……返ってくるのはなんと `user_B_999`！
――恐ろしいことに、ユーザーAの画面にユーザーBの機密データが表示されるという、致命的なセキュリティインシデント（クロス・リクエスト汚染）が簡単に引き起こされてしまいます。
—
3. 解決策：Zend VMのコンテキストと「Fiber-Local」の概念
では、この問題をどう解決すべきでしょうか。
答えはシンプルです。「グローバルや静的に頼らず、現在の実行コンテキスト（Fiberやリクエスト）に紐づいたスコープに状態を閉じ込める」ことです。
Javaの `ThreadLocal` ならぬ、`FiberLocal`（ファイバー・ローカル・ストレージ） という設計パターンをPHPで実装してみましょう。
PHP 8.1以降のFiberクラスや非同期フレームワークが提供するイベントループの仕組みを使い、「現在実行中のFiberを一意に識別するID」をキーにして、データを安全に分離・管理するアプローチです。
実装パターン：コンテキストマネージャーの構築
> /
private static array $storage = [];
/
- 現在のFiber（またはメインスレッド）の識別子を取得する
/
private static function getCurrentKey(): int|string
{
$fiber = Fiber::getCurrent();
// Fiberの外（メインスコープ）であれば ‘main’、Fiber内であればそのオブジェクトのハッシュまたはID
return $fiber ? spl_object_id($fiber) : ‘main’;
}
public static function set(string $key, mixed $value): void
{
$fiberKey = self::getCurrentKey();
self::$storage[$fiberKey][$key] = $value;
}
public static function get(string $key, mixed $default = null): mixed
{
$fiberKey = self::getCurrentKey();
return self::$storage[$fiberKey][$key] ?? $default;
}
/
- リクエストやFiberの終了時に、必ずメモリリークを防ぐために呼ぶこと！
/
public static function destroy(): void
{
$fiberKey = self::getCurrentKey();
unset(self::$storage[$fiberKey]);
}
}
この `FiberContext` を使えば、先ほどの危険な `RequestContext` は安全に書き換えることができます。
4. アーキテクトが教える、実装上の絶対的な鉄則
ここまで読んで、「なるほど、`FiberContext` を作れば万全だな」と思ったあなた。ちょっと待ってください。常駐型PHPアプリケーションを本番運用するにあたり、もう一つ絶対に忘れてはならない致命的な罠があります。
それが 「メモリリーク（Memory Leak）」 です。
PHP-FPMであれば、リクエストが終わればプロセスごとメモリが全開放されるため、クリーンアップをサボってもOSが掃除してくれました。しかし、常駐型プロセスでは、ストレージにデータを入れっぱなしにすると、Fiberが終了しても配列（`self::$storage`）の中にデータが残り続け、プロセスが肥大化してやがてOOM（Out of Memory）でクラッシュします。
これを防ぐための作法がこちらです。
1. try-finally 構文による確実なクリーンアップ
フレームワークのエントリポイント、またはミドルウェアのライフサイクルにおいて、必ず `finally` 節で `FiberContext::destroy()` を呼び出す構造を強制してください。
// ミドルウェアやイベントループのハンドラ内
$fiberKey = Fiber::getCurrent();
try {
// リクエスト処理の実行
$response = $handler->handle($request);
return $response;
} finally {
// 成功しようが例外落ちしようが、絶対に実行してスコープを消去する
\App\Concurrency\FiberContext::destroy();
}
2. 依存性注入（DI）コンテナのスコープ管理を活用する
自前で静的なストレージを書くのも良いですが、Swoole対応のモダンなフレームワーク（Laravel Octane, Hyperf, Workermanなど）の多くは、リクエストスコープやコルーチンスコープを持ったDIコンテナを提供しています。
可能な限りフレームワーク側のスコープ機能（`app()->scoped(…)` など）に依存し、オブジェクトのライフサイクル管理をフレームワークに委譲するのが最も安全で保守性の高い選択肢です。
—
まとめ：PHPの裏側を掌握し、モダンな非同期アーキテクチャへ
いかがでしたでしょうか？
「PHPは遅い」「状態管理が適当でも動く」というのは、もはや昔の話です。SwooleやRoadRunner、そしてFiberを駆使した現代のPHPは、他のどの言語にも劣らない爆発的なパフォーマンスを叩き出します。
その裏側で何が起きているのか――Zend VMがメモリをどう保持し、プロセスとFiberがどう共存しているのか。そのメカニズムさえ見えていれば、グローバル変数や静的プロパティの恐怖に怯える必要はもうありません。
「メモリのライフサイクルを制する者が、常駐型PHPを制する」。
ぜひ、次のアーキテクチャ設計にこの知見を活かしてみてください。あなたの書くPHPコードが、より美しく、ロバストなものになることを心から応援しています。