php opcache是如何工作的？PHP Opcache工作原理与配置-php教程-PHP中文网

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 opcache工作原理与配置

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的各种统计数据，比如缓存命中次数、未命中次数、内存使用情况等。例如：

<?php
$status = opcache_get_status();
if ($status && $status['opcache_enabled']) {
    echo "Opcache is enabled.\n";
    echo "Hit rate: " . round($status['opcache_statistics']['hits'] / ($status['opcache_statistics']['hits'] + $status['opcache_statistics']['misses']) * 100, 2) . "%\n";
    echo "Memory used: " . round($status['memory_usage']['used_memory'] / (1024 * 1024), 2) . " MB\n";
    // 更多详细信息...
} else {
    echo "Opcache is not enabled.\n";
}
?>

登录后复制

我个人觉得，

hit_rate

登录后复制

这个指标，比其他任何参数都更能直观地反映Opcache的“工作效率”。如果这个值不够高，那么即便Opcache开启了，它的实际价值也大打折扣。所以，在部署新应用或优化现有应用时，我都会特别关注这个数字。此外，也有一些第三方的Opcache GUI工具（比如

rlerdorf/opcache-gui

登录后复制

）可以提供更友好的可视化界面来监控Opcache状态，这在调试和长期监控时非常有用。

天工

昆仑万维推出的通用AI智能体平台，原天工AI

212

查看详情

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

登录后复制

设为

登录后复制

，这意味着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
```
登录后复制
：
```
<?php
if (function_exists('opcache_reset')) {
    opcache_reset();
    echo "Opcache has been reset.\n";
} else {
    echo "Opcache function not available.\n";
}
?>
```
登录后复制
然后，在部署完成后，通过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配合得天衣无缝。