Tomcat（2）Tomcat类加载机制

待我称王封你为后i 2021-12-11 05:21 301阅读 0赞

# 目录 #

> 1.  类加载
> 2.  类加载器
> 3.  双亲委派模型
> 4.  双亲委派模式优势
> 5.  Tomcat类加载机制
> 6.  Tomcat启动时类加载过程
> 7.  打破双亲委托机制的桎梏
> 8.  问题扩展
> 9.  阿里面试

--------------------

## 类加载 ##

在JVM中并不是一次性把所有的文件都加载，按时按需加载，比如JVM启动时，会通过不同的类加载器加载不同的类。当用户在自己的代码中，需要某些额外的类时，再通过加载机制加载到JVM中，并且存放一段时间，便于频繁使用。

## 类加载器 ##

什么是类加载器？

类加载器是一个用来加载类文件的类,java源代码通过javac编译器编译成类文件，然后JVM来执行类文件中的字节码来执行程序，类加载器负责加载文件系统、网络或其他 来源的类文件。有三种默认的类加载器：

BootStrap类加载器 – 加载/jre/lib/rt.jar  
Extension类加载器 –  /jre/lib/ext/下的jar包  
Application类加载器 – 加载用户类路径CLASSPATH下的类  
![70][]

# #

## 双亲委派模型 ##

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

![20170226110715016][]

# #

## 双亲委派模式优势 ##

1.  采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。
2.  其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。
3.  可能你会想，如果我们在classpath路径下自定义一个名为java.lang.SingleInterge类(该类是胡编的)呢？该类并不存在java.lang中，经过双亲委托模式，传递到启动类加载器中，由于父类加载器路径下并没有该类，所以不会加载，将反向委托给子类加载器加载，最终会通过系统类加载器加载该类。但是这样做是不允许，因为java.lang是核心API包，需要访问权限，强制加载将会报出如下异常

##    Tomcat类加载机制 ##

既然Tomcat的类加载机器不同于双亲委派模式，那么它又是一种怎样的模式呢？

另外，我们还是先来看看Tomcat整体的类加载图是怎样的吧~

![20170226110723953][]

我们在这张图中看到很多类加载器，除了Jdk自带的类加载器，我们尤其关心Tomcat自身持有的类加载器。仔细一点我们很容易发现：Catalina类加载器和Shared类加载器，他们并不是父子关系，而是兄弟关系。为啥这样设计，我们得分析一下每个类加载器的用途，才能知晓。

1.  Common类加载器，负责加载Tomcat和Web应用都复用的类
2.  Catalina类加载器，负责加载Tomcat专用的类，而这些被加载的类在Web应用中将不可见
3.  Shared类加载器，负责加载Tomcat下所有的Web应用程序都复用的类，而这些被加载的类在Tomcat中将不可见
4.  WebApp类加载器，负责加载具体的某个Web应用程序所使用到的类，而这些被加载的类在Tomcat和其他的Web应用程序都将不可见
5.  Jsp类加载器，每个jsp页面一个类加载器，不同的jsp页面有不同的类加载器，方便实现jsp页面的热插拔

## Tomcat启动时类加载过程 ##

在tomcat中类的加载稍有不同，如下图：

![141304597074685.jpg][]

当tomcat启动时，会创建几种类加载器：

**1 Bootstrap 引导类加载器**

加载JVM启动所需的类，以及标准扩展类（位于jre/lib/ext下）

**2 System 系统类加载器**

加载tomcat启动的类，比如bootstrap.jar，通常在catalina.bat或者catalina.sh中指定。位于CATALINA\_HOME/bin下。

![141311392073902.jpg][]

**3 Common 通用类加载器**

加载tomcat使用以及应用通用的一些类，位于CATALINA\_HOME/lib下，比如servlet-api.jar

![141312007698713.jpg][]

**　　4 webapp 应用类加载器**

每个应用在部署后，都会创建一个唯一的类加载器。该类加载器会加载位于 WEB-INF/lib下的jar文件中的class 和 WEB-INF/classes下的class文件。

**当应用需要到某个类时，则会按照下面的顺序进行类加载**：

1 使用bootstrap引导类加载器加载

2 使用system系统类加载器加载

3 使用应用类加载器在WEB-INF/classes中加载

4 使用应用类加载器在WEB-INF/lib中加载

5 使用common类加载器在CATALINA\_HOME/lib中加载

## 打破双亲委托机制的桎梏：线程上下文类加载器 ##

线程上下文类加载器是指的当前线程所用的类加载器，可以通过Thread.currentThread().getContextClassLoader()获得或者设置。

在spring中，他会选择线程上下文类加载器去加载web应用底下的类，如此就打破了双亲委托机制了。

## 问题扩展 ##

通过对上面tomcat类加载机制的理解，就不难明白 为什么java文件放在Eclipse中的src文件夹下会优先jar包中的class?

这是因为Eclipse中的src文件夹中的文件java以及webContent中的JSP都会在tomcat启动时，被编译成class文件放在 WEB-INF/class中。

而Eclipse外部引用的jar包，则相当于放在 WEB-INF/lib 中。

因此肯定是 **java文件或者JSP文件编译出的class优先加载**。

通过这样，我们就可以简单的把java文件放置在src文件夹中，通过对该java文件的修改以及调试，便于学习拥有源码java文件、却没有打包成xxx-source的jar包。

另外呢，开发者也会因为粗心而犯下面的错误。

在 CATALINA\_HOME/lib 以及 WEB-INF/lib 中放置了 不同版本的jar包，此时就会导致某些情况下报加载不到类的错误。

还有如果多个应用使用同一jar包文件，当放置了多份，就可能导致 多个应用间 出现类加载不到的错误。

## 阿里面试题 ##

**Tomcat的类加载机制是违反了双亲委托原则的，对于一些未加载的非基础类(Object,String等)，各个web应用自己的类加载器(WebAppClassLoader)会优先加载，加载不到时再交给commonClassLoader走双亲委托。 **

**对于JVM来说：**

**因此，按照这个过程可以想到，如果同样在CLASSPATH指定的目录中和自己工作目录中存放相同的class，会优先加载CLASSPATH目录中的文件。**

![141327112691951.jpg][]

# #

1、既然 Tomcat 不遵循双亲委派机制，那么如果我自己定义一个恶意的HashMap，会不会有风险呢？(**阿里的面试官问**)

答： 显然不会有风险，如果有，Tomcat都运行这么多年了，那群Tomcat大神能不改进吗？ tomcat不遵循双亲委派机制，只是自定义的classLoader顺序不同，但顶层还是相同的，

还是要去顶层请求classloader.

2、我们思考一下：Tomcat是个web容器， 那么它要解决什么问题：   
1. 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。   
2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机，这是扯淡的。   
3. web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。   
4. web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情，否则要你何用？ 所以，web容器需要支持 jsp 修改后不用重启。

再看看我们的问题：Tomcat 如果使用默认的类加载机制行不行？   
答案是不行的。为什么？我们看，第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的累加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。第三个问题和第一个问题一样。我们再看第四个问题，我们想我们要怎么实现jsp文件的热修改（楼主起的名字），jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。

Tomcat 如何实现自己独特的类加载机制？

所以，Tomcat 是怎么实现的呢？牛逼的Tomcat团队已经设计好了。我们看看他们的设计图：

![137084-20180526104342525-959933190.png][]

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

*  commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；
 *  catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；
 *  sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；
 *  WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见；

从图中的委派关系中可以看出：

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

好了，至此，我们已经知道了tomcat为什么要这么设计，以及是如何设计的，那么，tomcat 违背了java 推荐的双亲委派模型了吗？答案是：违背了。 我们前面说过：

> 双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。

很显然，tomcat 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。

我们扩展出一个问题：如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类，该怎么办？

看了前面的关于破坏双亲委派模型的内容，我们心里有数了，我们可以使用线程上下文类加载器实现，使用线程上下文加载器，可以让父类加载器请求子类加载器去完成类加载的动作。牛逼吧。

作者：Roger\_CoderLife

链接：https://blog.csdn.net/Roger\_CoderLife/article/details/95336813

本文为Roger\_CoderLife的原创文章，著作权归作者所有，转载请注明原文出处，欢迎转载！

[70]: /images/20211211/86e884f0bcc04bb78521f0178a97c98a.png
[20170226110715016]: /images/20211211/a37e41e56715495086aedb7f4bc8d342.png
[20170226110723953]: /images/20211211/940ac7c00f5a4f2c9d1d97beb2b19989.png
[141304597074685.jpg]: /images/20211211/a1ff983b90e046878866712f8badfdd0.png
[141311392073902.jpg]: /images/20211211/6835286236f7459983517b61f984aedf.png
[141312007698713.jpg]: /images/20211211/e3f9905fa57b49b4ab3915e2d84fac1d.png
[141327112691951.jpg]: /images/20211211/c3ba1bce1dd24a77a5c8811f810524da.png
[137084-20180526104342525-959933190.png]: /images/20211211/60acb6f0b66544b598b73a82d7194b85.png