Tomcat打破双亲委派机制实现隔离Web应用的方法

本文主要介绍了Tomcat打破双亲委派机制实现隔离Web应用的方法，文中通过示例代码介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下

tomcat通过自定义类加载器webappclassloader打破双亲委派，即重写了jvm的类加载器classloader的findclass方法和loadclass方法，以优先加载web应用目录下的类。

tomcat负责加载我们的servlet类、加载servlet所依赖的jar包。tomcat本身也是个java程序，因此它需要加载自己的类和依赖的jar包。

若在tomcat运行两个web应用程序，它们有功能不同的同名servlet，tomcat需同时加载和管理这两个同名的servlet类，保证它们不会冲突。所以web应用之间的类需要隔离

若两个web应用都依赖同一三方jar，比如spring，则spring jar被加载到内存后，tomcat要保证这两个web应用能共享之，即spring jar只被加载一次，否则随着三方jar增多，jvm的内存会占用过大。
所以，和 jvm 一样，需要隔离tomcat本身的类和web应用的类。

tomcat类加载器的层次结构

tomcat的类加载器层次结构

Tomcat打破双亲委派机制实现隔离Web应用的方法

前三个是加载器实例名，不是类名。

Tomcat打破双亲委派机制实现隔离Web应用的方法

webappclassloader

若使用jvm默认的appclassloader加载web应用，appclassloader只能加载一个servlet类，在加载第二个同名servlet类时，appclassloader会返回第一个servlet类的class实例。
因为在appclassloader眼里，同名servlet类只能被加载一次。

于是，tomcat自定义了一个类加载器webappclassloader，并为每个web应用创建一个webappclassloader实例。

每个web应用自己的java类和依赖的jar包，分别放在web-inf/classes和web-inf/lib目录下，都是webappclassloader加载的。

context容器组件对应一个web应用，因此，每个context容器创建和维护一个webappclassloader加载器实例。
不同加载器实例加载的类被认为是不同的类，即使类名相同。这就相当于在jvm内部创建相互隔离的java类空间，每个web应用都有自己的类空间，web应用之间通过各自的类加载器互相隔离。

sharedclassloader

两个web应用之间怎么共享库类，并且不能重复加载相同的类？

双亲委派机制的各子加载器都能通过父加载器去加载类，于是考虑把需共享的类放到父加载器的加载路径。

应用程序即是通过该方式共享jre核心类。
tomcat搞了个类加载器sharedclassloader，作为webappclassloader的父加载器，以加载web应用之间共享的类。

若webappclassloader未加载到某类，就委托父加载器sharedclassloader去加载该类，sharedclassloader会在指定目录下加载共享类，之后返回给webappclassloader，即可解决共享问题。

catalinaclassloader

如何隔离tomcat本身的类和web应用的类？

兄弟关系：两个类加载器是平行的，它们可能拥有同一父加载器，但两个兄弟类加载器加载的类是隔离的。

于是，tomcat搞了catalinaclassloader，专门加载tomcat自身的类。

问题是，当tomcat和各web应用之间需要共享一些类时该怎么办？

commonclassloader

共享依旧靠父子关系。
再增加个commonclassloader，作为catalinaclassloader和sharedclassloader的父加载器。

commonclassloader能加载的类都可被catalinaclassloader、sharedclassloader 使用，而catalinaclassloader和sharedclassloader能加载的类则与对方相互隔离。webappclassloader可以使用sharedclassloader加载到的类，但各个webappclassloader实例之间相互隔离。

spring的加载问题

jvm默认情况下，若一个类由类加载器a加载，则该类的依赖类也由相同的类加载器加载。
比如spring作为一个bean工厂，它需要创建业务类的实例，并且在创建业务类实例之前需要加载这些类。spring是通过调用class.forname来加载业务类的，我们来看一下forname的源码：

				?

									public static class<?> forname(string classname) {

									    class<?> caller = reflection.getcallerclass();

									    return forname0(classname, true, classloader.getclassloader(caller), caller);

									}

会使用调用者，即spring的加载器去加载业务类。

web应用之间共享的jar可交给sharedclassloader加载，以避免重复加载。spring作为共享的三方jar，本身由sharedclassloader加载，spring又要去加载业务类，按照前面那条规则，加载spring的类加载器也会用来加载业务类，但是业务类在web应用目录下，不在sharedclassloader的加载路径下，这该怎么办呢？

线程上下文加载器

于是有了线程上下文加载器，一种类加载器传递机制。因为该类加载器保存在线程私有数据里，只要是同一个线程，一旦设置了线程上下文加载器，在线程后续执行过程中就能把这个类加载器取出来用。因此tomcat为每个web应用创建一个webappclassloader类加载器，并在启动web应用的线程里设置线程上下文加载器，这样spring在启动时就将线程上下文加载器取出来，用来加载bean。spring取线程上下文加载的代码如下：

				?

									cl = thread.currentthread().getcontextclassloader();

在standardcontext的启动方法，会将当前线程的上下文加载器设置为webappclassloader。

Tomcat打破双亲委派机制实现隔离Web应用的方法

启动方法结束时，会恢复线程的上下文加载器：

				?

									thread.currentthread().setcontextclassloader(originalclassloader);

这是为什么呢？

线程上下文加载器其实是线程的一个私有数据，跟线程绑定，这个线程完成启动context组件后，会被回收到线程池，之后被用来做其他事情，为了不影响其他事情，需恢复之前的线程上下文加载器。
优先加载web应用的类，当加载完了再改回原来的。

线程上下文的加载器就是指定子类加载器来加载具体的某个桥接类，比如jdbc的driver的加载。

总结

tomcat的context组件为每个web应用创建一个webappclassloader类加载器，由于不同类加载器实例加载的类是互相隔离的，因此达到了隔离web应用的目的，同时通过commonclassloader等父加载器来共享第三方jar包。而共享的第三方jar包怎么加载特定web应用的类呢？可以通过设置线程上下文加载器来解决。

多个应用共享的java类文件和jar包，分别放在web容器指定的共享目录：

commonclassloader
对应 <tomcat>/common/*

catalinaclassloader
对应 <tomcat >/server/*

sharedclassloader
对应 <tomcat >/shared/*

webappclassloader
对应 <tomcat >/webapps/<app>/web-inf/*

可以在tomcat conf目录下的catalina.properties文件里配置各种类加载器的加载路径。

当出现classnotfound错误时，应该检查你的类加载器是否正确。
线程上下文加载器不仅仅可以用在tomcat和spring类加载的场景里，核心框架类需要加载具体实现类时都可以用到它，比如我们熟悉的jdbc就是通过上下文类加载器来加载不同的数据库驱动的。

到此这篇关于tomcat打破双亲委派机制实现隔离web应用的方法的文章就介绍到这了,更多相关tomcat 隔离web应用内容请搜索米米素材网以前的文章或继续浏览下面的相关文章希望大家以后多多支持米米素材网！

原文链接：https://blog.csdn.net/qq_33589510/article/details/119195107