深入理解Java虚拟机--中

深入理解Java虚拟机--中#

第6章 类文件结构

6.2 无关性的基石

　　无关性的基石：有许多可以运行在各种不同平台上的虚拟机，这些虚拟机都可以载入和执行同一种平台无关的字节码（ByteCode），从而实现了程序的“一次编写，到处运行”。

　　Java语言中的各种变量、关键字和运算符号的语义最终都是由多条字节码命令组合而成的，因此字节码命令所能提供的语义描述能力肯定会比Java语言本身更加强大。

6.3 Class类文件的结构

　　注意：任何一个Class文件都对应着唯一一个类或接口的定义信息，但反过来说，类或接口并不一定都得定义在文件里（譬如类或接口也可以通过类加载器直接生成）。

　　Class文件是一组以8位字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在Class文件之中，中间没有添加任何分隔符，这使得整个Class文件中存储的内容几乎全部是程序运行的必要数据，没有空隙存在。当遇到需要占用8位字节以上空间的数据项时，则会按照高位在前的方式分割成若干个8位字节进行存储。根据Java虚拟机规范的规定，Class文件格式只有两种数据类型：无符号数和表，后面的解析都要以这两种数据类型为基础。

• 无符号数：属于基本的数据类型，以u1、u2、u4、u8来分别代表1个字节、2个字节、4个字节和8个字节的无符号数，无符号数可以用来描述数字、索引引用、数量值或者按照UTF-8 编码构成字符串值。
• 表：是由多个无符号数或者其他表作为数据项构成的复合数据类型，所有表都习惯性地以“_info”结尾。表用于描述有层次关系的复合结构的数据，整个Class文件本质上就是一张表，它由表6-1所示的数据项构成。
  
  

6.3.1　魔数与Class文件的版本

　　每个Class文件的头4个字节称为魔数（Magic Number），它的唯一作用是确定这个文件是否为一个能被虚拟机接受的Class文件。使用魔数而不是扩展名来进行识别主要是基于安全方面的考虑，因为文件扩展名可以随意地改动。Java魔数值为：0xCAFEBABE。

　　紧接着魔数的4个字节存储的是Class文件的版本号：第5和第6个字节是次版本号（Minor Version），第7和第8个字节是主版本号（Major Version）。Java的主版本号是从45开始的，JDK1.1对应45，JDK1.2对应46，JDK1.3对应47，JDK1.4对应48，JDK1.5对应49，JDK1.6对应50，JDK1.7对应51，JDK1.8对应52。次版本号从0-65535，比如版本1.1.8。高版本的JDK能向下兼容以前版本的Class文件，但不能运行以后版本的Class文件，即使文件格式并未发生任何变化，虚拟机也必须拒绝执行超过其版本号的Class文件。

　　将以下面这段小程序使用JDK 1.8编译输出的Class文件为基础来进行讲解。

package org.fenixsoft.clazz;

public class TestClass {

	private int m;

	public int inc() {
		return m + 1;
	}
}

首先在cmd中对这个java文件进行编译：

javac C:\Users\xie\Desktop\TestClass.java

下图显示的是使用十六进制编辑器WinHex打开这个Class文件的结果，可以清楚地看见开头4个字节的十六进制表示是0xCAFEBABE，代表次版本号的第5个和第6个字节值为0x0000，而主版本号的值为0x0034，也即是十进制的52，该版本号说明这个文件是可以被JDK 1.8或以上版本虚拟机执行的Class文件：



图　6-2　Java Class文件的结构

6.3.2　常量池

　　紧接着主次版本号之后的是常量池入口，常量池可以理解为Class文件之中的资源仓库，它是Class文件结构中与其他项目关联最多的数据类型，也是占用Class文件空间最大的数据项目之一，同时它还是在Class文件中第一个出现的表类型数据项目。

首先贴出使用javap命令输出的反编译字节码，因为jdk8的常量顺序有所改动，故和书中变量顺序稍有不同：

C:\Users\xie>cd C:\Users\xie\Desktop

C:\Users\xie\Desktop>javap -verbose TestClass
警告: 二进制文件TestClass包含org.fenixsoft.clazz.TestClass
Classfile /C:/Users/xie/Desktop/TestClass.class
  Last modified 2017-7-13; size 295 bytes
  MD5 checksum 81f2ab948a7a3068839b61a8f91f634b
  Compiled from "TestClass.java"
public class org.fenixsoft.clazz.TestClass
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
   #1 = Methodref          #4.#15         // java/lang/Object."<init>":()V
   #2 = Fieldref           #3.#16         // org/fenixsoft/clazz/TestClass.m:I
   #3 = Class              #17            // org/fenixsoft/clazz/TestClass
   #4 = Class              #18            // java/lang/Object
   #5 = Utf8               m
   #6 = Utf8               I
   #7 = Utf8               <init>
   #8 = Utf8               ()V
   #9 = Utf8               Code
  #10 = Utf8               LineNumberTable
  #11 = Utf8               inc
  #12 = Utf8               ()I
  #13 = Utf8               SourceFile
  #14 = Utf8               TestClass.java
  #15 = NameAndType        #7:#8          // "<init>":()V
  #16 = NameAndType        #5:#6          // m:I
  #17 = Utf8               org/fenixsoft/clazz/TestClass
  #18 = Utf8               java/lang/Object
{
  public org.fenixsoft.clazz.TestClass();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 3: 0

  public int inc();
    descriptor: ()I
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: getfield      #2                  // Field m:I
         4: iconst_1
         5: iadd
         6: ireturn
      LineNumberTable:
        line 8: 0
}
SourceFile: "TestClass.java"

　　由于常量池中常量的数量是不固定的，所以在常量池的入口需要放置一项u2类型的数据，代表常量池容量计数值（constant_pool_count）。与Java中语言习惯不一样的是，这个容量计数是从1而不是0开始的，如图6-2所示，常量池容量（偏移地址：0x00000008）为十六进制数0x0013，即十进制的19，这就代表常量池中有18项常量，索引值范围为1～18。第0项常量空出来的目的：表示某些指向常量池的索引值不引用任何一个常量池项目。Class文件结构中只有常量池的容量计数是从1开始，对于其他集合类型，包括接口索引集合、字段表集合、方法表集合等的容量计数都与一般习惯相同，是从0开始的。

　　常量池中主要存放两大类常量：字面量（Literal）和符号引用（Symbolic References）。字面量比较接近于Java语言层面的常量概念，如文本字符串、声明为final的常量值等。而符号引用则属于编译原理方面的概念，包括了下面三类常量：类和接口的全限定名、字段的名称和描述符、方法的名称和描述符。

　　Java代码在进行Javac编译的时候，并不像C和C++那样有“连接”这一步骤，而是在虚拟机加载Class文件的时候进行动态连接。也就是说，在Class文件中不会保存各个方法、字段的最终内存布局信息，因此这些字段、方法的符号引用不经过运行期转换的话无法得到真正的内存入口地址，也就无法直接被虚拟机使用。当虚拟机运行时，需要从常量池获得对应的符号引用，再在类创建时或运行时解析、翻译到具体的内存地址之中。

　　常量池中每一项常量都是一个表，如表6-3所示的14个，这14种表都有一个共同的特点，就是表开始的第一位是一个u1类型的标志位，代表当前这个常量属于哪种常量类型。



　　之所以说常量池是最烦琐的数据，是因为这14种常量类型各自均有自己的结构。比如从反编译字节码(javap命令获得)中可以看到第1个常量类型为Methodref，对应tag=10，即16进制A，看图6-2中的第一个常量，它的标志位（偏移地址：0x0000000A）是0x0A，是符合的。查下面的6-6结构总表知道它后面紧跟两个u2类型的索引项，分别为0x0004和0x000F，分别是：指向声明方法的类描述符Class常量的索引项和指向方法名称和类型描述符NameAndType常量的索引项，这一点我们也可以通过反编译字节码（即#4和#15）检验。

　　再看反编译字节码中的第3个常量(即 #3 = Class #17 // org/fenixsoft/clazz/TestClass)，在图6-2中它的标志位（偏移地址：0x00000014）是0x07，查6-6结构总表知道它后面紧跟1个u2类型的索引项0x0011，即10进制17，是指向类的全限定名常量Utf8项的索引（即指向常量池中的第17个常量）。这是由于Class文件中方法、字段等都需要引用CONSTANT_Utf8_info型常量来描述名称，所CONSTANT_Utf8_info型常量的最大长度也就是Java中方法、字段名的最大长度。而这里的最大长度就是length的最大值，既u2类型能表达的最大值65535。所以Java程序中如果定义了超过64KB英文字符的变量或方法名，将会无法编译。

6.3.3 访问标志

　　在常量池结束之后，紧接着的两个字节代表访问标志（access_flags），这个标志用于识别一些类或者接口层次的访问信息，包括：这个Class是类还是接口；是否定义为public类型；是否定义为abstract类型；如果是类的话，是否被声明为final等。具体的标志位以及标志的含义见表6-7。



　　access_flags中一共有16个标志位可以使用，当前只定义了其中8个，没有使用到的标志位要求一律为0。比如上面的代码，从反编译字节码中可以看到它的ACC_PUBLIC、ACC_SUPER标志为真，其他为假，即0x0001|0x0020=0x0021，在图6-2中偏移地址：0x000000B1。

6.3.4 类索引、父类索引与接口索引集合

　　类索引（this_class）和父类索引（super_class）都是一个u2类型的数据，而接口索引集合（interfaces）是一组u2类型的数据的集合，Class文件中由这三项数据来确定这个类的继承关系。类索引用于确定这个类的全限定名，父类索引用于确定这个类的父类的全限定名。由于Java语言不允许多重继承，所以父类索引只有一个，除了java.lang.Object之外，所有的Java 类都有父类，因此除了java.lang.Object外，所有Java类的父类索引都不为0。类索引、父类索引和接口索引集合都按顺序排列在访问标志之后，类索引和父类索引用两个u2类型的索引值表示，它们各自指向一个类型为CONSTANT_Class_info的类描述符常量，通过CONSTANT_Class_info类型的常量中的索引值可以找到定义在CONSTANT_Utf8_info类型的常量中的全限定名字符串。

　　对于接口索引集合，入口的第一项——u2类型的数据为接口计数器（interfaces_count），表示索引表的容量。如果该类没有实现任何接口，则该计数器值为0，后面接口的索引表不再占用任何字节。

在图6-2中偏移地址：0x000000B3，即00 03 00 04 00 00。对应于常量池：

   #3 = Class              #17            // org/fenixsoft/clazz/TestClass
   #4 = Class              #18            // java/lang/Object
...
  #17 = Utf8               org/fenixsoft/clazz/TestClass
  #18 = Utf8               java/lang/Object

6.3.5 字段表集合

　　字段表（field_info）用于描述接口或者类中声明的变量。字段（field）包括类级变量以及实例级变量，但不包括在方法内部声明的局部变量。我们可以想一想在Java中描述一个字段可以包含什么信息？可以包括的信息有：字段的作用域（public、private、protected修饰符）、是实例变量还是类变量（static修饰符）、可变性（final）、并发可见性（volatile修饰符，是否强制从主内存读写）、可否被序列化（transient修饰符）、字段数据类型（基本类型、对象、数组）、字段名称。上述这些信息中，各个修饰符都是布尔值，要么有某个修饰符，要么没有，很适合使用标志位来表示。而字段叫什么名字、字段被定义为什么数据类型，这些都是无法固定的，只能引用常量池中的常量来描述。表6-8中列出了field_info字段表的最终格式。



　　字段修饰符放在access_flags项目中，它与类中的access_flags项目是非常类似的，在这里不详细说明。跟随access_flags标志的是两项索引值：name_index和descriptor_index。它们都是对常量池的引用，分别代表着字段的简单名称以及字段和方法的描述符。

• 全限定名：例如，“org/fenixsoft/clazz/TestClass”是这个类的全限定名，仅仅是把类全名中的“.”替换成了“/”而已，为了使连续的多个全限定名之间不产生混淆，在使用时最后一般会加入一个“；”表示全限定名结束。
• 简单名称：是指没有类型和参数修饰的方法或者字段名称，这个类中的inc（）方法和m字段的简单名称分别是“inc”和“m”。
• 描述符：作用是用来描述字段的数据类型、方法的参数列表（包括数量、类型以及顺序）和返回值。根据描述符规则，基本数据类型（byte、char、double、float、int、long、short、boolean）以及代表无返回值的void类型都用一个大写字符来表示，而对象类型则用字符L加对象的全限定名来表示，详见表6-10。
  
  
  
  　　对于数组类型，每一维度将使用一个前置的“[”字符来描述，如一个定义为“java.lang.String[][]”类型的二维数组，将被记录为：“[[Ljava/lang/String；”，一个整型数组“int[]”将被记录为“[I”。
  
  　　用描述符来描述方法时，按照先参数列表，后返回值的顺序描述，参数列表按照参数的严格顺序放在一组小括号“（）”之内。如方法void inc（）的描述符为“（）V”，方法 java.lang.String toString（）的描述符为“（）Ljava/lang/String；”，方法int indexOf（char[]source,int sourceOffset,int sourceCount,char[]target,int targetOffset,int targetCount,int fromIndex）的描述符为“（[CII[CIII）I”。
  
  　　由于只有一个私有变量m，在图6-2中（偏移地址：0x000000B9）00 01 00 02 00 05 00 06 00 00，分别表示：容量计数器fields_count值为0x0001；access_flags标志值为0x0002；代表字段名称的name_index的值为0x0005，从编译字节码的常量池中可以看到#5为m；代表字段描述符的descriptor_index的值为0x0006，指向常量池的字符串“I”。
  
  　　之后跟随着一个属性表集合用于存储一些额外的信息，字段都可以在属性表中描述零至多项的额外信息。对于本例中的字段m，它的属性表计数器为0，也就是没有需要额外描述的信息，但是，如果将字段m的声明改为“final static int m=123；”，那就可能会存在一项名称为ConstantValue的属性，其值指向常量123。关于attribute_info的其他内容，将在6.3.7节介绍属性表的数据项目时再进一步讲解。
  
  　　字段表集合中不会列出从超类或者父接口中继承而来的字段，但有可能列出原本Java代码之中不存在的字段，譬如在内部类中为了保持对外部类的访问性，会自动添加指向外部类实例的字段。

6.3.6 方法表集合

　　Class 文件存储格式中对方法的描述与对字段的描述几乎采用了完全一致的方式，即方法表的结构和表6-8完全一样。仅在访问标志和属性表集合的可选项中有所区别，因为volatile关键字和transient关键字不能修饰方法，所以方法表的访问标志中没有了ACC_VOLATILE标志和ACC_TRANSIENT标志。与之相对的，synchronized、native、strictfp 和abstract关键字可以修饰方法，所以方法表的访问标志中增加了ACC_SYNCHRONIZED、ACC_NATIVE、ACC_STRICTFP和ACC_ABSTRACT标志。

　　方法里面的代码去哪里了？方法里的Java代码，经过编译器编译成字节码指令后，存放在方法属性表集合中一个名为“Code”的属性里面，属性表作为Class文件格式中最具扩展性的一种数据项目，将在6.3.7节中详细讲解。

　　由于只有一个public方法inc，在图6-2中（偏移地址：0x000000C3）00 02 00 01 00 07 00 08 00 01 00 09 00 00，分别表示：容量计数器methods_count值为0x0002，代表集合中有两个方法（这两个方法为编译器添加的实例构造器＜init＞和源码中的方法inc（））；第一个方法的访问标志值为0x0001，也就是只有ACC_PUBLIC标志为真；名称索引值为0x0007，描述符索引值为0x0008，对应常量为“（）V”，属性表计数器attributes_count的值为0x0001就表示此方法的属性表集合有一项属性，属性名称索引为0x0009，对应常量为“Code”，说明此属性是方法的字节码描述。第二个方法的偏移地址：0x000000F0，00 01 00 0B 00 0C 00 01 00 09 00 00，分析方法和上面类似。

　　与字段表集合相对应的，如果父类方法在子类中没有被重写（Override），方法表集合中就不会出现来自父类的方法信息。但同样的，有可能会出现由编译器自动添加的方法，最典型的便是类构造器“＜clinit＞”方法和实例构造器“＜init＞”方法。

　　在Java语言中，要重载（Overload）一个方法，除了要与原方法具有相同的简单名称之外，还要求必须拥有一个与原方法不同的特征签名，Java特征签名就是一个方法中各个参数在常量池中的字段符号引用的集合，也就是因为返回值不会包含在特征签名中，因此Java语言里面是无法仅仅依靠返回值的不同来对一个已有方法进行重载的。但是在Class文件格式中，特征签名的范围更大一些，只要描述符不是完全一致的两个方法也可以共存。也就是说，如果两个方法有相同的名称和特征签名，但返回值不同，那么也是可以合法共存于同一个Class 文件中的。

6.3.7 属性表集合

　　属性表（attribute_info）在前面的讲解之中已经出现过数次，在Class文件、字段表、方法表都可以携带自己的属性表集合，以用于描述某些场景专有的信息。预定义属性在jdk1.7已经增加到21项。对于每个属性，它的名称需要从常量池中引用一个CONSTANT_Utf8_info类型的常量来表示，而属性值的结构则是完全自定义的，只需要通过一个u4的长度属性去说明属性值所占用的位数即可。我们选择重要的属性了解。

• Code属性
  
  　　只用于方法表。Java程序方法体中的代码经过Javac编译器处理后，最终变为字节码指令存储在Code属性内。Code属性出现在方法表的属性集合之中，但并非所有的方法表都必须存在这个属性，譬如接口或者抽象类中的方法就不存在Code属性，如果方法表有Code属性存在，那么它的结构将如表6-15所示。
  
  
  
  　　attribute_name_index是一项指向CONSTANT_Utf8_info型常量的索引，常量值固定为“Code”，它代表了该属性的属性名称。
  
  　　attribute_length指示了属性值的长度，由于属性名称索引与属性长度一共为6字节，所以属性值的长度固定为整个属性表长度减去6个字节。
  
  　　max_stack代表了操作数栈（Operand Stacks）深度的最大值。在方法执行的任意时刻，操作数栈都不会超过这个深度。虚拟机运行的时候需要根据这个值来分配栈帧（StackFrame）中的操作栈深度。
  
  　　max_locals代表了局部变量表所需的存储空间。在这里，max_locals的单位是Slot,Slot是虚拟机为局部变量分配内存所使用的最小单位。对于byte、char、float、int、short、boolean和returnAddress等长度不超过32位的数据类型，每个局部变量占用1个Slot，而double和long这两种64位的数据类型则需要两个Slot来存放。方法参数（包括实例方法中的隐藏参数“this”）、显式异常处理器的参数（Exception Handler Parameter，就是try-catch语句中catch 块所定义的异常）、方法体中定义的局部变量都需要使用局部变量表来存放。另外，并不是在方法中用到了多少个局部变量，就把这些局部变量所占Slot之和作max_locals的值，原因是局部变量表中的Slot可以重用，当代码执行超出一个局部变量的作用域时，这个局部变量所占的Slot可以被其他局部变量所使用，Javac编译器会根据变量的作用域来分配Slot给各个变量使用，然后计算出max_locals的大小。
  
  　　code_length和code用来存储Java源程序编译后生成的字节码指令。code_length代表字节码长度，code是用于存储字节码指令的一系列字节流。每个指令是一个u1类型的单字节，当虚拟机读取到code中的一个字节码时，就可以对应找出这个字节码代表的是什么指令，并且可以知道这条指令后面是否需要跟随参数，以及参数应当如何理解。我们知道一个u1数据类型的取值范围为0x00～0xFF，对应十进制的0～255，也就是一共可以表达256条指令，目前，Java虚拟机规范已经定义了其中约200条编码值对应的指令含义。

例子：

在图6-2中（偏移地址：0x000000D3）00 01 00 01 00 00 00 05 2A B7 00 01 B1，其中操作数栈的最大深度和本地变量表的容量都为0x0001，字节码区域所占空间的长度为0x00000005。虚拟机读取到字节码区域的长度后，按照顺序依次读入紧随的5个字节，并根据字节码指令表翻译出所对应的字节码指令。

仅仅贴出方法字节码指令，减少向上翻页的麻烦：

{
  public org.fenixsoft.clazz.TestClass();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 3: 0

  public int inc();
    descriptor: ()I
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: getfield      #2                  // Field m:I
         4: iconst_1
         5: iadd
         6: ireturn
      LineNumberTable:
        line 8: 0
}
SourceFile: "TestClass.java"

这个类中两个方法都没有参数，为什么Args_size会为1？而且无论是在参数列表里还是方法体内，都没有定义任何局部变量，那Locals又为什么会等于1？

　　在任何实例方法里面，都可以通过“this”关键字访问到此方法所属的对象。实现就是通过Javac编译器编译的时候把对this关键字的访问转变为对一个普通方法参数的访问，然后在虚拟机调用实例方法时自动传入此参数而已。

• LineNumberTable属性
  
  　　LineNumberTable属性用于描述Java源码行号与字节码行号（字节码的偏移量）之间的对应关系。如果选择不生成LineNumberTable 属性，对程序运行产生的最主要的影响就是当抛出异常时，堆栈中将不会显示出错的行号，并且在调试程序的时候，也无法按照源码行来设置断点。

• ConstantValue属性
  
  　　ConstantValue属性的作用是通知虚拟机自动为静态变量赋值。只有被static关键字修饰的变量（类变量）才可以使用这项属性。类似“int x=123”和“static int x=123”这样的变量定义在
  
  Java程序中是非常常见的事情，但虚拟机对这两种变量赋值的方式和时刻都有所不同。对于非static类型的变量（也就是实例变量）的赋值是在实例构造器＜init＞方法中进行的；而对于类变量，则有两种方式可以选择：在类构造器＜clinit＞方法中或者使用ConstantValue属性。目前Sun Javac编译器的选择是：如果同时使用final和static来修饰一个变量（按照习惯，这里称“常量”更贴切），并且这个变量的数据类型是基本类型或者java.lang.String的话，就生成ConstantValue属性来进行初始化，如果这个变量没有被final修饰，或者并非基本类型及字符串，则将会选择在＜clinit＞方法中进行初始化。
  
  

　　从数据结构中可以看出，ConstantValue属性是一个定长属性constantvalue_index数据项代表了常量池中一个字面量常量的引用，根据字段类型的不同，字面量可以是CONSTANT_Long_info、CONSTANT_Float_info、CONSTANT_Double_info、CONSTANT_Integer_info、CONSTANT_String_info常量中的一种。

6.4　字节码指令简介

　　Java虚拟机的指令由一个字节长度的、代表着某种特定操作含义的数字（称为操作码，Opcode）以及跟随其后的零至多个代表此操作所需参数（称为操作数，Operands）而构成。由于Java虚拟机采用面向操作数栈而不是寄存器的架构（这两种架构的区别和影响将在第8章中探讨），所以大多数的指令都不包含操作数，只有一个操作码。由于限制了Java虚拟机操作码的长度为一个字节（即0～255），这意味着指令集的操作码总数不可能超过256 条。

　　如果不考虑异常处理的话，那么Java虚拟机的解释器可以使用下面这个伪代码当做最基本的执行模型来理解：

do{
自动计算PC寄存器的值加1；
根据PC寄存器的指示位置，从字节码流中取出操作码；
if（字节码存在操作数）从字节码流中取出操作数；
执行操作码所定义的操作；
}while（字节码流长度＞0）；

6.4.1　字节码与数据类型

　　对于大部分与数据类型相关的字节码指令，它们的操作码助记符中都有特殊的字符来表明专门为哪种数据类型服务：i代表对int类型的数据操作，l代表long,s代表short,b代表byte,c代表char,f代表float,d代表double,a代表reference。

　　大部分的指令都没有支持整数类型byte、char和short，甚至没有任何指令支持boolean类型。编译器会在编译期或运行期将byte和short类型的数据带符号扩展（Sign-Extend）为相应的int类型数据，将boolean和char类型数据零位扩展（Zero-Extend）为相应的int类型数据。与之类似，在处理boolean、byte、short和char类型的数组时，也会转换为使用对应的int类型的字节码指令来处理。因此，大多数对于boolean、byte、short和char类型数据的操作，实际上都是使用相应的int类型作为运算类型（ComputationalType）。

6.4.2　加载和存储指令

加载和存储指令用于将数据在栈帧中的局部变量表和操作数栈之间来回传输。

• 将一个局部变量加载到操作栈：iload、iload_＜n＞、lload、lload_＜n＞、fload、fload_＜n＞、dload、dload_＜n＞、aload、aload_＜n＞。
• 将一个数值从操作数栈存储到局部变量表：istore、istore_＜n＞、lstore、lstore_＜n＞、 fstore、fstore_＜n＞、dstore、dstore_＜n＞、astore、astore_＜n＞。
• 将一个常量加载到操作数栈：bipush、sipush、ldc、ldc_w、ldc2_w、aconst_null、 iconst_m1、iconst_＜i＞、lconst_＜l＞、fconst_＜f＞、dconst_＜d＞。
• 扩充局部变量表的访问索引的指令：wide。

6.4.3　运算指令

　　运算或算术指令用于对两个操作数栈上的值进行某种特定运算，并把结果重新存入到操作数栈顶。

• 加法指令：iadd、ladd、fadd、dadd。
• 减法指令：isub、lsub、fsub、dsub。
• 乘法指令：imul、lmul、fmul、dmul。
• 除法指令：idiv、ldiv、fdiv、ddiv。
• 求余指令：irem、lrem、frem、drem。
• 取反指令：ineg、lneg、fneg、dneg。
• 位移指令：ishl、ishr、iushr、lshl、lshr、lushr。
• 按位或指令：ior、lor。
• 按位与指令：iand、land。
• 按位异或指令：ixor、lxor。
• 局部变量自增指令：iinc。
• 比较指令：dcmpg、dcmpl、fcmpg、fcmpl、lcmp。

6.4.4　类型转换指令

• i2b、i2c、i2s、l2i、f2i、f2l、d2i、d2l和d2f

6.4.5　对象创建与访问指令

• 创建类实例的指令：new。
• 创建数组的指令：newarray、anewarray、multianewarray。
• 访问类字段（static字段，或者称为类变量）和实例字段（非static字段，或者称为实例变量）的指令：getfield、putfield、getstatic、putstatic。
• 把一个数组元素加载到操作数栈的指令：baload、caload、saload、iaload、laload、 faload、daload、aaload。
• 将一个操作数栈的值存储到数组元素中的指令：bastore、castore、sastore、iastore、 fastore、dastore、aastore。
• 取数组长度的指令：arraylength。
• 检查类实例类型的指令：instanceof、checkcast。

6.4.6　操作数栈管理指令

• 将操作数栈的栈顶一个或两个元素出栈：pop、pop2。
• 复制栈顶一个或两个数值并将复制值或双份的复制值重新压入栈顶：dup、dup2、 dup_x1、dup2_x1、dup_x2、dup2_x2。
• 将栈最顶端的两个数值互换：swap

6.4.7　控制转移指令

• 条件分支：ifeq、iflt、ifle、ifne、ifgt、ifge、ifnull、ifnonnull、if_icmpeq、if_icmpne、 if_icmplt、if_icmpgt、if_icmple、if_icmpge、if_acmpeq和if_acmpne。
• 复合条件分支：tableswitch、lookupswitch。
• 无条件分支：goto、goto_w、jsr、jsr_w、ret。

6.4.8　方法调用和返回指令

• invokevirtual指令用于调用对象的实例方法，根据对象的实际类型进行分派（虚方法分派），这也是Java语言中最常见的方法分派方式。
• invokeinterface指令用于调用接口方法，它会在运行时搜索一个实现了这个接口方法的对象，找出适合的方法进行调用。
• invokespecial指令用于调用一些需要特殊处理的实例方法，包括实例初始化方法、私有方法和父类方法。
• invokestatic指令用于调用类方法（static方法）。
• invokedynamic指令用于在运行时动态解析出调用点限定符所引用的方法，并执行该方法，前面4条调用指令的分派逻辑都固化在Java虚拟机内部，而invokedynamic指令的分派逻辑是由用户所设定的引导方法决定的。
  
  　　方法调用指令与数据类型无关，而方法返回指令是根据返回值的类型区分的，包括
  
  ireturn（当返回值是boolean、byte、char、short和int类型时使用）、lreturn、freturn、dreturn和 areturn，另外还有一条return指令供声明为void的方法、实例初始化方法以及类和接口的类初始化方法使用。

6.4.9　异常处理指令

　　在Java程序中显式抛出异常的操作（throw语句）都由athrow指令来实现。而在Java虚拟机中，处理异常（catch语句）不是由字节码指令来实现的，而是采用异常表来完成的。

6.4.10　同步指令

　　Java虚拟机可以支持方法级的同步和方法内部一段指令序列的同步，这两种同步结构都是使用管程（Monitor）来支持的。

　　方法级的同步是隐式的，即无须通过字节码指令来控制，它实现在方法调用和返回操作之中。虚拟机可以从方法常量池的方法表结构中的ACC_SYNCHRONIZED访问标志得知一个方法是否声明为同步方法。

　　同步一段指令集序列通常是由Java语言中的synchronized语句块来表示的，Java虚拟机的指令集中有monitorenter和monitorexit两条指令来支持synchronized关键字的语义。

第7章　虚拟机类加载机制

7.1　概述

　　与那些在编译时需要进行连接工作的语言不同，在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略虽然会令类加载时稍微增加一些性能开销，但是会为Java应用程序提供高度的灵活性，Java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。例如，如果编写一个面向接口的应用程序，可以等到运行时再指定其实际的实现类；用户可以通过Java预定义的和自定义的类加载器，让一个本地的应用程序可以在运行时从网络或其他地方加载一个二进制流作为程序代码的一部分，这种组装应用程序的方式目前已广泛应用于Java程序之中。从最基础的Applet、JSP到相对复杂的OSGi技术，都使用了Java语言运行期类加载的特性。

7.2　类加载的时机

　　类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段。其中验证、准备、解析3个部分统称为连接（Linking）。

　　虚拟机规范严格规定了有且只有5种情况必须立即对类进行“初始化”：

• 遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
• 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
• 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
• 当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类。
• 当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。
  
  　　注意：“有且只有”这5种会触发类进行初始化的场景，称为对一个类进行主动引用。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。
• 对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。

package org.fenixsoft.classloading;

/**
 * 被动使用类字段演示一：
* 通过子类引用父类的静态字段，不会导致子类初始化
 **/
public class SuperClass {

	static {
		System.out.println("SuperClass init!");
	}

	public static int value = 123;
}

public class SubClass extends SuperClass {

	static {
		System.out.println("SubClass init!");
	}
}

/**
 * 非主动使用类字段演示
 **/
public class NotInitialization {

	public static void main(String[] args) {
		System.out.println(SubClass.value);
	}

}

只会输出“SuperClass init！”，而不会输出“SubClass init！”。

• 通过数组定义来引用类，不会触发此类的初始化

package org.fenixsoft.classloading;

/**
 * 被动使用类字段演示二：
* 通过数组定义来引用类，不会触发此类的初始化
 **/
public class NotInitialization {

	public static void main(String[] args) {
		SuperClass[] sca = new SuperClass[10];
	}

}

　　这段代码复用了上面代码的SuperClass，运行之后发现没有输出“SuperClass init！”，说明并没有触发类org.fenixsoft.classloading.SuperClass的初始化阶段。但是这段代码里面触发了另外一个名为“[Lorg.fenixsoft.classloading.SuperClass”（其中[表示数组，L表示对象类型）的类的初始化阶段，对于用户代码来说，这并不是一个合法的类名称，它是一个由虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作由字节码指令newarray触发。这个类代表了一个元素类型为org.fenixsoft.classloading.SuperClass的一维数组，数组中应有的属性和方法（用户可直接使用的只有被修饰为public的length属性和clone（）方法）都实现在这个类里。

• 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

package org.fenixsoft.classloading;

/**
 * 被动使用类字段演示三：
* 常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
 **/
public class ConstClass {

	static {
		System.out.println("ConstClass init!");
	}

	public static final String HELLOWORLD = "hello world";
}

/**
 * 非主动使用类字段演示
 **/
public class NotInitialization {

	public static void main(String[] args) {
		System.out.println(ConstClass.HELLOWORLD);
	}
}

　　上述代码运行之后，也没有输出“ConstClass init！”。其实在编译阶段通过常量传播优化，已经将此常量的值“hello world”存储到了NotInitialization类的常量池中，以后NotInitialization对常量ConstClass.HELLOWORLD的引用实际都被转化为NotInitialization类对自身常量池的引用了。也就是说，实际上NotInitialization的Class文件之中并没有ConstClass类的符号引用入口，这两个类在编译成Class之后就不存在任何联系了。

　　接口的加载过程与类加载过程稍有一些不同，针对接口需要做一些特殊说明：接口也有初始化过程，这点与类是一致的，接口中不能用“static{}”语句块，但编译器仍然会为接口生成“＜clinit＞（）”类构造器，用于初始化接口中所定义的成员变量。接口与类真正的区别：当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。

7.3　类加载的过程

　　Java虚拟机中类加载的全过程，也就是加载、验证、准备、解析和初始化这5个阶段所执行的具体动作。

7.3.1　加载

　　在加载阶段，虚拟机需要完成以下3件事情：

1） 通过一个类的全限定名来获取定义此类的二进制字节流。

2） 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3） 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

怎么获取二进制字节流：

• 从ZIP包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。
• 从网络中获取，这种场景最典型的应用就是Applet。
• 运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang.reflect.Proxy 中，就是用了ProxyGenerator.generateProxyClass来为特定接口生成形式为“*$Proxy”的代理类的二进制字节流。
• 由其他文件生成，典型场景是JSP应用，即由JSP文件生成对应的Class类等。

　　相对于类加载过程的其他阶段，一个非数组类的加载阶段（准确地说，是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成。

　　对于数组类而言，情况就有所不同，数组类本身不通过类加载器创建，它是由Java虚拟机直接创建的。但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型（Element Type，指的是数组的每一项）最终是要靠类加载器去创建，一个数组类（下面简称为C）创建过程就遵循以下规则：

　　如果数组的组件类型是引用类型，那就递归采用正常的加载过程去加载这个组件类型，数组C将在加载该组件类型的类加载器的类名称空间上被标识（这点很重要，一个类必须与类加载器一起确定唯一性）。

　　如果数组的组件类型不是引用类型（例如int[]数组），Java虚拟机将会把数组C标记为与引导类加载器（即启动类加载器）关联。数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为public。

　　加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义。然后在内存中实例化一个java.lang.Class类的对象（并没有明确规定是在Java堆中，对于HotSpot虚拟机而言，Class对象比较特殊，它虽然是对象，但是存放在方法区里面），这个对象将作为程序访问方法区中的这些类型数据的外部接口。

7.3.2　验证

　　验证是连接阶段的第一步，目的是：确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段包括4个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。

1.文件格式验证：

　　验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。

这一阶段可能包括下面这些验证点：

• 是否以魔数0xCAFEBABE开头。
• 主、次版本号是否在当前虚拟机处理范围之内。
• 常量池的常量中是否有不被支持的常量类型（检查常量tag标志）。
• 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
• CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据。
• Class文件中各个部分及文件本身是否有被删除的或附加的其他信息等。

　　这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证后，字节流才会进入内存的方法区中进行存储，所以后面的3个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流。

2.元数据验证：

　　对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求，这个阶段可能包括的验证点如下：

• 这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。
• 这个类的父类是否继承了不允许被继承的类（被final修饰的类）。
• 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
• 类中的字段、方法是否与父类产生矛盾（例如覆盖了父类的final字段，或者出现不符合规则的方法重载，例如方法参数都一致，但返回值类型却不同等）。

3.字节码验证：

　　第三阶段是整个验证过程中最复杂的一个阶段，主要对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件，例如：

• 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似这样的情况：在操作栈放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中。
• 保证跳转指令不会跳转到方法体以外的字节码指令上。
• 保证方法体中的类型转换是有效的，例如可以把一个子类对象赋值给父类数据类型，但是不能反过来等。

　　但通过程序去校验程序逻辑是无法做到绝对准确的——不能通过程序准确地检查出程序是否能在有限的时间之内结束运行。由于数据流验证的高复杂性，虚拟机设计团队为了避免过多的时间消耗在字节码验证阶段，给方法体的Code属性的属性表中增加了一项名为“StackMapTable”的属性，在编译阶段将一系列的验证类型（Verification Types）直接记录在Class文件之中，通过检查这些验证类型代替了类型推导过程，从而大幅提升了字节码验证的性能。

4.符号引用验证：

　　最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。比如：验证：

• 符号引用中通过字符串描述的全限定名是否能找到对应的类。
• 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段。
• 符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可被当前类访问等。

7.3.3　准备

　　准备阶段是正式为类变量（被static修饰的变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中）分配内存并设置类变量初始值（数据类型的零值）的阶段，这些变量所使用的内存都将在方法区中进行分配。

　　假设一个类变量的定义为：public static int value=123，那变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java 方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器＜clinit＞（）方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。

　　注意：如果类字段的字段属性表中存在ConstantValue属性（即final static修饰的常数），那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值。

7.3.4　解析

　　解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

• 符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。
• 直接引用（Direct References）：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。

　　虚拟机实现可以根据需要来判断到底是在类被加载器加载时就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前才去解析它。对同一个符号引用进行多次解析请求是很常见的事情，除invokedynamic指令以外，虚拟机实现可以对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标识为已解析状态）从而避免解析动作重复进行。对于invokedynamic指令，上面规则则不成立。因为invokedynamic指令的目的本来就是用于动态语言支持（目前仅使用Java语言不会生成这条字节码指令），它所对应的引用称为“动态调用点限定符”，这里“动态”的含义就是必须等到程序实际运行到这条指令的时候，解析动作才能进行。相对的，其余可触发解析的指令都是“静态”的，可以在刚刚完成加载阶段，还没有开始执行代码时就进行解析。

　　解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行，分别对应于常量池的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info和CONSTANT_InvokeDynamic_info 7种常量类型。简单介绍两个，其它类似：

1.类或接口的解析：

　　假设当前代码所处的类为D，如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，那虚拟机完成整个解析的过程需要以下3个步骤：

1） 如果C不是一个数组类型，那虚拟机将会把代表N的全限定名传递给D的类加载器去加载这个类C。在加载过程中，由于元数据验证、字节码验证的需要，又可能触发其他相关类的加载动作，例如加载这个类的父类或实现的接口。一旦这个加载过程出现了任何异常，解析过程就宣告失败。

2） 如果C是一个数组类型，并且数组的元素类型为对象，也就是N的描述符会是类似“[Ljava/lang/Integer”的形式，那将会按照第1点的规则加载数组元素类型，接着由虚拟机生成一个代表此数组维度和元素的数组对象。如果数组的元素类型不是引用类型（例如int[]数组），那么只包括由虚拟机生成一个代表此数组维度和元素的数组对象。

3） 如果上面的步骤没有出现任何异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，确认D是否具备对C的访问权限。如果发现不具备访问权限，将抛出java.lang.IllegalAccessError异常。

2.字段解析：

　　要解析一个未被解析过的字段符号引用，首先将会对字段表内class_index索引项的CONSTANT_Class_info符号引用进行解析，也就是字段所属的类或接口的符号引用。如果在解析这个类或接口符号引用的过程中出现了任何异常，都会导致字段符号引用解析的失败。如果解析成功完成，那将这个字段所属的类或接口用C表示，虚拟机规范要求按照如下步骤对C进行后续字段的搜索。

1） 如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。

2） 否则，如果在C中实现了接口，将会按照继承关系从下往上递归搜索各个接口和它的父接口，如果接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。

3） 否则，如果C不是java.lang.Object的话，将会按照继承关系从下往上递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。

4） 否则，查找失败，抛出java.lang.NoSuchFieldError异常。

如果查找过程成功返回了引用，将会对这个字段进行权限验证，如果发现不具备对字段的访问权限，将抛出java.lang.IllegalAccessError异常。

7.3.5　初始化

　　到了初始化阶段，才真正开始执行类中定义的Java程序代码（或者说是字节码）。在准备阶段，类变量已经赋过一次系统要求的初始值（零值），而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器<clinit>方法的过程。

在编译生成class文件时，会自动产生两个方法，一个是类的初始化方法<clinit>, 另一个是实例的初始化方法<init>：

<clinit>：所有的静态变量初始化和静态块初始化语句都被Java编译器收集到了一起，放在一个特殊的<clinit>方法中。在jvm第一次加载class文件时调用，包括静态变量初始化和静态块的执行。

<init>:在实例创建出来的时候调用，包括调用new操作符；调用Class或java.lang.reflect.Constructor对象的newInstance()方法；调用任何现有对象的clone()方法；通过java.io.ObjectInputStream类的getObject()方法反序列化。

• <clinit>方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的。
• <clinit>方法与类的构造函数（或者说实例构造器<init>方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>方法执行之前，父类的<clinit>方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>方法的类肯定是java.lang.Object。
• 由于父类的<clinit>方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
• <clinit>方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>方法。
• 接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>方法。但接口与类不同的是，执行接口的<clinit>方法不需要先执行父接口的<clinit>方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>方法。
• 虚拟机会保证一个类的<clinit>方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>方法，其他线程都需要阻塞等待。如果在一个类的<clinit>方法中有耗时很长的操作，就可能造成多个进程阻塞（需要注意的是，其他线程虽然会被阻塞，但如果执行<clinit>方法的那条线程退出<clinit>方法后，其他线程唤醒之后不会再次进入<clinit>方法。同一个类加载器下，一个类型只会初始化一次），在实际应用中这种阻塞往往是很隐蔽的。

7.4　类加载器

7.4.1　类与类加载器

　　对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。即：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等（这里所指的“相等”，包括代表类的Class对象的equals（）方法、isAssignableFrom（）方法、isInstance（）方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况）。

7.4.2　双亲委派模型

　　从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

　　从Java开发人员的角度来看，可以分为4种：

• 启动类加载器（Bootstrap ClassLoader）：负责将存放在＜ JAVA_HOME＞\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的类库加载到虚拟机内存中，无法被Java程序直接引用。
• 扩展类加载器（Extension ClassLoader）：负责加载＜JAVA_HOME＞\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
• 应用程序类加载器（Application ClassLoader）：由于这个类加载器是ClassLoader中的getSystemClassLoader（）方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，程序中默认的类加载器。
• 自定义类加载器：

图　7-2　类加载器双亲委派模型

　　双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码。

　　双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

　　好处：Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为 java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类。从安全层面，杜绝通过使用和相同的类名冒充现有的JRE类的替换攻击

7.4.3　破坏双亲委派模型

　　双亲委派模型并不是一个强制性的约束模型，而是Java设计者推荐给开发者的类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型，但也有例外，比如：

　　由于用户对程序动态性的追求，代码热替换（HotSwap）、模块热部署等，说白了就是希望应用程序能像我们的计算机外设那样，接上鼠标、U盘，不用重启机器就能立即使用。比如：OSGi实现模块化热部署的关键是：每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构。

第8章　虚拟机字节码执行引擎

8.1　概述

　　“虚拟机”是一个相对于“物理机”的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、硬件、指令集和操作系统层面上的，而虚拟机的执行引擎则是由自己实现的，因此可以自行制定指令集与执行引擎的结构体系，并且能够执行那些不被硬件直接支持的指令集格式。在不同的虚拟机实现里面，执行引擎在执行Java代码的时候可能会有解释执行（通过解释器执行）和编译执行（通过即时编译器产生本地代码执行）两种选择，也可能两者兼备。

8.2　运行时栈帧结构

　　栈帧（Stack Frame）是用于支持虚拟机进行方法调用和方法执行的数据结构，它是虚拟机运行时数据区中的虚拟机栈（Virtual Machine Stack）的栈元素。栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息。每一个方法从调用开始至执行完成的过程，都对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程。

　　在编译程序代码的时候，栈帧中需要多大的局部变量表，多深的操作数栈都已经完全确定了，并且写入到方法表的Code属性（详细看6.3节）之中，因此一个栈帧需要分配多少内存，不会受到程序运行期变量数据的影响，而仅仅取决于具体的虚拟机实现。

　　一个线程中的方法调用链可能会很长，很多方法都同时处于执行状态。对于执行引擎来说，在活动线程中，只有位于栈顶的栈帧才是有效的，称为当前栈帧（Current Stack Frame），与这个栈帧相关联的方法称为当前方法（Current Method）。执行引擎运行的所有字节码指令都只针对当前栈帧进行操作，典型的栈帧结构如下图所示。

8.2.1　局部变量表

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

　　局部变量表的容量以变量槽（Variable Slot，下称Slot）为最小单位，虚拟机规范中并没有明确指明一个Slot应占用的内存空间大小，只是很有导向性地说到每个Slot都应该能存放一个boolean、byte、char、short、int、float、reference或returnAddress类型的数据，这8种数据类型，都可以使用32位或更小的物理内存来存放。但需保证即使在64位虚拟机中使用了64位的物理内存空间去实现一个Slot，虚拟机仍要使用对齐和补白的手段让Slot在外观上看起来与32位虚拟机中的一致。

32位CPU：32位操作系统针对的32位的CPU设计，一般来讲32位的CPU对于我们来讲是最理性的CPU，对于软件开发来讲足够了。 但是2的32次方 = 4294967296bit = 4G左右，也就是32位CPU只有4G左右的内存寻址空间，对于一些服务器来讲4G的内存远远不够。

64位CPU：64位操作系统只能安装在64位电脑上(CPU必须是64位的)， 32位操作系统则可以安装在32位(32位CPU)或64位(64位CPU，性能无法充分利用)电脑上。64位CPU通用寄存器的数据宽度为64位，64位指令集可以运行64位数据指令。同时，内存寻址空间更大，理论上2的64次方。

reference类型：表示对一个对象实例的引用，虚拟机规范既没有说明它的长度，也没有明确指出这种引用应有怎样的结构。

returnAddress类型：它是为字节码指令jsr、jsr_w和ret服务的，指向了一条字节码指令的地址，很古老的Java虚拟机曾经使用这几条指令来实现异常处理，现在已经由异常表代替。

　　对于64位的数据类型，虚拟机会以高位对齐的方式为其分配两个连续的Slot空间。Java语言中明确的（reference类型则可能是32位也可能是64位）64位的数据类型只有long和double 两种。由于局部变量表建立在线程的堆栈上，是线程私有的数据，无论读写两个连续的Slot是否为原子操作，都不会引起数据安全问题。

　　虚拟机通过索引定位的方式使用局部变量表，索引值的范围是从0开始至局部变量表最大的Slot数量。如果访问的是32位数据类型的变量，索引n就代表了使用第n个Slot，如果是64 位数据类型的变量，则说明会同时使用n和n+1两个Slot。

　　在方法执行时，虚拟机是使用局部变量表完成参数值到参数变量列表的传递过程的，如果执行的是实例方法（非static的方法），那局部变量表中第0位索引的Slot默认是用于传递方法所属对象实例的引用this，其余参数则按照参数表顺序排列，占用从1开始的局部变量Slot，参数表分配完毕后，再根据方法体内部定义的变量顺序和作用域分配其余的Slot。为了尽可能节省栈帧空间，局部变量表中的Slot是可以重用的，方法体中定义的变量，其作用域并不一定会覆盖整个方法体，如果当前字节码PC计数器的值已经超出了某个变量的作用域，那这个变量对应的Slot就可以交给其他变量使用。

　　注意：就是局部变量不像前面介绍的类变量那样存在“准备阶段”，通过第7章的讲解，我们已经知道类变量有两次赋初始值的过程，一次在准备阶段，赋予系统初始值；另外一次在初始化阶段，赋予程序员定义的初始值。因此，即使在初始化阶段程序员没有为类变量赋值也没有关系，类变量仍然具有一个确定的初始值。但局部变量就不一样，如果一个局部变量定义了但没有赋初始值是不能使用的，不要认为Java中任何情况下都存在诸如整型变量默认为0，布尔型变量默认为false等这样的默认值。

8.2.2　操作数栈

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

　　当一个方法刚刚开始执行的时候，这个方法的操作数栈是空的，在方法的执行过程中，会有各种字节码指令往操作数栈中写入和提取内容，也就是出栈/入栈操作。例如，在做算术运算的时候是通过操作数栈来进行的，又或者在调用其他方法的时候是通过操作数栈来进行参数传递的。

　　Java虚拟机的解释执行引擎称为“基于栈的执行引擎”，其中所指的“栈”就是操作数栈。

8.2.3　动态连接

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

8.2.4　方法返回地址

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

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

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

8.3　方法调用

　　方法调用并不等同于方法执行，方法调用阶段唯一的任务就是确定被调用方法的版本（即调用哪一个方法），暂时还不涉及方法内部的具体运行过程。但前面已经讲过，Class文件的编译过程中不包含传统编译中的连接步骤，一切方法调用在Class文件里面存储的都只是符号引用，而不是方法在实际运行时内存布局中的入口地址（相当于之前说的直接引用）。这个特性给Java带来了更强大的动态扩展能力，但也使得Java方法调用过程变得相对复杂起来，需要在类加载期间，甚至到运行期间才能确定目标方法的直接引用。

8.3.1　解析

　　所有方法调用中的目标方法在Class文件里面都是一个常量池中的符号引用，在类加载的解析阶段，会将其中的一部分符号引用转化为直接引用，这种解析能成立的前提是：方法在编译期可知，运行期不可变。这类的方法调用称为解析调用。

　　在Java虚拟机里面提供了5条方法调用字节码指令，分别如下：

• invokestatic：调用静态方法。
• invokespecial：调用实例构造器＜init＞方法、私有方法和父类方法。
• invokevirtual：调用所有的虚方法。
• invokeinterface：调用接口方法，会在运行时再确定一个实现此接口的对象。
• invokedynamic：先在运行时动态解析出调用点限定符所引用的方法，然后再执行该方法，在此之前的4条调用指令，分派逻辑是固化在Java虚拟机内部的，而invokedynamic指令的分派逻辑是由用户所设定的引导方法决定的。

只要能被invokestatic和invokespecial指令调用的方法，都可以在解析阶段中确定唯一的调用版本，符合这个条件的有静态方法、私有方法、实例构造器、父类方法4类，它们在类加载的时候就会把符号引用解析为该方法的直接引用。

　　解析调用一定是个静态的过程，在编译期间就完全确定，在类装载的解析阶段就会把涉及的符号引用全部转变为可确定的直接引用，不会延迟到运行期再去完成。而分派（Dispatch）调用则可能是静态的也可能是动态的。

8.3.2　分派

建议首先了解Java的继承、封装与多态的概念。

Java中多态的实现方式：

• 方法的重载（overload）：重载是指同一个类中有多个同名的方法，但这些方法有不同的参数，因此在编译期就可以确定到底调用哪个方法，它是一种编译时多态。即一个类中的方法多态性。
• 方法的覆盖（即重写）（override）：子类可以覆盖父类的方法，即同样的方法会在子类和父类中有不同的表现形式。在Java语言中，父类引用可以指向父类对象或者子类对象，接口引用可以指向其实现类的实例对象。 而程序调用的方法在运行期才动态绑定（绑定指的是将一个方法调用和一个方法主体连接到一起），即：在运行期间判断所引用对象的实际类型，根据其实际的类型调用其相应的方法。（注意此时父类引用只是指向子类对象，真正运行的还是子类对象，即优先从实际运行的对象的方法表中找对应的方法签名（方法名+参数列表称为方法签名），如果找不到，才回到相应的父类方法表中找调用方法的方法签名），由于运行时才能确定调用哪个方法，因此称方法覆盖的多态为运行时多态。

1.静态分派：

首先贴出例子：

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 guy) {
		System.out.println("hello,gentleman!");
	}

	public void sayHello(Woman guy) {
		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);
	}
}

当然其中类前的static不是必须的，只不过将内部类写为static的可以实现和外部类相同的调用方式，比如下面的代码：

public class StaticDispatch {

	abstract class Human {
	}

	class Man extends Human {
	}

	class Woman extends Human {
	}

	public void sayHello(Human guy) {
		System.out.println("hello,guy!");
	}

	public void sayHello(Man guy) {
		System.out.println("hello,gentleman!");
	}

	public void sayHello(Woman guy) {
		System.out.println("hello,lady!");
	}

	public static void main(String[] args) {
		StaticDispatch staticDispatch = new StaticDispatch();
		Human man = staticDispatch.new Man();
		Human woman = staticDispatch.new Woman();
		StaticDispatch sr = new StaticDispatch();
		sr.sayHello(man);
		sr.sayHello(woman);
	}
}

运行结果都是：

hello,guy!
hello,guy!

　　我们把上面代码中的“Human”称为变量的静态类型（Static Type），或者叫做的外观类型（Apparent Type），后面的“Man”则称为变量的实际类型（Actual Type）。对于重载来说，Javac编译器会根据参数的静态类型决定使用哪个重载版本。所有依赖静态类型来定位方法执行版本的分派动作称为静态分派。

　　笔者讲述的解析与分派这两者之间的关系并不是二选一的排他关系，它们是在不同层次上去筛选、确定目标方法的过程。例如，前面说过，静态方法会在类加载期就进行解析，而静态方法显然也是可以拥有重载版本的，选择重载版本的过程也是通过静态分派完成的。

2.动态分派：

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();
	}
}

运行结果：

man say hello
woman say hello
woman say hello

　　对于覆盖或者重写来说，Java虚拟机（注意区分虚拟机和编译器）在运行期根据参数的实际类型决定使用哪个覆盖版本。在运行期根据实际类型确定方法执行版本的分派过程称为动态分派。

3.单分派与多分派：

　　今天（直至还未发布的Java 1.8）的Java语言是一门静态多分派、动态单分派的语言。强调“今天的Java语言”是因为这个结论未必会恒久不变。对本小节不做要求。

4.虚拟机动态分派的实现：

　　最常用的“稳定优化”手段就是为类在方法区中建立一个虚方法表（Vritual Method Table），使用虚方法表索引来代替元数据查找以提高性能，比如，对于下面的覆盖方法：

public class Dispatch {

	static class QQ {}

	static class _360 {}

	public static class Father {
		public void hardChoice(QQ arg) {
			System.out.println("father choose qq");
		}

		public void hardChoice(_360 arg) {
			System.out.println("father choose 360");
		}
	}

	public static class Son extends Father {
		public void hardChoice(QQ arg) {
			System.out.println("son choose qq");
		}

		public void hardChoice(_360 arg) {
			System.out.println("son choose 360");
		}
	}

	public static void main(String[] args) {
		Father father = new Father();
		Father son = new Son();
		father.hardChoice(new _360());
		son.hardChoice(new QQ());
	}
}

　　所对应的虚方法表结构示例:



　　

　　虚方法表中存放着各个方法的实际入口地址。如果某个方法在子类中没有被重写，那子类的虚方法表里面的地址入口和父类相同方法的地址入口是一致的，都指向父类的实现入口。如果子类中重写了这个方法，子类方法表中的地址将会替换为指向子类实现版本的入口地址。Son重写了来自Father的全部方法，因此Son的方法表没有指向Father类型数据的箭头。但是Son和Father都没有重写来自Object的方法，所以它们的方法表中所有从Object继承来的方法都指向了Object的数据类型。

　　方法表一般在类加载的连接阶段进行初始化，准备了类的变量初始值后，虚拟机会把该类的方法表也初始化完毕。

　　方法表是分派调用的“稳定优化”手段，虚拟机除了使用方法表之外，在条件允许的情况下，还会使用内联缓存（Inline Cache）和基于“类型继承关系分析”（Class Hierarchy Analysis,CHA）技术的守护内联两种非稳定的“激进优化”手段来获得更高的性能，关于这两种优化技术的原理和运作过程，读者可以参考本书第11章中的相关内容。

8.3.3　动态类型语言支持

　　invokedynamic指令是JDK 7实现“动态类型语言”（Dynamically Typed Language）支持而进行的改进之一。

　　动态类型语言的关键特征是它的类型检查的主体过程是在运行期而不是编译期，满足这个特征的语言有很多，常用的包括：Python、PHP、JavaScript、Groovy、Ruby等。相对的，在编译期就进行类型检查过程的语言（如C++和Java等）就是最常用的静态类型语言。

　　比如，obj.println（"hello world"）；。

　　现在假设这行代码是在Java语言中，并且变量obj的静态类型为java.io.PrintStream，那变量obj的实际类型就必须是PrintStream的子类（实现了PrintStream接口的类）才是合法的。否则，哪怕obj属于一个确实有用println（String）方法，但与PrintStream接口没有继承关系，代码依然不可能运行——因为类型检查不合法。但是相同的代码在JavaScript中情况则不一样，无论obj具体是何种类型，只要这种类型的定义中确实包含有println（String）方法，那方法调用便可成功。

　　这种差别产生的原因是Java语言在编译期间已将println（String）方法完整的符号引用（包含了此方法定义在哪个具体类型之中、方法的名字以及参数顺序、参数类型和方法返回值等信息）生成出来，作为方法调用指令的参数存储到Class文件中。而在JavaScript等动态类型语言中，变量obj本身是没有类型的，变量obj的值才具有类型，编译时最多只能确定方法名称、参数、返回值这些信息，而不会去确定方法所在的具体类型。“变量无类型而变量值才有类型”这个特点也是动态类型语言的一个重要特征。

　　静态类型语言在编译期确定类型，最显著的好处是编译器可以提供严谨的类型检查，这样与类型相关的问题能在编码的时候就及时发现，利于稳定性及代码达到更大规模。而动态类型语言在运行期确定类型，这可以为开发人员提供更大的灵活性，某些在静态类型语言中需用大量“臃肿”代码来实现的功能，由动态类型语言来实现可能会更加清晰和简洁，清晰和简洁通常也就意味着开发效率的提升。

8.4　基于栈的字节码解释执行引擎

8.4.1　解释执行

　　许多Java虚拟机的执行引擎在执行Java代码的时候都有解释执行（通过解释器执行）和编译执行（通过即时编译器产生本地代码执行）两种选择，比如图8-4中的各个步骤。其中，中间的那条分支是解释执行的过程；下面那条分支，则是程序代码到目标机器代码的生成过程。

　　Java语言中，Javac编译器完成了程序源码经过词法分析、语法分析到抽象语法树，再遍历语法树生成线性的字节码指令流的过程。因为这一部分动作是在Java虚拟机之外进行的，而解释器在虚拟机的内部，所以Java程序的编译就是半独立的实现。

8.4.2　基于栈的指令集与基于寄存器的指令集

　　Java编译器输出的指令流，基本上是一种基于栈的指令集架构，指令流中的指令大部分都是零地址指令，它们依赖操作数栈进行工作。与之相对的另外一套常用的指令集架构是基于寄存器的指令集，最典型的就是x86的二地址指令集，就是现在我们主流PC机中直接支持的指令集架构。基于栈的指令集主要的优点就是可移植，代码相对更加紧凑（字节码中每个字节就对应一条指令，而多地址指令集中还需要存放参数）、编译器实现更加简单（不需要考虑空间分配的问题，所需空间都在栈上操作）等；但是执行速度稍慢，完成相同功能所需的指令数量一般会比寄存器架构多。

8.4.3　基于栈的解释器执行过程

一段简单的算术代码例子：

	public int calc() {
		int a = 100;
		int b = 200;
		int c = 300;
		return (a + b) * c;
	}

直接使用javap命令看看它的字节码指令:

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个Slot的局部变量空间，笔者根据这些信息画了7张图，描述字节码执行过程中的程序计数器、操作数栈和局部变量表的变化情况。