【Code皮皮虾】带你盘点双亲委派机制【原理、优缺点】，以及如何打破它？

什么是双亲委派机制？

说到双亲委派机制，那么我们需要先了解Java中的类加载器！

🌊Java中的类加载器主要分为以下四类:

1. 启动类加载器(BootStrap ClassLoader)， 主要负责加载jre/lib/rt.jar相关的字节码文件的。

2. 扩展类加载器(Extension ClassLoader)， 主要负载加载 jre/lib/ext/*.jar 这些jar包的。

3. 应用程序类加载器(Application ClassLoader)， 主要负责加载用户自定义的类以及classpath环境变量所配置的jar包的。

4. 自定义类加载器(UserClassLoader)， 负责加载程序员指定的特殊目录下的字节码文件的。大多数情况下，自定义类加载器只需要继承ClassLoader这个抽象类，重写findClass()和loadClass()两个方法即可。

双亲委派机制原理

1. 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行。
2. 如果父类的加载器还存在其父类加载器，则进一步向上委托，依次递归请求最终达到顶层的启动类加载器。
3. 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派机制。

优点

1. 避免类的重复加载
2. 保护程序安全，防止核心API被随意篡改

缺点

• 在某些场景下双亲委派制过于局限，所以有时候必须打破双亲委派机制来达到目的。例如：SPI机制

打破双亲委派机制？

打破双亲委派机制？

小伙伴：我看这双亲委派机制挺好的啊，为什么要打破呢。

皮皮虾：哈哈，那就直接上实例讲解叭。😉

前提知识：线程上下文类加载器

线程上下文类加载器（context class loader）是从 JDK 1.2 开始引入的。Java.lang.Thread中的方法 getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。如果没有通过 setContextClassLoader(ClassLoader cl)方法进行设置的话，线程将继承其父线程的上下文类加载器。

Java 应用运行的初始线程的上下文类加载器是应用类加载器，在线程中运行的代码可以通过此类加载器来加载类和资源。

线程上下文类加载器从根本解决了一般应用不能违背 双亲委派模式 的问题，使得java类加载体系显得更灵活。上面所提到的问题正是线程上下文类加载器的拿手好菜。如果不做任何的设置，Java应用的线程上下文类加载器默认就是系统类加载器。因此，在 SPI 接口的代码中使用线程上下文类加载器，就可以成功的加载到 SPI 实现的类。

双亲委派出现之前

由于双亲委派模型是在JDK1.2之后才被引入的，而在这之前已经有用户自定义类加载器在用了。所以，这些是没有遵守双亲委派原则的。

自定义类加载器加载一个类需要：继承ClassLoader，重写findClass，如果不想打破双亲委派模型，那么只需要重写findClass；如果想打破双亲委派模型，那么就重写整个loadClass方法，设定自己的类加载逻辑

JDBC打破双亲委派机制

使用SPI机制创建数据库链接

前提是，只要mysql的jar包在类路径中。

Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mysql", "root", "0000");

代码执行之前，DriverManager会先被类加载器加载，因为java.sql.DriverManager类是位于rt.jar下面的 ，所以他会被启动类加载器加载。

类加载时，会执行该类的静态方法。其中有一段关键的代码是：

ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);

这段代码，会尝试加载classpath下面的所有实现了Driver接口的实现类。

那么，问题就来了。

DriverManager是被启动类加载器加载的，那么在加载时遇到以上代码，会尝试加载所有Driver的实现类，但是这些实现类基本都是第三方提供的，第三方的类不能被启动类加载器加载。

那么，怎么解决这个问题呢？

于是，就在JDBC中通过引入ThreadContextClassLoader（线程上下文加载器，默认情况下是AppClassLoader）的方式来使用应用程序类加载器 破坏了双亲委派原则。

我们深入到ServiceLoader.load方法就可以看到：

public static <S> ServiceLoader<S> load(Class<S> service) {
    //获取线程上下文类加载器
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

Tomcat

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

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

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

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

Tomcat的类加载机制：为了实现隔离性，优先加载 Web 应用自己定义的类，所以没有遵照双亲委派的约定，每一个应用自己的类加载器——WebAppClassLoader负责加载本身的目录下的class文件，加载不到时再交给CommonClassLoader加载，这和双亲委派刚好相反。

前面3个类加载和默认的一致，CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader则是Tomcat自己定义的类加载器，它们分别加载/common/、/server/、/shared/*（在tomcat 6之后已经合并到根目录下的lib目录下）和/WebApp/WEB-INF/*中的Java类库。

其中WebApp类加载器和Jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个JSP文件对应一个Jsp类加载器。

如何打破双亲委派机制？

1.自定义类加载器

自定义类加载器加载一个类需要：继承ClassLoader，重写findClass，如果不想打破双亲委派模型，那么只需要重写findClass；如果想打破双亲委派模型，那么就重写整个loadClass方法，设定自己的类加载逻辑

想要打破即重写的时候让自己去加载不让父加载器去加载

2. 使用线程上下文类加载器

public class Main {

    public static void main(String[] args) {
        ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
    }

}