很多人学JVM，学到类加载、运行时数据区的时候还挺有感觉，一进入执行引擎就卡住了。我自己也是这样的状态——类加载器把字节码读进来，内存模型把对象放好，这些好歹还能“看到”东西，而执行引擎抽象得多，总觉得隔着一层纱。直到有一次被问到“你写的Java代码到底是怎么变成CPU上真正执行的指令的”，我才意识到自己对执行引擎的理解还停留在“中间某个引擎把字节码跑起来”这种模糊印象上。
这一章我重新梳理了执行引擎，尽量不背书，而是从三个角度去拆：执行引擎的输入是什么、处理过程是什么、输出到哪里去。沿着这条线走下来，栈帧结构、字节码执行过程、解释器与JIT的分工、方法调用的分派机制，以及逃逸分析这类现代优化，都变成了一个整体。这份笔记适合正在系统学习JVM底层原理的读者，也适合那些已经写过不少Java代码、但想搞明白“多态到底怎么实现的”“字符串拼接为什么变快了”的人。
1. 执行引擎在JVM里的定位：从字节码到机器指令的必经之路
1.1 统一输入、处理、输出三个基本概念
执行引擎可以看作虚拟机里的“CPU”，它的职责和物理CPU是高度对齐的：取指令、译码、执行、写回结果。只不过物理CPU拿到的指令是机器码，而JVM执行引擎拿到的指令是class文件里的字节码。
- 输入：字节码文件（.class），本质是JVM规范定义的一套指令序列。
- 处理：逐条解释执行，或者把热点方法编译成当前平台的机器码后执行。
- 输出：操作结果写回运行时数据区，最常见的是写回操作数栈、局部变量表、堆中的对象，或者直接作为方法返回值。
我在学习时曾经犯过一个糊涂：以为执行引擎负责“把字节码翻译成Java代码”。这是完全反的。字节码本身已经是编译产物，执行引擎不需要把它还原成源码，只需要让它产生正确的执行效果。
1.2 为什么不能直接在物理CPU上跑字节码
这个问题值得先想清楚。字节码是面对抽象虚拟机设计的指令集，它的操作数栈模型、符号引用、指令编码等等，都是在“Java虚拟机”这个抽象平台上定义的。而你的物理CPU可能跑在x86上，也可能跑在Arm上，不同架构的寄存器数量、指令格式、寻址方式完全不一样。
所以执行引擎必须做一层翻译。解释器是“边翻译边执行”，JIT是“先把一批字节码整体翻译成机器码再执行”。这一层翻译让Java代码拥有跨平台能力，同时也意味着执行引擎的性能直接决定了Java程序的运行时表现。
1.3 执行引擎和运行时数据区是怎么配合的
执行引擎不是凭空工作的，它每执行一条指令，都要从运行时数据区取数据、写数据。可以这样理解：如果运行时数据区是内存，执行引擎就是CPU，而虚拟机栈里的栈帧就是它的“寄存器窗口”。
栈帧里放着局部变量表、操作数栈、动态链接信息、方法返回地址。字节码指令操作的主要对象，就是当前栈帧里的局部变量表和操作数栈。指令执行过程中如果需要对象，就从局部变量表或常量池里拿到引用，再通过引用去访问堆中的对象。这个过程和物理CPU通过寄存器、内存地址访问数据非常相似。
明确了这一点，再看后面关于栈帧的内容，就会很清楚：栈帧不是可有可无的理论概念，它是执行引擎运转时最核心的数据结构。
2. 栈帧：执行引擎按帧运转的根本依据
2.1 一个方法调用对应一个栈帧
虚拟机栈里的基本单元是栈帧。每调用一个方法，执行引擎就会在虚拟机栈里压入一个新的栈帧；方法执行完毕，不管是正常返回还是异常抛出，这个栈帧就被弹出。
所以方法嵌套调用的深度，就是虚拟机栈里栈帧的数量。递归没有出口时栈帧无限增长，最终抛出StackOverflowError，本质上就是栈空间被占满了。
学习栈帧时，重点关注四个部分：局部变量表、操作数栈、动态链接、方法返回地址。后面的字节码执行过程，几乎每一刻都在和这四个部分打交道。
2.2 局部变量表：Slot与容量规则
局部变量表存放方法参数和方法内部定义的局部变量。它的最小单位是Slot，一个Slot可以容纳32位以内的数据，比如int、float、引用类型。long和double这种64位类型，会占两个连续的Slot。
有两个细节容易忽略。
第一个细节：实例方法（非static方法）的局部变量表第0位永远是this，后面才依次排列方法参数。所以在一个实例方法里，字节码通过aload_0就能拿到当前对象的引用。静态方法没有this，局部变量表直接从参数开始。
第二个细节：Slot是可以复用的。如果某个局部变量的作用域结束，编译器可能让后面的变量复用它之前占用的Slot。这意味着局部变量表的大小不一定是“变量数量”，而要看活动变量同时存在的最大区间。class文件里对应的是Code属性中的max_locals，这个值在编译期就已经确定了。
2.3 操作数栈：深度已经写死在class文件里
操作数栈是执行引擎最常用的“工作台”。字节码指令从局部变量表或常量池取数据压入栈，指令执行时从栈顶弹出操作数，计算完再把结果压回去。
这里有个新手容易困惑的点：操作数栈的深度不是运行时才决定的，而是编译期就确定了。class文件中Code属性里有max_stack，JVM在加载类的时候就能为这个栈帧预留足够空间。因为每条字节码指令对操作数栈的影响是固定的，比如iadd需要两个操作数、弹出两个压入一个，净变化-1，编译器可以通过线性扫描整个方法体，算出操作数栈的最大深度。
你可能会好奇：为什么非要搞一个栈来做运算？后面第3章会专门讲，这一章先记住一个结论：基于栈的指令集设计简单、跨平台容易，但同样的计算需要更多指令来搬移数据，这是JVM早期性能不如本地编译代码的原因之一。
2.4 动态链接与方法返回地址
栈帧里保存着一个指向当前类常量池的引用，用来支持动态链接。字节码里的方法调用指令，一开始只能拿到常量池中的符号引用，比如“某个类的某个方法”。在执行引擎真正调用它之前，符号引用需要被解析成直接引用，或者运行时根据实际类型查找目标方法，这就是动态链接的用处。
方法返回地址也很好理解。调用方法的时候，当前方法的PC执行到调用指令的位置需要被记住，被调方法返回之后，执行引擎才能回到调用点继续往下走。如果是异常导致方法提前退出，则需要通过异常表查找是否有对应的异常处理器，找不到就逐层向外抛出。
3. 字节码指令的执行过程：从一段add方法看操作数栈的吞吐
3.1 先看一段最直观的字节码
与其空谈，不如直接拿一段Java方法，编译后看它长什么样。假设我们有这样一个静态方法：
public static int add(int a, int b) { int c = a + b; return c; }javap反编译之后，字节码大概是这样：
public static int add(int, int); Code: 0: iload_0 1: iload_1 2: iadd 3: istore_2 4: iload_2 5: ireturn我来逐步解释这几条指令，你跟着操作数栈的变化走一遍就懂了。
- iload_0：把局部变量表第0个Slot（参数a）压入操作数栈。栈顶变为a。
- iload_1：把局部变量表第1个Slot（参数b）压入操作数栈。栈顶变为b。
- iadd：弹出栈顶两个int，做加法，把结果压回栈。栈顶变为a+b。
- istore_2：弹出栈顶结果，存入局部变量表第2个Slot（变量c）。
- iload_2：把变量c重新压入栈。
- ireturn：弹出栈顶int，作为方法返回值返回。
你会看到，整个方法的运算过程，就是不断在“把数据压上栈、从栈上弹下来”之间往返。Java代码里简简单单的一行c = a + b，在字节码层面被拆成了五条指令。如果换成x86的寄存器指令，同样的加法可能只需要一两条指令。这就是基于栈的指令集的特点：简洁、规整，但不追求指令数量最小化。
3.2 执行引擎内部到底是怎么跑这些指令的
字节码解释执行的核心，是一个大的指令分发循环。大致流程是这样的：
- 从当前PC位置读取一个字节码。
- 根据操作码判断这是条什么指令，进入对应的处理逻辑。
- 执行指令：可能需要访问操作数栈、局部变量表、对象引用等。
- 更新PC，继续取下一条，除非遇到了跳转、返回、异常等改变控制流的指令。
这个“取指—译码—执行—更新PC”的循环，其实就是CPU的经典工作流程。只不过这里译码的输入是字节码，而不是机器码。
注意一个细节：字节码是逐个字节编码的，很多常用指令为了省空间，直接用了专用操作码，比如iload_0、iload_1、iload_2、iload_3就是iload后面跟不同索引的快捷版本。这是JVM设计上的小优化，毕竟class文件要尽量紧凑。
3.3 为什么JVM坚持选“基于栈”而不是“基于寄存器”
这是学习执行引擎时最容易冒出来的疑问。现代CPU几乎都是基于寄存器的，x86、Arm都是寄存器架构，JVM用栈不是自讨苦吃吗？
这里面有历史原因，也有工程原因。
从跨平台角度看，栈架构的虚拟机描述起来最简单。你只需要定义清楚“操作数栈”“局部变量表”和指令语义，不依赖任何物理寄存器。不同CPU的寄存器数量、宽度、命名都不一样，如果字节码指令集设计成寄存器架构，那JVM规范就要针对每种物理平台做映射，复杂度会高很多。
从编译角度看，javac生成字节码变得极其简单。表达式的计算结果天然可以压栈，方法传参也可以约定好按顺序压栈，编译器后端不需要做复杂的寄存器分配。寄存器分配在那时候是编译原理里的重头戏，放到JVM里反而会拖慢整个工具链。
当然有代价。栈指令数量多，解释器执行时频繁压栈弹栈，内存访问压力大。后来JIT编译器登场，实际上是把字节码先转成中间表示，再做现代编译器该做的优化，最后生成针对当前物理平台的机器码，这时寄存器分配问题就交给JIT内部的优化管线处理了。所以你可以这么说：解释执行时是“纯栈模型”，编译执行时栈模型只作为源语言，真正的执行效率由JIT的寄存器分配决定。
4. 解释器与JIT编译器：两条执行路线怎么分工协作
4.1 解释器：逐条翻译每条字节码
解释器是最古老的执行方式，思路非常直接：拿一条字节码，翻译一条，执行一条。JVM里的解释器本质上是一个巨大的switch循环，每个操作码对应一段处理代码。
它的优点是启动快。程序刚开始运行时，不需要额外编译时间，类加载完成就能立刻逐条执行。缺点也很明显：每执行一条字节码都要经历取指、译码、分发，而且每条指令自带的语义比较上层，频繁从栈中存取数据，所以解释执行的峰值性能上不去。
这也解释了为什么早期Java程序“跑得慢”。单纯靠解释器执行，再简单的循环也可能产生海量字节码指令，而这些指令又要经过解释器的分发循环，性能自然不如直接执行本地机器码。
4.2 JIT编译器：把热点代码变成真正的机器码
JIT（Just-In-Time，即时编译）的思路完全不同：不去逐条翻译，而是等到某个方法被频繁执行，成为“热点代码”之后，把整个方法编译成当前平台的机器码，再直接执行机器码。
这里有两个关键机制：热点检测和编译分层。
热点检测基于计数器。方法调用计数器和回边计数器分别统计方法被调用的次数和循环回边的次数。当一个方法的热度达到阈值，就会进入编译队列。早期JVM只有两个编译级别，后来发展了分层编译：先用优化程度较低但编译速度较快的编译器快速把热点方法编译掉，让程序尽快跑起来；如果方法继续变热，再用优化力度更大的编译器做第二轮深度编译。
两边的关系可以做成这样一张表：
| 对比维度 | 解释执行 | JIT编译执行 |
|---|---|---|
| 启动时间 | 快，无需预热 | 需要等待编译触发 |
| 峰值性能 | 较低 | 很高，经过深度优化 |
| 编译开销 | 无 | 有CPU开销和内存开销 |
| 适用场景 | 启动阶段、低频方法 | 长时间运行的热点方法 |
4.3 生产环境为什么默认是混合模式
很多人以为“JIT快的多，那就全交给JIT”。实际不是这样。JIT编译是有成本的，编译本身也要消耗CPU和内存。程序启动初期很多方法可能只执行一两次，这时候把它们编译成机器码，编译成本大于收益，反而拖慢启动。
所以主流JVM默认采用混合模式：解释器和JIT编译器共存。启动阶段靠解释器快速跑起来，运行中检测热点，把真正值得编译的方法交给JIT。这样既保证了启动速度，又能在长稳运行中逼近峰值性能。
虚拟机的执行模式可以通过参数控制：
- -Xint：纯解释模式，禁用JIT，适合调试和观察解释行为。
- -Xcomp：纯编译模式，启动即尝试编译所有方法，容易造成启动慢、内存占用高。
- -Xmixed：混合模式，也就是默认模式。
我用纯编译模式做过对比实验，把一个启动类里几十个方法全部强制编译，结果启动时间涨了好几倍，而后续执行性能的提升十分有限。这个实验让我彻底理解了混合模式的合理性。
4.4 如何实际观察代码是被解释还是被编译
调试执行引擎，最常用的开关是打印编译信息。JVM参数-XX:+PrintCompilation会在每个方法被JIT编译时打印一行日志，内容包括方法名、编译耗时、编译层级等。我排查线上性能问题时，第一步经常就是打开这个参数，看热点方法有没有被正确编译，以及卡在哪个编译层级。
方法被解释还是被编译，你是看不出来的，但通过编译日志能推断：如果某个高频方法迟迟没有出现在编译日志里，那它大概率还在解释执行，性能瓶颈多半就出在那。这时候可以考虑调整编译阈值，或者通过代码层面的改造让方法更容易触发内联等优化，后面第6章会展开讲。
5. 方法调用背后的分派机制：从invokestatic到invokedynamic
5.1 重载与静态分派：编译期就能知道答案
Java里方法的重载，选择哪个版本是在编译期决定的。编译器根据参数的“静态类型”来选方法，这就是静态分派。我见过不少人把重载和重写搞混，弄出一个经典笑话：方法接收参数是父类，实际传入子类对象，结果调用的还是父类版本的方法。下面这段代码就是典型：
class Animal {} class Dog extends Animal {} static void say(Animal a) { System.out.println("animal"); } static void say(Dog d) { System.out.println("dog"); } Animal a = new Dog(); say(a); // 运行时虽然a指向Dog对象，但编译期静态类型是Animal，所以调用say(Animal)如果传null进去，编译器还会按“最具体版本”规则选择say(Dog)，因为Dog比Animal更具体。这也是一个容易踩坑的行为，面试里经常拿来问。
静态分派在字节码层面对应invokestatic指令，或者invokespecial指令调用构造器、私有方法、super方法。这些方法的目标在编译期基本可以确定，执行引擎解析符号引用后，不需要再查表。
5.2 重写与动态分派：invokevirtual的运行时查找
重写对应的字节码指令主要是invokevirtual。当调用a.shout()，方法调用指令的参数是常量池里的符号引用，但真正执行哪个方法，取决于a的实际类型。
JVM的常规做法是给每个类生成一张虚方法表。类的加载和准备阶段，虚拟机会把该类可调用的虚方法入口地址填进虚方法表。子类重写父类方法时，对应表项直接指向子类的实现。这样invokevirtual执行时，只要根据实际类型找到类的虚方法表，按方法索引定位入口，就能完成一次O(1)的动态分派。
这就是Java多态的底层机制之一。不要把多态理解成什么神秘魔法，它本质上就是运行时查一次虚方法表。
需要补充一句：invokevirtual不一定总是走动态分派。如果JIT能证明某个虚方法在当前上下文只有一个可能的实现，它可能做去虚化优化，直接把调用变成静态绑定，这样就能被方法内联处理。所以写代码时，如果一个方法没必要被继承重写，加final反而可能帮助JIT优化。
5.3 invokeinterface与接口分派的性能代价
接口方法调用走的是invokeinterface。为什么接口调用通常比类方法调用更耗时？因为接口的实现类很多，不能在编译期预知调用点的接收者具体属于哪个类。早期实现里，接口方法解析需要遍历接口方法表，查找成本确实比虚方法表高。
现代JVM做了不少优化，实际性能差距已经缩小，但原理上仍然可以说：接口调用在分派阶段的复杂度天然高于类方法调用。这不是让你别用接口，而是提醒你，在超高频率的调用路径上，接口调用可能成为一个可观测的热点。遇到这种情况，可以考虑把接口调用改成抽象类调用，或者用final实现类来帮助JIT去虚化。
5.4 invokedynamic：把绑定的控制权交给运行时
Java 7引入invokedynamic指令的初衷，是支持动态类型语言。Java 8之后，lambda表达式也让这条指令进入了绝大多数Java开发者的日常。
invokedynamic最大的特点是：方法绑定的逻辑不再由JVM硬编码，而是由程序员自己定义引导方法。指令首次执行时，会调用一个引导方法，引导方法返回一个调用点对象，调用点内部关联着目标方法句柄。之后每次执行invokedynamic，直接调用这个调用点即可。
一个我感受特别深的变化是字符串拼接。早期版本里，多个字符串用+拼接会被javac改造成StringBuilder的链条，中间会生成大量临时StringBuilder对象。后来较新的JDK版本中，javac把字符串拼接改成了invokedynamic实现，运行时统一由引导方法选择拼接策略。JIT再一内联，很多临时对象直接被优化没了。同样一段拼接代码，在老版本和新版本上的实际性能差异非常大，这就是执行引擎和编译器优化共同作用的结果。
6. 现代JVM的执行优化：逃逸分析、方法内联与实战观察
6.1 逃逸分析在做什么
逃逸分析是JIT里非常关键的一项优化，它的作用不是生成代码，而是分析对象的动态作用域：对象是只在方法内使用，还是可能被传到方法外面？会不会被多个线程共享？
如果对象不逃逸，JVM可以做很多事情。常见的优化是标量替换：把一个对象拆成几个基础类型字段，直接在栈帧或寄存器里存放，而不是去堆里分配一整块内存。比如方法内部new了一个Point对象，只用了它的x和y，优化后可能就是两个局部变量，对象本身根本不存在。另一个是栈上分配的观念，对象直接分配在栈帧里，方法返回时栈帧销毁，对象随之消失，完全不需要垃圾收集器操心。
需要注意一点：主流的HotSpot JVM实现里，逃逸分析后真正“在栈上分配对象”的情况其实比较少，更常见的是标量替换。我在学习时被各种资料误导过，以为逃逸分析会让对象直接分配在栈上。实际观察测试结果，大多数受益场景都是对象被拆成标量，避免了堆分配的开销。
6.2 锁消除与同步优化：执行引擎偷偷帮你删掉无意义的竞争
逃逸分析的另一个衍生优化是锁消除。如果JIT判断一个对象不会逃逸出当前线程，那么这个对象上的同步操作就没有实际竞争意义，锁消除优化会把锁去掉。
举个极端例子：如果你在代码里写了synchronized(new Object())这种无意义的锁，JIT可能在运行时把同步指令直接忽略掉。我见过有新人写代码，为了“保险”在局部对象上加锁，其实线程之间根本不会共享它。JIT优化后这些锁代码可能完全不生效，这时候你反而要警惕：你以为的同步保护，可能什么都没保护。
另外，Java里的锁升级路径——偏向锁、轻量级锁、重量级锁——也都和解释器、JIT的同步逻辑相关。锁会有多级状态，是为了在无竞争、低竞争、高竞争场景下各取所需。
6.3 方法内联：影响执行速度最明显的优化之一
方法内联把被调用方法的方法体直接复制到调用方内部，省掉了方法调用本身的栈帧创建、参数传递、跳转开销。对高频小方法来说，内联收益极其明显。
JIT决定是否内联一个方法，会看方法字节码大小、调用热度、调用深度、方法是否为虚方法等。私有方法、静态方法最容易内联；虚方法如果JIT能确定实现唯一，也会先做去虚化，再内联。很多JVM调优经验里说“小方法更适合JIT”，本质原因就在这里。
我在排查性能时经常配合两个参数一起用：-XX:+PrintCompilation查看编译情况，-XX:+PrintInlining查看内联决策。打开之后你能看到某个方法为什么被内联，或者为什么没有被内联——比如调用次数不够、方法太大、invokeinterface没法去虚化。这些信息比瞎猜性能瓶颈有用得多。
6.4 从执行引擎视角重新看日常性能问题
理解执行引擎之后，很多性能问题会有新的解释。举几个我在实践中遇到过的例子。
有一次排查某个高频接口变慢，方法调用链里有一个抽象类模板方法，内部通过一个protected虚方法调用子类实现，每个请求都走动态分派。优化方式很简单：在确认子类不会被继续继承的前提下，把子类方法改成final，让JIT能够去虚化并内联。改造后接口响应时间下降不少，代码逻辑几乎没动。
还有一次，某个上报场景里大量拼接日志字符串，代码风格是连续+号拼接。我推测新版JDK的invokedynamic拼接策略加上方法内联后，性能不会太差，于是先观察编译日志，确认热点方法被内联后才放心。如果你还在手动new StringBuilder去拼字符串，在较新版本的JDK上反而可能不如直接用+，因为编译器端的拼接优化已经被调得相当成熟了。
最后说说我对执行引擎的观察方法：不要靠背参数，要根据证据调优。默认混合模式在绝大多数情况下是最优解，强行关闭解释器或调整编译阈值，往往会带来新的问题。让JIT按它自己的节奏工作，你只需要把代码写得更“可优化”——多用final、控制方法体积、减少不必要的接口动态分派，剩下的交给执行引擎。
学习执行引擎这章，我最深刻的体会是：Java程序的性能，不是单纯靠语言层面的优化技巧决定的，更关键的是你写出来的代码能不能被JIT看懂、能不能被内联、能不能被标量替换。花时间理解字节码和JIT决策逻辑，比背一百条调优参数都值。写代码的时候有意识地为JIT提供更多可优化空间，你会发现很多传统的“性能优化经验”在新版本JDK上已经不再适用了。亲手打开-XX:+PrintCompilation和-XX:+PrintInlining，观察你自己的项目，可能比看十篇笔记都更有收获。
