JAVA 双亲委派与类加载器
JAVA 双亲委派与类加载器
双亲委派
虚拟机在加载类的过程中需要使用类加载器进行加载，而在Java中，类加载器有很多，那么当JVM想要加载一个.class文件的时候，到底应该由哪个类加载器加载呢？
这就不得不提到”双亲委派机制”。
首先，我们需要知道的是，Java语言系统中支持以下4种类加载器：
- Bootstrap ClassLoader 启动类加载器
- Extention ClassLoader 标准扩展类加载器
- Application ClassLoader 应用类加载器
- User ClassLoader 用户自定义类加载器
这四种类加载器之间，是存在着一种层次关系的，如下图

一般认为上一层加载器是下一层加载器的父加载器，那么，除了BootstrapClassLoader之外，所有的加载器都是有父加载器的。
那么，所谓的双亲委派机制，指的就是：当一个类加载器收到了类加载的请求的时候，他不会直接去加载指定的类，而是把这个请求委托给自己的父加载器去加载。只有父加载器无法加载这个类的时候，才会由当前这个加载器来负责类的加载。
那么，什么情况下父加载器会无法加载某一个类呢？
其实，Java中提供的这四种类型的加载器，是有各自的职责的：
- Bootstrap ClassLoader ，主要负责加载Java核心类库，
%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。 - Extention ClassLoader，主要负责加载目录
%JRE_HOME%\lib\ext目录下的jar包和class文件。 - Application ClassLoader ，主要负责加载当前应用的
classpath下的所有类 - User ClassLoader ， 用户自定义的类加载器,可加载指定路径的
class文件
为什么使用双亲委派
通过委派的方式，可以避免类的重复加载，当父加载器已经加载过某一个类时，子加载器就不会再重新加载这个类。
另外，通过双亲委派的方式，还保证了安全性。因为Bootstrap ClassLoader在加载的时候，只会加载JAVA_HOME中的jar包里面的类，如java.lang.Integer，那么这个类是不会被随意替换的，除非有人跑到你的机器上， 破坏你的JDK。
那么，就可以避免有人自定义一个有破坏功能的java.lang.Integer被加载。这样可以有效的防止核心Java API被篡改。
“父子加载器”之间的关系是继承吗？
很多人看到父加载器、子加载器这样的名字，就会认为Java中的类加载器之间存在着继承关系。
甚至网上很多文章也会有类似的错误观点。
这里需要明确一下，双亲委派模型中，类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码的。
如下为ClassLoader中父加载器的定义：
public abstract class ClassLoader {
// The parent class loader for delegation
private final ClassLoader parent;
}
双亲委派的实现
实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中：
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
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()方法进行加载。
如何主动破坏双亲委派机制？
知道了双亲委派模型的实现，那么想要破坏双亲委派机制就很简单了。
因为他的双亲委派过程都是在loadClass方法中实现的，那么想要破坏这种机制，那么就自定义一个类加载器，重写其中的loadClass方法，使其不进行双亲委派即可。
loadClass（）、findClass（）、defineClass（）区别
ClassLoader中和类加载有关的方法有很多，前面提到了loadClass，除此之外，还有findClass和defineClass等，那么这几个方法有什么区别呢？
- loadClass()
- 就是主要进行类加载的方法，默认的双亲委派机制就实现在这个方法中。
- findClass()
- 根据名称或位置加载.class字节码
- definclass()
- 把字节码转化为Class
如果你想定义一个自己的类加载器，并且要遵守双亲委派模型，那么可以继承ClassLoader，并且在findClass中实现你自己的加载逻辑即可。
JDBC 加载SPI接口实现类
JDBC中DrvierManager
如典型的JDBC服务，我们通常通过以下方式创建数据库连接：
Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mysql", "root", "1234");
在以上代码执行之前，DriverManager会先被类加载器加载，因为java.sql.DriverManager类是位于rt.jar下面的 ，所以他会被根加载器加载。
类加载时，会执行DriverManager类的静态方法。其中有一段关键的代码是：
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
这段代码，会尝试加载classpath下面的所有实现了Driver接口的实现类。
那么，问题就来了。
DriverManager是被根加载器加载的，那么在加载时遇到以上代码，会尝试加载所有Driver的实现类，但是这些实现类基本都是第三方提供的，根据双亲委派原则，第三方的类不能被根加载器加载。
那么，怎么解决这个问题呢？
于是，就在JDBC中通过引入Thread ContextClassLoader（线程上下文加载器，默认情况下是AppClassLoader）的方式破坏了双亲委派原则。
Thread ContextClassLoader 线程上下文类加载器
这个ClassLoader可以通过 java.lang.Thread类的setContextClassLoaser()方法进行设置；如果创建线程时没有设置，则它会从父线程中继承；如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认为AppClassLoader。
public class Thread implements Runnable {
// 这里省略了无关代码
private void init(ThreadGroup g, Runnable target, String name,
long stackSize, AccessControlContext acc,
boolean inheritThreadLocals) {
// 这里省略了无关代码
if (security == null || isCCLOverridden(parent.getClass()))
this.contextClassLoader = parent.getContextClassLoader();
else
this.contextClassLoader = parent.contextClassLoader; // 继承父线程的 上下文类加载器
// 这里省略了无关代码
}
public Thread(Runnable target) {
init(null, target, "Thread-" + nextThreadNum(), 0);
}
// 这里省略了无关代码
public void setContextClassLoader(ClassLoader cl) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new RuntimePermission("setContextClassLoader"));
}
contextClassLoader = cl;
}
}
有了Thread ContextClassLoader，就可以实现父ClassLoader让子ClassLoader去完成一个类的加载任务，即父ClassLoader加载的类中，可以使用ContextClassLoader去加载其无法加载的类）。
ServiceLoader load
DriverManager类在被加载的时候就会执行通过ServiceLoader#load方法来加载数据库驱动（即Driver接口的实现）。
简单考虑以上代码的类加载过程为：可以想一下，DriverManager类由BootstrapClassLoader加载，DriverManager类依赖于ServiceLoader类，因此BootstrapClassLoader也会尝试加载ServiceLoader类，这是没有问题的；
再往下，ServiceLoader的load方法中需要加载数据库（MySQL等）驱动包中Driver接口的实现类，即ServiceLoader类依赖这些驱动包中的类，此时如果是默认情况下，则还是由BootstrapClassLoader来加载这些类，但驱动包中的Driver接口的实现类是位于CLASSPATH下的，BootstrapClassLoader是无法加载的。
在ServiceLoader#load方法中实际是指明了由Thread ContextClassLoader来加载驱动包中的类：
public final class ServiceLoader<S> implements Iterable<S> {
// 省略无关代码
public static <S> ServiceLoader<S> load(Class<S> service) {
// 需要注意的是，这里使用的是 当前线程的 ContextClassLoader 来加载实现，这也是 ContextClassLoader 为什么存在的原因。
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
}
DriverManager获取当前线程的线程上下⽂类加载器 AppClassLoader，⽤于加载 classpath 中的具体实现类。
