运行时栈帧结构

Java虚拟机以方法作为最基本的执行单元，“栈帧”（Stack Frame）则是用于支持虚拟机进行方法调用和方法执行背后的数据结构，它也是虚拟机运行时数据区中的虚拟机栈（Virtual Machine Stack）的栈元素。

每一个方法从调用开始至执行结束的过程，都对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程。

局部变量表

局部变量表（Local Variables Table）是一组变量值的存储空间，用于存放方法参数和方法内部定义的局部变量。

在Java程序被编译为Class文件时，就在方法的Code属性的max_locals数据项中确定了该方法所需分配的局部变量表的最大容量。

最小单位：变量槽（Variable Slot）
- 一个 Slot 中可以存放：boolean，byte，char，short，int，float，reference，returnAddress (少见)；
虚拟机可通过局部变量表中的 reference 做到：
- 查找 Java 堆中的实例对象的起始地址或索引；
- 查找方法区中的 Class 对象。

当一个方法被调用时，Java虚拟机会使用局部变量表来完成参数值到参数变量列表的传递过程，即实参到形参的传递。

如果执行的是实例方法（没有被static修饰的方法），那局部变量表中第0位索引的变量槽默认是用于传递方法所属对象实例的引用，在方法中可以通过关键字“this”来访问到这个隐含的参数。其余参数则按照参数表顺序排列，占用从1开始的局部变量槽，参数表分配完毕后，再根据方法体内部定义的变量顺序和作用域分配其余的变量槽。

变量槽复用

为了尽可能节省栈帧耗用的内存空间，局部变量表中的变量槽是可以重用的，方法体中定义的变量，其作用域并不一定会覆盖整个方法体，如果当前字节码PC计数器的值已经超出了某个变量的作用域，那这个变量对应的变量槽就可以交给其他变量来重用。

但是变量槽的复用也会影响系统的垃圾收集行为。

public static void main(String[] args)(){
    // 向内存中填充64MB的数据
    byte[] placeholder = new byte[64*1024*1024];
    System.gc();
}

-verbose:gc 查看运行结果：

1
2
3

[GC (System.gc())  68813K->66304K(123904K), 0.0034797 secs]
[Full GC (System.gc())  66304K->66204K(123904K), 0.0086225 secs]  
// 没有被回收

因为在执行System.gc()时，变量placeholder还处于作用域之内，虚拟机自然不敢回收掉placeholder的内存。

// 修改作用域
public static void main(String[] args)(){
    {
    // 向内存中填充64MB的数据
    byte[] placeholder = new byte[64*1024*1024];
    }
    System.gc();
}

再次查看执行结果：发现依旧没有被回收

我们再尝试再System.gc()调用前加入一行“int a=0；”

public static void main(String[] args) {
    {
    	byte[] placeholder = new byte[64 * 1024 * 1024];
    }
    int a = 1; // 新加一个赋值操作
    System.gc();
}

-verbose:gc 输出：

1
2
3

[GC (System.gc())  68813K->66320K(123904K), 0.0017394 secs]
[Full GC (System.gc())  66320K->668K(123904K), 0.0084337 secs]  
// 内存被回收了

placeholder能否被回收的根本原因就是：
局部变量表中的变量槽是否还存有关于 placeholder 数组对象的引用。
第一次修改中，代码虽然已经离开了 placeholder 的作用域，但在此之后，再没有发生过任何对局部变量表的读写操作， placeholder 原本所占用的变量槽还没有被其他变量所复用，所以作为GC Roots一部分的局部变量表仍然保持着对它的关联。
第二次修改后，int a 占用了原来 placeholder 所在的 Slot，所以可以被 GC 掉了。

操作数栈

操作数栈（Operand Stack）也常被称为操作栈，它是一个后入先出（Last In First Out，LIFO）栈。

同局部变量表一样，操作数栈的最大深度也在编译的时候被写入到Code属性的max_stacks数据项之中。

元素可以是任意 Java 类型，32 位数据占 1 个栈容量，64 位数据占 2 个栈容量；
Java 虚拟机的解释执行称为：基于栈的执行引擎，其中 “栈” 指的就是操作数栈；

另外在概念模型中，两个不同栈帧作为不同方法的虚拟机栈的元素，是完全相互独立的。但是在大多虚拟机的实现里都会进行一些优化处理，令两个栈帧出现一部分重叠。

让下面栈帧的部分操作数栈与上面栈帧的部分局部变量表重叠在一起，这样做不仅节约了一些空间，更重要的是在进行方法调用时就可以直接共用一部分数据，无须进行额外的参数复制传递了，重叠的过程如下图所示。

动态链接

每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接（Dynamic Linking）。

我们知道Class文件的常量池中存有大量的符号引用，字节码中的方法调用指令就以常量池里指向方法的符号引用作为参数。

这些符号引用一部分会在类加载阶段或者第一次使用的时候就被转化为直接引用，这种转化被称为静态解析。
另外一部分将在每一次运行期间都转化为直接引用，这部分就称为动态连接。

方法返回地址

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

执行引擎遇到任意一个方法返回的字节码指令。
在方法执行的过程中遇到了异常，并且这个异常没有在方法体内得到妥善处理。

无论采用何种退出方式，在方法退出之后，都必须返回到最初方法被调用时的位置，程序才能继续执行，方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层主调方法的执行状态。

方法推出操作有：等同于把当前栈帧出栈

恢复上层方法的局部变量表和操作数栈；
把返回值压入调用者栈帧的操作数栈；
调整 PC 计数器指向方法调用后面的指令。

Free Talk

距离上次看JVM的文章以前过去一个多月了，现在再重新开始感觉很吃力，写的进度很慢。其次是关于字节码执行机制的文章很少，我之前也没有了解过这个，写的时候只能参考《深入理解Java虚拟机》。最后限于篇幅和精力，这篇文章只写了字节码执行机制的一部分，后续会补上。

参考资料

GitHub
《深入理解Java虚拟机》