字节码执行引擎

运行时栈帧结构

每一个栈帧都包括了局部变量表、操作数栈、动态连接、方法返回地址和一些额外的附加信息。在编译程序代码的时候，栈帧中需要多大的局部变量表，多深的操作数栈就已经完全确定了，并且写入到方法表的 Code 属性之中，因此一个栈帧需要分配多大的内存，不会受程序运行期变量数据的影响，而仅仅取决于具体的虚拟机实现。

一个线程中的方法调用链可能会很长，很多方法都同时处于执行状态。对于虚拟机而言，在活动线程中，只有位于栈顶的栈帧才是有效的，称为当前栈帧。与这个栈帧相关联的方法称为当前方法。执行引擎运行的所有字节码指令都是针对当前栈帧进行操作，在概念模型上，典型的栈帧结构如下图所示：

局部变量表

局部变量表是一组变量值存储空间，用于存放方法参数和方法内部定义的局部变量。在 Java 程序编译为 Class 文件时，就在方法的 Code 属性的 max_locals 数据项中确定了该方法需要分配的局部变量表的最大容量。

局部变量表的容量以变量槽（Variable Slot）为最小单位，一个 Slot 可以存放一个32位以内的数据类型， Java 中占用32位以内的数据类型有 boolean、byte、char、short、int、float、reference 和 returnAddress 8中类型，其中 reference 类型表示一个对象实例的引用，一般来说，虚拟机实现都应能通过这个引用做到两点：一是从此引用中直接或间接地查找到对象在 Java 堆中的数据存放的起始地址索引，二是此引用中直接或间接地查找到对象所属的数据类型在方法区中存储的类型信息。

对于64位的数据类型，虚拟机会以高位对齐的方式为其分配两个连续的 Slot 空间，Java 语言中明确的（reference 类型可能是32位可能是64位）64位的数据类型只有 long 和 double两种，值得一提的是，这里把 long 和 double 数据类型分割存储的做法与“long 和 double的非原子性协定”中把一次 long 和 double 数据类型读写分割位两次32位读写的做法有些类似。不过由于局部变量表建立在线程的堆栈上，是线程私有的数据，无论读写两个连续的 Slot 是否是原子操作，都不会引起数据安全问题。

在方法执行时，虚拟机是使用局部变量表来完成参数值到参数列表的传递过程的，如果执行的是实例方法，那局部变量表中第0位索引的 Slot 默认是用于传递方法所属对象实例的引用，在方法中可以使用 this 关键字来访问到这个隐含的参数。其余参数则按照参数表顺序排列，占用从1开始的局部变量 Slot，参数表分配完毕后，再根据方法体内部定义的变量顺序和作用域分配其余的 Slot。

为了尽可能的节省栈帧空间，Slot 是可以复用的，方法体中定义的变量，其作用域并不一定会覆盖整个方法体，如果当前字节码 PC 计数器的值已经超过了某个变量的作用域，那么这个变量对应的 Slot 就可以交给其他变量使用。不过这样的复用设计，有时候会直接影响到系统的垃圾收集行为。代码如下：

public static void main (String[] args) {
    byte[] b = new byte[64 * 1024 * 1024];
    System.gc();
}

我们在虚拟机参数上加上“－verbose:gc” 来查看垃圾收集的过程，发现系统并没有回收这 64MB 的内存，因为在执行 GC 时变量 b 还处于作用域内，虚拟机自然不敢回收 b 的内存。我们改变一下代码如下：

public static void main (String[] args) {
  	static {
        byte[] b = new byte[64 * 1024 * 1024];    
    }
    System.gc();
}

从代码逻辑上讲，在执行 System.gc(); 的时候，b 已经不可能再被访问了，但是执行代码会发现 64 MB内存还是没有被回收。这是为什么？在解释为什么之前，我们先对代码进行第二次修改如下：

public static void main (String[] args) {
  	{
        byte[] b = new byte[64 * 1024 * 1024];    
    }
    int a = 0;
    System.gc();
}

运行代码发现，这次64 MB内存被正确回收了。在上述代码中，b 能否被回收的根本原因是：局部变量表中的 Slot 是否还存在有关于 b 数组对象的引用。第一次修改中，代码虽然已经离开了 b 的作用域，但在此之后，没有任何局部变量表的读写操作，b 原本所占用的 Slot 还没有被其他变量复用，所以作为 GC Roots 的一部分的局部变量表仍然保持着对它的关联。

关于局部变量表，还有一点可能会对实际开发产生影响，就是局部变量不像前面介绍的类变量存在“准备阶段”，即使在初始化阶段程序员没有为类变量赋值也没关系，类变量仍然有一个在准备阶段被系统赋予的初始值，但局部变量则不一样，如果一个局部变量定义了但是没有赋初始值是不能使用的。

操作数栈

同局部变量表一样，操作数栈的最大深度也在编译的时候写入到 Code 属性的 max_stacks 数据项中。操作数栈的每一个元素都可以是任意的 Java 数据类型，包括 long 和 double。32位数据类型占用的栈容量为1，64位数据类型占用栈容量为2。

操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，在编译程序代码的时候，编译器要严格保证这一点，在类检验阶段的数据流分析中还要再次验证这点。以 iadd 指令为例，这个指令用于整型数加法，它在执行时，栈顶的两个元素的数据类型必须是 int 型。

动态连接

每个栈帧都包含一个指向运行时常量池的中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接，通过前面已经知道了 Class 文件的常量池中存放有大量的符号引用，字节码的方法调用指令就以常量池中指向方法的符号引用作为参数。这些符号引用一部分会在类加载阶段或者第一次使用的时候就转化为直接引用，这种转化称为静态解析。另外一部分将在每次运行期转化为直接引用，这部分称为动态解析。后面会有详细讲解。

方法返回地址

当一个方法开始执行后，只有两种方式可以退出这个方法：

当执行引擎遇到任意一个方法返回的字节码指令，这时候可能会有返回值传递给上层的方法调用者（调用当前方法的方法称为调用者），是否有返回值和返回值类型讲根据遇到何种方法返回指令来决定，这种方式称为正常完成出口。
在方法执行过程中遇到了异常，并且这个异常没有在方法体内得到处理，无论是 Java 虚拟机内部的异常，还是代码中使用 athrow 字节码指令产生的异常，只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，这种退出称为异常完成出口。

无论哪种退出方式，在方法退出之后，都需要返回到方法被调用的位置，程序才能继续执行，方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层方法的执行状态。一般来说，方法正常退出时，调用者的 PC 计数器可以作为返回地址，栈帧中很可能会保存这个计数器的值。而方法异常退出时，返回地址是要通过异常处理器表来确定的，栈帧中一般不会保存这部分信息。

方法退出的过程就相当于把当前栈帧出栈，因此退出时可能执行的操作有：恢复上层方法的局部变量表和操作数栈，把返回值（如果有的话）压入调用者栈帧的操作数栈中，调整 PC 计数器的值以指向方法调用指令后面的一条指令等。

方法调用

方法调用并不等同于方法执行，方法调用阶段的唯一任务就是确定调用方法的版本（即调用哪一个方法），暂时还不涉及方法内部的具体运行过程。前面讲过 Class 文件的编译过程中不包括传统编译中的连接步骤，一切方法调用在 Class 文件里面存储的都只是符号引用，而不是方法在实际运行时内存布局中的入口地址（相当于前面说的直接引用）。

解析

在 Java 语言中符合“编译期可知，运行期不可变”这个要求的方法，主要包括静态方法和私有方法两类，前者直接与类型关联，后者在外部不可见，这两种方法各自的特点决定了它们都不可能通过继承或别的方式重写其他版本，因此它们都适合在类加载阶段进行解析。与之对应的，在 Java 虚拟机中提供5条方法调用字节码指令：

invokestatic：调用静态方法。
invokespecail：调用实例构造器 <init>方法、私有方法和父类方法。
invokevirtual：调用所有的虚方法。
invokeinterface：调用接口方法，会在运行时再确定一个实现此接口的对象。
invokedynamic：先在运行时动态解析出调用点限定符所引用的方法