JVM（三）：认清类加载子系统

前言：首先得了解类加载的一个总过程，见下图，然后我们再对每个过程中的细节拆分说明

类加载过程

• 加载
  这一步主要就靠类加载器去加载我们的class文件，具体流程：
  1）通过一个类的全限定名来获取此类的二进制流。
  2）将这个字节流的静态存储结构转化为方法区的运行时数据结构。
  3）在内存中创建一个 java.lang.Class 对象，作为方法区该类的各种数据的访问入口。
  其中注意点：非数组类的加载时通过类加载器来完成，而数组类本身是由java虚拟机直接创建，但是数组中元素的类型最终还是要靠类加载器创建。HotSpot这个虚拟机是将Class对象存放在方法区的。
• 验证
  验证比较耗时，它非常重要但是不一定必要，可以使用 -Xverify:none 来关闭，缩短类加载时间。验证的目的主要是为了确保二进制字节流中的信息是否符合虚拟机的规范，并且确保没有安全问题。
  其中包括：
  1）格式检查：比如魔数验证（见上一篇了解class文件中的魔数）、版本的校验啊、长度的校验等。
  2）语义检查：比如是否继承final、是否有父类、会否实现抽象方法等。
  3）字节码验证：跳转的指令是否指向正确的位置等
  4）符号引用验证：符号引用的直接引用是否存在。
• 准备
  主要做两件事情：
  1）为已在方法区中的类的静态成员变量分配内存（final修饰的除外，因为已经在编译阶段分配了，由于编译器的优化）。
  2）为静态成员变量设置初始值，初始值为零值。
  

比如：public static int x = 1000; 在这里x的初始值是0，而不是1000。
如果是 public static final int x = 1000; 在编译阶段x就已经被赋值为1000了。
注意：这里仅仅为类变量分配和赋值，分配在方法区；实例变量是随着对象的一起被分配到堆中。

• 解析
  解析是虚拟机将常量池的符号引用替换为直接引用的过程。
  首先说下符号引用和直接引用：
  符号引用：它是在class文件中的，是以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能够无歧义的定位到目标即可。比如 org.simple.People类 引用了 org.simple.Language类 ，在编译时People类并不知道Language类的实际内存地址，因此只能使用符号org.simple.Language （假设是这个，当然实际中是由类似于CONSTANT_Class_info的常量来表示的）来表示Language类的地址。
  直接引用：就是直接指向目标的指针，比如，指向“类型”【Class对象】、类变量、类方法的直接引用可能是指向方法区的指针。
• 初始化
  初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的Java程序代码。调用类初始化方法 <client>() 的过程，完成对static修饰的类变量的手动赋值还有主动调用静态代码块。比如上面准备阶段的类变量，真正给他赋值就是在这一步，准备阶段只是赋零值。
  注意点：
  1） <clinit>()方法是编译器自动收集类中所有变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的。
  2）静态代码块只能访问到出现在静态代码块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。
  3）虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法以及执行完毕。因此虚拟机中第一个被执行的<clinit>()方法肯定是java.lang.Object。
  4）由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
  5）<clinit>()方法不是必须的，如果一个类或接口中没有静态语句块，也没有静态成员变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。
  6）接口和类一样也会通过<init>()方法，只不过接口中没有静态语句块，而且执行接口的<clinit>()方法时不需要先执行父接口的<clinit>()方法，除非父接口中的静态成员变量被使用到了才会执行父接口的<clinit>()方法。另外接口的实现类初始化时也不会执行接口的<clinit>()方法。
  7）虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。同一个类加载器下，一个类型只会初始化一次。这也是为什么静态内部类的单例模式是线程安全的，就是由虚拟机保证的。

类加载时机

什么时候开始加载，虚拟机规范并没有强制性的约束，对于其它大部分阶段究竟何时开始虚拟机规范也都没有进行规范，这些都是交由虚拟机的具体实现来把握。所以不同的虚拟机它们开始的时机可能是不同的。但是对于初始化却严格的规定了。有且仅有以下四种情况下才会触发类的"初始化"。注意用词，有且仅有。

• 遇到 new、getstatic、putstatic、invokestatic 这四条指令时，如果对应的类没有初始化，则要对对应的类先进行初始化。

  对应我们java代码场景是：
  new实例化对象、读取或设置一个类的静态字段(被final修饰，已在编译器把结果放入常量池的静态字段除外)、调用一个类的静态方法

• 对类进行反射调用的时候

• 初始化一个类的时候发现其父类还没初始化，要先初始化其父类

• 当虚拟机开始启动时，用户需要指定一个主类，虚拟机会先执行这个主类的初始化

类加载器

• 启动类加载器(Bootstrap ClassLoader)
  负责加载 JAVA_HOME\lib 目录中的，或通过-Xbootclasspath参数指定路径中的，且被虚拟机认可（按文件名识别，如rt.jar）的类。由C++实现，不是ClassLoader子类。

• 扩展类加载器(Extension ClassLoader)
  负责加载 JAVA_HOME\lib\ext 目录中的，或通过java.ext.dirs系统变量指定路径中的类库。

• 应用程序类加载器(Application ClassLoader)
  负责加载用户路径（classpath）上的类库。

• 自定义类加载器(从Custom ClassLoader)，对于其他地方的一些class文件（比如本地的、网络上的），如果需要加载就只能通过自定义类加载器去加载。自带的三个类加载器只能加载指定路径下的类字节码。

加载过程中会先检查类是否被已加载，检查顺序是自底向上，从Custom ClassLoader到BootStrapClassLoader逐层检查，只要某个classloader已加载就视为已加载此类，保证此类只所有ClassLoader加载一次。而加载的顺序是自顶向下，也就是由上层来逐层尝试加载此类。

双亲委派模型

当一个类加载器收到类加载任务，会先交给其父类加载器去完成，因此最终加载任务都会传递到顶层的启动类加载器，只有当父类加载器无法完成加载任务时，才会尝试执行加载任务。

为什么要使用双亲委托这种模型呢？
因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。

考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时就被引导类加载器（Bootstrcp ClassLoader）加载，所以用 户自定义的ClassLoader永远也无法加载一个自己写的String。

所以，JVM在判定两个class是否相同时，不仅要判断两个类名是否相同，而且要判断是否由同一个类加载器实例加载的。

破坏双亲委派模型

什么时候需要破坏双亲委派模型呢？
某些情况下父类加载器加载的class文件由于受到加载范围的限制，无法加载到需要的文件，这个时候就需要委托子类加载器去加载，但是按照双亲委派模型的规定，只能子类加载去委托父类去加载，这个时候就需要破坏双亲委派模型才能成功加载到父类加载器需要的类，也就是说父类会委托子类去加载它需要的class文件。
比如JDBC中，Driver接口是在rt.jar中的，具体的实现是由各个数据库厂商提供的jar包中实现的，这些jar包都做为第三方引入在classpath路径下。
而DriverManager 这个类是在rt.jar中的，它在加载的时候需要加载各个实现了Driver接口的实现类，然后进行管理。DriverManager是由Bootstrap ClassLoader 来加载的，这个时候就需要Bootstrap ClassLoader来委托Application ClassLoader去加载Driver接口的各个实现类，从而就破坏了双亲委派模型。