Java ClassLoader 浅析

双亲委派

提起 java 类加载器，自然绕不开其双亲委派模型

什么是双亲委派

提起双亲委派，首先想到便是那张经典的向上委派图

双亲委派

一般场景下，当某个类将要被加载时，由系统上下文默认的类加载器Thread.currentThread().getContextClassLoader()对该类进行加载，通常这个类加载器为AppClassLoader，AppClassLoader不会直接尝试加载这个类，而是委托给它的父类ExtClassLoader对其加载，ExtClassLoader则会直接委托父类BootstrapClassLoader加载，当BootstrapClassLoader找不到要加载的目标类时，才会逐级下放给子类，否则类加载完毕

这里需要明确2个概念：

• 父类加载器： 这里虽然称为父加载器，但却跟 java 的继承没有关系，反而这里实现“父”加载器是通过组合的方式，本文后续还会说明
• 类定义加载器： 真正加载该类的类加载器，而不是发起加载动作的类加载器；比如AppClassLoader发起加载String类，而真正执行加载动作的却是BootstrapClassLoader，所以定义String的类加载器为BootstrapClassLoader

双亲委派好处

java 的设计者们为什么要大费周章设计如此复杂的加载模型呢？其实主要有以下两个好处

• 避免同一个类被重复加载

  当用户定义了相当多的类加载器时，如果没有此委托模型，将产生大量的类重复加载，占用内存（同一个类被不同的类加载器加载时，将会产生多个副本），可参见下面用例

  
  
  示例

• 保护 jdk 核心类不被篡改

  java向来以安全著称，试想，如果没有此隔离机制，某个依赖的 jar 包中被恶意篡改、注入java.lang.String类后，将导致整个进程的奔溃；同样参见上图，由于双亲委派机制，java 内部类不管由自定义类加载器还是AppClassLoader，都仅会产生一份实例，且一定由BootstrapClassLoader加载

jdk 类加载器剖析

下面我们依次分析3个类加载器

• AppClassLoader

  • 路径sun.misc.Launcher#AppClassLoader

  • 此类加载器主要负责加载用户编写的java文件，同时java默认的线程上下文类加载器亦为此类。我们翻看sun.misc.Launcher源码验证此观点
    

    1595676357635.jpg

  • 类结构图

    
    
    appClassLoader

  • 总结

    在一般的工程中，此类用来加载初jdk内部类外的所有java文件，如果项目工程需要自定义类加载器的话，一般也是会继承自此类来保证双亲委派模型；不过有些做三方包、二方包隔离的中间件会自定义多个类加载器继承自ExtClassLoader，从而保证用户编写的代码、依赖的jar包做到真正隔离

• ExtClassLoader

  • 路径sun.misc.Launcher#ExtClassLoader

  • 类结构图

    
    
    extClassLoader

  • 解析
    翻看源码，发现此类的parent为null

    
    
    1595680247927.jpg

    而加载class的方法ClassLoader#loadClass定义如下

    1595680463996.jpg

    即某个类加载器的parent指定为 null 时，它的父类会自动变为BootstrapClassLoader，而BootstrapClassLoader定义在native方法上

  • 加载哪些类？

    ExtClassLoader会加载系统变量java.ext.dirs对应的所有路径中的 jar 包，以macos为例，System.getProperty("java.ext.dirs") 内容如下：

    /Users/***/Library/Java/Extensions
    /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/ext
    /Library/Java/Extensions
    /Network/Library/Java/Extensions
    /System/Library/Java/Extensions
    /usr/lib/java
    

• BootstrapClassLoader

  • 加载哪些类？

    BootstrapClassLoader加载java的核心类库，我们可以通过sun.misc.Launcher.getBootstrapClassPath().getURLs()来获取其具体路径，以macos为例，内容如下：

    file:/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/resources.jar
    file:/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/rt.jar
    file:/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/sunrsasign.jar
    file:/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/jsse.jar
    file:/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/jce.jar
    file:/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/charsets.jar
    file:/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/jfr.jar
    file:/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/classes
    

至此，我们可以把双亲委派的模型画的更具体一些

双亲委派

打破双亲委派

java 双亲委派模型似乎固若金汤，足够安全；不过我们自定义的类加载器想打破这个委派机制的话，也是相当容易，甚至 jdk 自身在处理某些场景时，自己也会打破该机制，比如赫赫有名的 SPI

如何打破

如何打破双亲委派其实非常简单，我们先看 java 是如何保证双亲委派正常运行的

源码

ClassLoader的loadClass方法保证了双亲委派，不过此方法是被protected修饰的，所以任何子类都可以重写此方法；java 建议使用者重写findClass方法，这样可以在不破坏双亲委派的机制下，达到加载自身类的目的。不过在某些场景下，我们依旧可以直接重写loadClass来破坏委派机制

SPI

讨论 java 类加载器为何要提到spi ？ 是的，讨论类加载器一定绕不开 spi 的设计理念，spi 对委派概念是一次冲击，我们也可以看到 java 设计者们在双亲委派问题上做的让步

什么是spi

我们先简单回顾下 spi 的定义；spi 是 Service Provider Interface 的简写，翻译成中文就是服务提供发现接口。

要使用Java SPI，需要遵循如下约定：

• 1、当服务提供者提供了接口的一种具体实现后，在jar包的META-INF/services目录下创建一个以“接口全限定名”为命名的文件，内容为实现类的全限定名；
• 2、接口实现类所在的jar包放在主程序的classpath中；
• 3、主程序通过java.util.ServiceLoder动态装载实现模块，它通过扫描META-INF/services目录下的配置文件找到实现类的全限定名，把类加载到JVM；
• 4、SPI的实现类必须携带一个不带参数的构造方法；

java 通过 spi 机制，在解耦的同时实现了可插拔操作

带来的问题

通过上文分析，我们知道像诸如rt.java等核心类库均交由BootstrapClassLoader加载，不过核心类库返回的对象却是用户自定义的实现类，这在双亲委派机制上是说不通的，下面我们拿jdbc驱动举例说明

首先我们看下驱动启动的代码实例

Class.forName("com.mysql.jdbc.Driver");
Connection connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/wolong_extend?rewriteBatchedStatements=true&useServerPrepStmts=true","root","root");
System.out.println(connection.getClass().getName());

最后的输出结果为 com.mysql.jdbc.JDBC4Connection

mysql 对应的实现类在代码之前并未加载，而在加载 java rt.jar包中的java.sql.DriverManager时却返回了一个用户定义的对象，给人的错觉便是BootstrapClassLoader加载了com.mysql.jdbc.JDBC4Connection，那真实的情况又是什么样呢？

• 注：当 java 加载类 A，而 A 又依赖了 B，java 会用加载 A 的类加载器去加载类 B

DriverManager剖析

源码

翻看源码发现 java 为了解决 spi 问题引入了上下文类加载器的概念Thread.currentThread().getContextClassLoader()，首先获取调用类caller的类加载器，如果为空的话，便直接获取上下文类加载器

加载顺序

打破双亲委派

后记

所有实例代码 https://github.com/xijiu/share