一、为什么需要 opcache？
PHP 作为解释型语言，传统执行流程是：读取 .php 源文件 → 词法分析 → 语法分析 → 编译成 opcode → Zend 虚拟机执行 opcode。每次请求都会重复这一过程，其中编译阶段消耗大量 CPU 时间。
opcache 扩展的核心作用是将编译后的 opcode 缓存到共享内存中，后续请求直接复用，跳过词法/语法分析和编译步骤，从而大幅提升 PHP 执行效率。在生产环境中，opcache 通常能带来 2~5 倍的性能提升，是 PHP 应用部署的标配。
二、opcache 的工作原理
2.1 整体架构
opcache 的工作流程可以概括为以下几个阶段：
- 编译阶段：PHP 首次加载某个脚本时，Zend 引擎正常进行词法分析、语法分析并生成 opcode。
- 缓存写入：opcache 将生成的 opcode、类定义、函数定义等元数据写入共享内存（shared memory）。
- 缓存命中：后续请求加载同一脚本时，opcache 直接从共享内存读取 opcode，跳过编译过程。
- 失效与更新：当源文件被修改或缓存空间不足时，opcache 根据配置策略使缓存失效。
2.2 共享内存结构
opcache 使用共享内存（在 Linux 上通常通过 mmap 或 SysV SHM 实现）存储缓存数据。主要包含两部分：
- 主缓存区：存储 opcode 数组、类/函数/常量表等核心数据。
- 哈希表：用于快速定位缓存条目，通过文件路径、脚本指纹等作为键。
此外，opcache 还使用锁机制（如文件锁或自旋锁）来保证多进程并发读写共享内存时的数据一致性。
2.3 缓存键与失效机制
opcache 的缓存键通常由脚本的绝对路径、文件修改时间、文件大小等信息组合而成。当以下情况发生时，缓存会失效：
- 源文件的 mtime 发生变化（受
opcache.validate_timestamps控制）。 - 缓存空间不足，触发 LRU（最近最少使用）淘汰。
- 手动调用
opcache_reset()或opcache_invalidate()。 - 达到
opcache.max_accelerated_files上限后新文件无法缓存。
2.4 内存管理
opcache 在共享内存中采用类似“内存池”的管理方式。默认使用 opcache.memory_consumption 指定总大小，内部通过空闲链表和 LRU 策略管理内存块。当缓存条目被淘汰或失效时，其占用的内存会被回收供新条目使用。
三、生产环境配置建议
3.1 核心配置项
以下是一份经过生产验证的 php.ini 配置参考：
[opcache]
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=0
; 共享内存大小，根据项目规模调整
opcache.memory_consumption=256
; 可缓存的最大文件数，建议略大于项目文件总数
opcache.max_accelerated_files=20000
; 每个脚本最大可缓存 opcode 数
opcache.max_wasted_percentage=10
; 生产环境关闭时间戳验证，避免每次请求 stat 文件
opcache.validate_timestamps=0
; 若开启时间戳验证，设置检查间隔（秒）
opcache.revalidate_freq=60
; 关闭调试信息，减少内存占用
opcache.save_comments=0
opcache.fast_shutdown=1
; 启用文件缓存作为二级缓存（可选）
opcache.file_cache=/tmp/opcache
opcache.file_cache_only=0
3.2 关键参数解析
opcache.memory_consumption
共享内存大小，单位 MB。默认 128MB。对于中小型项目，256MB 通常足够；大型项目（如 Laravel、Symfony 全量加载）建议 512MB 甚至更高。可通过 opcache_get_status() 查看实际使用量。
opcache.max_accelerated_files
可缓存的最大文件数，默认 10000。该值应大于项目中所有 PHP 文件的总数。注意此值是“最大可缓存数”，实际哈希表大小会向上取整到最近的质数。
opcache.validate_timestamps
生产环境强烈建议设为 0。开启时，opcache 会在每次请求时检查文件 mtime，带来额外的 stat 系统调用开销。关闭后，代码更新需通过重启 PHP-FPM 或调用 opcache_reset() 生效。
opcache.revalidate_freq
仅在 validate_timestamps=1 时生效，表示每隔多少秒检查一次文件更新。设为 0 表示每次请求都检查。
opcache.save_comments
是否保存注释。框架（如 Doctrine、Symfony）依赖注解时需设为 1；若使用 PHP 8 Attributes 且不依赖注释，可设为 0 节省内存。
3.3 部署与运维建议
- 预热缓存：部署后通过脚本批量请求核心文件，或使用
opcache_compile_file()预热，避免首批请求变慢。 - 监控命中率：通过
opcache_get_status()['opcache_statistics']['opcache_hit_rate']监控命中率，生产环境应保持在 99% 以上。 - 合理设置文件缓存：在容器化或多机部署场景下，可启用
opcache.file_cache实现二级缓存，加速冷启动。 - 避免频繁 reset：
opcache_reset()会清空整个共享内存，导致所有请求重新编译，应谨慎使用。 - 注意 CLI 与 FPM 隔离：
opcache.enable_cli通常设为0，因为 CLI 脚本生命周期短，缓存收益低且占用内存。
四、常见面试追问
Q1：opcache 与 JIT 的关系？
opcache 负责缓存 opcode，JIT（Just-In-Time）则是在 opcode 执行阶段进一步将热点代码编译为机器码。PHP 8.0 引入的 JIT 建立在 opcache 之上，需先启用 opcache 才能使用 JIT。
Q2：为什么关闭 validate_timestamps 后代码更新不生效？
因为 opcache 不再检查文件 mtime，仍使用旧 opcode。解决方式是重启 PHP-FPM、调用 opcache_reset()，或使用 opcache_invalidate($file, true) 针对单个文件失效。
Q3：opcache 缓存穿透怎么办？
当缓存空间不足或文件数超限时，新文件无法缓存，每次请求都需重新编译。应监控 opcache_get_status() 中的 cache_full、wasted_memory 等指标，及时调整 memory_consumption 和 max_accelerated_files。
Q4：多台服务器如何保持一致？
在负载均衡架构下，每台服务器独立维护 opcache。部署时应确保代码同步后统一重启 FPM 或触发预热，避免版本不一致。
五、总结
opcache 通过将 opcode 缓存到共享内存，显著减少 PHP 脚本的编译开销，是生产环境性能优化的第一道关卡。理解其共享内存结构、缓存失效机制和关键配置项，不仅能应对面试，更能指导实际部署。核心配置口诀：内存给够、文件数调大、生产关时间戳、部署做预热、监控看命中率。掌握这些，你就能在生产环境中把 opcache 的价值发挥到最大。
未经允许不得转载：任鹏个人博客 » PHP 面试题：PHP 的 opcache 工作原理与生产环境配置
