深刻理解 Tomcat（四）Tomcat 类加载器之为什么违背双亲委派模型

这是咱们研究Tomcat的第四篇文章，前三篇文章咱们搭建了源码框架，了解了tomcat的大体的设计架构， 还写了一个简单的服务器。按照咱们最初订的计划，今天，咱们要开始研究tomcat的几个主要组件（组件太多，没法一一解析，解析几个核心），包括核心的类加载器，链接器和容器，还有生命周期，还有pipeline 和 valve。一个一个来，今天来研究类加载器。

咱们分为4个部分来探讨:

1. 什么是类加载机制？
   2. 什么是双亲委任模型？
   3. 如何破坏双亲委任模型？
   4. Tomcat 的类加载器是怎么设计的？
复制代码

我想，在研究tomcat 类加载以前，咱们复习一下或者说巩固一下java 默认的类加载器。楼主之前对类加载也是懵懵懂懂，借此机会，也好好复习一下。

楼主翻开了神书《深刻理解Java虚拟机》第二版，p227, 关于类加载器的部分。请看：

1. 什么是类加载机制？

代码编译的结果从本地机器码转变成字节码，是存储格式的一小步，倒是编程语言发展的一大步。

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

虚拟机设计团队把类加载阶段中的“经过一个类的全限定名来获取描述此类的二进制字节流”这个动做放到Java虚拟机外部去实现，以便让应用程序本身决定如何去获取所须要的类。实现这动做的代码模块成为“类加载器”。

类与类加载器的关系

类加载器虽然只用于实现类的加载动做，但它在Java程序中起到的做用却远远不限于类加载阶段。对于任意一个类，都须要由加载他的类加载器和这个类自己一同确立其在Java虚拟机中的惟一性，每个类加载器，都拥有一个独立的类命名空间。这句话能够表达的更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，不然，即便这两个类来自同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不一样，那这个两个类就一定不相等。

2. 什么是双亲委任模型

1. 从Java虚拟机的角度来讲，只存在两种不一样类加载器：一种是启动类加载器(Bootstrap ClassLoader)，这个类加载器使用C++语言实现（只限HotSpot），是虚拟机自身的一部分；另外一种就是全部其余的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，而且全都继承自抽象类java.lang.ClassLoader.

2. 从Java开发人员的角度来看，类加载还能够划分的更细致一些，绝大部分Java程序员都会使用如下3种系统提供的类加载器：

   • 启动类加载器（Bootstrap ClassLoader）：这个类加载器复杂将存放在 JAVA_HOME/lib 目录中的，或者被-Xbootclasspath 参数所指定的路径种的，而且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即便放在lib目录下也不会重载）。
   • 扩展类加载器（Extension ClassLoader）：这个类加载器由sun.misc.Launcher$ExtClassLoader实现，它负责夹杂JAVA_HOME/lib/ext 目录下的，或者被java.ext.dirs 系统变量所指定的路径种的全部类库。开发者能够直接使用扩展类加载器。
   • 应用程序类加载器（Application ClassLoader）：这个类加载器由sun.misc.Launcher$AppClassLoader 实现。因为这个类加载器是ClassLoader 种的getSystemClassLoader方法的返回值，因此也成为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库。开发者能够直接使用这个类加载器，若是应用中没有定义过本身的类加载器，通常状况下这个就是程序中默认的类加载器。

这些类加载器之间的关系通常以下图所示：

图中各个类加载器之间的关系成为 类加载器的双亲委派模型（Parents Dlegation Mode）。双亲委派模型要求除了顶层的启动类加载器以外，其他的类加载器都应当由本身的父类加载器加载，这里类加载器之间的父子关系通常不会以继承的关系来实现，而是都使用组合关系来复用父加载器的代码。

类加载器的双亲委派模型在JDK1.2 期间被引入并被普遍应用于以后的全部Java程序中，但他并非个强制性的约束模型，而是Java设计者推荐给开发者的一种类加载器实现方式。

双亲委派模型的工做过程是：若是一个类加载器收到了类加载的请求，他首先不会本身去尝试加载这个类，而是把这个请求委派父类加载器去完成。每个层次的类加载器都是如此，所以全部的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈本身没法完成这个请求（他的搜索范围中没有找到所需的类）时，子加载器才会尝试本身去加载。

为何要这么作呢？

若是没有使用双亲委派模型，由各个类加载器自行加载的话，若是用户本身编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统将会出现多个不一样的Object类， Java类型体系中最基础的行为就没法保证。应用程序也将会变得一片混乱。

双亲委任模型时如何实现的？

很是简单：全部的代码都在java.lang.ClassLoader中的loadClass方法之中，代码以下：

逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass方法， 如父加载器为空则默认使用启动类加载器做为父加载器。若是父类加载失败，抛出ClassNotFoundException 异常后，再调用本身的findClass方法进行加载。

3. 如何破坏双亲委任模型？

刚刚咱们说过，双亲委任模型不是一个强制性的约束模型，而是一个建议型的类加载器实现方式。在Java的世界中大部分的类加载器都遵循者模型，但也有例外，到目前为止，双亲委派模型有过3次大规模的“被破坏”的状况。 第一次：在双亲委派模型出现以前-----即JDK1.2发布以前。 第二次：是这个模型自身的缺陷致使的。咱们说，双亲委派模型很好的解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载），基础类之因此称为“基础”，是由于它们老是做为被用户代码调用的API， 但没有绝对，若是基础类调用会用户的代码怎么办呢？

这不是没有可能的。一个典型的例子就是JNDI服务，JNDI如今已是Java的标准服务，它的代码由启动类加载器去加载（在JDK1.3时就放进去的rt.jar）,但它须要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者（SPI， Service Provider Interface）的代码，但启动类加载器不可能“认识“这些代码啊。由于这些类不在rt.jar中，可是启动类加载器又须要加载。怎么办呢？

为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器能够经过java.lang.Thread类的setContextClassLoader方法进行设置。若是建立线程时还未设置，它将会从父线程中继承一个，若是在应用程序的全局范围内都没有设置过多的话，那这个类加载器默认即便应用程序类加载器。

嘿嘿，有了线程上下文加载器，JNDI服务使用这个线程上下文加载器去加载所须要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动做，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的通常性原则。但这迫不得已，Java中全部涉及SPI的加载动做基本胜都采用这种方式。例如JNDI，JDBC，JCE，JAXB，JBI等。

第三次：为了实现热插拔，热部署，模块化，意思是添加一个功能或减去一个功能不用重启，只须要把这模块连同类加载器一块儿换掉就实现了代码的热替换。

书中还说到：

Java 程序中基本有一个共识：OSGI对类加载器的使用时值得学习的，弄懂了OSGI的实现，就能够算是掌握了类加载器的精髓。

牛逼啊！！！

如今，咱们已经基本明白了Java默认的类加载的做用了原理，也知道双亲委派模型。说了这么多，差点把咱们的tomcat给忘了，咱们的题目是Tomcat 加载器为什么违背双亲委派模型？下面就好好说说咱们的tomcat的类加载器。

4. Tomcat 的类加载器是怎么设计的？

首先，咱们来问个问题：

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类加载器。从新建立类加载器，从新加载jsp文件。

Tomcat 如何实现本身独特的类加载机制？

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

咱们看到，前面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 中的类，该怎么办？

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

总结

好了，终于，咱们明白了Tomcat 为什么违背双亲委派模型，也知道了tomcat的类加载器是如何设计的。顺便复习了一下 Java 默认的类加载器机制，也知道了如何破坏Java的类加载机制。这一次收获不小哦！！！ 嘿嘿。

好了，今天到此为止。下篇 深刻理解 Tomcat（五）Tomcat 两大核心组件----链接器和容器！！！

good luck！！！