深度分析：Java虚拟机类加载机制、过程与类加载器

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

​ 须要注意的是 Java 语言与其余编译时须要进行链接工做的语言不通，它的链接过程是在程序运行期间完成的，这样会在类加载时稍微增长一些性能开销，可是却能为 Java 应用程序提供高度的灵活性。例如，若是编写一个使用接口的应用程序，能够等到运行时再指定其实际的实现。

经过文章，你能够了解到如下内容

类加载时机
类加载过程
类加载器与不足

1. 类加载的时机

类从被加载到虚拟机内存中开始，到卸载出内存，生命周期七个阶段：

加载、验证、准备、解析、初始化、使用、卸载

其中加载、验证、准备、初始化和卸载这五个阶段时肯定的，由于 Java 支持运行时绑定，因此解析再某些状况下能够在初始化阶段以后

虚拟机规范规定有且只有四中状况必须当即对类进行“初始化”（而加载、验证、准备天然须要在此以前）

遇到 new、getstatic、putstatic 或 invokestatic 这 4 条字节码指令时，常见场景：
使用 new 关键字实例化对象
读取或设置一个类的静态字段（被 final 修饰、已在编译期把结果放入常量池的静态字段除外）
调用一个类的静态方法
使用 java.lang.reflect 包的方法对类进行反射调用的时候
初始化一个类的时候，若是发现其父类尚未进行初始化，则须要先触发其父类的初始化
当虚拟机启动时，用户须要指定一个要执行的主类（包含 mian() 方法的那个类），虚拟机会先初始化这个主类

2. 类加载过程

详细介绍一下类加载的全过程，加载、验证、准备、解析和初始化

1. 加载

加载过程须要完成三件事情

经过一个类的全限定名来获取定义此类的二进制字节流
将这个字节流所表明的静态存储结构转化为方法区的运行时数据结构
在 Java 堆中生成一个表明这个类的 java.lang.Class 对象，做为方法区这些数据的访问入口
主要注意的是，第一点的二进制字节流能够从文件、网络、数据库等地方获取；加载阶段也能够由用户自定义的类加载器完成；加载和链接的部份内容（文件格式校验）是交叉进行的

2. 验证

验证的目的是为了确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身安全

（1）文件格式验证：

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

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

保证任意时刻操做数栈的数据类型与指令代码序列都能配合工做，例如不会出现相似这样的状况：在操做栈中放置了一个 int 类型的数据，使用时却按 long 类型来加载入本地变量表中
保证跳转指令不会跳转到方法体之外的字节码指令上
保证方法体中的类型转换是有效的，例如能够把一个子类对象赋值给与它毫无继承关系、彻底不相干的一个数据类型，则是危险和不合法的
（4） 符号引用验证：

符号引用中经过字符串描述的全限定名是否能找到对应的类
在指定类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段
符号引用中的类、字段和方法的访问性是否可被当前类访问

3. 准备

准备阶段是正式为类变量分配内存并设置类变量初始值；内存分配仅包括类变量（被 static 修饰的变量），而不包括实例变量，而这里的初始化，表明零值，即 static 变量初始化为 0

4. 解析

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

符号引用：符号引用以一组符号来描述所引用的目标，符号能够是任何形式的字面量，只要使用时能无歧义地定位到目标便可。符号引用与虚拟机实现的内存布局无关，引用的目标并不必定已经加载到内存中
直接引用：直接引用能够是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句子柄。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不一样虚拟机实例上翻译出来的直接引用通常不会相同
解析的动做主要针对类或接口的解析、字段的解析、类方法解析、接口方法解析

5. 初始化

初始化阶段是根据程序员经过程序制定的主观计划去初始化类变量的其余资源；也能够说是执行类构造器 <clinit>() 的过程。

<clinit>() 方法是由编译器自动收集类中的全部类变量的赋值动做和静态语句块 (static{}) 中的语句并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块以前的变量，定义在它以后的变量，在前面的静态语句块中能够赋值，可是不能访问。
<clinit>() 方法与类的构造函数（或者说实例构造器 <init>() 方法）不一样，它不须要显式地调用父类构造器，虚拟机会保证在子类的 <clinit>() 犯法执行以前，父类的 <clinit>() 方法已经执行完毕。所以在虚拟机中第一个被执行的 <clinit>() 犯法的类确定是 java.lang.Object。
因为父类的 <clinit>() 犯法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操做
<clinit>() 方法对于类或接口来讲并非必须的，若是一个类钟没有静态语句块，也没有对变量的赋值操做，那么编译器能够不为这个类生产 <clinit> 方法
接口中不能使用静态语句块，但仍然有变量初始化的赋值操做，所以接口与类同样都会生成 <clinit> 方法。但接口与类不一样，执行接口的 <clinit>() 方法不须要先执行父接口的 <clinit>() 方法。只有父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也同样不会执行接口 <clinit>() 方法
虚拟机会保证一个类的 <clinit>() 方法在多线程环境中被正确地加锁和同步，若是多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的 <clinit>() 方法，其余线程都须要阻塞等待，直到活动线程执行 <clinit>() 方法完毕。

3. 类加载器与不足

类加载器只用于实现类的加载动做，可是对于任意一个类，都须要由加载它的类加载器和这个类自己一同肯定其在 Java 虚拟机中的惟一性。

双亲委派模型

虚拟机有两种不一样的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用 C++ 语言实现，是虚拟机自身的一部分；另一种就是全部其余的类加载器，这些类加载器都是由 Java 语言实现，独立于虚拟机外部，而且所有继承自抽象类 java.lang.ClassLoader

启动类加载器（Bootstrap ClassLoader）：将存放在 <JAVA_HOME>lib 目录中的，或者被 -Xbootclasspath 参数所指定的路径中的，而且是虚拟机识别的类库加载到虚拟机内存中，启动类加载器没法被 Java 程序直接引用
扩展类加载器（Extension ClassLoader）：这个加载器由 sun.misc.Launcher$ExtClassLoader 实现，它负责加载 <JAVA_HOME>libext 目录中的，或者被 java.ext.dirs 系统变量所指定的路径中的全部类库，开发者能够直接使用扩展类加载器
应用程序类加载器（Application ClassLoader）：这个类加载器由 sun.misc.Launcher$AppClassLoader 来实现，负责加载用户类路径上所指定的类库
咱们的应用程序都是由这三种类加载器互相配合进行加载的，若是有必要，还能够加入本身定义的类加载器

双亲委派模型的工做过程是：若是一个类加载器收到类加载的请求，它首先不会本身去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每个层次的类加载器都是如此，所以全部的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈本身没法完成这个加载请求（它的搜索范围中没有找到所须要的类）时，子加载器才会唱谁本身去加载

好处：Java 类随着它的类加载器一块儿具有了一种带有优先级的层次关系。例如类 java.lang.Object，它放在 rt.jar 之中，不管哪个类加载器加载这个类，最终都是启动类加载器去完成加载，所以 Object 类在程序的各类类加载器环境中都是同一个类；相反，若是没有双亲委派模型，由各个类加载器自行去加载的话，若是用户本身写了一个名为 java.lang.Object 的类，并放在 ClassPath 中，那系统将会出现多个不一样 Object 类，形成程序混乱

破坏双亲委派模型

双亲委派模型是 Java 设计者们推荐给开发者的类加器实现方式，但也有例外，出现过三次大规模的破坏状况

JDK1.2
​ 双亲委派模型是 JDK1.2以后才引入的，但类加载器和抽象类 java.lang.ClassLoader 则在 JDK 1.0 存在了，面对已经存在的用户自定义类加载器的实现代码，Java 设计者们引入双亲委派模型时不得不作出一些妥协。为了向前兼容，JDK 1.2 以后的 java.lang.ClassLoader 添加了一个新的 protected 方法 findClass()，在此以前，用户去继承 java.lang.ClassLoader 的惟一目的是为了重写 loadClass() 方法，由于虚拟机在进行类加载的时候会调用加载器的私有方法 loadClassInternal()，而这个方法的惟一逻辑就是去调用本身的 loadClass()。

​ JDK1.2以后已不提倡用户再去覆盖 loadClass() 方法，由于 loadClass() 方法是双亲委派的实现，而另外提供了一个 protected 的 findClass() 方法，在 loadClass() 方法逻辑里若是父类加载失败，则会调用本身的 findClass() 方法来完成加载

线程上下文类加载器
​ 双亲委派模型解决了各个类加载器的基础类的统一问题，可是若是基础类又要调用回用户的代码的话，是作不到的，由于基础类的类加载器只加载它目录下的文件，可是基础类调用到用户的代码的话，基础类的类加载器就没法加载用户目录下的类了

​ 为了解决这个困境，Java 设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread context ClassLoader）。这个类加载器能够经过 java.lang.Thread 类的 setContextClassLoader() 方法进行设置，若是建立线程时还未设置，它将会从父线程中继承一个；若是在应用程序的全局范围内都没有设置过，那么这个类加载器就是应用类加载器。

​ 有了线程上下文类加载器，原本基础类（例如rt.jar）加载用户的类时，只能经过自身的启动类加载器完成的；如今即可以主动获取线程上下文类加载器去完成用户的类加载。对于SPI（Service Provider Interface）服务提供 API，即可以采用线程上下文类加载器，例如 JNDI、JDBC、JCE、JAXB 和 JBI 等

OGSi
​ OGSi 是当前业界“事实上”的 Java 模块化标准，而 OSGi 实现模块化热部署的关键则是它自定义的类加载器机制的实现。每个程序模块（OSGi 中称为 Bundle）都有一个本身的类加载器，当须要更换一个 Bundle 时，就把 Bundle 连同类加载器一块儿换掉以实现代码的热替换

​ 在 OGSi 环境下，类加载器再也不是双亲委派模型中的树状结构，而是进一步发展为网状结构，当类加载请求时，OSGi 将按照下面的顺序进行搜索：

（1）将以 java.* 开头的类，委派给父类加载器加载

（2）不然，将委派列表名单内的类，委派给父类加载器加载

（3）不然，将 Import 列表中的类，委派给 Export 这个类的 Bundle 的类加载器加载

（4）不然，查找当前 Bundle 的 ClassPath，使用本身的类加载器加载

（5）不然，查找类是否在本身的 Fragment Bundle 中，若是在，则委派给 Fragment Bundle 的类加载器加载

（6）不然，查找 Dynamic Import 列表的 Bundle，委派给对应 Bundle 的类加载器加载

（7）不然，类查找失败