（每日一题）Tomcat类加载器为什么要破坏双亲委派机制？_tomcat 类加载器之为何违背双亲委派模型-CSDN博客

本文链接：https://blog.csdn.net/seanxwq/article/details/118146715

首先解决上面的问题，必须搞懂两点，什么是双亲委派机制？Tomcat使用Java双亲委派机制有什么问题？

什么是双亲委派机制？

很多人可能觉得Java的双亲委派机制这个是非常基础的问题，这有什么好解释的。可是，从强哥面试过的许多候选人来看，经常这种最基础的问题，往往能够将许多候选人卡住。所以，还是在这里不厌其烦的和大家简单的说下。

一句话解释

如果一个类加载器需要加载类，那么首先它会把这个类请求委派给父类加载器去完成，每一层都是如此；一直递归到顶层，当父加载器无法完成这个请求时，子类才会尝试去加载。

举例

当一个Hello.class这样的文件要被加载时。不考虑我们自定义类加载器，首先会在AppClassLoader中检查是否加载过，如果有那就无需再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。父类中同理也会先检查自己是否已经加载过，如果没有再往上。注意这个类似递归的过程，直到到达Bootstrap classLoader之前，都是在检查是否加载过，并不会选择自己去加载。直到BootstrapClassLoader，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己无法加载，会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException。

Tomcat使用Java双亲委派机制有什么问题？

首先要回答这个问题我们又要先回答：Tomcat作为一个web容器，要解决的问题有哪些？

一个web容器可能要部署两个或者多个应用程序，不同的应用程序，可能会依赖同一个第三方类库的不同版本，因此要保证每一个应用程序的类库都是独立、相互隔离的；
部署在同一个web容器中的相同类库的相同版本可以共享，否则，会有重复的类库被加载进JVM；
web容器也有自己的类库，不能和应用程序的类库混淆，需要相互隔离；
web容器支持jsp文件修改后不用重启，jsp文件也是要编译成.class文件的，支持HotSwap功能。

基于上面4点，如果Tomcat使用Java的双亲委派机制会有什么问题呢？

第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的累加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。

第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。

第三个问题和第一个问题一样。

第四个问题，我们想我们要怎么实现jsp文件的热修改，jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。

既然弄清楚了Tomcat作为一个Web容器直接使用Java双亲委派机制的问题，那Tomcat又是怎么破坏双亲委派机制来解决上面的问题的呢？

Tomcat基于Java的类加载机制做了扩展:

我们看到，前面3个类加载和默认的一致，CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader则是Tomcat自己定义的类加载器，它们分别加载/common/*、/server/*、/shared/*（在tomcat 6之后已经合并到根目录下的lib目录下）和/WebApp/WEB-INF/*中的Java类库。其中WebApp类加载器和Jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个JSP文件对应一个Jsp类加载器。

CommonClassLoader：tomcat最基本的类加载器，加载路径中的class可以被tomcat和各个webapp访问；
CatalinaClassLoader：tomcat私有的类加载器，webapp不能访问其加载路径下的class，即对webapp不可见；
SharedClassLoader：各个webapp共享的类加载器，对tomcat不可见；
WebappClassLoader：webapp私有的类加载器，只对当前webapp可见。

经过上面新增的类加载器扩展之后，Tomcat类怎么解决上面提到的问题呢：

CommonClassLoader能加载的类都可以被Catalina ClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而CatalinaClassLoader和Shared ClassLoader自己能加载的类则与对方相互隔离。
WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。
而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

由此可见，Tomcat为了实现隔离性，破坏了双亲委派原则，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。而假如想要tomcat 的 Common ClassLoader 加载 WebApp ClassLoader 中的类的话，我们可以使用线程上下文类加载器实现，使用线程上下文加载器，可以让父类加载器请求子类加载器去完成类加载的动作，确实是精髓。

参考：https://www.cnblogs.com/aspirant/p/8991830.html

关注公众号获取更多内容，有问题也可在公众号提问哦：