前言JITJust-In-Time即时编译是 PHP 8.0 引入的头号新特性。但很多人的调优过程是这样的在php.ini里加上一行opcache.jit1重启 PHP-FPM压测一轮发现 QPS 几乎没动于是得出结论JIT 是噱头。实际上最常见的三种情况是配置根本没生效opcache.jit_buffer_size默认为 0缓冲区为零等于关闭、跑的是 I/O 密集型代码JIT 对等待数据库和网络的时间无能为力、运行环境不支持 JIT官方 JIT 只在 x86-64 与 AArch64 的 Linux/macOS 构建上生效32 位与 Windows 场景请以官方文档说明为准。本文只讲 PHP 8.0 上确实存在、且能验证的配置项与调优方法先讲清楚 JIT 生效的三个前提再拆解opcache.jit那串四位数的含义然后按CLI 计算密集型和Web 请求型两种场景给参数最后给一段读者可以自己跑出对比数据的验证脚本。一、JIT 生效的三个前提JIT 是挂在 OPcache 里的子系统它不会绕过 OPcache 单独工作。所以下面三件事必须同时成立前提配置项说明OPcache 已启用opcache.enable1CLI 下还需要opcache.enable_cli1否则命令行跑脚本时 OPcache 整体不工作分配了 JIT 缓冲区opcache.jit_buffer_size64M默认值是0代表不分配内存给 JIT此时哪怕opcache.jit设成 tracing 也不会有任何机器码生成JIT 模式不是关闭opcache.jittracingopcache.jit0或disable表示显式关闭验证是否真的生效不要靠猜直接问 OPcache?php // 需要 PHP 8.0ext-opcache $status opcache_get_status(false); if (!is_array($status)) { exit(OPcache 未启用或当前 SAPI 下被禁用\n); } // JIT 的状态在 jit 这个键里不同小版本字段略有差异整段打印最稳妥 print_r($status[jit] ?? 未提供 jit 状态信息说明 JIT 未编译任何代码);如果输出里on为false或者整段信息缺失那JIT 没效果的答案就已经找到了它压根没开。二、拆开那串四位数CRTOopcache.jit的值可以用预置名字符串也可以用四位数字。四位数字按CRTO顺序解读位名称含义建议取值CCPU 特定优化是否允许使用宿主 CPU 的向量指令等优化1允许如 AVXR寄存器分配是否做跨基本块的全局寄存器分配2全局分配收益最大T触发时机何时把字节码升级编译为机器码数值越大越倾向先跑热、再编译用预置模式即可O优化级别机器码优化强度5默认级别PHP 8.0 提供两个可读的预置值opcache.jittracing默认值追踪式 JIT。它记录实际执行过的热点路径trace追踪轨迹对循环与调用链做整体优化。官方文档中它等价于1255。opcache.jitfunction函数式 JIT以单个函数为单位编译。官方文档中它等价于1205优化保守、编译开销小。选择逻辑很朴素场景推荐理由长生命周期 CLI 进程常驻 worker、批量计算tracing有足够时间让热点轨迹沉淀收益上限高短生命周期请求FPM 每次请求启动/复用脚本function或tracing都行先量测追踪本身有运行时开销请求很短时未必划算纯 I/O 业务大量 DB/Redis/HTTP 调用开不开都效益有限CPU 时间占比低热点不在 PHP 字节码上调试、排查诡异崩溃先设为0关闭排除 JIT 因素再逐个开回来还有一组热度阈值参数例如opcache.jit_hot_loop、opcache.jit_hot_func用来决定一个循环/函数被执行多少次后才值得编译。它们的默认值请以官方文档为准不建议在没有压测数据支撑时乱改——调低会让编译开销提前发生调高则让真正的热点错过编译机会。三、两条实战配置路线路线 A常驻 CLI 计算进程; php.ini —— CLI 场景PHP 8.0 opcache.enable1 opcache.enable_cli1 opcache.jittracing opcache.jit_buffer_size128M opcache.memory_consumption256M opcache.max_accelerated_files20000 opcache.validate_timestamps0要点CLI 下必须显式打开opcache.enable_cli常驻进程适合把validate_timestamps关掉省掉每次检查文件 mtime 的开销但部署时要记得重载进程。路线 BFPM 下的 Web 请求; php.ini —— FPM 场景PHP 8.0 opcache.enable1 opcache.enable_cli0 opcache.jitfunction opcache.jit_buffer_size64M opcache.memory_consumption192M opcache.validate_timestamps1 opcache.revalidate_freq2要点Web 请求普遍是 I/O 密集的JIT 的收益主要出现在框架启动、模板编译、纯计算工具类上。缓冲区不要盲给很大——jit_buffer_size是从进程内存里预扣的FPM 模式下每个 worker 都会占一份给 512M 会让几百个 worker 直接把机器内存吃满。四、代码实战自己跑出 JIT 的对比数据JIT 的收益高度依赖代码形态所以任何别人的数字对你都没有参考价值必须自己量。下面这段脚本是一段纯 CPU 计算大量整数与浮点运算没有 I/O最适合观察 JIT 的作用。保存为jit_bench.php用同一条命令跑两次一次关 JIT一次开 JIT。?php declare(strict_types1); // PHP 8.0需要 ext-opcache建议 CLI 运行 function workload(int $n): float { $sum 0.0; $acc 1; for ($i 0; $i $n; $i) { $acc ($acc * 31 $i) % 1000003; // 整数热点循环 $sum sqrt((float) $acc) / 7.0; // 浮点热点循环 } return $sum; } $n 300_000; $t0 hrtime(true); $result workload($n); $t1 hrtime(true); $status opcache_get_status(false); $jitOn is_array($status) !empty($status[jit][on]); printf(JIT: %-3s | n%d | 结果%.6f | 耗时%.1f ms\n, $jitOn ? ON : OFF, $n, $result, ($t1 - $t0) / 1e6 );# 第一次显式关闭 JIT 作为基线 php -d opcache.enable_cli1 -d opcache.jit_buffer_size0 -d opcache.jit0 jit_bench.php # 第二次开启追踪式 JIT注意缓冲区必须大于 0 php -d opcache.enable_cli1 -d opcache.jit_buffer_size64M -d opcache.jittracing jit_bench.php跑的时候有三点必须注意否则数据毫无意义每次都要用-d显式传参不要依赖php.ini避免两次跑的不是同一份配置。循环次数要够大让热度超过编译阈值$n太小时测出来的主要是 JIT 的编译开销。同一台机器交替跑多轮取中位数。单次hrtime的抖动很容易把差异淹没。如果你手头是业务代码而不是计算代码把上面的workload换成你自己的函数即可。看到耗时几乎没变是正常结果——这说明你的瓶颈不在 CPU 指令层面此时把精力放回 SQL、缓存和网络调用上收益会大得多。常见坑点1. 只设了opcache.jit没设缓冲区❌opcache.jittracingopcache.jit_buffer_size保持默认0。 ✅ 两者同时设置缓冲区给到 64M 起步并用opcache_get_status()确认on为真。2. 在 CLI 里调优却忘了opcache.enable_cli❌ 命令行跑脚本对比两次耗时一模一样——因为 CLI 下 OPcache 默认关闭JIT 自然也不存在。 ✅ 基线组和实验组都带上-d opcache.enable_cli1。3. 用opcache_reset()之后以为 JIT 还在❌ 请求里调用opcache_reset()清缓存之后继续压测并对比数据。 ✅opcache_reset()会一并重置 JIT 的编译产物压测期间不要调用手工清理后要重新预热再测。4. 缓冲区开得越大越好❌ FPM 下opcache.jit_buffer_size1Gworker 一多直接 OOM。 ✅ 按缓冲区大小 × worker 数量估算总占用留出余量用buffer_free观察是否真的被用满。5. 拿 I/O 密集接口去验证 JIT❌ 压测一个查库 渲染模板的接口得出JIT 无效的结论并把它关掉。 ✅ 用纯计算脚本判断 JIT 是否正常工作业务接口的收益另做评估。6. 改了php.ini但没重启进程❌ 修改后直接测FPM 仍在用旧配置或者只reload了 nginx。 ✅ 改 OPcache 相关配置后重启 PHP-FPMsystemctl restart php-fpm再用phpinfo()或opcache_get_status()复核。7. 把 JIT 当成性能问题的万能药❌ 接口慢就先去调 JIT 参数。 ✅ 先用慢查询日志、EXPLAIN、APM 找到真正的瓶颈CPU 火焰图里如果 PHP 字节码执行占比很低调 JIT 就是白费功夫。8. 调优时忘了validate_timestamps的副作用❌ 为了让 OPcache 命中率更高关掉validate_timestamps结果发版后代码不生效排查半天。 ✅ 关闭它的同时把发布后必须 reload/restart PHP-FPM写进部署流程。总结配置项典型值作用不生效的常见原因opcache.enable1打开 OPcache未重启进程opcache.enable_cliCLI 下1让命令行也走 OPcache只调了 Web 侧没管 CLIopcache.jit_buffer_size64M~128MJIT 缓冲区默认0等于关闭 JITopcache.jittracing/function编译策略设为0或disableopcache.jit_hot_*保持默认热点触发阈值未压测就乱调收益为负JIT 调优的有效性取决于三个问题的答案它是否真的在编译代码看opcache_get_status()、你跑的是不是 CPU 密集型逻辑看火焰图、以及收益是否被你自己的压测数据证实自己跑对比脚本。三问全部为是时JIT 才值得占用内存预算否则把它留给 OPcache 的其他参数会更划算。