JIT 在 PHP 8.3 中的演进
PHP 8.0 首次引入 JIT（Just-In-Time）编译器，将热点字节码直接编译为机器码执行。历经 8.1、8.2 两个版本的打磨，PHP 8.3 对 JIT 的寄存器分配策略、类型推断精度以及内存管理进行了深度重构。OPcache 与 JIT 的协同机制在 8.3 中更加成熟，尤其是在高并发、长生命周期进程场景下，编译缓存的命中率显著提升。
然而，开发环境跑分漂亮，不代表生产环境同样给力。本文基于一组真实生产环境的压测数据，拆解 PHP 8.3 JIT 的实际加速表现。
测试环境配置
测试在一台 8 核 16GB 内存的云服务器上进行，操作系统为 Ubuntu 22.04 LTS，Web 服务器采用 Nginx 1.24 + PHP-FPM 8.3.4。OPcache 开启且 opcache.jit_buffer_size 设置为 128MB，opcache.jit 模式为 tracing（默认值）。
测试对象为一个中等复杂度的 Laravel 10 应用，包含 200+ 路由、80+ 模型、30+ 中间件，数据库查询以读操作为主。使用 wrk 进行压测，并发连接数 100，持续时间 60 秒。
核心指标对比
关闭 JIT 时的表现
|
指标 |
数值 |
|---|---|
|
平均响应时间 |
42.3 ms |
|
每秒请求数 (RPS) |
2,364 |
|
CPU 占用率 |
78% |
|
内存峰值 |
312 MB |
开启 JIT 后的表现
|
指标 |
数值 |
|---|---|
|
平均响应时间 |
31.7 ms |
|
每秒请求数 (RPS) |
3,152 |
|
CPU 占用率 |
65% |
|
内存峰值 |
348 MB |
从数据可见，RPS 提升约 33.3%，平均响应时间下降 25.1%，CPU 占用率降低 13 个百分点。内存消耗略有上升，增量约 36 MB，主要来自 JIT 编译缓存区的占用。
不同场景下的差异
纯 I/O 密集型接口
对于以数据库查询、Redis 读取、文件读写为主的接口，JIT 的加速效果有限。实测某列表查询接口，RPS 仅从 1,890 提升到 2,012，增幅 6.4%。原因在于 I/O 等待时间占主导，CPU 计算并非瓶颈。
CPU 密集型业务逻辑
涉及大量数组运算、字符串处理、正则匹配的接口，JIT 的优势被放大。某数据清洗接口在开启 JIT 后，RPS 从 856 飙升至 1,420，增幅高达 65.9%。这类场景下，热点循环被编译为原生机器码，解释执行的开销被大幅削减。
长时间运行进程
在 Swoole 协程服务器或 Laravel Octane 常驻内存模式下，JIT 的预热成本被摊薄。压测显示，进程启动后前 100 个请求性能波动较大，第 200 个请求后趋于稳定。对于需要 7×24 小时运行的服务，JIT 的长期收益远高于短生命周期脚本。
开启 JIT 的配置要点
生产环境启用 JIT 并非简单设置 opcache.jit=1 即可。以下配置直接影响编译效果：
opcache.jit_buffer_size 建议设置为 64MB 至 256MB，过小会导致频繁重新编译，过大则浪费内存。opcache.jit 模式推荐保持默认的 tracing，它在大多数业务场景下平衡了编译开销与执行效率。
opcache.jit_hot_func 控制函数被编译为机器码的调用阈值，默认 127 次。对于流量稳定的生产环境，可适当调高至 256 或 512，减少低频次函数的无效编译。
结论与建议
PHP 8.3 JIT 在生产环境中的加速效果取决于业务类型。CPU 密集型任务可获得 30% 至 60% 的性能提升，I/O 密集型任务提升通常在 5% 至 15% 之间。内存开销增加可控，CPU 占用率反而下降，说明 JIT 提升了单核效率。
建议在生产环境逐步灰度开启 JIT，优先在计算密集模块上验证。配合 OPcache 预加载（opcache.preload）使用，可进一步缩短 JIT 预热时间。PHP 8.3 的 JIT 已足够成熟，值得在生产环境正式部署。
