类加载器

虚拟机在加载累的过程中需要类加载器进行加载，那么当JVM想要加载一个.class文件时，到底需要那个类加载器来加载？这时候就需要双亲委派机制来高速JVM使用哪个类加载器加载。

从Java虚拟机角度来看只存在两种类加载器：

• 启动类加载器（Bootstrap ClassLoader）：由C++实现，是JVM的一部分，java中用null代替

• 其他类加载器：由Java实现，独立于JVM，全部继承自抽象类ClassLoader

从开发者角度来看类加载器可以划分的更细致一些：

• 启动类加载器（Bootstrap Class Loader）：加载<JAVA_HOME>\lib或-Xbootclasspath指定路径中的类库

• 扩展类加载器（Extension Class Loader）：在sun.misc.Launcher$ExtClassLoader，加载<JAVA_HOME>\lib\ext或java.ext.dirs指定路径中的类库

• 应用程序类加载器（Application Class Loader）：在sun.misc.Launcher$AppClassLoader，通过ClassLoader.getSystemClassLoader()返回，加载用户类路径（ClassPath）上的类库

启动类加载器

使用C/C++语言实现，负责将存放在<JAVA_HOME>\lib目录中，或者被-Xbootclasspath参数执行的目录中的，并且是虚拟机识别的类库加载到虚拟机内存中，启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要吧加载请求委派给引导类加载器，直接使用null代替即可。可以通过如下代码查看启动类加载器加载那些路径的jar:

String bootClassLoader = System.getProperty("sun.boot.class.path");

for (String s : bootClassLoader.split(";")) {

  System.out.println("bootClassLoader：");

  System.out.println(s);

}

扩展类加载器

扩展类加载器Extension ClassLoader 由 Java 语言编写，并由 sun.misc.Launcher$ExtClassLoader 实现，父类加载器为启动类加载器。负责加载 <JAVA_HOME>\lib\ext 目录中的，或者被 java.ext.dirs 系统变量所指定的路径中的所有类库。开发者可以直接使用扩展类加载器，如果用户创建的 JAR 放在扩展目录下，也会自动由扩展类加载器加载。可以通过如下代码查看扩展类启动器可以加载哪些路径的jar：

String extensionClassLoader = System.getProperty("java.ext.dirs");

for (String s : extensionClassLoader.split(";")) {

  System.out.println("extensionClassLoader：");

  System.out.println(s);

}

应用程序类加载器

应用程序类加载器 Application ClassLoader 由 Java 语言编写，并由 sun.misc.Launcher$App-ClassLoader 实现，父类加载器为扩展类加载器。由于这个类加载器是 ClassLoader 中的 getSystemClassLoader() 方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径 ClassPath 或系统属性 java.class.path 指定路径下的类库。开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

可以通过如下代码查看应用程序类加载器可以加载哪些路径的 jar：

String appClassLoader = System.getProperty("sun.class.path");

for (String s : appClassLoader.split(";")) {

  System.out.println("appClassLoader：");

  System.out.println(s);

}

自定义类加载器

一般类加载几乎都是上述三种类加载器配合执行的，在必要时也可以自定义类加载器，一般用到的场景如下：

• 隔离加载类

• 修改类加载方式

• 扩展加载源

• 防止源码泄露

开发者可以通过继承抽象类`java.lang.ClassLoader`类的方式，实现自己的类加载器。在JDK1.2之前，自定义类加载器总会去继承 ClassLoader 类并重写 loadClass() 方法，从而实现自定义的类加载类，但是在 JDK 1.2 之后已不再建议用户去覆盖 loadClass() 方法，而是建议把自定义的类加载逻辑写在 findclass() 方法中。

双亲委派模块

什么是双亲委派模型

上述四种类加载器之间存在着一种层级关系

自定义类加载器->应用程序类加载器->扩展类加载器->启动类加载器。

除了启动类加载器外，其余的加载器都有自己的父类加载器，通过组合而非继承关系类复用父加载器的代码。

可以通过代码来查看类加载器的层级结构：

CustomClassLoader myClassLoader = new CustomClassLoader("/opt/data");

Class<?> myClass = myClassLoader.loadClass("top.maplefix.notes.bean.Car");

// 创建对象实例

Object o = myClass.newInstance();

// 调用方法

Method print = myClass.getDeclaredMethod("print", null);

print.invoke(o, null);

// 输出类加载器

System.out.println("ClassLoader: " + o.getClass().getClassLoader());

可以看到当前类的加载器是应用程序类加载器，它的父类亲加载器是扩展类加载器，扩展类加载器的父类输出了一个 null，这个 null 会去调用启动类加载器。后续通过 ClassLoader 类的源码我们可以知道这一点。

那到底什么事双亲委派模型呢？其实我们吧上数类加载器之间的这层关系，我们成为类加载器的双亲委派模型（Parents Delegation Model）。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里的类加载器之间的父子关系一般不会以继承（Inheritance）的关系实现，而是都是用组合（Composition）关系来复用附加在气的代码。总结就是：

• 任意类加载器收到了类加载的请求

• 把请求委派给父类加载器去完成（直到传给启动类加载器）

• 当父类加载器无法完成加载（其搜索范围未找到所需的类）

• 子加载器才会尝试去加载

为什么需要双亲委派模型

如上面提到的，因为类加载器之间有严格的层级关系，那么也就是的Java类也随之具备了一种带有优先的层级关系。例如对于java.lang.Object，它存放于rt.jar中，无论哪一个类架子阿奇要加载这个类，最终都会委派给顶层的启动来加载器进行加载。因此Object类在程序的各种类加载环境中都是同一个类。相反，如果没有双亲委派模型的话，由各个类加载器自行去加载的话，如果用户自己编写了一个也叫java.lang.Object的类，并且存放在Classpath中，那系统就会出现多个不同的Object，Java类型体系中最基础的行为就无法保证。

所以双亲委派模型的核心就是保障类加载的唯一性和安全性：

• 唯一性：可以避免类的重复加载，当父类加载器已经加载过某一个类时，子加载器就不会再重新加载这个类。例如上述提及的 java.lang.Object 类，最终都委派给最顶层的启动类加载器进行加载，因此 Object 类在程序的各种类加载器环境中都是同一个类。

• 安全性：保证了 Java 的核心 API 不被篡改。因为启动类加载器 Bootstrap ClassLoader 在加载的时候，只会加载 JAVA_HOME 中的 jar 包里面的类，如 java.lang.Object，那么就可以避免加载自定义的有破坏能力的 java.lang.Object。

双亲委派模型是怎么实现的

实现双亲委派的代码都在java.lang.ClassLoader#loadClass()中：

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {

    synchronized (getClassLoadingLock(name)) {

        // 首先检查类是否已经被加载过

        Class<?> c = findLoadedClass(name);

        if (c == null) {

            long t0 = System.nanoTime();

            try {

                if (parent != null) {

                    // 若没有加载过并且有父类加载器则调用父类加载器的 loadClass() 方法

                    c = parent.loadClass(name, false);

                } else {

                    // 调用启动类加载器

                    c = findBootstrapClassOrNull(name);

                }

            } catch (ClassNotFoundException e) {

            }

            if (c == null) {

                // 如果仍未找到，则调用 findClass 以查找该类。

                long t1 = System.nanoTime();

                c = findClass(name);

                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);             sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);

                sun.misc.PerfCounter.getFindClasses().increment();

            }

        }

        if (resolve) {

            resolveClass(c);

        }

        return c;

    }

}

首先检查类是否已经被加载过，如果没有加载过且有父类加载器则调用父类加载器的loadClass()方法，如父类加载器为空则默认使用启动类加载器作为父加载器。如果父类加载器失败，抛出ClassNotFoundException异常后在调用自己的findClass()方法进行加载。

如何破坏双亲委派机制

双亲委派模型并不是强制性的约束模型，而是Java设计者推荐给开发者的来加载器实现方式。在Java世界中大部分类加载器都遵循这个模型，到目前为止双亲委派模型出现过三次“被破坏”的情况。

JDK 1.2 历史原因

双亲委派模型在JDK1.2推出，在此之前的类加载器都是通过复写loadClass()方法加载类。为了兼容，无法再以技术手段避免loadClass()被子类复写，**即可以通过复写loadClass()方法进行双亲委派模型**

为了避免破坏双亲委派模型，JDK1.2新增了protect的ffindClass()方法，让用户尽可能重写findClass()而不是loadClass()，这样就不影响用户自定义加载类，又可以保证新写的类加载器符合双亲委派模型。

SPI

根据双亲委派模型，越基础的类由越上层的加载器加载，基础类型是作为被用户代码继承、调用的API存在。如果基础类又要回调用户的代码，那该怎么办？例如JNDI服务，它的代码由启动类加载器去加载，但JNDI的目的就是对资源进行集中管理和查找，他需要调用由独立厂商实现并部署在应用程序 ClassPath 下的 JNDI 接口提供者（SPI，Service Provider Interface）的代码，但是启动类不可能认识这个代码。Java设计团队由此引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread 类的 setContextClassLoaser() 方法进行设置，如果创建线程时还未设置，将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

JNDI 服务使用这个线程上下文类加载器去加载所需要的 SPI 代码，也就是父类加载器请求子类加载器去完成类加载的动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则，但这也是无可奈何的事情。Java 中所有涉及 SPI 的加载动作基本上都采用这种方式，例如 JNDI、JDBC、JCE、JAXB和JBI等。

OSGI、Jigsaw等模块化技术的应用

IBM推出的OSGi为了实现模块热部署，每个程序模块（称为Bundle）都有自身的类加载器，当需要更换Bundle时连同类加载器一起换掉以实现代码的热替换。

在OSGi环境下，类加载器不再是双亲微泡模型的树状结构，而是网状结构，当收到类加载请求时，按照下面的顺序镜像类搜索。

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

• 否则，将委派列表名单内的类，委派给父类加载器加载

• 否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载

• 否则，查找当前Bundle的ClassPath，使用自己的类加载器加载

• 否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载

• 否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载

• 否则，类查找失败

上述步骤除了前两点符合双亲委派模型，其余类的查找都是在平级的来加载器进行的。

Tomcat等web容器的出现

我们知道，Tomcat是web容器，那么一个web容器可能需要部署多个应用程序。

不同的应用程序可能会依赖同一个第三方类库的不同版本，但是不同版本的类库中某一个类的全路径名可能是一样的。

如多个应用都要依赖hollis.jar，但是A应用需要依赖1.0.0版本，但是B应用需要依赖1.0.1版本。这两个版本中都有一个类是com.hollis.Test.class。

如果采用默认的双亲委派类加载机制，那么是无法加载多个相同的类。

所以，Tomcat破坏双亲委派原则，提供隔离的机制，为每个web容器单独提供一个WebAppClassLoader加载器。

实现热插拔热部署工具

跟模块化类似，为了让代码动态生效而无需重启，实现方式时把模块连同类加载器一起换掉就实现了代码的热替换。