前言JITJust-In-Time即时编译确实是 PHP 8.0 引入的特性标题没有写错。但很多人在php.ini里抄了一行opcache.jit tracing就以为开好了压测下来却几乎看不到变化于是得出「JIT 是噱头」的结论另一些人开了 JIT 后发现进程内存涨了一截又慌忙关掉。这两种情况的原因都不是 JIT 没用而是配置没生效、或者用在了 JIT 帮不上忙的地方。JIT 只对「CPU 密集且反复执行」的代码有意义而绝大多数 Web 请求是「活得很短、大部分时间在等 IO」的压测脚本量到的往往是数据库和网络的耗时不是 CPU 的。本文讲清楚三件事JIT 在 PHP 的执行链路里处在哪一层、哪几个配置项真正决定它开不开、以及怎么自己动手测出「在你这份代码上 JIT 到底有没有用」而不是照抄别人的结论。文中示例需要 PHP 8.0 及以上涉及 PHP 8.4 默认值变化的地方会单独标注。一、JIT 在 PHP 执行链路里的位置想配置对先要知道 JIT 不是把解释器换掉了它是叠在 OPcache 之上的一层PHP 源码 │ 词法 / 语法分析 ▼ AST抽象语法树 │ 编译 ▼ OPcodes中间代码──────────┐ │ │ 由 OPcache 缓存在共享内存里 │ Zend VM 解释执行 │ 这一步是 OPcache 的功劳不是 JIT ▼ │ 执行结果 │ │ JIT 在运行时把「热点」OPcodes ▼ 直接编译成 CPU 机器码 机器码存在 JIT buffer 里由此可以推出几条硬约束没有 OPcache 就没有 JIT。opcache.enable0时 JIT 一定不工作。JIT buffer 满了就不再编译新代码只是回退到解释执行不会报错所以「性能没提升」和「JIT 没生效」从现象上很难区分必须去看状态。JIT 只编译热点。只执行一次的代码编译机器码的开销反而大于收益所以默认的触发策略是「跑够次数才编译」。二、决定 JIT 开不开的三个配置项生产上最小可用的一组配置php.ini; 第一层OPcache 必须开 opcache.enable1 opcache.memory_consumption128 opcache.max_accelerated_files20000 ; 第二层JIT 自身的开关 opcache.jit_buffer_size64M opcache.jittracing这三个值里最容易踩坑的是opcache.jit_buffer_size它是 JIT 的总开关值为0时无论opcache.jit写什么JIT 都完全不启用。PHP 8.0 到 8.3 的这个默认值就是0所以「只加了opcache.jit而没加 buffer size」是最常见的失效原因。PHP 8.4 起opcache.jit的默认值改成了disable不再是tracing也就是说从 8.4 开始两行都得显式写出来。另外两个要注意的点opcache.jit_buffer_size属于INI_SYSTEM级别不能在运行时用ini_set()改改了也不生效只能改配置文件后重载 PHP。命令行要单独开 OPcacheopcache.enable_cli的默认值是0。你在终端里php bench.php测出来的结果默认是没有OPcache 也没有 JIT 的。三、opcache.jit的两种写法opcache.jit可以写名字也可以写一个四位数。名字只有两种常用取值取值含义适合场景tracing追踪模式沿着「热循环 / 热函数」把跨调用的执行路径汇编成一条 trace长生命周期进程、CPU 密集计算function函数模式以一个函数为单位编译整段想控制编译开销和内存占用时disable/off关闭PHP 8.4 起的默认值四位数的写法叫 CRTO四位分别控制CPU 相关优化、寄存器分配策略、编译触发方式、优化级别。这种写法在不同版本的资料里解释并不完全一致而且数字和名字之间也不是简单的一一对应所以实践建议是直接用tracing/function这两个名字不要手写四位数。真要写数字之前请先对照你所用版本的官方手册里那张 CRTO 说明表。与触发相关的还有几个阈值项它们在tracing模式下决定「多热才算热」配置项作用opcache.jit_hot_loop循环执行多少次后进入候选opcache.jit_hot_func函数被调用多少次后进入候选opcache.jit_hot_return函数返回多少次后进入候选opcache.jit_hot_side_exit追踪退出多少次后不再重试这些值只有在你已经确认 JIT 生效、并且确实需要调优时才动。默认值对多数场景是安全的一上手就改只会增加变量。四、JIT 对什么样的代码有效JIT 的收益来自「把解释执行的开销换成已经编译好的机器码」所以它对下面这类代码有效纯 PHP 实现的、跑在循环里的大量算术和字符串处理调用了很多次的用户态函数tracing模式能把跨函数的路径合成一条 trace长驻内存的服务常驻进程、worker、队列消费进程。而对下面这类代码基本无效请求生命周期很短几十毫秒CPU 时间只占其中很小一部分瓶颈在数据库、Redis、HTTP 上游调用主要耗时在扩展内部比如preg_*、json_*、GD这些是已经编译好的 C 代码JIT 编译不了它们大量依赖动态特性eval()、变量函数名、__call、call_user_func_array混用编译器的静态假设容易失效。有一类代码 JIT 能帮上明显的忙带完整类型声明的代码。标量类型、返回类型、declare(strict_types1)能给编译器更多可依赖的信息类型越确定能做的优化越多。反过来全篇mixed的代码JIT 的优化空间很小。代码实战自己测出 JIT 有没有用不要相信任何现成的百分比用下面这个脚本在你自己的机器上跑。它做一件纯 CPU 的事递归计算斐波那契并把opcache_get_status()里的 JIT 状态一并打印出来PHP 8.0 可用。?php // jit_bench.php —— 需要 PHP 8.0 declare(strict_types1); function fib(int $n): int { return $n 2 ? $n : fib($n - 1) fib($n - 2); } function busy(int $rounds): int { $sum 0; for ($i 0; $i $rounds; $i) { $sum ($i % 7) * 3 intdiv($i, 5); } return $sum; } // 1. 先把 JIT 的真实状态打出来 $status function_exists(opcache_get_status) ? opcache_get_status(false) : false; if ($status false) { echo [!] OPcache 未启用本次测量结果与 JIT 无关\n; } else { $jit $status[jit] ?? []; printf( [i] opcache.enable%s jit.enabled%s jit.on%s kind%s opt_level%s buffer%d free%d\n, ($status[opcache_enabled] ?? false) ? 1 : 0, ($jit[enabled] ?? false) ? 1 : 0, ($jit[on] ?? false) ? 1 : 0, (string) ($jit[kind] ?? -), (string) ($jit[opt_level] ?? -), (int) ($jit[buffer_size] ?? 0), (int) ($jit[buffer_free] ?? 0) ); if (($jit[buffer_size] ?? 0) 0) { echo [!] jit_buffer_size 为 0JIT 一定没有启用\n; } } // 2. 热身让热点计数涨上去否则 JIT 还没来得及编译就结束了 busy(200_000); // 3. 计时 $t0 hrtime(true); $r1 busy(5_000_000); $t1 hrtime(true); $f0 hrtime(true); $r2 fib(32); $f1 hrtime(true); printf(busy(): %d 用时 %.1f ms\n, $r1, ($t1 - $t0) / 1e6); printf(fib(32): %d 用时 %.1f ms\n, $r2, ($f1 - $f0) / 1e6);同一个脚本用两组参数各跑一次自己对比# 对照组有 OPcache但没有 JIT php -d opcache.enable_cli1 -d opcache.jit_buffer_size0 -d opcache.jitdisable jit_bench.php # 实验组开启 OPcache 与 tracing JIT php -d opcache.enable_cli1 -d opcache.jit_buffer_size64M -d opcache.jittracing jit_bench.php判断方法很直接两组的busy()和fib()用时如果基本相同说明这段代码上 JIT 帮不上忙——这在递归这类调用密集的代码上并不少见别急着下结论换成你自己的业务热点代码再测。如果实验组明显更快且jit.on1、buffer_free明显小于buffer_size说明 JIT 真的在编译。如果jit.enabled1但jit.on0说明 JIT 初始化了但一次都没编成功多半是 buffer 太小或者优化级别/触发条件没满足。hrtime(true)返回纳秒整数是 PHP 7.3 引入的比microtime(true)精度更高也不受系统时钟调整影响。常见坑点只写opcache.jit忘了 buffer size❌opcache.jittracing单独一行opcache.jit_buffer_size保持默认0。 ✅ 两行都写opcache.jit_buffer_size64M加opcache.jittracing。拿命令行测 Web 性能❌php bench.php直接跑以为测的是线上配置——CLI 的opcache.enable_cli默认是0。 ✅ 加-d opcache.enable_cli1或者把热点逻辑放到 HTTP 请求里压测。在php.ini里开了却忘了重载❌ 改完php.ini直接看效果fpm 的进程池里还是旧配置。 ✅php-fpm -t检查语法后平滑重载并用php -i或opcache_get_status()确认生效。只看「总耗时」判断 JIT 效果❌ 拿一个大量读写数据库的接口做对比两次结果差异全来自 IO 抖动。 ✅ 单独剥离出 CPU 密集的那段代码测或者用hrtime()只包住计算部分。把jit_buffer_size设得极大❌ 直接写opcache.jit_buffer_size1G以为越大越快结果这部分共享内存被长期占住。 ✅ 从64M起步看buffer_free是否还有大量剩余再决定要不要调。在短生命周期请求上纠结 JIT❌ 每个请求只有 20 毫秒、其中 18 毫秒在等数据库还在反复调 JIT 参数。 ✅ 先确认瓶颈在 CPU 还是 IO。IO 密集的场景该优化的是缓存、索引和连接复用。代码里到处是动态调用❌ 全篇call_user_func([$obj, $method], ...)、mixed参数、字符串函数名然后期待 JIT 带来提升。 ✅ 补上类型声明、declare(strict_types1)把动态分派改成明确的调用再测一次。总结配置项作用关键事实opcache.enableOPcache 总开关关掉它 JIT 必然不工作opcache.enable_cliCLI 下是否启用 OPcache默认0命令行测试必须显式打开opcache.jit_buffer_sizeJIT 代码缓冲区为0等于关闭 JITINI_SYSTEM不能ini_setopcache.jitJIT 模式tracing/functionPHP 8.4 起默认disableopcache.jit_hot_*热点判定阈值确认生效后再调别一上来就动opcache_get_status()[jit]唯一可信的状态来源看buffer_size和buffer_free配置 JIT 只做三件事确保 OPcache 打开、把opcache.jit_buffer_size设为非 0、用名字而不是四位数指定模式。至于值不值得开取决于你的代码里 CPU 时间占比有多高——用hrtime()把自己的热点代码单独量一遍比任何道听途说的结论都可靠。