虚拟机类加载机制（笔记）

一、概述

1、类加载机制：虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。

2、Java语言中，类型的加载、连接和初始化过程都是在程序运行期间完成的。

优点：为Java应用程序提供高度的灵活性。Java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。例如：如果编写一个面向接口的应用程序，可以等到运行时再指定其实际的实现类；用户可以让本地的应用程序在运行时从网络或其他地方加载一个二进制流作为程序代码的一部分。

缺点：令类加载时稍微增加一些性能开销

 

二、类加载的时机

1、类从被加载到内存，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）和卸载（Unloading）7个阶段。

2、注意点：

2.1.加载、验证、准备、初始化和卸载五个阶段的顺序是确定的，但是解析阶段则不一定。它可以在初始化阶段之后在开始（这是为了支持Java语言的动态绑定（也成为运行时绑定或晚期绑定））。

2.2.这些阶段通常都是互相交叉地混合式进行的，通常会在一个阶段执行的过程中调用、激活另一个阶段。

3、初始化阶段

加载阶段的开始没有强制规范，可以由虚拟机的具体实现来把握。但是初始化阶段，虚拟机则是严格规定了有且只有5种情况必须立即对类进行“初始化”（而加载、验证、准备自然要在此之前开始）——被称为“主动引用”。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。

4、主动引用

4.1.遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这四条指令最常见的Java场景：使用new关键字实例化对象、读取或设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）以及调用一个类的静态方法的时候。

4.2.使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发器初始化。

4.3.当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

4.4.当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。

4.5.当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个句柄所对应的类没有进行过初始化，则需要先触发其初始化。

5、被动引用

5.1.通过子类引用父类的静态字段不会导致子类初始化

package Initialization;

public class SuperClass {
	static{
		System.out.println("SuperClass init!");
	}
	public static int value=123;
        public static final String HELLOWORLD="Hello World!";
}


package Initialization;

public class SubClass extends SuperClass {
	static{
		System.out.println("SubClass init!");
	}
}

package Initialization;

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

}

运行结果

对于静态字段，只有直接定义了这个字段的类才会被初始化，因此通过子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。

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

package Initialization;

public class NotInitialization {
	public static void main(String[] args){
		//System.out.println(SubClass.value);
		SuperClass[] sca=new SuperClass[10];
	}

}

它不会触发org.fenixsoft.classloading.SuperClass的初始化阶段，但是触发了另外一个名为“[Lorg.fenixsoft.classloading.SuperClass”的类的初始化阶段。这是一个由虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作由字节码指令newarray触发。

这个类代表了一个元素类型为org.fenixsoft.classloading.SuperClass的一维数组，数组中应有的属性和方法（用户可直接使用的只有length属性和clone()方法）都实现在这个类中。

小结：如果你用数组定义来引用类，那么触发的是一个数组类的初始化，而不会触发该引用类的初始化。

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

package Initialization;

public class NotInitialization {
	public static void main(String[] args){
		//System.out.println(SubClass.value);
		//SuperClass[] sca=new SuperClass[10];
		System.out.println(SuperClass.HELLOWORLD);
	}

}

运行结果

虽然在Java源码中引用了SuperClass类中的常量HELLOWORLD，但其实在编译阶段通过常量传播优化，“Hello,World!”的值已经被存储到NotInitialization类的常量池中了。以后NotInitialization对常量SuperClass.HELLOWORLD的引用实际都被转化为NotInitialization对自身常量池的引用了。

6、接口

接口也有初始化过程，这一点和类是一致的，上面的代码都是用静态语句块“static{}”来输出初始化信息的，而接口中不能使用“static{}”语句块，但编译器仍然会为接口生成“<clinit>()”类构造器，用于初始化接口中所定义的成员变量。

接口与类真正有所区别的是前面所述的5种“有且仅有”需要开始初始化场景中的第3种：当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时并不要求其父接口全部都完成了初始化，只有在真正用到父接口的时候才会初始化。

 

三、类加载的过程

1、加载

1.1.工作：

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

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

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

1.2.特点——高灵活度

比如：“通过一个类的全限定名”来获取此类的二进制字节流”这条，并没有指明一定要从Class文件中获取。

#从ZIP包中读取，最终成为日后JAR、EAR、WAR格式的基础

#从网络中获取，这种场景最典型的应用就是Applet

#运行时计算生成，这种场景使用最多的就是动态代理技术

#由其他文件生成，典型场景是JSP应用，即由JSP文件生成对应的Class类

#从数据库中读取，相对比较少见

1.3.非数组类的加载阶段（准确地说，是加载阶段中获取类的二进制字节流的动作）

开发人员可控性最强，因为加载阶段既可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式（即重写一个类加载器的loadClass()方法）。

1.4.数组类的加载阶段

数组类本身不通过类加载器创建，它是由Java虚拟机直接创建的。但是数组类的元素类型（Element Type，指的是数组去掉所有维度的类型。比如SuperClass[] sca=new SuperClass[10]中的SuperClass）最终还是要依靠类加载器去创建，一个数组类（下面简称C）创建过程就遵循以下规则：

#如果数组的组件类型（Component Type，指的是去掉一个维度的类型）是引用类型，那就递归采用本届中定义的加载过程去加载这个组件类型，数组C将在加载该组件类型的类加载器的类名称空间上被标识。

#如果数组的组件类型不是引用类型（比如int[] 数组），Java虚拟机将会把数组C标识为与引导类加载器关联。

#数组类的可见性与它的组件类型的可见性一致（比如SuperClass[]数组，它的可见性和SuperClass一致），如果组件类型不是引用类型，那数组类的可见性默认为public（比如int[]数组）。

1.5.加载完成后

虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中了，方法区中的数据存储格式由虚拟机实现自行定义。然后在内存中实例化一个java.lang.Class类的对象（并没有规定在Java堆中，HotSpot虚拟机把Class对象存放在了方法区）——作为程序访问方法区中的这些类型数据的外部接口。

2、验证

2.1.目的：连接阶段的第一步。确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

2.2.安全问题：

使用纯粹的Java代码是无法做到诸如访问数组边界以外的数据等事情的，如果这样子做了，编译器将会拒绝编译。但是Class文件的来源并不一定是有Java代码编译而来的，你甚至可以直接用十六进制编辑器进行编写。因此上述Java代码无法做到的事情在字节码语言层面上是可以表达出来的。因此，为了防止因载入有害的字节流导致系统崩溃，虚拟机会对其进行验证

2.3.文件格式验证

#是否以魔数0xCAFEBABE开头

#主、次版本号是否在当前虚拟机处理范围之内

...

目的：保证输入的字节流能正确地解析并存储于方法区之内。

基于二进制字节流进行验证，只有通过了这个验证后，字节流才会进入内存的方法区中进行存储。

2.4.元数据验证

#这个类是否有父类（除了java.lang.Object以外，所有的类都要有父类）

#这个类是否继承了不允许被继承了类（如final修饰的类）

#类中的字段、方法是否与父类产生矛盾（不符合规则的方法重载等）

...

目的：对类的元数据信息进行语义校正，保证不存在不符合Java语言规范的元数据信息

2.5.字节码验证（验证过程中最复杂的阶段）

#保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作

#保证跳转指令不会跳转到方法体之外的字节码指令上

...

目的：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。

在第二阶段对元数据信息中的数据类型做完校验后，这个阶段将对类的方法体进行校验分析。

改进：利用一项名为“StackMapTable”的属性（这项属性描述了方法体中所有的基本块开始时本地变量表和操作数栈应有的状态），将字节码验证的类型推导转变为类型检查从而节省一些时间。JDK1.7之后，对于主版本号大于50的Class文件，使用类型检查来完成数据流分析校验则是唯一的选择，不允许再退回到类型推导的校验方式。

2.6.符号引用验证

目的：将符号引用转化为直接引用。符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验。——确保解析动作能正常执行

时间：发生在连接的第三个阶段——解析阶段

校验内容：

#符号引用中通过字符串描述的全限定名是否能找到对应的类

#在制定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段

...

2.7.小结：对于虚拟机的类加载机制来说，验证阶段是一个非常重要的、但不是一定必要（因为对程序运行期没有影响）的阶段，如果所运行的全部代码都已经被反复使用和验证过，那么在实施阶段就可以考虑使用-Xvetify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

3、准备

3.1.目的：正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。

3.2.注意点：

A、这个时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆Java堆中。

B、这里所说的初始值，通常情况下是数据类型的零值。假设一个类变量的定义为：

public static int value = 123；

那变量在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。

特殊情况：如果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值，假设上面类变量value的定义变为：

public static final int value = 123；

编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123；

4、解析

4.1.作用：将常量池内的符号引用替换为直接引用的过程

符号引用（Symbolic Reference）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。它与虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们所能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件中

直接引用（Direct Reference）：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。

4.2.发生时间：只要在执行anewarray等16个用于操作符号引用的字节码指令之前进行即可。

4.3.虚拟机实现可以对对第一次解析的结果进行缓存（在运行时常量池记录直接引用，并把常量标识为已解析状态）从而避免解析动作重复进行。（invokedynamic指令除外，它的目的本来就是用于动态语言支持，必须等到程序实际运行到这条指令的时候，解析动作才能进行）

4.4.针对对象：类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符，分别对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info、CONSTANT_InvokeDynamic_info7中常量类型。

4.5.类或接口的解析

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

#如果C不是一个数组类型，那虚拟机会把代表N的全限定名传递给D的类加载器去加载这个类C。在加载过程中又可能触发其他类的加载动作。

#如果C是一个数组类型，并且数组的元素类型为对象，那将会按照第1点的规则加载数组元素类型。接着由虚拟机生成一个代表次数组维度和元素的数组对象。

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

4.6.字段解析

要解析一个从未被解析过的字段符号引用，首先会对字段表内class_index项中索引的CONSTANT_Class_info符号进行解析，也就是字段所属的类或接口的符号引用。若出现异常则解析失败，如果解析成功那将这个字段所属的类或接口用C表示。接着对C进行后续字段的搜索。

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

#否则，从下往上递归搜索它的各个接口和父接口，若找到则返回这个字段的直接引用，查找结束

#否则，按照继承关系从下往上递归搜索其父类，若找到则返回这个字段的直接引用，查找结束

#否则查找失败，抛出java.lang.NoSuchFieldError异常

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

总结：先找到带解析字段所属类或接口，接着搜索所属类或接口，再从下至上搜索接口，最后搜索父类

注意：如果有一个同名字字段同时出现在C的接口和父类中，或者同时在自己活父类的多个接口中出现，那编译器可能拒绝编译。

package Initialization;

public class FieldResolution {
	interface Interface0{
		int A=0;
	}
	
	interface Interface1 extends Interface0{
		int A=1;
	}
	
	interface Interface2{
		int A=2;
	}
	
	static class Parent implements Interface1{
		public static int A=3;
	}
	
	static class Sub extends Parent implements Interface2{
		public static int A=4;
	}
	
	public static void main(String[] args){
		System.out.println(Sub.A);
	}
}

运行结果

JDK1.8中是可以编译的。

4.7.类方法解析

同样地，需要先解析出类方法表中的class_index项中索引的方法所属的类或接口，若解析成功，用C表示这个类或接口。后续的类方法搜索：

#类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现class_index的索引C是个接口，那就直接抛出java.lang.IncompatibleClassChangeError异常。

#否则，在类C中查找是否有简单名称和描述符都与目标匹配的方法，如果有则返回这个方法的直接引用，查找结束

#否则，在类C的父类中查找，有则返回直接引用

#否则，在类C实现的接口列表及它们的父接口中递归查找，如果有相匹配的方法，说明类C是一个抽象类，抛出java.lang.AbstractMethodError异常

#否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError异常

最后如果返回了直接引用，同样要对这个方法进行权限验证，如果发现不具备对此方法的访问权限，将抛出java.lang.IllegalAccessError异常。

4.8.接口方法解析

解析class_index项中索引的方法所属的类或接口的符号引用，若成功，用C表示这个接口。接着进行后续的接口方法搜索：

#与类方法解析不同，如果在接口方法表中发现class_index中的索引C是个类不是接口，就抛出java.lang,IncompatibleClassChangeError异常。

#否则，查找接口中是否有相匹配的方法，若有则返回直接引用，查找结束

#否则，在接口C的父接口中递归查找，直到java.lang.Object类（包括在内）为止，有则返回直接引用

#否则宣告方法查找失败，抛出java.lang.NoSuchMethodError异常

由于接口中所有的方法默认都是public，所以不存在访问权限的问题，因此接口方法的符号解析中应当不会抛出java.lang.IllegalAccessError异常。

5、初始化

类加载的最后一步，前面的类加载过程中除了加载阶段，用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段才真正开始执行类中定义的Java程序代码。

初始化阶段是执行类构造器<clinit>()方法的过程。

5.1.<clinit>()方法的特点

#<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的静态语句块中只能访问到定义在它之前的变量，定义在它之后的变量，它可以对其进行赋值，但是不能访问。

#<clinit>()方法与类的构造函数（实例构造器<init>()）不同，它不需要显示地调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个执行的<clinit>()方法的类一定是java.lang.Object。

#由于父类的<clinit>()方法先执行，也就意味着父类的静态语句块要优先于子类的变量赋值操作。如以下程序运行后，字段B的值将会是2而不是1。

package Initialization;

public class Sub extends Parent{
	public static int B=A;
	
	public static void main(String[] args){
		System.out.println(Sub.B);
	}
}

运行结果

#<clinit>()方法对于类和接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量（类变量？）的赋值操作，那么编译器可以不为这个类生成<clinit>()方法

#接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此类和接口一样都会生成<clinit>()方法。但和类不同的是，执行接口的<clinit>()方法不需要执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也不会执行接口接口的<clinit>()方法。

#虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步。如果一个类中的<clinit>()方法中有耗时很长的操作，就可能造成多个进程阻塞。

 

四、类加载器

虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作代码模块称为“类加载器”。

1、类加载器的作用：

#实现类的加载动作

#对于每一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。（即使两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那么这两个类就必定不相等）——这里所说的“相等”包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果。

2、双亲委派模型

2.1.分类：

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

从Java开发人员的角度划分，可分为以下三种

#启动类加载器（Bootstrap ClassLoader）：这个类加载器负责将存放在<JAVA_HOME>\bin目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。

#扩展类加载器（Extension ClassLoader）：它负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定路径中的所有类库，开发者可以直接使用扩展类加载器。

#应用程序类加载器（Application ClassLoader）：由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下就是程序中默认的类加载器。

如果有必要还可以加入自己定义的类加载器，关系如下：

2.2.双亲委派模型

要求除了顶层的启动类加载器外，其余的加载器都要有自己的父类加载器。这里的父子关系一般不会以继承来实现，而是使用组合关系来复用父加载器的代码。

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

优点：确定了类的唯一性。比如类java.lang.Object，它存放在rt.jar之中，无论哪个类加载器要加载这个类，最终都是委派给启动类加载器来完成加载，因此Object在程序的各种类加载器环境中都是同一个类。

2.3.发展

在OSGI环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构。——实现模块化热部署

关键：每一个程序模块都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉已实现代码的热替换。

 

博客内容来自《深入理解Java虚拟机》