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

本文链接：https://blog.csdn.net/2401_84617131/article/details/138232869

本文详细解释了Java的双亲委派机制，包括其工作原理、优点和缺点，以及在JDBC和Tomcat中的应用。同时介绍了如何通过自定义类加载器和线程上下文类加载器打破双亲委派机制的示例。

摘要由CSDN通过智能技术生成

文章目录

- 🌊前言

🌊前言

Code皮皮虾 一个沙雕而又有趣的憨憨少年，和大多数小伙伴们一样喜欢听歌、游戏，当然除此之外还有写作的兴趣，emm…，日子还很长，让我们一起加油努力叭🌈

👉话不多说，直达底部有粉丝专享福利！！！

什么是双亲委派机制？

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

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

启动类加载器(BootStrap ClassLoader)，主要负责加载jre/lib/rt.jar相关的字节码文件的。
扩展类加载器(Extension ClassLoader)，主要负载加载 jre/lib/ext/*.jar 这些jar包的。
应用程序类加载器(Application ClassLoader)，主要负责加载用户自定义的类以及classpath环境变量所配置的jar包的。
自定义类加载器(UserClassLoader)，负责加载程序员指定的特殊目录下的字节码文件的。大多数情况下，自定义类加载器只需要继承ClassLoader这个抽象类，重写findClass()和loadClass()两个方法即可。

双亲委派机制原理

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

优点

避免类的重复加载
保护程序安全，防止核心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加载，这和双亲委派刚好相反。

tomcat

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

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

如何打破双亲委派机制？

1.自定义类加载器

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

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

public class Main {

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

}