Java 基础体系 · 第 72/100 篇。示例统一以 Java 25 LTS 为语言和 JVM 基线；框架示例使用与其兼容的现代稳定版本。

JVM JIT 编译：解释执行、分层编译、内联、去优化和证据

Java 程序通常不会直接执行 .class 文件中的字节码。运行时首先由 JVM 加载类、校验字节码并执行方法；在执行过程中，JVM 收集调用次数、循环回边、类型分布等运行时信息，再把部分“足够热”的字节码编译为本地机器码。这一过程称为 JIT（Just-In-Time）编译，即即时编译。

JIT 不是 Java 语言规范或 Java 虚拟机规范要求的唯一实现方式。JVMS 规定的是类文件格式、字节码语义、异常、线程、内存模型等可观察行为；它并不要求 JVM 必须使用解释器，也不规定某个方法必须在第几次调用后编译。HotSpot 的解释器、C1、C2 和相关编译策略属于常见实现，不应当误写成 Java 25 LTS 的规范保证。

---

1. 从字节码到机器码：JVM 实际要保持什么不变

考虑下面的方法：

static int sum(int[] values) {
    int result = 0;
    for (int value : values) {
        result += value;
    }
    return result;
}

编译后，方法的核心逻辑会表现为类似以下字节码操作：

1. 读取数组长度；
2. 判断循环索引是否越界；
3. 从数组读取元素；
4. 执行整数加法；
5. 增加索引；
6. 跳回循环判断；
7. 返回结果。

解释器可以逐条执行这些字节码；JIT 则可以把循环转换为机器指令。无论采用哪一种方式，以下结果必须保持一致：

• 对合法输入返回相同结果；
• 数组越界时仍然抛出相应异常；
• null 解引用仍然产生规定的异常行为；
• synchronized、异常处理和线程内存语义不能被任意改变；
• 其他线程能够观察到的行为必须符合 Java 内存模型。

因此，JIT 的目标不是“把所有代码都翻译成最快的机器码”，而是在不改变 Java 语义的前提下，利用运行时事实进行更激进的优化。

例如，JIT 可能根据已经收集到的信息暂时假设：

Animal animal = ...;
animal.speak();

这里的 animal 实际上一直是 Dog。于是它可以生成类似这样的机器码路径：

if (animal的实际类型 == Dog) {
    直接执行 Dog.speak 的机器码
} else {
    转到慢路径，执行完整的虚调用逻辑
}

这个假设不是永久真理。之后如果出现了 Cat，或者新的子类被加载，原来的优化可能不再成立，JVM 就需要去优化。

---

2. 解释执行：启动快，但每条字节码都有解释成本

2.1 解释执行的基本流程

解释执行是指 JVM 使用解释器读取字节码，并根据当前指令执行对应逻辑。以虚方法调用为例，解释器可能需要：

1. 从当前栈帧取出对象引用；
2. 检查对象是否为 null；
3. 查看对象的实际类；
4. 在方法表中查找目标方法；
5. 建立新的栈帧；
6. 转移到被调用方法；
7. 返回后恢复调用方状态。

这类工作需要反复执行。即使源代码只有一行：

return account.balance() + fee;

解释器也可能为方法调用、栈帧管理、类型检查和返回值处理付出多步成本。

解释执行的优点是：

• JVM 启动时不需要等待大量本地代码生成；
• 冷代码不会浪费编译时间和代码缓存；
• 能够直接执行任意已验证的字节码；
• 编译线程不会在启动阶段消耗太多 CPU。

缺点是：

• 循环体每次迭代都要承担字节码分派和解释器检查；
• 解释器难以像 JIT 一样跨方法消除抽象层；
• 解释器本身通常不能充分利用运行时类型和分支概率。

2.2 解释器不是“逐行执行源代码”

JVM 执行的是字节码，而不是 Java 源代码。编译器可能已经完成了：

• 语法分析；
• 类型检查；
• 局部变量和操作数栈布局；
• 字段、方法和常量池引用编码；
• 部分编译期常量折叠。

因此，“解释执行”并不意味着 JVM 重新解析 Java 源码。它是在运行时解释字节码指令的语义。

2.3 解释器也会收集证据

解释器并非 JIT 的对立面。HotSpot 通常在解释执行过程中记录方法调用次数、循环回边次数和类型信息。这些数据构成编译决策的输入。

例如，下面的循环：

static long work(int n) {
    long result = 0;
    for (int i = 0; i < n; i++) {
        result += i * 31L;
    }
    return result;
}

JVM 可能观察到：

• work 被调用很多次；
• 循环回边执行次数很高；
• n 经常为正数；
• 循环中的类型都是稳定的 int 和 long；
• 没有异常路径被频繁触发。

这些事实使编译该方法具有经济价值。

---

3. 分层编译：在启动成本和长期性能之间分配资源

3.1 为什么需要多个编译层次

如果一开始就使用最激进的优化，编译本身可能耗时较长，而且许多优化依赖的运行时事实还没有收集充分。相反，如果只做非常简单的编译，长期吞吐又可能不够好。

因此，HotSpot 常见的分层编译策略大致是：

字节码
  │
  ▼
解释执行并收集 profiling 数据
  │
  ▼
较快的低级编译器（通常称为 C1）
  │
  ▼
继续收集更丰富的运行时数据
  │
  ▼
较激进的高级编译器（通常称为 C2）
  │
  ▼
优化后的机器码

C1 通常更重视编译速度和较低的启动延迟；C2 通常更重视长期运行性能和更复杂的优化。具体编译器组合、触发阈值和策略属于 JVM 实现与启动配置，不是 JVMS 的固定要求。

3.2 方法并不只有“解释”和“已编译”两种状态

一个方法在运行中可能经历如下状态：

1. 尚未执行；
2. 由解释器执行；
3. 被编译为较快但优化较少的版本；
4. 被再次编译为更激进的版本；
5. 旧版本失效；
6. 回到解释器或进入新的编译版本。

此外，方法可能因为循环很热而在一次长时间调用中被编译，这种情况称为 OSR（On-Stack Replacement，栈上替换）。它解决的是“当前调用已经运行很久，不能等到方法返回后再使用编译代码”的问题。

3.3 OSR 的状态转换

假设下面的方法执行一个很大的循环：

static long count(int limit) {
    long sum = 0;
    for (int i = 0; i < limit; i++) {
        sum += i;
    }
    return sum;
}

执行过程可能是：

进入 count
  │
  ▼
解释器执行循环前若干次迭代
  │
  ▼
发现循环回边足够热
  │
  ▼
编译器生成“从循环中间位置继续执行”的机器码
  │
  ▼
当前解释器栈帧转换为编译代码所需的状态
  │
  ▼
剩余迭代由机器码执行

OSR 编译代码不是简单地从方法入口开始执行。它必须能够接管当前解释器的局部变量、操作数栈和程序计数位置。这也是为什么编译器需要保存“可恢复的调试状态”。

如果程序只运行几毫秒，JIT 可能还没有完成编译，或者编译成本尚未摊平。这个事实解释了为什么短小基准测试经常错误地把 JVM 的启动和预热成本当成业务代码本身的性能。

---

4. JIT 何时值得编译：一个简单的经济模型

可以用一个简化模型理解编译决策。

设：

• $N$：某方法未来预计执行的次数；
• $I$：解释执行每次执行的成本；
• $J$：编译后每次执行的成本；
• $C$：编译成本；
• $P$：编译后额外产生的代码和数据维护成本。

不编译时，总成本近似为：

$$T_{\text{interpret}} = N \cdot I$$

编译后，总成本近似为：

$$T_{\text{JIT}} = C + P + N \cdot J$$

只有在：

$$N \cdot (I - J) > C + P$$

时，编译才可能带来净收益。

这不是 HotSpot 使用的精确决策公式，但它解释了几个重要现象：

• 冷方法不值得编译；
• 高频循环比只调用一次的方法更容易被编译；
• 编译线程本身会消耗 CPU；
• 低延迟服务可能不希望为了极少执行的路径支付长编译成本；
• 长时间运行的服务更容易从激进优化中获益。

“方法被编译了”并不等价于“程序更快了”。如果方法很快就不再执行，或者编译后版本频繁去优化，编译成本可能超过收益。

---

5. 内联：把调用边界变成优化机会

5.1 内联的定义

内联（Inlining） 是把被调用方法的代码直接复制或嵌入调用方，使调用方可以继续优化被调用方法的逻辑。

原始代码：

static int totalPrice(Item item) {
    return item.price() + 10;
}

如果 item.price() 是一个足够小、类型稳定的方法，JIT 可能把它变成概念上的：

static int totalPrice(Item item) {
    // 直接放入 price() 的实现
    return item.internalPrice + 10;
}

这里的代码不是 Java 源码级别的机械复制，而是编译器中间表示上的调用消除。

5.2 为什么内联影响巨大

不内联时，调用边界会阻碍调用方了解被调用方内部行为。内联后，编译器可能继续进行：

• 常量传播；
• 条件分支消除；
• 空值检查合并；
• 逃逸分析；
• 锁消除；
• 标量替换；
• 循环优化；
• 公共子表达式消除。

例如：

static int price(Item item) {
    return item.basePrice() * item.quantity();
}

static int total(Item item) {
    return price(item) + 5;
}

如果 price 和两个访问器都被内联，编译器可能看到完整的字段计算关系，而不是三个独立的方法调用。

5.3 内联不是无条件展开

内联受到多种因素限制：

• 方法体大小；
• 调用频率；
• 调用点是否单态、双态或多态；
• 递归深度；
• 编译器的代码大小预算；
• 异常处理和控制流复杂度；
• 内联后是否会导致机器码膨胀；
• 调用目标是否稳定。

调用点可以粗略分为：

单态调用：几乎总是同一个目标
双态调用：通常只有两个目标
多态调用：目标类型很多

单态调用最容易直接内联。双态调用可能生成类型判断：

if (对象类型 == A) {
    执行 A 的内联代码
} else if (对象类型 == B) {
    执行 B 的内联代码
} else {
    进入通用虚调用路径
}

多态调用通常更难内联，但“难”不等于“绝对不能”。JIT 可以根据类型概率和守护条件生成部分内联路径。

5.4 一个反例：方法很小，但仍然没有明显收益

interface Formatter {
    String format(int value);
}

static String render(Formatter formatter, int value) {
    return formatter.format(value);
}

即使 render 本身很小，如果运行时出现大量不同的 Formatter 实现，调用点可能变成高度多态。JIT 可能选择保留通用调用，原因是生成大量类型分支会：

• 增加代码尺寸；
• 降低指令缓存局部性；
• 增加分支预测压力；
• 仍然无法覆盖未知实现。

所以“把方法写得更短”不保证内联；“接口调用一定很慢”也不准确。真正决定结果的是运行时调用点的形态和编译器的成本模型。

---

6. 运行时假设：优化可以激进，但必须可撤销

JIT 最有价值的优化往往依赖尚未被规范永久保证的运行时事实。

例如某个调用点当前只见过 Dog：

static int soundLength(Animal animal) {
    return animal.sound().length();
}

JIT 可以把它优化成：

检查 animal 的实际类型是否为 Dog
  ├─ 是：执行 Dog.sound 的内联代码
  └─ 否：进入未优化的通用路径

这里的类型检查称为守护条件或保护条件。优化后的代码实际上包含两部分：

1. 快速路径：假设成立时执行；
2. 慢路径：假设不成立时恢复到更通用的执行方式。

这种设计把“运行时事实”转换成了可验证的机器码条件。它不要求 JVM 永远相信过去的观察，只要求在假设失效时采取正确动作。

---

7. 去优化：当已编译代码不再满足前提

7.1 去优化的定义

去优化（Deoptimization） 是让正在执行的优化机器码退出，并回到解释器或其他更保守代码版本，同时恢复出符合 Java 语义的栈帧和程序状态。

它不是“编译失败”，也不等价于“JVM 崩溃”。它是 JIT 为了使用投机优化而必须提供的回退机制。

7.2 一个完整的去优化过程

继续考虑：

static int soundLength(Animal animal) {
    return animal.sound().length();
}

可能发生以下步骤：

1. 编译器观察到调用点长期只出现 Dog；
2. 编译器内联 Dog.sound()；
3. 生成“实际类型必须是 Dog”的检查；
4. 程序后来传入 Cat；
5. 类型检查失败；
6. 机器码跳到去优化入口；
7. JVM 根据编译代码中的调试映射恢复解释器栈帧；
8. 从对应字节码位置继续执行；
9. 解释器执行正确的 Cat.sound() 调用；
10. JVM 可能重新收集 profile，并在之后生成更合适的版本。

恢复的不是机器寄存器的任意快照，而是一个能够表达 Java 方法调用状态的逻辑状态，包括：

• 当前字节码位置；
• 局部变量；
• 操作数栈；
• 调用者和被调用者栈帧；
• 尚未完成的表达式状态。

因此，JIT 编译代码需要保留足够的映射信息，即使这些信息不会用于普通机器码执行。

7.3 常见去优化原因

去优化可能由以下事件触发：

• 类型假设失效；
• 类层次结构发生变化；
• 某个被内联的方法需要恢复独立调用；
• 稀有异常路径实际发生；
• 编译器基于 profile 做出的分支假设失效；
• 某些检查被推迟到慢路径后发现失败；
• 类加载、重定义或其他运行时状态使旧代码失效。

其中，类加载是容易被忽略的一点。假设当前 JVM 只加载到了一个实现类，编译器据此认为某个虚调用实际上是单态的。之后如果加载了新的实现类，原来的假设可能失效。JVM 必须使相关编译代码失效，或者让它通过检查安全地转入通用路径。

7.4 去优化不是越少越好

如果完全不允许投机优化，编译器就只能基于静态保守信息生成代码，很多内联和类型特化机会会消失。

但去优化过于频繁也会产生问题：

• 执行线程反复退出优化代码；
• profile 不稳定；
• 编译线程不断重新编译；
• 代码缓存和编译 CPU 被浪费；
• 延迟出现尖峰。

因此，工程上应关注的是“去优化是否持续、是否集中在关键路径”，而不是把所有去优化都视为错误。一次偶发的去优化可能只是正常的自适应过程。

---

8. 解释执行、分层编译、内联和去优化的整体时序

下面的流程展示了一个典型但非规范强制的 HotSpot 路径：

flowchart TD
    A[加载并校验类文件] --> B[解释器执行字节码]
    B --> C[收集调用次数、回边和类型信息]
    C --> D{是否值得编译}
    D -- 否 --> B
    D -- 是 --> E[C1 或其他较快编译]
    E --> F[继续执行并收集更丰富的 profile]
    F --> G{是否值得更激进优化}
    G -- 否 --> E
    G -- 是 --> H[C2 或其他高级编译]
    H --> I[内联与投机优化后的机器码]
    I --> J{运行时假设是否仍成立}
    J -- 是 --> I
    J -- 否 --> K[去优化与状态恢复]
    K --> B
    B --> L[重新收集 profile]
    L --> D

关键路径是：

• 解释器提供初始执行能力和 profile；
• 编译器根据 profile 生成机器码；
• 内联使跨方法优化成为可能；
• 投机优化依赖运行时假设；
• 假设失效时去优化保证正确性；
• 去优化后的执行又会提供新证据。

这不是一次性“解释到编译”的转换，而是一个带反馈的自适应系统。

---

9. 证据：如何确认代码到底发生了什么

仅凭源码推测“这里一定被内联”或“这里一定被 C2 编译”是不可靠的。JIT 行为依赖：

• JVM 实现；
• CPU 架构；
• 启动参数；
• 方法调用频率；
• 类加载顺序；
• 输入数据分布；
• 运行时间；
• 其他线程造成的资源竞争。

因此需要区分三类证据：

1. 规范证据：JVMS 对字节码和可观察语义的规定；
2. 实现证据：编译日志、JFR 事件、JIT 日志；
3. 性能证据：经过预热、重复和统计处理后的基准结果。

9.1 用一个可运行示例产生编译活动

保存为 JitEvidence.java：

public class JitEvidence {
    interface Operation {
        int apply(int x);
    }

    static final class AddOne implements Operation {
        @Override
        public int apply(int x) {
            return x + 1;
        }
    }

    static final class MultiplyTwo implements Operation {
        @Override
        public int apply(int x) {
            return x * 2;
        }
    }

    static int run(Operation operation, int count) {
        int result = 0;
        for (int i = 0; i < count; i++) {
            result += operation.apply(i);
        }
        return result;
    }

    public static void main(String[] args) throws Exception {
        Operation operation = new AddOne();

        for (int round = 0; round < 20_000; round++) {
            run(operation, 1_000);
        }

        System.out.println(run(operation, 1_000));

        // 改变调用点的类型分布，观察运行时假设可能受到的影响。
        for (int round = 0; round < 20_000; round++) {
            Operation current =
                    (round & 1) == 0 ? new AddOne() : new MultiplyTwo();
            run(current, 1_000);
        }

        System.out.println(run(new MultiplyTwo(), 1_000));
    }
}

编译并运行：

javac JitEvidence.java

java \
  -XX:+PrintCompilation \
  -XX:+UnlockDiagnosticVMOptions \
  -XX:+PrintInlining \
  JitEvidence

前置条件是安装并配置 Java 25 LTS 的 JDK，而不是只有运行时的 JRE。PrintCompilation 通常用于查看方法何时进入编译列表；PrintInlining 用于查看编译器在相关编译过程中对调用点的内联判断。

输出格式和具体方法名会随 JDK 构建、平台和编译策略变化。常见输出可能包含：

• 方法被某个编译层编译；
• 方法重新编译；
• 方法被标记为失效；
• 某个调用点因为太大、太冷或类型不稳定而没有内联；
• 某个调用点因为类型稳定而被内联。

不要把“日志中出现了某个方法”直接解释成“最终所有调用都执行了这份机器码”。方法可能被重新编译，也可能在后续因依赖失效而退出优化版本。

9.2 为什么示例中的类型变化有意义

第一段循环长期只使用 AddOne：

run(new AddOne(), ...);

编译器可能观察到 operation.apply(i) 是单态调用，因而更容易：

1. 识别目标类型；
2. 内联 AddOne.apply；
3. 把 x + 1 放进调用方循环；
4. 消除一部分虚调用开销。

第二段交替使用 AddOne 和 MultiplyTwo，调用点变成双态甚至更复杂的类型分布。编译器可能选择：

• 为两个类型生成带守护检查的快速路径；
• 仅内联其中一个高概率目标；
• 保留通用虚调用；
• 使原先的单态优化版本失效并重新编译。

最终采取哪一种策略不能由 Java 源码单独确定，必须以日志或运行时事件为证据。

9.3 使用 JFR 记录运行时证据

Java Flight Recorder（JFR）可以记录编译、去优化、代码缓存和其他运行时事件。可以先运行：

java \
  -XX:StartFlightRecording=filename=jit.jfr,duration=30s,settings=profile \
  JitEvidence

运行结束后查看记录：

jfr summary jit.jfr
jfr print --events jdk.Compilation,jdk.Deoptimization jit.jfr

事件名称和字段可能随 JDK 版本、事件配置及构建有所差异。如果某个事件没有输出，不能直接推断“没有发生”；还需要检查：

• 事件是否存在于当前 JDK；
• recording settings 是否启用了该事件；
• 事件阈值是否过滤了记录；
• 程序是否在 recording 窗口内执行了相关行为。

JFR 记录的是运行时观察结果，例如编译事件、去优化事件、线程和 CPU 活动。JMC 可以用于图形化分析这些记录，但图形界面不能替代对实验设计和事件语义的理解。

9.4 日志与性能数据回答的是不同问题

编译日志可以回答：

• 哪些方法进入了编译流程；
• 某些调用点是否被尝试内联；
• 是否发生了重新编译或失效。

它不能单独回答：

• 优化后端到端请求是否更快；
• 延迟尾部是否改善；
• 编译线程是否抢占了业务 CPU；
• 代码缓存是否造成了压力；
• GC、锁竞争或 I/O 是否才是瓶颈。

性能测试则需要独立验证。一个简单的循环测试可以用于观察现象，但不适合作为严谨微基准：

long start = System.nanoTime();
int result = 0;

for (int round = 0; round < 20_000; round++) {
    result += JitEvidence.run(new JitEvidence.AddOne(), 1_000);
}

long elapsed = System.nanoTime() - start;
System.out.println(result + " " + elapsed);

它至少存在以下风险：

• 没有独立预热阶段；
• 没有多次测量和统计；
• 可能受到编译线程、GC 和操作系统调度影响；
• 结果可能被编译器识别为无用；
• 运行次数和输入规模可能不足以触发稳定的优化。

更严谨的微基准通常使用 JMH，让框架负责 fork、warmup、measurement、参数化和结果统计。对于“是否内联”的问题，JMH 负责减少测量噪声；JIT 日志或 JFR 则负责提供机制证据，两者不能互相替代。

---

10. 去优化的可观测失败表现

去优化本身通常不会抛出 Java 异常，也不会向应用直接报告“某个假设失效”。常见可观测表现包括：

• 编译日志中出现重新编译或失效信息；
• JFR 中出现去优化事件；
• 某段代码在预热后仍然表现出不稳定吞吐；
• 延迟测试中出现与编译活动同时发生的尖峰；
• CPU 时间增加，但业务操作数没有增加；
• 代码缓存或编译线程活动明显升高。

不过，这些现象没有唯一解释。例如延迟尖峰也可能由：

• Stop-The-World GC；
• 操作系统调度；
• 锁竞争；
• 页缺失；
• 容器 CPU 限制；
• 类加载或资源初始化；

引起。因此正确的诊断路径应当把 JFR 中的编译、去优化、GC、线程、锁和 CPU 时间放在同一时间线上观察，而不是看到一次尖峰就归因于 JIT。

---

11. 常见误解与边界

11.1 “Java 是解释型语言”

这是把语言、字节码和 JVM 实现混为一谈。Java 源码通常先编译为字节码；字节码可以由解释器执行，也可以由 JIT 编译为机器码，甚至可以由其他方式执行。更准确的说法是：Java 程序运行在虚拟机抽象上，具体实现可以混合解释与编译。

11.2 “每个方法只编译一次”

错误。方法可能被不同编译层次编译多次，可能存在普通入口和 OSR 入口，也可能因假设失效而使旧版本失效。

11.3 “内联就是复制源码”

错误。内联是在编译器中间表示和机器码生成阶段消除调用边界。编译器可以只内联部分路径，也可以在内联后继续做大量转换；最终机器码未必保留与源码相同的结构。

11.4 “去优化说明 JVM 出错了”

通常错误。去优化正是 JIT 实现投机优化时的安全回退机制。真正需要关注的是去优化频率和业务代价，而不是一次事件本身。

11.5 “加大编译强度一定更快”

不一定。更激进的编译会增加：

• 编译 CPU；
• 启动时间；
• 代码缓存占用；
• 运行时 profile 和失效维护成本；
• 低延迟场景中的背景活动。

在短生命周期命令行程序中，优化代码可能尚未执行足够多次就退出；在长生命周期服务中，优化成本通常更容易摊销。

11.6 “规范保证了 C1、C2 和固定阈值”

错误。JVMS 规定字节码的执行语义和可观察行为，不规定 HotSpot 的编译器名称、分层方式、阈值、内联预算或去优化实现。即使运行同一个 Java 25 LTS 程序，不同 JVM 实现、CPU 架构和启动选项也可能产生不同机器码。

---

12. 生产诊断中的证据链

分析一个 JIT 相关问题时，可以按以下因果链建立证据：

业务现象
  │
  ├─ 延迟、吞吐、CPU 或启动时间变化
  │
  ▼
时间线证据
  │
  ├─ JFR 中的编译、去优化、GC、线程和锁事件
  │
  ▼
编译决策证据
  │
  ├─ PrintCompilation
  ├─ PrintInlining
  └─ 必要时使用更详细的统一日志或编译日志
  │
  ▼
代码形态证据
  │
  ├─ 调用点类型分布
  ├─ 方法大小和调用频率
  ├─ 类加载顺序
  └─ 输入数据分布
  │
  ▼
性能验证
  │
  ├─ 预热后的基准
  ├─ 多次 fork
  ├─ 统计置信区间
  └─ 线上同时间窗口对比

如果只看到“没有内联”，还需要继续问：

• 调用点是否过冷；
• 目标方法是否过大；
• 调用点是否多态；
• 编译层次是否仍处于早期；
• 内联是否被代码尺寸预算限制；
• 该调用是否真的处于性能关键路径。

如果只看到“发生了去优化”，还需要继续问：

• 去优化发生在哪个方法；
• 触发原因是什么；
• 是否反复发生；
• 是否与类加载或类型分布变化同时发生；
• 业务延迟是否在同一时间窗口恶化。

---

13. 对 Java 25 LTS 的范围说明

本文讨论的是 Java 25 LTS 运行时上的通用 JVM JIT 原理，重点是 JVMS 所要求的执行语义，以及 HotSpot 中常见的解释器、分层编译、内联和去优化机制。

需要明确区分：

• 规范层面：JVMS 规定类文件、字节码和程序可观察语义；
• HotSpot 实现层面：C1、C2、解释器、profile、OSR 和去优化是常见实现机制；
• 诊断层面：JFR、JMC 以及编译日志用于观察实际运行，但事件、字段、输出格式和默认配置应以当前 JDK 构建为准；
• 性能层面：任何“内联后更快”“去优化导致延迟上升”的结论，都需要在目标 JDK、目标 CPU、目标输入和目标负载上测量。

最完整的理解不是记住“解释器慢、JIT 快”，而是掌握这条闭环：

解释器执行
→ 收集运行时证据
→ 分层编译
→ 内联和投机优化
→ 运行时假设失效
→ 去优化恢复
→ 重新收集证据并再次编译

JIT 的性能来自它能够利用运行时事实；JIT 的正确性来自这些事实始终带有可验证条件和可恢复路径。

---

系列导航与关联阅读

• 系列入口：Java 完整学习路线：从 Java 25 语言与 JVM 到 Spring、微服务和生产交付
• 上一篇：JVM 字节码工具：javap、ASM、Byte Buddy、Instrumentation 和验证
• 下一篇：JVM 逃逸分析：标量替换、锁消除、分配观测和误区

官方资料

• Java Virtual Machine Specification
• JDK Mission Control Documentation

本文依据 Java、Spring 与相关项目官方文档重新梳理；正文、示例与生产清单由 WR BLOG 编写。