JVM第七章-虚拟机类加载机制

代码编译的结果从本地机器码转变为字节码，本章涉及虚拟机如何加载这些Class文件，Class文件中的信息进入到虚拟机后会发生什么变化
类加载机制
Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制。
类加载的时机
一个类型从被加载到虚拟机内存中到卸载出内存的整个生命周期

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类型的加载过程必须按
照这种顺序按部就班地开始。而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）。为这些阶段通常都是互相交叉地混合进行的，会在一个阶段执行的过程中调用、激活另一个阶段
初始化开始的情况：
1）遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段。能够生成这四条指令的典型Java代码场景有：
·使用new关键字实例化对象的时候。
·读取或设置一个类型的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）
的时候。
·调用一个类型的静态方法的时候。
2）使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先触发其初始化
3）当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
4）当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先
初始化这个主类
5）动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。（什么是动态语言支持？）
6）当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。
这六种场景中的行为称为对一个类型进行主动引用。除此之外，所有引用类型的方式都不会触发初始化，称为被动引用。
被动引用的例子
1.通过子类引用父类的静态字段，不会导致子类初始化

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

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

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

运行之后发现没有输出“SuperClass init！”
3.常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的
上述代码运行之后，也没有输出“ConstClass init！”，这是因为虽然在Java源码中确实引用了
ConstClass类的常量HELLOWORLD，但其实在编译阶段通过常量传播优化，已经将此常量的值“helloworld”直接存储在NotInitialization类的常量池中，以后NotInitialization对常量ConstClass.HELLOWORLD的引用，实际都被转化为NotInitialization类对自身常量池的引用了。也就是说，实际上NotInitialization的Class文件之中并没有ConstClass类的符号引用入口，这两个类在编译成Class文件后就已不存在任何联系了。

类加载的过程

加载

在加载阶段，Java虚拟机需要完成以下三件事情：
1）通过一个类的全限定名来获取定义此类的二进制字节流。
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
非数组类型的加载阶段可以使用Java虚拟机里内置的引导类加载器来完成，也可以由用户自定义的类加载器去完成
数组类的加载如下：（没懂）
数组类本身不通过类加载器创建，它是由Java虚拟机直接在内存中动态构造出来的。但数组类的元素类型（ElementType，指的是数组去掉所有维度的类型）最终还是要靠类加载器来完成加载
其创建流程遵循以下规则
1.如果数组的组件类型是引用类型，就递归采用本节中定义的加载过程去加载这个组件类型，数组C将被标识在加载该组件类型的类加载器的类名称空间上
2.如果数组的组件类型不是引用类型（例如int[]数组的组件类型为int），Java虚拟机将会把数组C
标记为与引导类加载器关联。
加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段
尚未完成，连接阶段可能已经开始。

连接

验证

这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求
大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证和符号引用验证。
虚拟机验证到输入的字节流如不符合Class文件格式的约束，就应当抛出一个java.lang.VerifyError异常或其子类异常
文件格式验证
该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求。这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的
验证之后，这段字节流才被允许进入Java虚拟机内存的方法区中进行存储，所以后面的三个验证阶段全部是基于方法区的存储结构上进行的
元数据验证
第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java语言规范》的要
求
字节码验证
目的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的。该阶段对类的方法体（Class文件中的Code属性）进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的行为，但不可能用程序来准确判定一段程序是否存在Bug
符号引用验证
发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。目的是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。
如果无法通过符号引用验证，Java虚拟机将会抛出一个java.lang.IncompatibleClassChangeError的子类异常，典型的如：java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等

准备

准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初
始值的阶段。在JDK 7及之前，HotSpot使用永久代来实现方法区时，实现是完全符合这种逻辑概念的；而在JDK 8及之后，类变量则会随着Class对象一起存放在Java堆中。这时候进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。类变量在准备阶段过后的初始值为0值，但如果类变量是Constant的话，在准备阶段虚拟机会赋值为最终的常量值

解析

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

什么是直接引用：

初始化

直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。
初始化阶段，则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源
初始化阶段就是执行类构造器()方法的过程
()并不是程序员在Java代码中直接编写的方法，它是Javac编译器的自动生成物
()如何产生的
()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的
语句合并产生的
·()方法与类的构造函数（即在虚拟机视角中的实例构造器()方法）不同，它不需要显
式地调用父类构造器，Java虚拟机会保证在子类的()方法执行前，父类的()方法已经执行完毕。因此在Java虚拟机中第一个被执行的()方法的类型肯定是java.lang.Object。

类加载器

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性。两个类即使来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等
示例：
不同的类加载器对instanceof关键字运算的结果的影响

public class ClassLoaderTest {
public static void main(String[] args) throws Exception {
	ClassLoader myLoader = new ClassLoader() {
	@Override
	public Class<?> loadClass(String name) throws ClassNotFoundException {
	try {
		String fileName = name.substring(name.lastIndexOf(".") + 1)+".class";
		InputStream is = getClass().getResourceAsStream(fileName);
		if (is == null) {
			return super.loadClass(name);
		}
		byte[] b = new byte[is.available()];
		is.read(b);
		return defineClass(name, b, 0, b.length);
	} catch (IOException e) {
		throw new ClassNotFoundException(name);
	}
}
};
	Object obj =myLoader.loadClass("org.fenixsoft.classloading.ClassLoaderTest").newInstance();
	System.out.println(obj.getClass());
	System.out.println(obj instanceof org.fenixsoft.classloading.ClassLoaderTest);
}
}

运行结果

class org.fenixsoft.classloading.ClassLoaderTest
false

我们使用这个类加载器去加载了一个名为“org.fenixsoft.classloading.ClassLoaderTest”的类，并实例化了这个类的对象。
两行输出结果中，从第一行可以看到这个对象确实是类org.fenixsoft.classloading.ClassLoaderTest实例化出来的
在第二行的输出中却发现这个对象与类org.fenixsoft.classloading.ClassLoaderTest做所属类型检查的时候返回了false。这是因为Java虚拟机中同时存在了两个ClassLoaderTest类，一个是由虚拟机的应用程序类加载器所加载的，另外一个是由我们自定义的类加载器加载的，虽然它们都来自同一个Class文件，但在Java虚拟机中仍然是两个互相独立的类，做对象所属类型检查时的结果自然为false。

双亲委派模型

站在Java虚拟机的角度来看，只存在两种不同的类加载器
1）启动类加载器（Bootstrap ClassLoader）： 是虚拟机自身的一部分
2）其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader
本节主要介绍JDK8中的，什么是三层类加载器，以及什么是双亲委派模型
三层类加载器
启动类加载器（Bootstrap Class Loader）
启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，
如果需要把加载请求委派给引导类加载器去处理。这个类加载器负责加载存放在
\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的

示例：

public ClassLoader getClassLoader() {
	//获取当前类的类加载器
	ClassLoader cl = getClassLoader0();
	//如果getClassLoader0()返回null，则表示当前类是由启动类加载器加载的。
	if (cl == null)
		return null;
	//安全检查
	SecurityManager sm = System.getSecurityManager();
	if (sm != null) {
		ClassLoader ccl = ClassLoader.getCallerClassLoader();
	if (ccl != null && ccl != cl && !cl.isAncestor(ccl)) {
		sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);
	}
}
//返回当前类的类加载器
return cl;
}

扩展类加载器（Extension Class Loader）
以Java代码的形式实现的，开发者可以直接在程序中使用扩展类加载器来加载Class文件
应用程序类加载器（Application Class Loader）
这个类加载器由sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystemClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器
注： JDK 9之前的Java应用都是由这三种类加载器互相配合来完成加载的，如果用户认为有必要，还可以加入自定义的类加载器来进行拓展

双亲委派模型

双亲委派模型描述各类加载器之间的层次关系

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。
双亲委派模型的工作过程：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。
好处：
Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。反之，如果没有使用双亲委派模型，都由各个
类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。
以实现双亲委派的代码

protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException
{
	// 首先，检查请求的类是否已经被加载过了
	Class c = findLoadedClass(name);
	if (c == null) {
		try {
			if (parent != null) {
				//若没有则调用父加载器的loadClass()方法
				c = parent.loadClass(name, false);
			} else {
			//若父加载器为空则默认使用启动类加载器作为父加载器
				c = findBootstrapClassOrNull(name);
			}
			} catch (ClassNotFoundException e) {
			// 如果父类加载器抛出ClassNotFoundException
			// 说明父类加载器无法完成加载请求
			}
			//假如父类加载器加载失败，抛出ClassNotFoundException异常的话，才调用自己的findClass()方法尝试进行加载
			if (c == null) {
				// 在父类加载器无法加载时
				// 再调用本身的findClass方法来进行类加载
				c = findClass(name);
			}
			}
			if (resolve) {
				resolveClass(c);
			}	
			return c;
}

破坏双亲委派模型

1）
双亲委派模型有时并不适用，特别是在一些基础服务需要调用用户定义的代码时。JNDI服务（Java Naming and Directory Interface）是一个例子。JNDI是Java的一部分，由启动类加载器加载，因此是一个“基础类型”。但它需要调用由第三方实现的服务提供者接口（SPI），这些SPI通常位于应用程序类路径下，由应用程序类加载器或其它自定义类加载器加载。

线程上下文类加载器的引入
为了解决这个问题，Java引入了线程上下文类加载器的概念。这个类加载器可以通过Thread类的setContextClassLoader()方法设置。如果没有显式设置，线程将继承其父线程的上下文类加载器。如果整个应用中都没有设置，那么默认为应用程序类加载器
线程上下文类加载器允许服务（如JNDI）使用它来加载用户定义的代码。这相当于让一个父类加载器请求一个子类加载器来完成类的加载，这在某种程度上“破坏”了双亲委派模型的原则。但这是解决基础服务需要调用用户代码这一特殊场景的必要手段
2）
由于用户对程序动态性的追求而导致的。动态性指”热“，希望程序不用重启机器就能立即使用
OSGi是如何通过类加载器实现热部署的
OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构，当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：

Java模块化系统

为了能够实现模块化可配置的封装隔离机制，Java虚拟机对类加载架构也做出了相应的变动调整，才使模块化系统得以顺利地运作。JDK 9的模块不仅仅像之前的JAR包那样只是简单地充当代码的容器，除了代码外，Java的模块定义还包含以下内容：
·依赖其他模块的列表。
·导出的包列表，即其他模块可以使用的列表。
·开放的包列表，即其他模块可反射访问模块的列表。
·使用的服务列表。
·提供服务的实现列表。
如果启用了模块化进行封装，模块就可以声明对其他模块的显式依赖，这样Java虚拟机就能够在启动时验证应用程序开发阶段设定好的依赖关系在运行期是否完备