JVM （十）Java虚拟机栈栈详解，一文透彻栈的那些事（方法调用，动态分派，栈上分配等）

我们已经从JVM（一） 面试必知——运行时数据区域
了解到Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。
本篇详解Java虚拟机栈相关内容

运行时栈帧结构

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

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

每个线程都有一个私有的虚拟徐栈，栈中每一个栈帧对应线程中每一个方法，当前栈帧对应当前方法

栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息，

局部变量表

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

局部变量表的容量以变量槽（Variable Slot）为最小单位，其中64位长度的long和 double类型的数据会占用两个变量槽，其余的数据类型只占用一个

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

private static void test1() {
        String a = "a";
    }
    private  void test2() {
        String a = "a";
    }

test1是静态方法，查看字节码文件，astore_0表示将栈顶元素“a”放入局部变量表索引为0的位置

test1是实例方法，查看字节码文件，astore_1表示将栈顶元素“a”放入局部变量表索引为1的位置，那么0的位置就是隐含的this了

变量槽复用

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

private static void test1() {
        {
            String a = "a";
        }
        String b = "b";//此时变量a已经出了作用于，变量b会复用a的变量槽
    }

代码中注释部分此时变量a已经出了作用域，变量b会复用a的变量槽

操作数栈

操作数栈（Operand Stack）也常被称为操作栈，它是一个后入先出（Last In First Out，LIFO） 栈。同局部变量表一样，操作数栈的最大深度也在编译的时候被写入到Code属性的max_stacks数据项 之中。操作数栈的每一个元素都可以是包括long和double在内的任意Java数据类型。32位数据类型所占 的栈容量为1，64位数据类型所占的栈容量为2。Javac编译器的数据流分析工作保证了在方法执行的任 何时候，操作数栈的深度都不会超过在max_stacks数据项中设定的最大值。

当一个方法刚刚开始执行的时候，这个方法的操作数栈是空的，在方法的执行过程中，会有各种 字节码指令往操作数栈中写入和提取内容，也就是出栈和入栈操作

两个不同栈帧作为不同方法的虚拟机栈的元素，是完全相互独立的。但是在 大多虚拟机的实现里都会进行一些优化处理，令两个栈帧出现一部分重叠。让下面栈帧的部分操作数 栈与上面栈帧的部分局部变量表重叠在一起，这样做不仅节约了一些空间，更重要的是在进行方法调 用时就可以直接共用一部分数据，无须进行额外的参数复制传递了

动态连接

每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方 法调用过程中的动态连接（Dynamic Linking）。我们知道Class文件的常量池中存 有大量的符号引用，字节码中的方法调用指令就以常量池里指向方法的符号引用作为参数。

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

静态解析

所有方法调用的目标方法在Class文件里面都是一个常量池中的符 号引用，在类加载的解析阶段，会将其中的一部分符号引用转化为直接引用，这种解析能够成立的前 提是：方法在程序真正运行之前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不 可改变的。换句话说，调用目标在程序代码写好、编译器进行编译那一刻就已经确定下来。这类方法 的调用被称为解析（Resolution）。

在Java语言中符合“编译期可知，运行期不可变”这个要求的方法，主要有静态方法和私有方法两 大类，前者与类型直接关联，后者在外部不可被访问，这两种方法各自的特点决定了它们都不可能通 过继承或别的方式重写出其他版本，因此它们都适合在类加载阶段进行解析

调用不同类型的方法，字节码指令集里设计了不同的指令。在Java虚拟机支持以下5条方法调用字 节码指令，分别是：

1. invokestatic。用于调用静态方法。
2. invokespecial。用于调用实例构造器init()方法、私有方法和父类中的方法。
3. invokevirtual。用于调用所有的虚方法。
4. invokeinterface。用于调用接口方法，会在运行时再确定一个实现该接口的对象。
5. invokedynamic。先在运行时动态解析出调用点限定符所引用的方法，然后再执行该方法。

前面4 条调用指令，分派逻辑都固化在Java虚拟机内部，而invokedynamic指令的分派逻辑是由用户设定的引 导方法来决定的。

总结

1. 只要能被invokestatic和invokespecial指令调用的方法，都可以在解析阶段中确定唯一的调用版本， Java语言里符合这个条件的方法共有静态方法、私有方法、实例构造器、父类方法4种，再加上被final 修饰的方法（尽管它使用invokevirtual指令调用），这5种方法调用会在类加载的时候就可以把符号引 用解析为该方法的直接引用。

2. 这些方法统称为“非虚方法”（Non-Virtual Method），与之相反，其他方 法就被称为“虚方法”（Virtual Method）

3. 虽然由于历史设计的原因，final方法是使用invokevirtual指令来调用的，但是因为它也无 法被覆盖，没有其他版本的可能，所以也无须对方法接收者进行多态选择，又或者说多态选择的结果 肯定是唯一的。在《Java语言规范》中明确定义了被final修饰的方法是一种非虚方法。

动态分派

我们把这种在运行期根据实 际类型确定方法执行版本的分派过程称为动态分派

invokevirtual指令的运行时解析过程大致分为以下几步

1. 找到操作数栈顶的第一个元素所指向的对象的实际类型，记作C。
2. 如果在类型C中找到与常量中的描述符和简单名称都相符的方法，则进行访问权限校验，如果 通过则返回这个方法的直接引用，查找过程结束；不通过则返回java.lang.IllegalAccessError异常。
3. 否则，按照继承关系从下往上依次对C的各个父类进行第二步的搜索和验证过程。
4. 如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。

动态分派是执行非常频繁的动作，而且动态分派的方法版本选择过程需要运行时在接收者类型的 方法元数据中搜索合适的目标方法，因此，Java虚拟机实现基于执行性能的考虑，真正运行时一般不 会如此频繁地去反复搜索类型元数据。面对这种情况，一种基础而且常见的优化手段是为类型在方法 区中建立一个虚方法表（Virtual Method Table，也称为vtable，与此对应的，在invokeinterface执行时也 会用到接口方法表——Interface Method Table，简称itable），使用虚方法表索引来代替元数据查找以 提高性能

虚方法表中存放着各个方法的实际入口地址。如果某个方法在子类中没有被重写，那子类的虚方 法表中的地址入口和父类相同方法的地址入口是一致的，都指向父类的实现入口。如果子类中重写了 这个方法，子类虚方法表中的地址也会被替换为指向子类实现版本的入口地址

方法返回地址

当一个方法开始执行后，只有两种方式退出这个方法。
第一种方式是执行引擎遇到任意一个方法 返回的字节码指令，这时候可能会有返回值传递给上层的方法调用者（调用当前方法的方法称为调用 者或者主调方法），方法是否有返回值以及返回值的类型将根据遇到何种方法返回指令来决定，这种 退出方法的方式称为“正常调用完成”（Normal Method Invocation Completion）。

另外一种退出方式是在方法执行的过程中遇到了异常，并且这个异常没有在方法体内得到妥善处 理。无论是Java虚拟机内部产生的异常，还是代码中使用athrow字节码指令产生的异常，只要在本方 法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，这种退出方法的方式称为“异常调用 完成（Abrupt Method Invocation Completion）”。一个方法使用异常完成出口的方式退出，是不会给它 的上层调用者提供任何返回值的

无论采用何种退出方式，在方法退出之后，都必须返回到最初方法被调用时的位置，程序才能继 续执行，方法返回时可能需要在栈帧中保存一些信息（怎么做还是要看具体的虚拟机实现），用来帮助恢复它的上层主调方法的执行状态

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

附加信息

《Java虚拟机规范》允许虚拟机实现增加一些规范里没有描述的信息到栈帧之中，例如与调试、 性能收集相关的信息，这部分信息完全取决于具体的虚拟机实现，这里不再详述。

在讨论概念时，一 般会把动态连接、方法返回地址与其他附加信息全部归为一类，称为栈帧信息。

逃逸分析

逃逸分析的基本原理是：分析对象动态作用域，当一个对象在方法里面被定义后，它可能被外部 方法所引用，例如作为调用参数传递到其他方法中，这种称为方法逃逸；甚至还有可能被外部线程访 问到，譬如赋值给可以在其他线程中访问的实例变量，这种称为线程逃逸；

从不逃逸、方法逃逸到线 程逃逸，称为对象由低到高的不同逃逸程度。 如果能证明一个对象不会逃逸到方法或线程之外（换句话说是别的方法或线程无法通过任何途径 访问到这个对象），或者逃逸程度比较低（只逃逸出方法而不会逃逸出线程），则可能为这个对象实 例采取不同程度的优化

栈上分配

栈上分配（Stack Allocations）：在Java虚拟机中，Java堆上分配创建对象的内存空间几乎是 Java程序员都知道的常识，Java堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引 用，就可以访问到堆中存储的对象数据。虚拟机的垃圾收集子系统会回收堆中不再使用的对象，但回 收动作无论是标记筛选出可回收对象，还是回收和整理内存，都需要耗费大量资源。

如果确定一个对 象不会逃逸出线程之外，那让这个对象在栈上分配内存将会是一个很不错的主意，对象所占用的内存 空间就可以随栈帧出栈而销毁。

在一般应用中，完全不会逃逸的局部对象和不会逃逸出线程的对象所 占的比例是很大的，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾收 集子系统的压力将会下降很多。栈上分配可以支持方法逃逸，但不能支持线程逃逸。

代码示例

private  void test2() {
        String a = "a";
    }

我们创建了对象“a”,但是该对象无论外部方法或者其他线程都是访问不到的，此时对象是分配在栈上随方法的退出而自动销毁

标量替换

标量替换（Scalar Replacement）：若一个数据已经无法再分解成更小的数据来表示了，Java虚拟 机中的原始数据类型（int、long等数值类型及reference类型等）都不能再进一步分解了，那么这些数据 就可以被称为标量。相对的，如果一个数据可以继续分解，那它就被称为聚合量（Aggregate），Java 中的对象就是典型的聚合量。

如果把一个Java对象拆散，根据程序访问的情况，将其用到的成员变量 恢复为原始类型来访问，这个过程就称为标量替换。

假如逃逸分析能够证明一个对象不会被方法外部 访问，并且这个对象可以被拆散，那么程序真正执行的时候将可能不去创建这个对象，而改为直接创 建它的若干个被这个方法使用的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上 （栈上存储的数据，很大机会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可 以为后续进一步的优化手段创建条件。标量替换可以视作栈上分配的一种特例，实现更简单（不用考 虑整个对象完整结构的分配），但对逃逸程度的要求更高，它不允许对象逃逸出方法范围内
代码示例

public int test(int x) { 
	int xx = x + 2;
	Point p = new Point(xx, 42); 
	return p.getX();
}

其中Point类的代码，就是一个包含x和y坐标的POJO类型
经过逃逸分析，发现在整个test()方法的范围内Point对象实例不会发生任何程度的逃逸， 这样可以对它进行标量替换优化，把其内部的x和y直接置换出来，分解为test()方法内的局部变量，从 而避免Point对象实例被实际创建，优化后的结果如下：

public int test(int x) {
	 int xx = x + 2;
	 int px = xx; 
	 int py = 42 return px; 
}

通过数据流分析，发现py的值其实对方法不会造成任何影响，那就可以放心地去做无效 代码消除得到最终优化结果

public int test(int x) { return x + 2; }

同步消除

同步消除（Synchronization Elimination）：线程同步本身是一个相对耗时的过程，如果逃逸分析 能够确定一个变量不会逃逸出线程，无法被其他线程访问，那么这个变量的读写肯定就不会有竞争， 对这个变量实施的同步措施也就可以安全地消除掉

private void test2(){
        System.out.println(new StringBuffer("a").append("b"));
    }

这块代码append方法是加锁的，但是经过逃逸分析能够确定变量不会逃逸出线程，无法被其他线程访问，此时虽然append方法是加锁的，但是执行引擎执行时是不会加锁的。

总结

关于逃逸分析的研究论文早在1999年就已经发表，但直到JDK 6，HotSpot才开始支持初步的逃逸 分析，而且到现在这项优化技术尚未足够成熟，仍有很大的改进余地。不成熟的原因主要是逃逸分析 的计算成本非常高，甚至不能保证逃逸分析带来的性能收益会高于它的消耗。如果要百分之百准确地 判断一个对象是否会逃逸，需要进行一系列复杂的数据流敏感的过程间分析，才能确定程序各个分支
执行时对此对象的影响。

可以试想一下，如果逃逸分析完毕后发现几乎找不到几个不逃逸的对象， 那这些运行期耗用的时间就白白浪费了，所以目前虚拟机只能采用不那么准确，但时间压力相对较小 的算法来完成分析。

曾经在很长的一段时 间里，即使是服务端编译器，也默认不开启逃逸分析，甚至在某些版本（如JDK 6 Update 18）中还 曾经完全禁止了这项优化，一直到JDK 7时这项优化才成为服务端编译器默认开启的选项。如果有需 要，或者确认对程序运行有益，用户也可以使用参数-XX：+DoEscapeAnalysis来手动开启逃逸分析， 开启之后可以通过参数-XX：+PrintEscapeAnalysis来查看分析结果。有了逃逸分析支持之后，用户可 以使用参数-XX：+EliminateAllocations来开启标量替换，使用+XX：+EliminateLocks来开启同步消 除，使用参数-XX：+PrintEliminateAllocations查看标量的替换情况。