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.
(PHP 5 >= 5.5.0, PHP 7, PHP 8, PECL ZendOpcache >= 7.0.0)
opcache_invalidate — 废除脚本缓存
$script
, boolean $force = false
) : boolean
该函数的作用是使得指定脚本的字节码缓存失效。
如果 force 没有设置或者传入的是 false，那么只有当脚本的修改时间
比对应字节码的时间更新，脚本的缓存才会失效。
script缓存需要被作废对应的脚本路径
force
如果该参数设置为true，那么不管是否必要，该脚本的缓存都将被废除。
如果脚本的字节码缓存失效设置成功或者该脚本本来就没有缓存，则返回 true；如果字节码缓存被禁用，则返回false。
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.
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.
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.