概述
执行引擎是 Java 虚拟机最核心的组成部分之一。“虚拟机”是一个相对于“物理机”的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、硬件、指令集和操作系统层面上的，而虚拟机的执行引擎是有自己实现的，因此可以自行制定指令集与引擎的结构体系，并且能够执行那些不被硬件直接支持的指令集格式。
Java 虚拟机规范中制定了虚拟机字节码执行引擎的概念模型，这个概念模型成为各种虚拟机执行引擎的统一外观（Facade）。不同的虚拟机实现里面，执行引擎在执行 Java 代码的时候可能会有解释执行（通过解释器执行）和编译执行（通过及时编译器产生本地代码）两种选择，也可能两者兼备，甚至还可能会包含几个不同级别的编译器执行引擎。但从外观上看起来，所有的 Java 虚拟机的执行引擎都是一致的：输入的是字节码文件，处理过程是字节码解析的等效过程，输出的是执行结果。
运行时栈帧结构
栈帧（Stack Frame）是用于支持虚拟机运行方法调用和方法执行的数据结构，它是虚拟机运行时数据区中的虚拟机栈（Virtual Machine Stack）的栈元素。栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息。每一个方法从调用开始执至执行完成的过程，都对应着一个栈帧在虚拟机里从入栈到出栈的过程。
每一个栈帧都包含了局部变量表、操作数栈、动态连接、方法返回地址和一些额外的附加信息。在编译程序代码的时候，栈帧中需要多大的局部变量表，多深的操作数栈都已经完全确定了，并且写入了方法表的 Code 属性之中。
一个线程中的方法调用链可能会很长，很多方法都是同时处于执行状态。对于执行引擎来说，在活动线程中，只有位于栈顶的栈帧才是有效的，称为当前栈帧（Current Stack Frame），与这个栈帧相关联的方法称为当前方法（Current Method）。执行引擎运行的所有字节码指令都只针对当前栈帧进行操作，在概念模型上，典型的栈帧结构如下。
局部变量表
局部变量表（Local Variable Table）是一组变量值存储空间，用于存放方法参数和方法内部定义的局部变量表。在 Java 程序编译为 Class 文件时，就在方法的 Code 属性的 max_locals 数据项中确定了该方法所需要分配的局部变量表的最大容量。
局部变量表的容量以变量槽（Variable Slot，下称 Slot）为最下单位，虚拟机规范中导向性的说道每个 Slot 都应该能存放一个 boolean、byte、char、short、float、reference 或 returnAddress 类型的数据，这 8 种数据类型，都可以使用 32 位或更小的物理内存来存放，但这种描述与明确指出“每个 Slot 占用 32 位长度的内存空间”是有一些差别的，它允许 Slot 的长度可以随着处理器操作系统或虚拟机的不同而发生变化。只要保证即使在 64 为虚拟机中使用了 64 位的物理内存空间去实现一个 Slot，虚拟机仍要使用对齐和补白的手段让 Slot 在外观上看起来与 32 位虚拟机中的一致。
一个 Slot 可以起存放一个 32 位以内的数据类型，Java 中占用 32 位以内的数据类型有 boolean、byte、char、short、int、float、reference 和 returnAddress 8 种类型。第 7 种 reference 类型表示一个对象实例的引用，虚拟机规范既没有说明他的长度，也没有明确指出这种引用应该有怎样的结构。但一般来说，虚拟机实现至少都应该通过这个引用做到两点：一是从此引用中直接或间接地查找到对象在 Java 堆中的数据存放的其实地址索引，二是次引用中直接或间接地查找到对象所属数据类型在方法区中的存放的类型信息，否则无法实现 Java 语言规范中定义的语法约束约束。第 8 种即 returnAddress 类型目前已经很少见了，它是为字节码指令 jsr、jst_w 和 ret 服务的，指向了一条字节码指令的地址，很古老的 Java 虚拟机曾经使用这几条指令来实现异常处理，现在已经由异常表代替。
对于 64 位的数据类型，虚拟机会以高位对齐的方式为其分配两个连续的 Slot 空间。Java 语言中明确第（reference 类型则可能是 32 位也可能是 64 位）64 位的数据类型只有 long 和 double 两种。这里把 long 和 double 数据类型分割存储的做法与 “long 和 double 的非原子性协定“中把一次 long 和 double 数据类型读写分割为两次 32 为读写的做法有些类似，不过，由于局部变量表建立在线程的堆栈上，是线程私有的数据，无论读写两个连续的 Slot 是否为原子操作，都不会引起线程数据安全问题。
虚拟机通过索引定位的方式使用局部变量表，索引值的范围是从 0 开始至局部变量表最大的 Slot 数量。如果访问的是 32 位数据类型的变量，索引 n 就代表了使用第 n 个 Slot，如果是 64 位数据类型的变量，则说明会同时使用 n 和 n+1 两个 Slot。对于两个相邻的共同存放一个 64 位数据的两个 Slot，不允许任何方式淡村访问其中的某一个，Java 虚拟机规范中明确要求了如果遇到这种操作的字节码序列，虚拟机应该在类加载的校验阶段抛出异常。
在方法执行时，虚拟机是使用局部变量表完成参数值到参数变量列表的传递过程的，如果要执行的是实例方法（非 static 的方法），那局部变量表中的第 0 位索引的 Slot 默认用于传递方法所属对象实例的引用，在方法中可以通过关键字“this”来访问这个隐含的参数。其余参数则按照参数表顺序排序，占用从 1 开始的局部变量表 Slot， 参数表分配完毕后，再根据方法体内部定义的变量顺序和作用域分配其余的 Slot。
为了尽可能节省栈帧空间，局部变量表中的 Slot 是可以重用的，方法体中定义的变量，其作用域不一定会覆盖整个方法体，如果当前字节码 PC 计数器的值已经超出了某个变量的作用域，那这个对应的 Slot 就可以交个其他变量使用。这样的设计除了节省栈帧空间以外，还会伴随一些额外的副作用，例如，在某些情况下，Slot 的复用会直接影响到系统的垃圾回收行为。
1
2
3
4
public static void main(String[] args) {
byte[] placeholder = new byte[64 * 1024 * 1024];
System.gc();
}
以上代码即向内存填充了 64MB 的数据，然后通知虚拟机进行垃圾收集。在虚拟机运行参数中加上 “-verbose:gc” 来看看垃圾收集的过程，发现在 System.gc() 运行后并没有回收这 64MB 的内存，下面是运行结果。
1
2
[GC (System.gc()) 68880K->66104K(125952K), 0.0012534 secs]
[Full GC (System.gc()) 66104K->66043K(125952K), 0.0070797 secs]
没有回收 placeholder 所占用的内存能说的过去，因为在执行 System.gc() 时，变量 placeholder 还处于作用域之内，虚拟机自然不敢回收 placeholder 的内存。当我们把代码改成如下，然后在运行一次。
1
2
3
4
5
6
public static void main(String[] args) {
{
byte[] placeholder = new byte[64 * 1024 * 1024];
}
System.gc();
}
加入花括号之后，placeholder 的作用域被限制在花括号之内，从代码逻辑上讲，在执行 System.gc() 的时候，placeholder 已经不可能再被访问了，但发现还有 64MB 的内存没有被回收，运行结果如下：
1
2
[GC (System.gc()) 68880K->66104K(125952K), 0.0027400 secs]
[Full GC (System.gc()) 66104K->66043K(125952K), 0.0089934 secs]
如果我们在调用 System.gc() 之前加入一行 int a = 0;，变成如下代码。
1
2
3
4
5
6
7
public static void main(String[] args) {
{
byte[] placeholder = new byte[64 * 1024 * 1024];
}
int a = 0;
System.gc();
}
运行发现，这次内存被正确的回收了。
1
2
[GC (System.gc()) 68880K->66104K(125952K), 0.0027665 secs]
[Full GC (System.gc()) 66104K->507K(125952K), 0.0075104 secs]
placeholder 能否被税收的根本原因是：局部变量表中的 Slot 是否还存在有关于 placeholder 数组对象的引用。第一次修改中，代码虽然离开了 placeholder 的作用域，但在此之后，没有任何对局部变量表的读写操作，placeholder 原本所占用的 Slot 还没有被其他变量所复用，所以作为 GC Roots 一部分的局部变量表仍然保持着对它的关联。这种关联没有被及时打断，在绝大部分情况下影响都轻微。但如果遇到一个方法，其后面的代码需要耗时很长的操作，前面有定义了占用了大量内存、实际上已经不会在使用的变量，手动将其设置为 null 值（用来代替那句 int a = 0，把变量对应的局部变量表 Slot 清空）扁扁的是一个绝对无意义的操作，这种操作可以作为一种在极特殊情形（对象占用大、才方法的栈帧长时间不能被回收、方法调用次数达不到 JIT 的编译条件）下的“奇技”来使用。
经过 JIT 编译器后，才是虚拟机执行代码的主要方式，赋 null 值得操作在经过 JIT 编译后就会被消除掉，这时候变量设置为 null 就是没有意义的。字节码被编译为本地代码后，对 GC Roots 的枚举与解释执行时期有巨大差别，以前面例子来看，第二段代码在经过 JIT 编译后，System.gc() 执行时就可以正确地回收掉，无需写成第三段代码的样子。
操作数栈
操作数栈（Operand Stack）也常称为操作栈，它是一个后入先出（Last In First Out，LIFO）栈。操作数栈的每一个元素都可以是任意的 Java 数据类型（Java 的值类型），包括 long 和 double，32位数据类型所占的的栈容量为 1 ，64 位数据类型所占的栈容量为 2。在方法执行的任何时候，操作数栈的深度都不会超过 max_stacks 数据项中设定的最大值。
在概念模型中，两个栈帧作为虚拟机栈的元素，是完全互相独立的。但在大多虚拟机的实现里都会做一些优化处理，另两个栈帧出现一部分重叠。让下面栈帧的部分操作数栈与上面的部分局部变量表重叠在一起，这样在进行方法调用时就可以共用一部分数据，无需进行额外的参数复制传递，重叠的过程如图所示。
Java 虚拟机的解释执行引擎称为 “基于栈的执行引擎”，其中所指的“栈”就是操作数栈。
动态连接
每个栈帧都包含一个运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接（Dynamic Linking）。我们知道 Class 文件的常量池中存有大量的符号引用，字节码中的方法调用指令就以常量池中指向的方法的符号引用作为参数。这些符号引用一部分在类加载阶段活着第一次使用的时候就转化为直接引用，这种转化成为静态解析。另外一部分将在每一次运行期间转化为直接引用，这部分成为动态连接。
方法返回地址
当一个方法开始执行后，只有两种方式可以退出这个方法。第一种方式是执行引擎遇到任意一个方法返回的字节码指令，这时候可能会有返回值传递给上层的方法调用者（调用当前方法的方法称为调用者），是否有返回值和返回值的类型将根据遇到何种方法返回指令来决定，这种退出方法的方式称为正常完成出口（Normal Method Invocation Completion）。
在方法执行过程中遇到异常，并且这个异常没有在方法体内的到护理，无论是 Java 虚拟机内部产生的异常，还是代码中使用 athrow 字节码指令产生的异常，只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，这种退出方法的方式称为异常完成出口（Abrupt Method Invocation Completion）。一个方法使用异常完成出口的方式退出，是不会给他的上层调用者产生任何返回值的。
无论采用何种退出方式，在方法退出之后，都需要返回到方法被调用的位置，程序才能继续执行，方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层方法的执行状态。一般来说，方法退出时，调用者的 PC 计数器的值可以作为返回地址，栈帧中很可能会保存这个计数器值。而方法异常退出时，返回地址是要通过异常处理器表来确定的。栈帧中一般不会保存这部分信息。
方法退出的过程实际上就等同于把当前栈帧出栈，因此退出时可能执行的操作有：恢复上层方法的局部变量表和操作数栈，把返回值（如果有的话）压入调用者栈帧的操作数栈中，调整 PC 计数器的值以指向方法调用指令后的一条指令等。
附加信息
在实际开发中，一般会把动态连接、方法返回地址与其他附加信息全部归为一类，称为栈帧信息。