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源码验证此观点
- 类结构图
- 总结
  
  在一般的工程中，此类用来加载初jdk内部类外的所有java文件，如果项目工程需要自定义类加载器的话，一般也是会继承自此类来保证双亲委派模型；不过有些做三方包、二方包隔离的中间件会自定义多个类加载器继承自ExtClassLoader，从而保证用户编写的代码、依赖的jar包做到真正隔离
ExtClassLoader
- 路径sun.misc.Launcher#ExtClassLoader
- 类结构图
- 解析
  
  翻看源码，发现此类的parent为null
  
  而加载class的方法ClassLoader#loadClass定义如下
  
  即某个类加载器的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，那真实的情况又是什么样呢？