Java类加载机制

目前正在读《深入理解Java虚拟机》这本书，此篇是根据这本书的内容进行整理。

1. 类加载机制定义

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

在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略虽然会另类加载时稍微增加一点开销，但是会为Java应用程序提供高度的灵活性，Java里天生可以动态拓展的语言特性就是依赖运行期动态加载（Android中的热更新原理）和动态连接这个特点实现的。

2. 类加载的时机

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载，验证，准备，解析，初始化，使用和卸载。其中验证，准备，解析3个部分统称为连接。这7个阶段的发生顺序如下图所示：（图片来自百度图片）

加载、验证、准备、初始化、卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序开始，而解析阶段则不一定：它在某情况下可以在初始化阶段之后在再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。对于初始化阶段，虚拟机规范中则是严格定义了有且只有5种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前），换句话说，触发类加载的条件有以下5种：

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

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

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

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

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

这5中场景中的行为称为对一个类进行主动引用。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。

3. 类加载的过程

3.1 加载

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

②.将这个字节流所代表的静态存储结构转换为方法区内的运行时数据结构

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

3.2 验证

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

3.3 准备 

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

3.4 解析

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

3.5 初始化

类初始化阶段是类加载过程的最后一步。初始化是对类变量进行赋值以及执行静态代码块。

4. 类加载器

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

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

4.1 类加载器的分类

4.1.1 启动类加载器（Bootstrap ClassLoader）：负责将存放在<JAVA_HOME>目录中的，或者被 -Xbootclasspath 参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机内存中。

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

4.1.3 应用程序类加载器 （Application ClassLoader）：这个类加载器是ClassLoader.getSystemClassLoader()的返回值，所以一般也称为系统类加载器。负责加载用户类路径（classpath）上的指定类库，开发者可以直接使用这个类加载器。一般情况，如果我们没有自定义类加载器默认就是用这个加载器。

4.2 双亲委派模型

如下图所展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型（图片来自百度图片）。

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

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