Java类加载机制总结

下面简单的介绍一下整个加载过程中，每个阶段JVM都执行了什么操作：

加载(Loading)

加载过程是 Java 的一大特点，类的来源可以多种多样，压缩包、网络字节流、运行时动态计算生成(reflect)等等...这也造就了Java语言强大的动态特性。

java.lang.Class

验证(Verification)

这一过程主要是为了确保Class的字节流中包含的信息符合虚拟机标准，以免造成破坏

1. 文件格式验证
2. 元数据验证
3. 字节码验证，通过数据流和控制流分析确定程序的语义是合法的
4. 符号引用验证，确保解析动作能够正常执行

准备(Preparation)

这一阶段将会为类变量分配内存并设置其初始值，注意此时进行内存分配的仅包括类变量(static修饰)，并且初始值通常情况下是数据类型的零值而不是设定值，如下例

public static int val = 123;
复制代码

在这一阶段变量 val 的赋值是0而不是123，因为此时尚未执行任何Java方法，而对 val 复制的 putstatic 指令在初始化阶段后才会执行。

当然也有特殊情况，如下

public static final int val = 123;
复制代码

加上final关键字修饰后，Java编译时会为 val 生成 ConstantValue 属性，这时准备阶段就会根据设置将其值设置为123。

解析(Resolution)

此阶段虚拟机将常量池内的符号替换为直接引用，主要包含以下动作：

1. 类或接口的解析
2. 字段解析
3. 类方法解析
4. 接口方法解析

初始化(Initialization)

这时类加载过程的最后一步，这部分开始真正的执行Java代码，也就是说，这个阶段可以由 程序员 参与。

此阶段其实就是执行类构造器 <clinit>() 方法的过程。

类加载器

类加载器(Class Loader)是Java虚拟机的一大创举，它将“获取类的二进制字节流”这个过程交给了开发人员自己去实现，只要编写不同的Class Loader，应用程序本身就可以用相应的方式来获取自己需要的类。

类与加载器的关系

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在虚拟机中的唯一性。

通俗的讲，就是即便同一个Class文件，被不同的类加载器加载之后，得到也不是同一个“类”（equals方法返回false）。

双亲委派模型

从虚拟机角度讲，只有两种类加载器，一种是启动类加载器(Bootstrap ClassLoader)，在hotpot上使用C++实现，属于虚拟机的一部分；另一种则是所有其他类的加载器，这些加载器是独立于虚拟机的，由Java语言实现的，从开发者角度看，可以分为以下两类：

1. 扩展类加载器(Extension ClassLoader)

2. 应用程序类加载器(Appliaction ClassLoader)

当然开发人员也可以自己编写类加载器，最终不同的类加载器之间的层次关系如下图所示：

这就是Java中著名的 双亲委派模型 ，它要求除了顶级的BootStrap加载器之外，其他类加载器都必须有父类加载器，工作流程如下：

如果一个类加载器收到了类加载的请求，他首先不会自己去尝试加载这个类，而是将这个请求委派给父类加载器去完成，只有当父加载器反馈自己无法完成加载请求时，子加载器才会自己去尝试加载这个类。

这样做的好处是，Java类随着它的类加载器一起具备了一种带有优先级的层次关系。举个例子，比如 java.lang.Object 这个类，无论哪个类加载器加载时，最终都会委派给Bootstrap加载器去加载，这就保证了整个系统运行过程中的 Object 都是同一个类。

否则，如果用户自己编写了一个 java.lang.Object 类，并放在程序的classpath中，最终系统将会出现多个不同的Object类，整个Java体系就变得一团混乱了。