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，那真实的情况又是什么样呢？
- 注：当 java 加载类 A，而 A 又依赖了 B，java 会用加载 A 的类加载器去加载类 B
DriverManager剖析
翻看源码发现 java 为了解决 spi 问题引入了上下文类加载器的概念Thread.currentThread().getContextClassLoader()，首先获取调用类caller的类加载器，如果为空的话，便直接获取上下文类加载器
加载顺序
后记
所有实例代码 https://github.com/xijiu/share
