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程序代码。调用类初始化方法的过程，完成对static修饰的类变量的手动赋值还有主动调用静态代码块。比如上面准备阶段的类变量，真正给他赋值就是在这一步，准备阶段只是赋零值。

类加载时机

什么时候开始加载，虚拟机规范并没有强制性的约束，对于其它大部分阶段究竟何时开始虚拟机规范也都没有进行规范，这些都是交由虚拟机的具体实现来把握。所以不同的虚拟机它们开始的时机可能是不同的。但是对于初始化却严格的规定了。
有如下几个时机

• 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)

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

双亲委派模型

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

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

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

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