学习日志：类加载器

---

前言

• 类加载过程：加载->连接->初始化。
• 连接过程又可分为三步：验证->准备->解析。
  
  加载是类加载过程的第一步，主要完成下面 3 件事情：
  1.通过全类名获取定义此类的二进制字节流
  2.将字节流所代表的静态存储结构转换为方法区的运行时数据结构
  3.在内存中生成一个代表该类的 Class 对象，作为方法区这些数据的访问入口类加载器

---

一、类加载器介绍

类加载器从 JDK 1.0 就出现了，最初只是为了满足 Java Applet（已经被淘汰） 的需要。后来，慢慢成为 Java 程序中的一个重要组成部分，赋予了 Java 类可以被动态加载到 JVM 中并执行的能力。

• 类加载器是一个负责加载类的对象，用于实现类加载过程中的加载这一步。
• 每个 Java 类都有一个引用指向加载它的ClassLoader。
• 数组类不是通过 ClassLoader 创建的（数组类没有对应的二进制字节流），是由 JVM 直接生成的。

class Class<T> {
  ...
  private final ClassLoader classLoader;
  @CallerSensitive
  public ClassLoader getClassLoader() {
     //...
  }
  ...
}

简单来说，类加载器的主要作用就是加载 Java 类的字节码（ .class 文件）到 JVM 中（在内存中生成一个代表该类的 Class 对象）。 字节码可以是 Java 源程序（.java文件）经过 javac 编译得来，也可以是通过工具动态生成或者通过网络下载得来。

其实除了加载类之外，类加载器还可以加载 Java 应用所需的资源如文本、图像、配置文件、视频等等文件资源。本文只讨论其核心功能：加载类。

二、类加载器加载规则

JVM 启动的时候，并不会一次性加载所有的类，而是根据需要去动态加载。也就是说，大部分类在具体用到的时候才会去加载，这样对内存更加友好。对于已经加载的类会被放在 ClassLoader 中。在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。也就是说，对于一个类加载器来说，相同二进制名称的类只会被加载一次。

public abstract class ClassLoader {
  ...
  private final ClassLoader parent;
  // 由这个类加载器加载的类。
  private final Vector<Class<?>> classes = new Vector<>();
  // 由VM调用，用此类加载器记录每个已加载类。
  void addClass(Class<?> c) {
        classes.addElement(c);
   }
  ...
}

三、类加载器总结

JVM 中内置了三个重要的 ClassLoader：

1. BootstrapClassLoader(启动类加载器)：最顶层的加载类，由 C++实现，通常表示为null，并且没有父级，主要用来加载 JDK 内部的核心类库（ %JAVA_HOME%/lib目录下的rt.jar、resources.jar、charsets.jar等 jar 包和类）以及被-Xbootclasspath参数指定的路径下的所有类。
2. ExtensionClassLoader(扩展类加载器)：主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类以及被 java.ext.dirs系统变量所指定的路径下的所有类。
3. AppClassLoader(应用程序类加载器)：面向我们用户的加载器，负责加载当前应用classpath 下的所有 jar 包和类。

🌈 拓展：

• rt.jar：rt 代表“RunTime”，rt.jar是 Java 基础类库，包含 Java doc里面看到的所有的类的类文件。也就是说，我们常用内置库java.xxx.都在里面，比如java.util.、java.io.、java.nio.、java.lang.、java.sql.、java.math.*。
• Java 9 引入了模块系统，并且略微更改了上述的类加载器。扩展类加载器被改名为平台类加载器（platform class loader）。Java SE 中除了少数几个关键模块，比如说 java.base 是由启动类加载器加载之外，其他的模块均由平台类加载器所加载。

除了这三种类加载器之外，用户还可以加入自定义的类加载器来进行拓展，以满足自己的特殊需求。就比如说，我们可以对 Java 类的字节码（ .class 文件）进行加密，加载时再利用自定义的类加载器对其解密。

除了 BootstrapClassLoader 是 JVM 自身的一部分之外，其他所有的类加载器都是在 JVM 外部实现的，并且全都继承自 ClassLoader抽象类。这样做的好处是用户可以自定义类加载器，以便让应用程序自己决定如何去获取所需的类。

每个 ClassLoader 可以通过getParent()获取其父 ClassLoader，如果获取到 ClassLoader 为null的话，那么该类是通过 BootstrapClassLoader 加载的。

public abstract class ClassLoader {
  ...
  // 父加载器
  private final ClassLoader parent;
  @CallerSensitive
  public final ClassLoader getParent() {
     //...
  }
  ...
}

为什么 获取到 ClassLoader 为null就是 BootstrapClassLoader 加载的呢？
这是因为BootstrapClassLoader 由 C++ 实现，由于这个 C++ 实现的类加载器在 Java 中是没有与之对应的类的，所以拿到的结果是 null。
获取 ClassLoader 的小案例：

public class PrintClassLoaderTree {

    public static void main(String[] args) {

        ClassLoader classLoader = PrintClassLoaderTree.class.getClassLoader();

        StringBuilder split = new StringBuilder("|--");
        boolean needContinue = true;
        while (needContinue){
            System.out.println(split.toString() + classLoader);
            if(classLoader == null){
                needContinue = false;
            }else{
                classLoader = classLoader.getParent();
                split.insert(0, "\t");
            }
        }
    }

}

输出结果(JDK 8 )：

|--sun.misc.Launcher$AppClassLoader@18b4aac2
    |--sun.misc.Launcher$ExtClassLoader@53bd815b
        |--null

从输出结果可以看出：

• 我们编写的 Java 类 PrintClassLoaderTree 的 ClassLoader 是AppClassLoader；
• AppClassLoader的父 ClassLoader 是ExtClassLoader；
• ExtClassLoader的父ClassLoader是Bootstrap ClassLoader，因此输出结果为 null。

四、自定义类加载器

除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader。如果我们要自定义自己的类加载器，很明显需要继承 ClassLoader抽象类。

ClassLoader 类有两个关键的方法：

• protected Class loadClass(String name, boolean resolve)：加载指定二进制名称的类，实现了双亲委派机制 。name 为类的二进制名称，resolve 如果为 true，在加载时调用 resolveClass(Class<?> c) 方法解析该类。
• protected Class findClass(String name)：根据类的二进制名称来查找类，默认实现是空方法。

如果我们不想打破双亲委派模型，就重写 ClassLoader 类中的 findClass() 方法即可，无法被父类加载器加载的类最终会通过这个方法被加载。但是，如果想打破双亲委派模型则需要重写 loadClass() 方法。