追新求快的时代 别让 Java Web 开发必备工具 Tomcat 变成“熟悉的陌生人”！
Class ? clazz = null;
//1. 先在本地 cache 查找该类是否已经加载过clazz = findLoadedClass0(name);if(clazz != null) {if(resolve)resolveClass(clazz);returnclazz;}
//2. 从系统类加载器的 cache 中查找是否加载过clazz = findLoadedClass(name);if(clazz != null) {if(resolve)resolveClass(clazz);returnclazz;}
// 3. 尝试用 ExtClassLoader 类加载器类加载，为什么？ClassLoader javaseLoader = getJavaseClassLoader;try{clazz = javaseLoader.loadClass(name);if(clazz != null) {if(resolve)resolveClass(clazz);returnclazz;}} catch(ClassNotFoundException e) {// Ignore}
// 4. 尝试在本地目录搜索 class 并加载try{clazz = findClass(name);if(clazz != null) {if(resolve)resolveClass(clazz);returnclazz;}} catch(ClassNotFoundException e) {// Ignore}
// 5. 尝试用系统类加载器 (也就是 AppClassLoader) 来加载try{clazz = Class.forName(name, false, parent);if(clazz != null) {if(resolve)resolveClass(clazz);returnclazz;}} catch(ClassNotFoundException e) {// Ignore}}
//6. 上述过程都加载失败，抛出异常thrownew ClassNotFoundException(name);}
主要有六个步骤：
先在本地 Cache 查找该类是否已经加载过，也就是说 Tomcat 的类加载器是否已经加载过这个类。
如果 Tomcat 类加载器没有加载过这个类，再看看系统类加载器是否加载过。
如果都没有，就让ExtClassLoader去加载，这一步比较关键，目的 防止 Web 应用自己的类覆盖 JRE 的核心类。因为 Tomcat 需要打破双亲委托机制，假如 Web 应用里自定义了一个叫 Object 的类，如果先加载这个 Object 类，就会覆盖 JRE 里面的那个 Object 类，这就是为什么 Tomcat 的类加载器会优先尝试用 ExtClassLoader去加载，因为 ExtClassLoader会委托给 BootstrapClassLoader去加载，BootstrapClassLoader发现自己已经加载了 Object 类，直接返回给 Tomcat 的类加载器，这样 Tomcat 的类加载器就不会去加载 Web 应用下的 Object 类了，也就避免了覆盖 JRE 核心类的问题。
如果 ExtClassLoader加载器加载失败，也就是说 JRE核心类中没有这类，那么就在本地 Web 应用目录下查找并加载。
如果本地目录下没有这个类，说明不是 Web 应用自己定义的类，那么由系统类加载器去加载。这里请你注意，Web 应用是通过Class.forName调用交给系统类加载器的，因为Class.forName的默认加载器就是系统类加载器。
如果上述加载过程全部失败，抛出 ClassNotFound异常。
先在本地 Cache 查找该类是否已经加载过，也就是说 Tomcat 的类加载器是否已经加载过这个类。
如果 Tomcat 类加载器没有加载过这个类，再看看系统类加载器是否加载过。
如果都没有，就让ExtClassLoader去加载，这一步比较关键，目的 防止 Web 应用自己的类覆盖 JRE 的核心类。因为 Tomcat 需要打破双亲委托机制，假如 Web 应用里自定义了一个叫 Object 的类，如果先加载这个 Object 类，就会覆盖 JRE 里面的那个 Object 类，这就是为什么 Tomcat 的类加载器会优先尝试用 ExtClassLoader去加载，因为 ExtClassLoader会委托给 BootstrapClassLoader去加载，BootstrapClassLoader发现自己已经加载了 Object 类，直接返回给 Tomcat 的类加载器，这样 Tomcat 的类加载器就不会去加载 Web 应用下的 Object 类了，也就避免了覆盖 JRE 核心类的问题。
如果 ExtClassLoader加载器加载失败，也就是说 JRE核心类中没有这类，那么就在本地 Web 应用目录下查找并加载。
如果本地目录下没有这个类，说明不是 Web 应用自己定义的类，那么由系统类加载器去加载。这里请你注意，Web 应用是通过Class.forName调用交给系统类加载器的，因为Class.forName的默认加载器就是系统类加载器。
如果上述加载过程全部失败，抛出 ClassNotFound异常。
Tomcat 类加载器层次
Tomcat 作为 Servlet容器，它负责加载我们的 Servlet类，此外它还负责加载 Servlet所依赖的 JAR 包。并且 Tomcat本身也是也是一个 Java 程序，因此它需要加载自己的类和依赖的 JAR 包。首先让我们思考这一下这几个问题：
假如我们在 Tomcat 中运行了两个 Web 应用程序，两个 Web 应用中有同名的 Servlet，但是功能不同，Tomcat 需要同时加载和管理这两个同名的 Servlet类，保证它们不会冲突，因此 Web 应用之间的类需要隔离。
假如两个 Web 应用都依赖同一个第三方的 JAR 包，比如 Spring，那 Spring的 JAR 包被加载到内存后，Tomcat要保证这两个 Web 应用能够共享，也就是说 Spring的 JAR 包只被加载一次，否则随着依赖的第三方 JAR 包增多，JVM的内存会膨胀。
跟 JVM 一样，我们需要隔离 Tomcat 本身的类和 Web 应用的类。
假如我们在 Tomcat 中运行了两个 Web 应用程序，两个 Web 应用中有同名的 Servlet，但是功能不同，Tomcat 需要同时加载和管理这两个同名的 Servlet类，保证它们不会冲突，因此 Web 应用之间的类需要隔离。
假如两个 Web 应用都依赖同一个第三方的 JAR 包，比如 Spring，那 Spring的 JAR 包被加载到内存后，Tomcat要保证这两个 Web 应用能够共享，也就是说 Spring的 JAR 包只被加载一次，否则随着依赖的第三方 JAR 包增多，JVM的内存会膨胀。
跟 JVM 一样，我们需要隔离 Tomcat 本身的类和 Web 应用的类。
1. WebAppClassLoader
Tomcat 的解决方案是自定义一个类加载器 WebAppClassLoader， 并且给每个 Web 应用创建一个类加载器实例。我们知道，Context 容器组件对应一个 Web 应用，因此，每个 Context容器负责创建和维护一个 WebAppClassLoader加载器实例。这背后的原理是，不同的加载器实例加载的类被认为是不同的类，即使它们的类名相同。这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间，每一个 Web 应用都有自己的类空间，Web 应用之间通过各自的类加载器互相隔离。
2.SharedClassLoader
本质需求是两个 Web 应用之间怎么共享库类,并且不能重复加载相同的类。在双亲委托机制里，各个子加载器都可以通过父加载器去加载类，那么把需要共享的类放到父加载器的加载路径下不就行了吗。
因此 Tomcat 的设计者又加了一个类加载器 SharedClassLoader，作为 WebAppClassLoader的父加载器，专门来加载 Web 应用之间共享的类。如果 WebAppClassLoader自己没有加载到某个类，就会委托父加载器 SharedClassLoader去加载这个类，SharedClassLoader会在指定目录下加载共享类，之后返回给 WebAppClassLoader，这样共享的问题就解决了。
3. CatalinaClassloader
如何隔离 Tomcat 本身的类和 Web 应用的类？
要共享可以通过父子关系，要隔离那就需要兄弟关系了。兄弟关系就是指两个类加载器是平行的，它们可能拥有同一个父加载器，基于此 Tomcat 又设计一个类加载器 CatalinaClassloader，专门来加载 Tomcat 自身的类。
这样设计有个问题，那 Tomcat 和各 Web 应用之间需要共享一些类时该怎么办呢？
老办法，还是再增加一个 CommonClassLoader，作为 CatalinaClassloader和 SharedClassLoader的父加载器。CommonClassLoader能加载的类都可以被 CatalinaClassLoader和 SharedClassLoader使用。
整体架构设计解析收获总结
通过前面对 Tomcat 整体架构的学习，知道了 Tomcat 有哪些核心组件，组件之间的关系。以及 Tomcat 是怎么处理一个 HTTP 请求的。下面我们通过一张简化的类图来回顾一下，从图上你可以看到各种组件的层次关系，图中的虚线表示一个请求在 Tomcat 中流转的过程。
Tomcat 整体组件关系
连接器
Tomcat 的整体架构包含了两个核心组件连接器和容器。连接器负责对外交流，容器负责内部处理。连接器用 ProtocolHandler接口来封装通信协议和 I/O模型的差异，ProtocolHandler内部又分为 EndPoint和 Processor模块，EndPoint负责底层 Socket通信，Proccesor负责应用层协议解析。连接器通过适配器 Adapter调用容器。
对 Tomcat 整体架构的学习，我们可以得到一些设计复杂系统的基本思路。首先要分析需求，根据高内聚低耦合的原则确定子模块，然后找出子模块中的变化点和不变点，用接口和抽象基类去封装不变点，在抽象基类中定义模板方法，让子类自行实现抽象方法，也就是具体子类去实现变化点。
容器
运用了组合模式 管理容器、通过 观察者模式 发布启动事件达到解耦、开闭原则。骨架抽象类和模板方法抽象变与不变，变化的交给子类实现，从而实现代码复用，以及灵活的拓展。使用责任链的方式处理请求，比如记录日志等。
类加载器
Tomcat 的自定义类加载器 WebAppClassLoader为了隔离 Web 应用打破了双亲委托机制，它首先自己尝试去加载某个类，如果找不到再代理给父类加载器，其目的是优先加载 Web 应用自己定义的类。防止 Web 应用自己的类覆盖 JRE 的核心类，使用 ExtClassLoader 去加载，这样即打破了双亲委派，又能安全加载。
如何阅读源码持续学习
学习是一个反人类的过程，是比较痛苦的。尤其学习我们常用的优秀技术框架本身比较庞大，设计比较复杂，在学习初期很容易遇到 “挫折感”，debug 跳来跳去陷入恐怖细节之中无法自拔，往往就会放弃。
找到适合自己的学习方法非常重要，同样关键的是要保持学习的兴趣和动力，并且得到学习反馈效果。
学习优秀源码，我们收获的就是架构设计能力，遇到复杂需求我们学习到可以利用合理模式与组件抽象设计了可拓展性强的代码能力。
如何阅读
比如我最初在学习 Spring 框架的时候，一开始就钻进某个模块啃起来。然而由于 Spring 太庞大，模块之间也有联系，根本不明白为啥要这么写，只觉得为啥设计这么 “绕”。
错误方式
陷入细节，不看全局：我还没弄清楚森林长啥样，就盯着叶子看 ，看不到全貌和整体设计思路。所以阅读源码学习的时候不要一开始就进入细节，而是宏观看待整体架构设计思想，模块之间的关系。
还没学会用就研究如何设计：首先基本上框架都运用了设计模式，我们最起码也要了解常用的设计模式，即使是“背”，也得了然于胸。在学习一门技术，我推荐先看官方文档，看看有哪些模块、整体设计思想。然后下载示例跑一遍，最后才是看源码。
看源码深究细节：到了看具体某个模块源码的时候也要下意识的不要去深入细节，重要的是学习设计思路，而不是具体一个方法实现逻辑。除非自己要基于源码做二次开发。
陷入细节，不看全局：我还没弄清楚森林长啥样，就盯着叶子看 ，看不到全貌和整体设计思路。所以阅读源码学习的时候不要一开始就进入细节，而是宏观看待整体架构设计思想，模块之间的关系。
还没学会用就研究如何设计：首先基本上框架都运用了设计模式，我们最起码也要了解常用的设计模式，即使是“背”，也得了然于胸。在学习一门技术，我推荐先看官方文档，看看有哪些模块、整体设计思想。然后下载示例跑一遍，最后才是看源码。
看源码深究细节：到了看具体某个模块源码的时候也要下意识的不要去深入细节，重要的是学习设计思路，而不是具体一个方法实现逻辑。除非自己要基于源码做二次开发。
正确方式
定焦原则：抓主线（抓住一个核心流程去分析，不要漫无目的的到处阅读）。
宏观思维：从全局的视角去看待，上帝视角理出主要核心架构设计，先森林后树叶。切勿不要试图去搞明白每一行代码。
断点：合理运用调用栈（观察调用过程上下文）。
定焦原则：抓主线（抓住一个核心流程去分析，不要漫无目的的到处阅读）。
宏观思维：从全局的视角去看待，上帝视角理出主要核心架构设计，先森林后树叶。切勿不要试图去搞明白每一行代码。
断点：合理运用调用栈（观察调用过程上下文）。
带着目标去学
比如某些知识点是面试的热点，那学习目标就是彻底理解和掌握它，当被问到相关问题时，你的回答能够使得面试官对你刮目相看，有时候往往凭着某一个亮点就能影响最后的录用结果。
又或者接到一个稍微复杂的需求，学习从优秀源码中借鉴设计思路与优化技巧。
最后就是动手实践，将所学运用在工作项目中。只有动手实践才会让我们对技术有最直观的感受。有时候我们听别人讲经验和理论，感觉似乎懂了，但是过一段时间便又忘记了。
实际场景运用
简单的分析了 Tomcat 整体架构设计，从 【连接器】 到 【容器】，并且分别细说了一些组件的设计思想以及设计模式。接下来就是如何学以致用，借鉴优雅的设计运用到实际工作开发中。学习，从模仿开始。
责任链模式
在工作中，有这么一个需求，用户可以输入一些信息并可以选择查验该企业的 【工商信息】、【司法信息】、【中登情况】等如下如所示的一个或者多个模块，而且模块之间还有一些公共的东西是要各个模块复用。
这里就像一个请求，会被多个模块去处理。所以每个查询模块我们可以抽象为 处理阀门，使用一个 List 将这些 阀门保存起来，这样新增模块我们只需要新增一个阀门即可，实现了开闭原则，同时将一堆查验的代码解耦到不同的具体阀门中，使用抽象类提取 “不变的”功能。
具体示例代码如下所示：
首先抽象我们的处理阀门， NetCheckDTO是请求信息