Tomcat 类加载器之为何违背双亲委派机制

在之前的博客中已经介绍了类加载机制，今天来谈谈Tomcat为何打破了双亲委派机制。

先了解几个概念：

       java虚拟机把描述类的数据从Class文件加载进内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用的java类型，这就是虚拟机的类加载机制。

       把类加载阶段中的"通过一个类的全限定名来获取描述此类的二进制文件"这个动作放到java虚拟机外部去实现，以便让程序自己决定如何去获取所需要的的类。实现这个动作的代码块称为"类加载器"。

类与类加载器的关系

       类加载器虽然只用于实现类的加载动作，但它在java程序中起到的作用远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类命名空间。简而言之：比较两个类是否"相等"，只有这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来自同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

类加载器：

      从java虚拟机的角度来说，只有两种不同的类加载器：一种是启动类加载器(Bootstrap ClassLoader),这个类加载器使用C++语言实现(只限HotSpot)，是虚拟机自身的一部分；另一种就是所有的其它的类加载器，这些类加载器都由java语言实现，独立于虚拟机外部，并且全部都继承自抽象类java.lang.ClassLoader。

     但是从java开发人员的角度来看，类加载还可以做更细致的划分，可以参考博客：https://blog.csdn.net/duan196_118/article/details/104215262

双亲委派机制：

      简单的说就是先委托父类加载器寻找目标类，在找不到的情况下再在自己的路径中查找并载入目标类。

其优点是：

      沙箱安全机制：比如自己写的String.class类不会被加载，可以防止核心类库被随意篡改。

      避免类的重复加载：当父类ClassLoader已经加载了该类的时候，就不需要子ClassLoader再加载一次。

说了这么多，那Tomcat使用默认的类加载机制行不行？它的类加载机制是怎么设计的呢？为什么打破了双亲委派机制？

首先，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文件。

Tomcat的类加载机制是如何实现的？

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

先看看Tomcat整体的类加载图

 

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

    1. commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；

    2. CatalinaLoader：负责加载Tomcat专用的类，而这些被加载的类在Web应用中将不可见；

    3. SharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；

    4. WebAppLoader：负责加载具体的某个Web应用程序所使用到的类，而这些被加载的类在Tomcat和其他的Web应用程序都将不可见；

    5. JasperLoader：每个jsp页面一个类加载器，不同的jsp页面有不同的类加载器，方便实现jsp页面的热插拔；

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

CommonClassLoader能加载的类都可以被Catalina ClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而CatalinaClassLoader和Shared ClassLoader自己能加载的类则与对方相互隔离。

WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。

而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

        双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。而tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。

有关Tomcat和类加载机制的底层本人理解的并不到位，如有不足，欢迎留言指正。望不吝赐教。。。