PHP Opcache通过缓存编译后的操作码，避免重复解析编译，提升执行效率。启用后，首次请求生成Opcode并存入共享内存，后续请求直接加载缓存，跳过解析步骤。关键指标如opcache.hit_rate反映缓存命中率，理想值应达95%以上。通过phpinfo()或opcache_get_status()可查看运行状态。核心配置包括opcache.memory_consumption（建议128-256MB）、opcache.max_accelerated_files（根据文件数设定）、opcache.revalidate_freq（生产环境设60秒）等。开发环境可设revalidate_freq=0实时更新；生产环境推荐结合蓝绿部署或使用opcache_reset()在部署后清除缓存，避免重启服务中断。原子化部署通过软链接切换目录，使Opcache自动加载新版本Opcode，确保一致性。
PHP Opcache通过将PHP脚本编译后的操作码（Opcode）存储在共享内存中，显著减少了每次请求时PHP引擎重复解析和编译脚本的开销，从而大幅提升了PHP应用的执行效率。简单来说，它就像给PHP代码加了一个“快照缓存”，让服务器可以直接运行预编译好的版本，而不是每次都从头开始“翻译”。
PHP Opcache的工作原理，在我看来，是PHP性能优化中最基础也最有效的一环。它巧妙地解决了PHP作为解释型语言在每次请求时都需要重复“加载-解析-编译-执行”的固有瓶颈。
当一个PHP脚本首次被请求时，PHP引擎会执行一系列步骤：
加载文件： 从磁盘读取
.php
文件内容。词法分析（Lexing）： 将代码分解成一个个最小的单元（Token）。语法分析（Parsing）： 根据Token构建抽象语法树（AST）。编译（Compilation）： 将AST转换成PHP虚拟机可以执行的Opcode（操作码）。执行（Execution）： PHP虚拟机执行这些Opcode。
Opcache介入的正是第4步之后。在Opcode生成后，Opcache会将其存储在服务器的共享内存中。这样一来，后续对同一个脚本的请求，Opcache会先检查共享内存中是否有对应的Opcode缓存。如果存在，并且原始文件没有被修改（Opcache会通过文件时间戳等机制进行校验），那么PHP引擎就可以直接从内存中加载并执行这些预编译好的Opcode，完全跳过了前面繁重的加载、解析和编译步骤。这就像你第一次去图书馆借书，需要找书、登记，但如果下次你直接从已经借过的书架上拿走，效率自然高得多。它本质上是把CPU和磁盘I/O的压力，巧妙地转化成了内存的利用，这在现代服务器资源配置下，通常是一个非常划算的交易。
立即学习“PHP免费学习笔记（深入）”；
如何判断我的PHP应用是否正在使用Opcache，以及它的效果如何？
要确认PHP Opcache是否正在运行并评估其效果，有几种方法，我个人认为最直观且常用的就是通过
phpinfo()
输出或使用Opcache提供的内置函数。
首先，最简单的方法是在你的Web服务器上创建一个包含
<?php phpinfo();
的PHP文件，然后通过浏览器访问它。在输出页面中搜索“opcache”字段。你会看到一个专门的“Zend Opcache”部分，里面会列出Opcache的各项配置和运行时状态。这里有几个关键指标值得关注：
opcache.enable
: 如果显示为
On
，说明Opcache已启用。如果显示
Off
，那就需要检查
php.ini
配置了。
opcache.memory_consumption
: 这个会告诉你Opcache占用了多少共享内存，以及其中有多少是被实际使用的。
opcache.hit_rate
: 这是最重要的一个指标，它表示从缓存中直接获取Opcode的请求比例。一个健康的生产环境，这个值应该尽可能高，通常在95%以上才算理想。如果
hit_rate
很低，那说明Opcache可能没有发挥应有的作用，或者配置有问题。
num_cached_scripts
: 当前缓存了多少个PHP脚本。
start_time
: Opcache进程的启动时间。
除了
phpinfo()
，你也可以在代码中通过
opcache_get_status()
函数来获取更详细、程序化的状态信息。这个函数返回一个关联数组，包含了Opcache的各种统计数据，比如缓存命中次数、未命中次数、内存使用情况等。例如：
我个人觉得，
hit_rate
这个指标，比其他任何参数都更能直观地反映Opcache的“工作效率”。如果这个值不够高，那么即便Opcache开启了，它的实际价值也大打折扣。所以，在部署新应用或优化现有应用时，我都会特别关注这个数字。此外，也有一些第三方的Opcache GUI工具（比如
rlerdorf/opcache-gui
）可以提供更友好的可视化界面来监控Opcache状态，这在调试和长期监控时非常有用。
PHP Opcache的关键配置参数有哪些，我应该如何调整它们以获得最佳性能？
Opcache的配置参数直接决定了它的性能表现和资源占用。以下是一些我经常会调整的关键参数，以及我通常的考量：
opcache.enable = 1
: 这个不用多说，必须开启。
opcache.memory_consumption = 128
: 这是Opcache可以使用的共享内存大小，单位是兆字节（MB）。我的经验： 我通常会从128MB开始，对于中小型应用这通常足够了。对于大型框架（如Laravel、Symfony）或拥有大量文件的应用，可能需要256MB甚至更多。如果这个值设置得太小，Opcache会因为内存不足而频繁地将旧的Opcode踢出缓存（缓存驱逐），导致
hit_rate
下降。判断是否足够，可以观察
opcache_get_status()
中的
used_memory
和
free_memory
，确保
free_memory
不会长期处于非常低的状态。
opcache.interned_strings_buffer = 8
: 用于存储PHP内部字符串（如类名、函数名、常量名等）的内存大小，单位是MB。我的经验： 这个参数常常被忽视，但在大型应用中，它能显著减少内存开销。PHP会把一些常用的字符串进行“内部化”处理，避免重复存储。如果这个缓冲区太小，PHP会回退到普通内存分配，导致内存占用增加。我通常会设置为8MB或16MB，对于非常大的应用，可能需要更高。
opcache.max_accelerated_files = 10000
: Opcache可以缓存的最大文件数量。我的经验： 这个值应该大于你的应用中所有PHP文件的总和。如果设置得太小，新的文件可能无法被缓存，或者旧的文件会被频繁踢出。我通常会设置为10000甚至20000，因为现代应用的文件数量往往比我们想象的要多。可以通过
find . -name "*.php" | wc -l
来估算你的项目文件数量。
opcache.revalidate_freq = 60
: Opcache检查文件时间戳以判断文件是否被修改的频率（秒）。我的经验： 在生产环境，我倾向于设置一个相对较大的值，比如60秒。这意味着Opcache每60秒才检查一次文件更新。如果设置为
0
，则每次请求都会检查文件，这会带来微小的性能开销，但对于开发环境来说很方便。在生产环境，如果你的部署流程能确保代码更新后会强制刷新Opcache，那么这个值可以设得更高，甚至配合
opcache.validate_timestamps = 0
来使用。
opcache.validate_timestamps = 1
: 是否检查文件时间戳。我的经验： 默认是
1
，表示Opcache会根据
revalidate_freq
来检查文件是否被修改。如果设置为
0
，Opcache将永远不会检查文件是否被修改，除非你手动清除缓存。这能带来微小的性能提升（因为它省去了
stat
系统调用），但要求你的部署流程必须非常严谨，每次代码更新后都要通过
opcache_reset()
等方式强制刷新Opcache，否则用户将一直看到旧的代码。我通常只在非常成熟的CI/CD流程中考虑将其设为
0
。
opcache.fast_shutdown = 1
: 开启快速关机模式。我的经验： 这个通常是开启的，没什么副作用，可以提高PHP请求结束时的清理速度。
opcache.enable_cli = 0
: 是否为PHP CLI SAPI启用Opcache。我的经验： 默认是
0
。对于普通的CLI脚本，每次执行都短命且独立，开启Opcache意义不大。但对于常驻内存的CLI脚本，比如Laravel Octane、Swoole应用、或者一些长时间运行的队列消费者，开启它（设置为
1
）非常有意义，可以显著提升这些服务的性能。
调整这些参数时，没有一劳永逸的“最佳”配置，你需要根据应用的实际情况（文件数量、请求量、内存预算）进行测试和监控，逐步优化。
在部署新代码或开发过程中，我应该如何管理或清除Opcache缓存？
管理Opcache缓存，尤其是在部署新代码时，是确保用户能立即看到最新功能、避免奇怪错误的关键。不同的环境和部署策略有不同的做法。
在开发环境中，我通常会把
opcache.revalidate_freq
设为
0
，这意味着Opcache在每次请求时都会检查文件是否更新。虽然这会带来一点点性能开销，但对于开发来说，它省去了手动刷新缓存的麻烦，确保我改动代码后能立即看到效果。另一种做法是保持
opcache.revalidate_freq
为一个小值（比如1秒），并确保
opcache.validate_timestamps = 1
。
在生产环境中，管理Opcache缓存则需要更精细的策略，以确保部署的原子性和用户体验：
重启PHP-FPM服务：这是最暴力也最有效的办法。重启PHP-FPM服务会清空所有Opcache缓存。命令通常是
sudo systemctl restart php-fpm
或
sudo service php-fpm restart
。
我的看法： 这种方法简单粗暴，但对于高并发服务，它会导致短暂的服务中断，所有正在处理的请求都可能失败。因此，我通常会避免在不进行滚动更新或蓝绿部署的情况下直接重启服务。
通过
opcache_reset()
函数清除缓存：这是我最常用的方式，尤其是在蓝绿部署或滚动更新时，可以精确控制刷新时机。你可以创建一个专门的PHP脚本，例如
clear_opcache.php
：
然后，在部署完成后，通过HTTP请求访问这个脚本（确保它受到IP限制或身份验证保护），或者在CLI环境下执行它（如果
opcache.enable_cli = 1
）：
php clear_opcache.php
。
我的看法： 这种方式灵活且不会中断服务，因为它只清空了Opcache，不会影响正在运行的PHP进程。你甚至可以将其集成到你的部署脚本中，在代码切换完成后自动触发。
使用
opcache_invalidate()
清除特定文件缓存：如果你只需要清除某个或某几个文件的缓存，可以使用
opcache_invalidate($file_path, $force)
。
$force
参数如果设置为
true
，即使文件时间戳没有变化也会强制失效。
我的看法： 这种方法在需要局部更新时很有用，但对于整个应用部署来说，通常不如
opcache_reset()
来得彻底和方便。
利用版本化部署或原子化部署（Atomic Deployment）：这种部署方式本身就对Opcache非常友好。其核心思想是：每次部署都将新代码部署到一个全新的目录（例如
releases/v2
），然后通过更新一个软链接（例如
current -> releases/v2
）来切换到新版本。
我的看法： 当软链接指向新目录后，PHP-FPM进程在处理后续请求时，会发现请求的文件路径（例如
/var/www/current/index.php
）实际上指向了一个全新的物理路径（
/var/www/releases/v2/index.php
）。Opcache会认为这是一个“新文件”，从而自动编译并缓存新版本的Opcode，而不会使用旧目录中的缓存。这种方式能最大限度地减少部署时的风险和停机时间，并且与Opcache配合得天衣无缝。
部署时，最怕的就是新旧代码混杂运行，Opcache缓存了旧的，但应用逻辑依赖新的，导致各种奇怪的问题。所以，部署策略要和Opcache的刷新策略匹配好，确保每次代码更新都能得到及时、正确的缓存刷新。
以上就是php opcache是如何工作的？PHP Opcache工作原理与配置的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1320850.html
微信扫一扫 
支付宝扫一扫 
