起源：www.jianshu.com/p /abf6fd4531e7
我想，在钻研 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 容器，那么它要解决什么问题：
- 一个 web 容器可能须要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因而要保障每个应用程序的类库都是独立的，保障互相隔离。
- 部署在同一个 web 容器中雷同的类库雷同的版本能够共享。否则，如果服务器有 10 个应用程序，那么要有 10 份雷同的类库加载进虚拟机，这是扯淡的。
- web 容器也有本人依赖的类库，不能于应用程序的类库混同。基于平安思考，应该让容器的类库和程序的类库隔离开来。
- 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 的类加载机制。这一次播种不小哦！！！嘿嘿。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！