JDBC、Tomcat为什么要破坏双亲委派模型？

问题一：双亲委派模型是什么

如果一个类加载器收到了加载某个类的请求，则该类加载器并不会去加载该类，而是把这个请求委派给父类加载器，每一个层次的类加载器都是如此，因此所有的类加载请求最终都会传送到顶端的启动类加载器；只有当父类加载器在其搜索范围内无法找到所需的类，并将该结果反馈给子类加载器，子类加载器会尝试去自己加载。

问题二：JDBC为什么要破坏双亲委派模型

因为类加载器受到加载范围的限制，在某些情况下父类加载器无法加载到需要的文件，这时候就需要委托子类加载器去加载class文件。

JDBC的Driver接口定义在JDK中，其实现由各个数据库的服务商来提供，比如MySQL驱动包。DriverManager 类中要加载各个实现了Driver接口的类，然后进行管理，但是DriverManager位于 $JAVA_HOME中jre/lib/rt.jar 包中，由BootStrap类加载器加载，而其Driver接口的实现类是位于服务商提供的 Jar 包中，根据类加载机制，当被装载的类引用了另外一个类的时候，虚拟机就会使用装载第一个类的类装载器装载被引用的类。也就是说BootStrap类加载器还要去加载jar包中的Driver接口的实现类。我们知道，BootStrap类加载器默认只负责加载 $JAVA_HOME中jre/lib/rt.jar 里所有的class，所以这个时候就需要由子类加载器去加载Driver实现，这就破坏了双亲委派模型。

这个子类加载器是通过 Thread.currentThread().getContextClassLoader() 得到的线程上下文加载器。

那么这个上下文类加载器又是什么呢？

public Launcher() {
    ...
    try {
        this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
    } catch (IOException var9) {
        throw new InternalError("Could not create application class loader", var9);
    }
    Thread.currentThread().setContextClassLoader(this.loader);
    ...
}

可以看到，在 sun.misc.Launcher 初始化的时候，会获取AppClassLoader，然后将其设置为上下文类加载器，所以线程上下文类加载器默认情况下就是系统加载器。

问题三：Tomcat为什么要破坏双亲委派模型

Tomcat如何破坏双亲委派模型的呢？

每个Tomcat的webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。

事实上，tomcat之所以造了一堆自己的classloader，大致是出于下面三类目的：

对于各个 webapp中的 class和 lib，需要相互隔离，不能出现一个应用中加载的类库会影响另一个应用的情况，而对于许多应用，需要有共享的lib以便不浪费资源。
与 jvm一样的安全性问题。使用单独的 classloader去装载 tomcat自身的类库，以免其他恶意或无意的破坏；
热部署。相信大家一定为 tomcat修改文件不用重启就自动重新装载类库而惊叹吧。

延伸阅读

https://blog.csdn.net/u012129558/article/details/81540804

https://blog.csdn.net/liweisnake/article/details/8470285