Java虚拟机之类加载学习总结

1 什么是类加载

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

1.1 类加载的应用

在 Java 中类型的加载、连接和初始化过程都是在程序运行期间完成的，为 Java 应用提供了极高的扩展性和灵活性，例如，编写一个面向接口的应用程序，可以等到运行时再指定其实际的实现类（例如下面会提到的 SPI 机制）；通过Java预置的或自定义类加载器，让某个本地的应用程序在运行时从网络或其他地方上加载一个二进制流作为其程序代码的一部分（JSP、字节码增强）。

1.2 类加载过程

在 Java 中，一个类从定义到使用可以分为加载、验证、准备、解析、初始化、使用以及卸载几个步骤。其中验证、准备和解析又可以统称为连接。

1. 加载：通过全限定类名查找并加载类的二进制数据，将静态存储结构转化为方法区的运行时数据结构（java.lang.Class 对象）；
2. 验证：确保被加载的类的正确性；
3. 准备：为类的静态变量分配内存，并将其初始化为默认值；
4. 解析：把类中的符号引用转换为直接引用；
5. 初始化：为类的静态变量赋予正确的初始；

1.3 类的验证

验证是连接阶段的第一步，这一阶段的目的是为了确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

1）文件格式验证：此阶段保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个 Java 类型信息的要求。如是否以魔数 0xCAFEBABE 开头，主、次版本号是否在当前虚拟机处理范围之内，常量合理性验证等。

2）元数据验证：此阶段保证不存在不符合 Java 语言规范的元数据信息。如是否存在父类，父类的继承链是否正确，抽象类是否实现了其父类或接口之中要求实现的所有方法，字段、方法是否与父类产生矛盾等。

3）字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。例如保证跳转指令不会跳转到方法体以外的字节码指令上。

4）符号引用验证：在解析阶段中发生，保证可以将符号引用转化为直接引用。

可以考虑使用 -Xverify:none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

1.4 类初始化顺序

1. 父类静态变量/静态初始化块 - 子类静态变量/静态初始化块；
2. 父类变量/初始化块 - 父类构造器；
3. 子类变量/初始化块 - 子类构造器。

2 类加载时机

JVM 规范并未对何时进行类加载过程进行强制约束，但 JVM 规范严格规定了有且只有六种情况必须立即对类进行“初始化”，同时保证在此之前完成加载、验证、准备，这六种场景称之为对类的主动使用：

1. 遇到 new、getstatic、putstatic 或 invokestatic 这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段；
2. 使用 java.lang.reflect 包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需 要先触发其初始化；
3. 当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化；
4. 当虚拟机启动时，用户需要指定一个要执行的主类（包含 main() 方法的那个类），虚拟机会先初始化这个主类；
5. 当使用 JDK 7 新加入的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化；
6. 当一个接口中定义了 JDK 8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

除此之外，所有引用类的方式都不会触发初始化，称为被动引用，如：

1. 通过子类引用父类的静态字段，不会导致子类初始化。
2. 通过数组定义来引用类，不会触发此类的初始化。MyClass[] cs = new MyClass[10];
3. 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

3 类加载器

JVM 团队有意将通过一个类的全限定名来获取描述该类的二进制字节流这个动作放到 JVM 之外实现，以方便程序积极决定如何获取所需要的类。即实现这一动作的代码被称之为类加载器（ClassLoader）。

3.1 类加载分类

类加载器可以分为两种类型，分别是虚拟机自带类加载器和用户自定义类加载器。当 JVM 启动时，会自顶向下形成会形成由三个类加载器组成的初始类加载器层次结构：

1. 启动类加载器（BootstrapClassLoader）：是嵌在 JVM 内核中的加载器，该加载器是用 C++ 语言编写，主要负载加载 JAVA_HOME/lib 下的类库，启动类加载器无法被应用程序直接使用。
2. 扩展类加载器（ExtensionClassLoader）：该加载器器是用 JAVA 编写，且它的父类加载器是 Bootstrap。主要加载 JAVA_HOME/lib/ext 目录中的类库。也可通过 -Djava.ext.dirs= 参数设置加载路径。
3. 应用程序类加载器（AppClassLoader）：负责加载应用程序 classpath 目录下的所有 jar 和 class 文件。它的父加载器为 ExtClassLoader。

3.2 双亲委派

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（在该类加载的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

看下ClassLoader#loadClass()方法的就能明白 Classloader 是如何通过组合父加载器 来实现双亲委托模型的了：

protected Class<?> loadClass(String name, boolean resolve) {synchronized (getClassLoadingLock(name)) {// 首先检查类是否已加载Class<?> c = findLoadedClass(name);if (c == null) {// 先尝试通过该加载器的父加载器或启动类加载器加载try {if (parent != null) {c = parent.loadClass(name, false);} else {c = findBootstrapClassOrNull(name);}} catch (ClassNotFoundException e) {// ClassNotFoundException thrown if class not found// from the non-null parent class loader}if (c == null) {// 如果还找不到，调用findClass查找类c = findClass(name);}}// 如果是true的话，将该加载器链接到加载的类if (resolve) {resolveClass(c);}return c;}
}

3.3 自定义类加载器

实现自定义类加载器一般分为两步：一是继承 java.lang.ClassLoader；二是重写父类的 findClass() 方法。除此以外还有两个比较重要的方法：

1. defineClass()：将一个字节数组转换为 Class 类的实例；
2. loadClass()：根据全限定类名找到类，推荐自定义类加载器重写findClass()，而不是当前方法。

实际上，即使我们按如上方法自定义了类加载器，也无法使用自定义类加载器。分析内部调用父类的无参构造函数 super()：

protected ClassLoader() {this(checkCreateClassLoader(), null, getSystemClassLoader());
}

不难发现当我们实例化一个自定义类加载器的时候如果没有显示指定其父类加载器，默认会使用系统（应用）类加载器作为其父类加载器，又因为双亲委派模型的存在，自定义类加载器会先使用其父类加载器(即AppClassLoader)去加载，而我们自定义类 MyClass是在 classpath
下的，系统类加载器能加载到，所以，最终MyClass的类加载器就是系统类加载器。

为了解决此问题，可以冲几个方面入手：

1. 重写 loadClass() 方法打破双亲委派模型；
2. 指定自定义类加载器的父类加载器；
3. 将需要加载的 class 字节码文件移出父类加载器的扫描范围。

3.4 类加载器的命名空间

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在 Java 虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。

同时父子类加载器命名空间之间存在一定的可见性关系。

1. 同一个命名空间内的类是相互可见的；
2. 子加载器的命名空间包含所有父加载器的命名空间，因此由子加载器加载的类能看见父加载器加载的类（例如系统类加载器加载的类能看见启动类加载器加载的类）；
3. 由父加载器加载的类不能看见子加载器加载的类；
4. 如果两个加载器之间没有直接或间接的父子关系，那么它们各自加载的类相互不可见（通过两个自定加载类对同一个字节码文件加载生成的 Class 对象的 hashCode 是不同的）。

4 打破双亲委派

4.1 线程上下文类加载器

通常情况下，线程执行到某个类的时候，只能看到这个类对应加载器所加载的类。即每个类都会使用自己的类加载器（加载自身的类加载器）来去加载其它类（指所依赖的类），如果classX 引用了 classY，那么 classX 的类加载器就会去加载classY（前提是classY 尚余被加载）。

JDK 1.2 引入线程上下文类加载器，Thread 提供getContextClassLoader() 与setContextClassLoader() 两个方法，如果没有通过 setContextClassLoader 进行设置的话，线程将继承其父线程的上下文类加载器，Java 应用运行时的初始线程的上下文类加载器是应用程序类加载器（AppClassLoader），在线程中运行的代码可以通过该类加载器来加载类与资源。

SPI (Service Provider Interface) 机制就是一个 JAVA 中使用线程上下文类加载器比较典型的例子，是 JAVA 提供的可用于第三方实现和扩展的机制。JDK 定义接口规范，各个厂商根据接口规范实现。接口定义是在 JAVA 核心库中，由启动类加载器加载，上面我们提到一个类都会使用加载自己的类加载器去加载引用的类，而这些接口的实现却来自于不同的 jar 包，放在 classpath 下，对启动类加载器是不可见的，这样传统的双亲委托模型就无法满足SPI 的要求。需要 JAVA 核心类通过线程上下文类加载器（通常是 AppClassLoader）去加载不同的厂商的实现类。通过在 jar 包下的 META-INF/services/xxx（要实现的接口）文件中声明该接口的实现类，就可以通过 ServiceLoader.load(xxx.class) 扫描到然后加载该类。

ref 真正理解线程上下文类加载器（多案例分析)

4.2 自定义类加载器

使用自定义类加载器，重写 loadClass() 方法（注意不是 findClass() 方法）。

但需要注意过滤类名放过需要加载的 JAVA 核心类（如 java.lang.Object），因为这些类无法使用自定义的类加载器加载。

5 类的卸载

JVM 规范中提到可以不要求虚拟机在方法区中实现垃圾收集，因为方法区垃圾收集的“性价比”通常也是比较低的。判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件:

1. 该类所有的实例都已经被回收，Java堆中不存在该类及其任何派生子类的实例；
2. 加载该类的类加载器已经被回收，这个条件除非是经过精心设计，否则通常是很难达成的；
3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

当满足了类卸载的条件后，通过Full GC便可执行类卸载，回收方法区空间。