1、前言
本文旨在介绍Tomcat的处理机制，内容包括：架构，启动流程，访问处理流程，IO模型、类加载机制。帮助加深对于Tomcat的理解。
2、架构
Catalina
负责解析Tomcat的配置⽂件（server.xml） , 以此来创建服务器Server组件并进⾏管理
Server
服务器表示整个Catalina Servlet容器以及其它组件，负责组装并启动Servlaet引擎,Tomcat连接器。Server通过实现Lifecycle接⼝，提供了⼀种优雅的启动和关闭整个系统的⽅式
Service
服务是Server内部的组件，⼀个Server包含多个Service。它将若⼲个Connector组件绑定到⼀个Service
Container
Container容器，负责处理⽤户的servlet请求，并返回对象给web⽤户的模块
Container组件下有四种具体的组件，分别是Engine、Host、Context和Wrapper，他们是层级关系。
Engine
表示整个Catalina的Servlet引擎，⽤来管理多个虚拟站点，⼀个Service最多只能有⼀个Engine，但是⼀个引擎可包含多个Host。
Host
代表⼀个虚拟主机，或者说⼀个站点，可以给Tomcat配置多个虚拟主机地址，⽽⼀个虚拟主机下可包含多个Context。
Context
表示⼀个Web应⽤程序， ⼀个Web应⽤可包含多个Wrapper。
Wrapper
表示⼀个Servlet，Wrapper 作为容器中的最底层，不能包含⼦容器。
3、启动流程
Tomcat的启动流程是从父容器开始把组件一个个初始化再逐级启动。
4、请求流程
5、IO模型
Tomcat6 和之前的版本默认都是使用的 BIO 模型，即阻塞式IO。在TomcatBIO模型中，主要参与的角色有：Acceptor和Handler工作线程池，它们的分工如下：
Acceptor：Accepter线程专门负责建立网络连接（accept）。新连接创建后，交给Handler工作线程池处理请求。
Handlers：针对每个请求的连接，Handler工作线程池都会分配一个线程，执行后面的所有步骤（read、decode、process、encode、send）。
Tomcat7之后（包含7），默认使用NIO模型，即非阻塞式IO，Tomcat的NIO模型，相比较于BIO模型，多了个Poller角色：Acceptor、Poller和Handler工作线程池。
Acceptor：Accepter线程专门负责建立网络连接（accept）。新连接创建后，不是直接使用Worker线程处理请求，而是先将请求发送给Poller缓冲队列。
Poller：在Poller中，维护了一个Selector对象，当Poller从缓冲队列中取出连接后，注册到该Selector中，阻塞等待读写就绪（read等待就绪、send等待就绪）。
Handlers：遍历Selector，找出其中就绪的IO操作，并交给Worker线程处理（read内存读、decode、process、encode、send内存写）。
6、类加载机制
6.1、JVM类加载机制
Jvm内置了⼏种类加载器，包括：启动类加载器、扩展类加载器、应用程序类加载器，他们之间形成⽗⼦关系，通过 Parent
属性来定义这种关系，最终可以形成树形结构，同时我们自己也可以自定义类加载器。启动类加载器（Bootstrap Class Loader）：负责加载<JAVA_HOME>\lib 目录，或者被 -Xbootclasspath 参数制定的路径，例如 jre/lib/rt.jar 里所有的class文件。由C++实现，不是ClassLoader子类。
拓展类加载器（Extension ClassLoader）：负责加载Java平台中扩展功能的一些jar包，包括<JAVA_HOME>\lib\ext 目录中 或
java.ext.dirs 指定目录下的jar包。由Java代码实现。应用程序类加载器（Application ClassLoader）：我们自己开发的应用程序，就是由它进行加载的，负责加载ClassPath路径下所有jar包。
双亲委派机制： 任何一个类加载器在接到一个类的加载请求时，都会先让其父类进行加载，只有父类无法加载（或者没有父类）的情况下，才尝试自己加载。
6.2 Tomcat类加载机制
web容器需要解决几个问题：
部署多个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。
部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机。
web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情，否则要你何用？ 所以，web容器需要支持， jsp 修改后不用重启。
jvm加载机制无法满足上诉所有场景：
1、默认的类加载器机制，无法加载两个相同类库的不同版本的。
2、要实现jsp的热替换，默认的类加载机制无法做到，jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。如果要做到热替换，可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。
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能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而CatalinaClassLoader和Shared
ClassLoader自己能加载的类则与对方相互隔离。WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。
而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。
双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。
Tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。
如果父类加载器需要委派子类加载器进行加载类，可以使用线程上下文类加载器。
1161
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
