概述
虚拟机与物理机的执行引擎区别:
- 物理机执行引擎:直接建立在处理器、缓存、指令集和操作系统层面上的,可以近似理解为基于硬件的
- 虚拟机执行引擎:由软件自行实现,因此可以不受物理条件制约地定制指令集与执行引擎的结构体系,能够执行哪些不被硬件直接支持的指令集格式。
运行时栈帧结构
Java虚拟机以方法作为最基本的执行单元,“栈帧”(Stack Frame)则是用于支持虚拟机进行方法调用和方法执行背后的数据结构,它也是虚拟机运行时数据区中的虚拟机栈(Virtual Machine Stack)的栈元素。栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息。每一个方法从调用开始至执行结束的过程,都对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程。
每一个栈帧都包括了局部变量表、操作数栈、动态连接、方法返回地址和一些额外的附加信息。在编译时所需的局部变量表大小和操作数栈就已经确定。
在活动线程中,只有位于栈顶的方法才是在运行的,只有位于栈顶的栈帧才是生效的,其被称为“当前栈帧”(Current Stack Frame),与 这个栈帧所关联的方法被称为“当前方法”(Current Method)。执行引擎所运行的所有字节码指令都只针对当前栈帧进行操作。
局部变量表
局部变量表的容量以变量槽(Variable Slot)为最小单位。一个变量槽可以存放一个数据类型。局部变量表中的变量槽是可以重用的。
由于局部变量表是建立在线程堆栈中的,属于线程私有的数据,无论读写两个连续的变量槽是否为原子操作,都不会引起数据竞争和线程安全问题。
Java虚拟机通过索引定位的方式使用局部变量表,索引值的范围是从0开始至局部变量表最大的变量槽数量。32位数据类型的变量,索引N就代表了使用第N个变量槽,64位数据类型的变量,同时使用第N和N+1两个变量槽。对于两个相邻的共同存放一个64位数据的两个变量槽,虚拟机不允许采用任何方式单独访问其中的某一个。
当一个方法被调用时,即实参到形参的传递。如果执行的是实例方法(没有被static修饰的方法),那局部变量表中第0位索引的变量槽默认是用于传递方法所属对象实例的引用,即为了方法中使用this来表示实例引用。其余参数则按照参数表顺序排列,占用从1开始的局部变量槽,参数表分配完毕后,再根据方法体内部定义的变量顺序和作用域分配其余的变量槽。
操作数栈
操作数栈(Operand Stack)称为操作栈,是后入先出栈。操作数栈的深度在编译的时候被写入到Code属性的max_stacks数据项中。32位数据类型的栈容量是1,64位数据类型所占的栈容量是2。
方法的执行过程最终体现的是执行一系列出栈和入栈的操作指令过程。
在概念模型中,两个不同栈帧作为不同的方法的虚拟机栈的元素,是完全相互独立的。但是在大多数虚拟机实现做了优化,另两个栈帧出现一部分重叠让下面栈帧的部分操作数栈与上面栈帧的部分局部变量表重叠在一起,这样做不仅节约了一些空间,更重要的是在进行方法调用时就可以直接共用一部分数据,无须进行额外的参数复制传递了。
Java虚拟机的解释执行引擎被称为“基于栈的执行引擎”,里面的“栈”就是操作数栈。
动态连接
每个栈帧都包含一个指向运行时常量中该栈帧所属方法的引用持有这个引用是为了支持方法调用过程中的动态连接(Dynamic Linking)。字节码中常量池中的符号引用,一部分在类加载或第一次使用就被转为直接引用,称为静态解析。另一部分将在每次运行期间都转为直接引用,称为动态连接。
方法返回地址
方法的执行只有两种方式退出方法:
- 正常调用完成(Normal Method Invocation Completion):执行引擎遇到任意一个方法返回的字节码指令。
- 异常调用完成(Abrupt Method Invocation Completion):方法执行的过程中遇到了异常,并且这个异常没有在方法体内得到妥善处理,不会给它的上层调用者提供任何返回值的。
在方法退出之后,都必须返回到最初方法被调用时的位置,程序才能继续执行,方法返回时可能需要在栈帧中保存一些信息,用来帮助恢复它的上层主调方法的执行状态。 一般来说,方法正常退出时,主调方法的PC计数器的值就可以作为返回地址,栈帧中很可能会保存这个计数器值。而方法异常退出时,返回地址是要通过异常处理器表来确定的,栈帧中就一般不会保存这部分信息。
方法退出的过程实际上等同于把当前栈帧出栈,因此退出时可能执行的操作有:恢复上层方法的局部变量表和操作数栈,把返回值(如果有的话)压入调用者栈帧的操作数栈中,调整PC计数器的值以指向方法调用指令后面的一条指令等。
方法调用
方法调用阶段唯一的任务就是确定被调用方法的版本 (即调用哪一个方法),暂时还未涉及方法内部的具体运行过程。
解析
所有方法调用的目标方法在Class文件里面都是一个常量池中的符号引用,在类加载的解析阶段,会将部分符号引用转化为直接引用,前提是:方法在程序执行前后的调用版本是不可改变的。这类方法的调用叫解析(Resolution)。
适合类加载阶段进行解析的有静态方法和私有方法两大类,前者与类型直接关联,后者在外部不可被访问。
不同方法调用字节码指令:
- invokestatic。用于调用静态方法。
- invokespecial。用于调用实例构造器
<init>()
方法、私有方法和父类中的方法。 - invokevirtual。用于调用所有的虚方法。
- invokeinterface。用于调用接口方法,会在运行时再确定一个实现该接口的对象。
- invokedynamic。先在运行时动态解析出调用点限定符所引用的方法,然后再执行该方法。前面4 条调用指令,分派逻辑都固化在Java虚拟机内部,而invokedynamic指令的分派逻辑是由用户设定的引导方法来决定的。
非虚方法(Non-Virtual Method):调用的方法都可以在解析阶段中确定唯一的调用版本,Java中符合的方法有:静态方法、私有方法、实例构造器、父类方法和被final修饰的方法,在类加载时把符号引用解析为直接引用。反之其他的都被称为虚方法(Virtual Method)
/**
* 方法静态解析演示
*/
public class StaticResolution {
public static void sayHello() {
System.out.println("hello world!");
}
public static void main(String[] args) {
StaticResolution.sayHello();
}
}
//调用的方法在编译就明确以常量池项的形式固化在字节码指令参数中(#5)
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=0, locals=1, args_size=1
0: invokestatic #5 // Method sayHello:()V
3: return
LineNumberTable:
line 9: 0
line 10: 3
解析调用一定是个静态的过程,在编译期间就完全确定。
另一种主要的方法调用形式:分派调用(Dispatch),可能是静态或者动态的,按分派依据的宗量数可分为单分派和多分派,两两组合构成:静态单分派、静态多分派、动态单分派、动态多分派。
分派
- 静态分派
/**
* 方法静态分派演示
* 输出结果是:
* hello, guy!
* hello, guy!
*/
public class StaticDispatch {
static abstract class Human {
}
static class Man extends Human {
}
static class Woman extends Human {
}
public void sayHello(Human guy) {
System.out.println("hello, guy!");
}
public void sayHello(Man man) {
System.out.println("hello, gentleman!");
}
public void sayHello(Woman man) {
System.out.println("hello, lady!");
}
public static void main(String[] args) {
Human man = new Man();
Human woman = new Woman();
StaticDispatch sr = new StaticDispatch();
sr.sayHello(man);
sr.sayHello(woman);
}
}
Human称为变量的“静态类型”(Static Type)或者“外观类型”(Apparent Type),后面的Man称为变量的“实际类型”(Actual Type)或者叫“运行时类型”(Runtime Type)。静态类型和实际类型在程序中都可能会发生变化,区别是静态类型的变化仅仅在使用时发生,变量本身的静态类型不会被改变,并且最终的静态类型是在编译期可知的;而实际类型变化的结果在运行期才可确定。
在方法接收者已经确定是对象“sr”的前提下,使用哪个重载版本,就完全取决于传入参数的数量和数据类型。代码中故意定义了两个静态类型相同,而实际类型不同的变量,但虚拟机(或者准确地说是编译器)在重载时是通过参数的静态类型而不是实际类型作为 判定依据的。由于静态类型在编译期可知,所以在编译阶段,Javac编译器就根据参数的静态类型决定 了会使用哪个重载版本,因此选择了sayHello(Human)作为调用目标,并把这个方法的符号引用写到 main()方法里的两条invokevirtual指令的参数中。
所有依赖静态类型来决定方法执行版本的分派动作,都称为静态分派。
如果方法重载有多个版本,会确定一个相对更合适的版本。
-
/** *注释sayHello(char arg)方法 *输出结果 *hello int *发生了自动类型转换,'a'除了可以代表一个字符串,还可以代表数字97 */
/** *继续注释掉say Hello(int arg)方法 *输出结果 *hello long *发生了两次自动类型转换,'a'转型为整数97之后,进一步转型为长整数97L,匹配了参数类型 为long的重载。 实际还能发生多次自动转型,按照char>int>long>float>double顺序 */
/** *注释掉sayHello(long arg)方法 *输出结果 *hello Character *发生了一次自动装箱,'a'被包装为它的封装类型java.lang.Character,所以匹配到了参数类型为 Character的重载 */
/** *继续注释掉sayHello(Character arg)方法 *输出结果 *hello Serializable *因为java.lang.Serializ able是java.lang.Charact er类实现的一个接口,当自动装箱之后发现还是找不到装 箱类,但是找到了装箱类所实现的接口类型,所以紧接着又发生一次自动转型。char可以转型成int, 但是Charact er是绝对不会转型为Int eger的,它只能安全地转型为它实现的接口或父类。 */
/** *继续注释掉sayHello(Serializable arg)方法 *输出结果 *hello Object *char装箱后转型为父类了,如果有多个父类,那将在继承关系中从下往上开始搜索,越接 上层的优先级越低。 */
/** *say Hello(Object arg)也注释掉 *输出结果 *hello char ... *优先级最低 */
动态分派
/**
*方法动态分派演示
*输出结果
* man say hello
* woman say hello
* woman say hello
*/
public class DynamicDispatch {
static abstract class Human {
protected abstract void sayHello();
}
static class Man extends Human {
@Override
protected void sayHello() {
System.out.println("man say hello");
}
}
static class Woman extends Human {
@Override
protected void sayHello() {
System.out.println("woman say hello");
}
}
public static void main(String[] args) {
Human man = new Man();
Human woman = new Woman();
man.sayHello();
woman.sayHello();
man = new Woman();
man.sayHello();
}
}
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=3, args_size=1
0: new #2 // class part8/DynamicDispatch$Man
3: dup
4: invokespecial #3 // Method part8/DynamicDispatch$Man."<init>":()V
7: astore_1
8: new #4 // class part8/DynamicDispatch$Woman
11: dup
12: invokespecial #5 // Method part8/DynamicDispatch$Woman."<init>":()V
15: astore_2
16: aload_1
17: invokevirtual #6 // Method part8/DynamicDispatch$Human.sayHello:()V
20: aload_2
21: invokevirtual #6 // Method part8/DynamicDispatch$Human.sayHello:()V
24: new #4 // class part8/DynamicDispatch$Woman
27: dup
28: invokespecial #5 // Method part8/DynamicDispatch$Woman."<init>":()V
31: astore_1
32: aload_1
33: invokevirtual #6 // Method part8/DynamicDispatch$Human.sayHello:()V
36: return
0~15的字节码是准备动作,作用是建立man和woman内存空间、调用Man和Woman类型的实例构造器,将两个实例引用存放在第1、2个局部变量表的变量槽中,对应代码:
Human man = new Man();
Human woman = new Woman();
16~21的字节码是将创建的两个对象压入栈顶,两条invokevirtual引用的都是Human.sayHello,但是最终执行的目标方法是不同的。invokevirtual指令的运行时解析过程大致分为:
- 找到操作数栈顶的第一个元素所指向的对象的实际类型,记作C。
- 如果在类型C中找到与常量中的描述符和简单名称都相符的方法,则进行访问权限校验,如果通过则返回这个方法的直接引用,查找过程结束;不通过则返回java.lang.IllegalAccessError异常。
- 否则,按照继承关系从下往上依次对C的各个父类进行第二步的搜索和验证过程。
- 如果始终没有找到合适的方法,则抛出java.lang.AbstractMethodError异常。
正是因为invokevirtual指令执行的第一步就是在运行期确定接收者的实际类型,所以两次调用中的 invokevirtual指令并不是把常量池中方法的符号引用解析到直接引用上就结束了,还会根据方法接收者的实际类型来选择方法版本,这个过程就是Java语言中方法重写的本质。我们把这种在运行期根据实际类型确定方法执行版本的分派过程称为动态分派。
/**
* 字段不参与多态
* 输出结果
* I am Son, i have $0
* I am Son, i have $4
* This gay has $2
* 当子类声明了与父类同名的字段时,虽然在子类的内存中两个字段都会存在,但是子类的字段会遮蔽父类的同名字段。
* 输出两句都是“I am Son”,这是因为Son类在创建的时候,首先隐式调用了Father的构造函数,而 Father构造函数中对showMeTheMoney()
* 的调用是一次虚方法调用,实际执行的版本是 Son::showMeTheMoney()方法,所以输出的是“I am Son”。而这时候虽然父类的money字段已
* 经被初始化成2了,但Son::showMeTheMoney()方法中访问的却是子类的money 字段,这时候结果自然还是0,因为它要到子类的构造函数执行
* 时才会被初始化。 main()的最后一句通过静态类型访问到了父类中的money ,输出了2。
*/
public class FieldHasNoPolymorphic {
static class Father {
public int money = 1;
public Father() {
money = 2;
showMeTheMoney();
}
public void showMeTheMoney() {
System.out.println("I am Father, i have $" + money);
}
}
static class Son extends Father {
public int money = 3;
public Son() {
money = 4;
showMeTheMoney();
}
public void showMeTheMoney() {
System.out.println("I am Son, i have $" + money);
}
}
public static void main(String[] args) {
Father gay = new Son();
System.out.println("This gay has $" + gay.money);
}
}
-
单分派与多分派
方法的接收者与方法的参数统称为方法的宗量。根据分派基于多少种宗量,可以将分派划分为单分派和多分派两种。单分派是根据一个宗量对目标方法进行选择,多分派则是根据多于一个宗量对目标方法进行选择。
运行阶段中虚拟机的选择,也就是动态分派的过程。在执行“son.hardChoice(newQQ())”这行代码时,更准确地说,是在执行这行代码所对应的invokevirtual指令时,由于编译期已经决定目标方法的签名必须为hardChoice(QQ),虚拟机此时不会关心传递过来的参数“QQ”到底是“腾讯QQ”还是“奇瑞QQ”,因为这时候参数的静态类型、实际类型都对方法的选择不会构成任何影响,唯一可以影响虚拟机选择的因素只有该方法的接受者的实际类型是Father还是Son。因为只有一个宗量作为选择依据,所以Java语言的动态分派属于单分派类型。
Java语言是一门静态多分派,动态单分派语言。
-
虚拟机动态分派的实现
而且动态分派的方法版本选择过程需要运行时在接收者类型的方法元数据中搜索合适的目标方法,因此,Java虚拟机面对这种情况,一种基础而且常见的优化手段是为类型在方法区中建立一个虚方法表(Virtual Method Table,也称为vtable,与此对应的,在invokeinterface执行时也会用到接口方法表——Interface Method Table,简称itable),使用虚方法表索引来代替元数据查找以提高性能
虚方法表中存放着各个方法的实际入口地址。如果某个方法在子类中没有被重写,那子类的虚方法表中的地址入口和父类相同方法的地址入口是一致的,都指向父类的实现入口。如果子类重写了这个方法,子类虚方法表的地址也会被替换成执行子类实现版本的入口地址。上图的hardChoice方法父类和子类指向的地址是不一样的。
为了程序实现方便,具备相同签名的父类、子类的虚方法表中具有一样的索引序号,当类型转换时,只需变更查找的虚方法表即可。虚方法表一般在类加载的连接阶段进行初始化,准备了类的变量初始值后,虚拟机会把该类的虚方法表也一同初始化完毕。
动态类型语言支持
动态类型语言
动态类型语言:动态类型语言的关键特征是它的类型检查的主体过程是在运行期而不是编译期进行的。而Java是在编译期就进行类型检查过程的语言,所以是静态类型语言。
public static void main(String[] args) {
int[][][] array = new int[1][0][-1];
}
上面代码能正常编译,但是运行会出现NegativeArraySizeException运行时异常,是在运行期抛出的。相反是连接时异常,例如NoClassDefFoundError,即导致连接时异常的代码放在一条根本无法被执行的路径分支上,类加载时也会照样抛出异常。
什么是类型检查?
obj.println("hello world");
假设上面一行是Java语言,并且变量obj的静态类型为java.io.PrintStream,那变量obj的实际类型就必须是PrintStream的子类(实现PrintStream接口的类)才是合法的。否则,哪怕obj属于一个确定包含有println(String)方法相同签名方法的类型,但只要它与PrintStream接口没有继承关系,代码依然不可能运行——因为类型检查不合法。
但是相同的代码在ECMAScript(JavaScript)中情况则不一样,无论obj具体是何种类型,无论其继承关系如何,只要这种类型的方法定义中确实包含有println(String)方法,能够找到相同签名的方法,调用便可成功。
产生这种差别产生的根本原因是Java语言在编译期间却已将println(String)方法完整的符号引用(本例中为一项CONSTANT_InterfaceMethodref_info常量)生成出来,并作为方法调用指令的参数存储到 Class文件中。例如:
invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
这个符号引用包括了该方法定义在哪个具体类型之中、方法的名字以及参数顺序、参数类型和方 法返回值等信息,通过这个符号引用,Java虚拟机就可以翻译出该方法的直接引用。而ECMAScript等 动态类型语言与Java有一个核心的差异就是变量obj本身并没有类型,变量obj的值才具有类型,所以编译器在编译时最多只能确定方法名称、参数、返回值这些信息,而不会去确定方法所在的具体类型 (即方法接收者不固定)。变量无类型而变量值才有类型这个特点也是动态类型语言的一个核心特征。
静态类型语言与动态类型语言的比较:
- 静态类型语言:能够在编译期确定变量类型,编译期可以提供全面严谨的类型检查,这样与数据类型相关的潜在问题就能在编码时被及时发现,利于稳定性及让项目容易达到更大的规模。
- 动态类型语言:在运行期才确定类型,灵活性,某些在静态类型语言中要花大量臃肿代码来实现的功能,由动态类型语言去做可能会很清晰简洁。
Java与动态类型
java.lang.invoke包
JDK7新加入java.lang.invoke,这个包的主要目的是在之前单纯依靠符号引用确定调用的目标方法之外,提供一种新的动态确定目标方法的机制,称为方法句柄(Method Handle)。
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodType;
import static java.lang.invoke.MethodHandles.lookup;
/**
*方法句柄演示
*/
public class MethodHandleTest {
static class ClassA {
public void println(String s) {
System.out.println(s);
}
}
public static void main(String[] args) throws Throwable {
Object obj = System.currentTimeMillis() % 2 == 0 ? System.out : new ClassA();
// 无论obj最终是哪个实现类,下面这句都能正确调用到println方法。
getPrintlnMH(obj).invokeExact("icyfenix");
}
//模拟了invokevirtual指令的执行过程
private static MethodHandle getPrintlnMH(Object reveiver) throws NoSuchMethodException, IllegalAccessException {
// MethodType:代表“方法类型”,包含了方法的返回值(methodType()的第一个参数)和具体参数(methodType()第二个及以后的参数)。
MethodType mt = MethodType.methodType(void.class, String.class);
// lookup()方法来自于MethodHandles.lookup,这句的作用是在指定类中查找符合给定的方法名称、方法类型,并且符合调用权限的方法句柄。
// 因为这里调用的是一个虚方法,按照Java语言的规则,方法第一个参数是隐式的,代表该方法的接收者,也即this指向的对象,这个参数以前是放在参数列表中进行传递,现在提供了bindTo()方法来完成这件事情。
return lookup().findVirtual(reveiver.getClass(), "println", mt).bindTo(reveiver);
}
}
MethodHandle在使用方法和效果上与Reflection有很多类似的地方,但是还是有区别:
站在Java语言的角度看:
- MethodHandle和Reflection机制本质上都是在模拟方法调用。但是Reflection是在模拟Java代码层次的方法调用,而MethodHandle是在模拟字节码层次的方法调用。在MethodHandles.Lookup上的3个方法findStatic()、findVirtual()、findSpecial()正是为了对应于invokestatic、invokevirtual(以及invokeinterface和invokespecial这几条字节码指令的执行权限校验行为,而这些底层细节在使用ReflectionAPI时是不需要关心的。
- Reflection中的java.lang.reflect.Method对象远比MethodHandle机制中的
java.lang.invoke.MethodHandle对象所包含的信息来得多。前者是方法在Java端的全面映像,包含了方法的签名、描述符以及方法属性表中各种属性的Java端表示方式,还包含执行权限等的运行期信息。而后者仅包含执行该方法的相关信息。用开发人员通俗的话来讲,Reflection是重量级,而MethodHandle是轻量级。 - 由于MethodHandle是对字节码的方法指令调用的模拟,那理论上虚拟机在这方面做的各种优化(如方法内联),在MethodHandle上也应当可以采用类似思路去支持(但目前实现还在继续完善中),而通过反射去调用方法则几乎不可能直接去实施各类调用点优化措施。
不止于Java语言的角度看:
Reflection API的设计目标是只为Java语言服务的,而MethodHandle 则设计为可服务于所有Java虚拟机之上的语言,其中也包括了Java语言而已。
invokedynamic指令
每一处含有invokedynamic指令的位置都被称作“动态调用点(Dynamically-Computed Call Site)”。这条指令的第一个参数不再是代表方法符号引用的CONSTANT_Methodref_info常量,而是变为JDK 7时新加入的CONSTANT_InvokeDynamic_info常量,从这个新常量中可以得到3项信息:引导方法 (Bootstrap Method,该方法存放在新增的BootstrapMethods属性中)、方法类型(MethodType)和名称。引导方法是有固定的参数,并且返回值规定是java.lang.invoke.CallSite对象,这个对象代表了真正要执行的目标方法调用。根据CONSTANT_InvokeDynamic_info常量中提供的信息,虚拟机可以找到并且执行引导方法,从而获得一个CallSite对象,最终调用到要执行的目标方法上。
基于栈的字节码解释执行引擎
许多Java虚拟机的执行引擎在执行Java代码的时候都有解释执行(通过解释器执行)和编译执行(通过即时编译器产生本地代码执行)两种选择。
解释执行
大部分的程序代码转换成物理机的目标代码或虚拟机能执行的指令集之前,都需要经过图8-4中的各个步骤。
基于栈的指令集与基于寄存器的指令集
Javac编译器输出的字节码指令流,基本上是一种基于栈的指令集架构(Instruction Set Architecture,ISA),字节码指令流里面的指令大部分都是零地址指令,依赖操作数栈进行工作。与之相对的另外一套常用的指令集架构是基于寄存器的指令集(x86)
基于栈的指令集与基于寄存器的指令集区别:
//基于栈的指令集例子
iconst_1
iconst_1
iadd
istore_0
//基于寄存器的指令集例子
mov eax, 1
add eax, 1
基于栈的指令集主要优点是可移植,因为寄存器由硬件直接提供,程序直接依赖这些硬件寄存器则不可避免地要受到硬件的约束。代码相对更加紧凑(字节码中每个字节就对应一条指令,而多地址指令集中还需要存放参数)、编译器实现更加简单(不需要考虑空间分配的问题,所需空间都在栈上操作)等。
在解释执行时,栈架构指令集的代码虽然紧凑,但是完成相同功能所需的指令数量一般会比寄存器架构来得更多,因为出栈、入栈操作本身就产生了相当大量的指令。更重要的是栈实现在内存中, 频繁的栈访问也就意味着频繁的内存访问,相对于处理器来说,内存始终是执行速度的瓶颈。尽管虚拟机可以采取栈顶缓存的优化方法,把最常用的操作映射到寄存器中避免直接内存访问,但这也只是优化措施而不是解决本质问题的方法。因此由于指令数量和内存访问的原因,导致了栈架构指令集的 执行速度会相对慢上一点。
基于栈的解释器执行过程
public int calc() {
int a = 100;
int b = 200;
int c = 300;
return (a + b) * c;
}
public int calc();
Code:
Stack=2, Locals=4, Args_size=1
0: bipush 100
2: istore_1
3: sipush 200
6: istore_2
7: sipush 300 10: istore_3
11: iload_1
12: iload_2
13: iadd 14: iload_3 15: imul 16: ireturn
}
javap 提示这段代码需要深度为2的操作数栈和4个变量槽的局部变量空间。
上面的执行过程仅仅是一种概念模型,虚拟机最终会对执行过程做出一系列优化来提高性能,实际情况会和上面描述的概念模型差距非常大,差距产生的根本原因是虚拟机中解析器和即时编译器都会对输入的字节码进行优化,即使解释器中也不是按照字节码指令去逐条执行的。例如在HotSpot虚拟机中,就有很多以“fast_”开头的非标准字节码指令用于合并、替换输入的字节码以提升解释执行性能,即时编译器的优化手段则更是花样繁多
源自书籍:深入理解Java虚拟机:JVM高级特性与最佳实践(第3版)-周志明