JIT 和 AOT 编译有什么区别？Java 服务为什么需要预热？

知识点详解：编译时机，为什么影响服务表现？

javac 与 JIT，不是在重复做同一件事

假设 Java 源码先由 javac 编译成 class。class 中主要是 JVM 字节码，不是目标 CPU 可以直接执行的完整机器码程序。

典型 JVM 可以解释执行字节码，并收集运行信息。某些方法频繁调用后，JIT 把它们编译成机器码，减少后续执行成本。

“Java 已经编译过，为什么还要 JIT”的疑问，来自没有区分编译产物。

JIT 为什么能够利用真实运行情况？

运行时可以知道某个方法是否热点、某个调用通常出现什么类型，以及哪些分支常见。编译器可以利用这些信息做内联等优化。

如果优化依赖的假设后来不成立，JVM 可能去优化，并重新选择执行或编译方式。不能把 JIT 理解成“一旦编译，机器码永远不再改变”。

分层编译和相关机制可以核对 HotSpot 性能增强说明。

预热不仅仅是让 JIT 编译

服务刚启动，还可能加载类、初始化连接池、构建缓存和建立下游连接。JIT 只是其中一部分。

假设压测直接在启动后开始，前一段请求可能承担这些一次性成本。只报告这一段平均耗时，会把冷启动与稳定性能混在一起。

但也不能无限预热直到数字好看。应该明确测量目标：如果用户关心函数冷启动，就测试冷启动；如果关心长期服务，分别报告预热阶段和稳定阶段。

图：这些工作可以交错发生，不是固定的四步流水线；提前编译也不会替业务完成建连和缓存预热。

AOT 减少启动工作，也增加构建与兼容要求

以 GraalVM Native Image 为例，它在构建阶段分析应用并生成本地可执行文件。需要知道可达代码，动态反射、资源和代理等能力可能需要额外配置。

这不是把任意项目按一个按钮就无损变快。依赖库、构建平台、运行时行为及观测能力都需确认，见 Native Image 概述。

JIT 与 AOT 也不是绝对互斥，具体运行时可能有不同组合。应指定实现，而不是把所有语言与虚拟机放进同一结论。

应该怎样做公平比较？

保持业务数据、请求模型、机器资源和功能一致，分别测冷启动到可用、首次请求、稳定吞吐、尾延迟和内存。

同时记录构建成本和运维限制。快速扩缩场景更关注启动，长期高负载服务更关注稳定效率。没有脱离工作负载的通用赢家。

本题是运行时机制，不提供伪等价的 TypeScript/Python 编译代码。

面试官继续追问

为什么压测要跑一段时间？

为了观察状态是否稳定，而不是自动忽略所有慢请求。记录预热长度和稳定判断，必要时单独测试冷态。

AOT 程序完全不需要预热吗？

不一定。运行时编译减少了，缓存、连接和业务初始化仍存在。

吞吐高，代表用户体验好吗？

不能。还要看尾延迟、资源开销和故障时表现，尤其是启动与扩容期间。

面试速记卡

• 编译产物：字节码与机器码分开。
• JIT：运行时热点编译，可利用实际执行信息。
• AOT：提前编译，评估构建和动态能力限制。
• 预热：编译、类加载、连接和缓存都可能参与。
• 比较：冷启动与稳定性能分别测量。