こんにちは。プロダクション環境のデプロイで「あれ、キャッシュが残って古いコードが動いているぞ…」と冷や汗をかいた経験はありませんか？
他の言語、例えばNode.jsやGo、あるいはJavaの世界では、アプリケーションは常駐する単一のプロセス（あるいは軽量スレッド）としてメモリ空間を維持します。しかし、PHP（PHP-FPM）の伝統的かつ強力なモデルは、「1リクエストごとに独立したプロセスが動き、終了時にすべてのメモリを解放する」という徹底したリソース隔離の思想に基づいています。
この思想は「メモリリークがリクエストを跨いで蓄積しない」という圧倒的な堅牢性を生む一方で、「毎回スクリプトをパースしてコンパイルしていたら、Webの速度として間に合わない」という深刻なジレンマを抱えていました。それを解決するのが、Zend VMの心臓部であるOPcacheです。
今回は、複数立ち並ぶPHP-FPMワーカーたちが、どうやって共有メモリ（Shared Memory）上のOPcacheを安全に、そして極限まで高速に共有しているのか。その裏側にあるロックフリーな世界と、デプロイ時のアトミックな真実を、一緒に紐解いていきましょう。ここを理解すると、PHPの裏側が美しいひとつの巨大なシステムとして見えてきますよ。
—
1. そもそもOPcacheは何をキャッシュしているのか？
私たちが書いたPHPのコード（`.php`ファイル）は、Webサーバー（Nginx + PHP-FPM）にリクエストが届いた瞬間、以下のステップを踏んで実行されます。
1. Lexical Analysis（字句解析）: コードをトークンに分解する。
2. Parsing（構文解析）: AST（抽象構文木）を構築する。
3. Compilation（コンパイル）: ASTをZend VMが理解できるOpcode（オペコード）に変換する。
4. Execution（実行）: Zend Engineの仮想マシンがOpcodeを評価する。
通常、この1〜3のステップはリクエストごとに発生します。数千行のフレームワークを毎回パースしていたのではCPUがいくらあっても足りません。
OPcacheは、この「コンパイル済みのOpcode配列（および関数・クラスのシンボルテーブル）」を、PHP-FPMの親プロセスが起動時に確保する巨大な共有メモリ領域（Shared Memory: SHM）に丸ごと載せる仕組みです。FPMの子ワーカー（子プロセス）たちは、forkによって親プロセスのメモリ空間の多くをコピー（Copy-on-Write）しつつ、このOPcache領域に関しては同一の共有メモリをアタッチして直接参照します。
つまり、どのワーカーにリクエストが当たっても、パース済みのOpcodeをノーコストで即座にZend VMへ流し込めるというわけです。
—
2. マルチプロセス環境における「同期」とロックフリーの幻想
さて、ここでアーキテクトとして最もシビれるポイント、そしてトラブルの温床になりやすい領域に踏み込みましょう。
「複数のPHP-FPMワーカーが、同時に同じ共有メモリ上のOpcodeを読み書きする」とき、何が起きているでしょうか？
読み込み（Read）は、実質「ロックフリー」
結論から言うと、通常のスクリプト実行時、ワーカーは共有メモリ上のOpcode構造体をロックなし（Lock-free）で読み込んでいます。CPUのキャッシュコヒーレンシとメモリの不可分性（Atomicなポインタ参照）が担保されているため、複数プロセスが同時に同じOpcode配列を読んでクラッシュすることは基本的にありません。この「排他制御のオーバーヘッドがゼロ」という設計こそが、PHP-FPM + OPcacheが驚異的なスループットを叩き出す最大の理由です。
書き込み（Write）とキャッシュ無効化のジレンマ
問題は、「ソースコードが修正されたとき（あるいはデプロイされたとき）」です。
あるワーカーがリクエストを処理している最中に、別のワーカーが「おっと、ソースコードが書き換わっているから、OPcacheの該当エントリを新しいOpcodeにコンパイルし直して共有メモリに上書きしなきゃ！」となったとします。
もしここで何の保護もなしに書き込みを行うと、他のワーカーが「まさに今まさに書き換えられようとしている不完全なメモリ構造（壊れたポインタや途中まで書き込まれた構造体）」を読み取ってしまい、Segmentation Fault（セグフォ）を起こしてワーカーが即死します。
OPcacheはこの競合を防ぐため、内部で巧妙な排他制御を行っています。
- グローバルロック（Exclusive Lock）: 新しいスクリプトのコンパイルや、共有メモリのハッシュテーブルへのエントリ追加・削除の際には、セマフォ（Semaphore）等を用いた排他ロックが取得されます。
- 読込はノンブロック: あくまで「書き込み・更新」時のみロックが必要であり、通常の「実行」はロックの影響を受けずに走り続けます。
—
3. デプロイ時の罠：なぜ「古いコード」が動き続けるのか？
モダンなCI/CDパイプラインにおいて、Git経由でソースコードをデプロイした瞬間、次のような設定（`php.ini`）に直面したことはありませんか？
[opcache]
; プロダクション環境での推奨設定
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 2
ここで注目すべきは `opcache.validate_timestamps = 1` と `opcache.revalidate_freq = 2` です。
タイムスタンプ検証のコストとタイムラグ
`validate_timestamps = 1` にしている場合、Zend VMはスクリプトを実行する前に「おや、このファイルの最終更新日時は、前回キャッシュしたときより新しくなっているかな？」と`stat()`システムコールを発行してファイルシステムに問い合わせます。
- `revalidate_freq = 2` の意味: 「毎回`stat()`を呼ぶのはディスクI/Oのボトルネックになるから、最低でも2秒間は前回のキャッシュ結果を信じて、ファイルシステムを見に行かないでおこう」というスロットル機構です。
ここにデプロイ時の落とし穴があります。
デプロイが完了したまさにその瞬間、ロードバランサーが新しいリクエストを転送してきても、FPMワーカーは設定された秒数（例: 2秒間）、あるいは次のアクセスがあるまで古いタイムスタンプをキャッシュし続け、古いOpcodeを実行し続けます。これが「デプロイ直後になぜか古い画面が出る」現象の正体です。
プロダクション環境の最適解：`validate_timestamps = 0` と明示的クリア
真に洗練された高負荷Webシステムでは、パフォーマンスの極限を追求するために `opcache.validate_timestamps = 0` に設定します。これにより、ファイルシステムの`stat()`呼び出しを完全に排除し、CPUキャッシュヒット率を限界まで高めます。
ただし、これをやるとファイル群を書き換えてもOPcacheが永遠に更新されなくなります。そのため、デプロイメントのスクリプト（GitHub ActionsやDeployerなど）の最後に、アトミックにキャッシュをクリアするフックを必ず組み込む必要があります。
/
if (function_exists(‘opcache_reset’)) {
// 共有メモリ上のすべてのOpcodeキャッシュを無効化し、次回リクエストで再コンパイルを強制する
$result = opcache_reset();
if ($result) {
echo “OPcacheの共有メモリが正常にリセットされました。\n”;
} else {
echo “警告: OPcacheのリセットに失敗しました。\n”;
}
} else {
echo “OPcache拡張モジュールが有効ではありません。\n”;
}
※注意: `opcache_reset()` は共有メモリのハッシュテーブルをクリアするため、実行直後の数リクエストで微小なコンパイル負荷（Warm-up）が発生しますが、数秒でウォームアップされ、再び超高速なロックフリーの世界に戻ります。
—
4. OPcache File Cacheという「もう一つの切り札」
共有メモリ（Shared Memory）は非常に高速ですが、弱点もあります。それは「サーバーの再起動（OS再起動やPHP-FPMのフルリスタート）時に、メモリの内容が揮発して消える」という点です。
コールドスタート直後の最初のリクエストを踏んだユーザーは、全ファイルのコンパイルが終わるまで数ミリ秒〜数十ミリ秒待たされることになります（スレッド・キャッシュ・ウォーミングが必要な理由です）。
この弱点を補うために用意されたのが、OPcache File Cache です。
[opcache]
; コンパイル済みOpcodeをディスク上のバイナリとして永続化する
opcache.file_cache = “/var/cache/php/opcache”
File Cacheの裏側の挙動
この機能を有様にすると、Zend VMは共有メモリにOpcodeを展開するだけでなく、コンパイル結果をシリアライズして指定されたディレクトリにバイナリファイルとして書き出します。
次回サーバーが再起動した際、PHPはファイルシステム上のソースコード（`.php`）をわざわざパース・コンパイルし直すことなく、ディスク上の最適化済みOpcodeバイナリを直接メモリにロードします。これにより、コールドスタート時のレイテンシを劇的に短縮することが可能です。
ただし、マルチプロセス・マルチサーバー環境（コンテナ群など）では、共有ストレージ（NFSなど）にFile Cacheを置くとファイルロックの競合でパフォーマンスが破綻するため、各コンテナのローカルな一時領域（`/tmp` や専用の高速NVMeストレージ）に配置するのがアーキテクチャ上の鉄則となります。
—
5. まとめ：PHPの裏側を掌握する者
PHPは「スクリプト言語だから遅い」というのは、もう何年も前の神話に過ぎません。Zend VMとOPcacheが織りなすメモリ管理とロックフリーの実行メカニズムは、適切にチューニングされれば、コンパイル言語に匹敵するスループットを叩き出します。
- 共有メモリ（SHM）は、FPMのマルチプロセス群がゼロコピーに近い状態でOpcodeを共有するための神殿。
- 読み込みはロックフリーで極限まで高速に。
- 書き込みとデプロイの特性を理解し、`validate_timestamps` や明示的な `opcache_reset()` をコントロールする。
ここを理解したあなたなら、もうデプロイ時のキャッシュ迷子になることはありません。PHPのエンジンが内部でどう息をしているかを感じ取りながら、美しくスケーラブルなWebシステムを設計していってくださいね。