Beware that only existing files can be invalidated.
Instead of removing a file from opcache that you have delete, you need to call opcache_invalidate before deleting it.
opcache_invalidate
(PHP 5 >= 5.5.0, PHP 7, PHP 8, PECL ZendOpcache >= 7.0.0)
opcache_invalidate — キャッシュされたスクリプトを無効にする
説明
この関数は opcode キャッシュのうち、特定のスクリプトを無効にします。
force パラメータが指定されていないか、 false の場合は、スクリプトの更新時刻が opcode キャッシュ時の更新時刻より新しい場合にだけ無効にします。
この関数は、インメモリキャッシュ の情報だけを無効にします。
ファイルキャッシュ の情報は無効にしません。
パラメータ
-
filename -
無効にしたいスクリプトのパス
-
force -
trueにすると、無効にする必要があるかどうかに関わらずスクリプトは無効にされます。
戻り値
filename の opcode キャッシュが無効にされたか、無効にする対象が存在しない場合は true を返します。
opcode キャッシュ機能そのものが無効にされている場合は false を返します。
add a note
User Contributed Notes 3 notes
joel at taotesting dot com ¶
9 years ago
dmitry dot balabka at gmail dot com ¶
5 years ago
opcache_invalidate tries to acquire SHM lock. When the lock can not be acquired opcache_invalidate will return FALSE. During multiple concurrent opcache_invalidate calls with higher probability, the function will return FALSE.
kaare at colourbox dot com ¶
8 years ago
Note that invalidation doesn't actually evict anything from the cache, it just forces a recompile. You can verify this by calling opcache_get_status() and seeing that the invalidated script is not actually removed from "scripts". This means it cannot be used as a more graceful alternative to opcache_reset() when the cache is full ("cache_full":true in status). The cache will eventually fill up and refuse to cache new requests if you do atomic deployment of PHP code by changing the web server's document root. It appears opcache_reset() is the only way to prevent this, but opcache_reset() can disable the cache for any amount of time while attempting to restart, causing load spikes.
