窥探Tomcat整体架构，server.xml常用配置解析

た入场券 2022-10-10 11:12 44阅读 0赞

> 首发CSDN：[徐同学呀][Link 1]，原创不易，转载请注明源链接。我是徐同学，用心输出高质量文章，希望对你有所帮助。

### 文章目录 ###

*   *  一、前言
     *   *  server.xml配置示例
     *  二、Tomcat运行实例Server
     *   *  1、生命周期监听器
         *   *  （1）VersionLoggerListener
             *  （2）AprLifecycleListener
             *  （3）JreMemoryLeakPreventionListener
             *  （4）GlobalResourcesLifecycleListener
             *  （5）ThreadLocalLeakPreventionListener
             *  （6）NamingContextListener
         *  2、GlobalNamingResources
         *  3、监听SHUTDOWN命令
         *  4、定时触发自动部署周期性事件
     *  三、服务抽象Service
     *   *  1、共享线程池Executor
         *  2、连接器Connector
         *  3、容器引擎Engine
         *  4、URI映射器Mapper
     *  四、虚拟主机Host
     *   *  Host部署web应用
     *  五、Web应用Context
     *   *  Resources配置
     *  六、Servlet包装器Wrapper
     *  七、要点总结

## 一、前言 ##

`server.xml` 配置，是 `Tomcat`启动配置，从配置结构可以看出 `Tomcat` 的整体架构。如果能够了解其常用配置项，对 `Tomcat`有一个高屋建瓴的把握，然后再庖丁解牛，一步步深入源码中分析每一个核心功能的实现细节，这样会有事半功倍的效果。

### server.xml配置示例 ###

![server.xml][]

1.  如上图 `server.xml` 配置，最外层是一个 `Server`，代表 `Tomcat`的运行实例。`Server` 里有一些监听器 `Listener`，一个不知道干啥的 `GlobalNamingResources`，还有一个 `Service`，通过阅读源码，发现一个 `Server` 里可以有多个 `Service`。
2.  `Service`可以理解为是对部署在`Tomcat`里的服务的抽象，一个`Tomcat`可以部署多个服务，但是我更喜欢把一个`Service`理解成一个服务集合或者集群。
3.  `Service`里有一个 `Executor`、`Connector` 和 `Engine`。`Executor`是一个线程池，可以供 `Contector`使用；`Connector` 定义了协议连接（HTTP/AJP），外界就是通过`Connector`访问`Service`里的服务的；`Engine`是容器引擎，可以理解它为`Servlet`容器，真正的业务处理在`Engine`里。通过阅读源码，一个`Service`可以有多个`Executor`，多个`Connector`，一个`Engine`。如果把`Service`比作一个房子，`Connector`比作门，一个房子可以有多个门就好理解了。
4.  `Engine`内部较复杂，它内部就像俄罗斯套娃，有多个子容器，子容器下又可以有多个子容器。正如`Engine`的英文含义，引擎，驱动和管理内部子容器。因为是最顶端的管理者，会包含一些组件辅助管理子容器。`Engine`可以有多个`Host`容器，可以理解为虚拟主机（URL地址中主机部分抽象）；`Host`容器里有多个`Context`容器，`Context`就是一个个Web应用；`Context`容器里有多个`Wrapper`容器，`server.xml`中一般不用配置，`Wrapper`是对Servlet的包装，就是一个个业务功能了。
5.  如果对应上`Service`房子的比喻，`Engine`可以比作房子里所有房间的总和，或者是通向每个房间的走道，`Host`就是一个个房间，房间里有一些家具家电（`Context`），每一个家具家电有很多功能（`Wrapper`）。

![Tomcat整体架构-来自《Tomcat内核设计剖析》][Tomcat_-_Tomcat]

## 二、Tomcat运行实例Server ##

`Server`是`Tomcat`运行实例的抽象，管理着内部多个服务。在Tomcat源码中Server的默认标准实现是`org.apache.catalina.core.StandardServer`：

*  默认有6个生命周期监听器，监听Server不同运行阶段的事件并作出响应。
 *  GlobalNamingResources全局命名资源，通过JNDI提供统一的命名对象访问接口。
 *  Server监听了一个端口，默认8005，如果这个端口传来SHUTDOWN指令，则关闭Tomcat。
 *  Server还有两个定时任务，监听触发一些在Tomcat整个生命周期里周期性事件，暂时只有自动部署。

### 1、生命周期监听器 ###

#### （1）VersionLoggerListener ####

`org.apache.catalina.startup.VersionLoggerListener`监听初始化阶段，输出一些运行日志，如操作系统、`JDK`、`Tomcat`版本信息以及`catalina.base`、`catalina.home`的定义等。

#### （2）AprLifecycleListener ####

Tomcat可以使用APR本地库从操作系统级别解决异步IO问题，通过JNI方式调用APR本地库大幅提高对静态资源的处理性能。`org.apache.catalina.core.AprLifecycleListener`对初始化前的事件和销毁后的事件感兴趣：

*  在Tomcat初始化前，`AprLifecycleListener`尝试初始化APR库，如果初始化成功，则使用APR接收并处理客户端的请求。
 *  在Tomcat销毁后，`AprLifecycleListener`会对APR做一些销毁终止操作。

#### （3）JreMemoryLeakPreventionListener ####

`org.apache.catalina.core.JreMemoryLeakPreventionListener`监听器会在`Tomcat`初始化时使用系统类加载器预先加载一些JRE的类和设置`URLConnection`缓存禁用属性，以避免线程上下文类加载器是`Tomcat`自定义的`Webappclassloader`时，加载JRE导致的内存泄漏和`URLConnection`缓存导致的锁文件问题。

#### （4）GlobalResourcesLifecycleListener ####

`org.apache.catalina.mbeans.GlobalResourcesLifecycleListener`会在`Tomcat`启动时为`JNDI`创建`MBean`，停止时销毁`MBean`。

#### （5）ThreadLocalLeakPreventionListener ####

`org.apache.catalina.core.ThreadLocalLeakPreventionListener`监听器监听`Context`停止后，销毁连接器`Connector`中`Executor`的所有核心工作线程，并重新创建，以避免使用`ThreadLocal`带来的内存泄漏。

#### （6）NamingContextListener ####

`org.apache.catalina.core.NamingContextListener`监听器在Tomcat启动时创建并绑定全局命名资源，在Tomcat停止前做一些解绑全局命名资源、反注册销毁等操作。

### 2、GlobalNamingResources ###

`GlobalNamingResources`全局命名资源，通过JNDI提供统一的命名对象访问接口。而JNDI（`Java Naming and Directory Interface`）是一个比较老旧的技术，在历史遗留的企业级应用中可能还在用，诸如获取一个数据库连接资源、自定义配置等，这种强耦合在启动配置文件里的方式已经不适用现在轻量级的应用和分布式服务了。（后续可以单独研究下，这里了解即可。）

### 3、监听SHUTDOWN命令 ###

`Tomcat`启动时，主线程做完所有启动工作后，会进入循环等待`SHUTDOWN`的状态。如果接收到`SHUTDOWN`，结束循环调用`Tomcat`停止销毁接口。

实现方式很简单，单独给主线程建立一个`socket`连接，时刻监听某个端口（默认8005），是否发来`SHUTDOWN`命令。

### 4、定时触发自动部署周期性事件 ###

`Server`启动时，会开启两个定时任务，一个是每10秒触发一次自动部署事件，而这个定时任务可能会因为自动部署的检查和部署过程中出现异常导致该定时任务停止，所以就有了另一个定时任务每1分钟检查一次自动部署定时任务是否有在正常运行，没有就重新设置。（自动部署是`Host`的工作，在Host的生命周期监听器`HostConfig`中监听执行）

## 三、服务抽象Service ##

`Service`默认标准实现是`org.apache.catalina.core.StandardService`，如果在`Server`中配置了多个`Service`，`name`必须唯一，不可重复。

`Service`包含的组件有`Executor`、`Connector`、`Engine`，还有一个`Mapper`组件没有在配置中体现，一般也不需要配置。

### 1、共享线程池Executor ###

`Service`中可以定义一些线程池，供`Connector`和其他组件使用。`Tomcat`没有另起炉灶实现自己的线程池，而是在JUC的`ThreadPoolExecutor`基础上做了定制化改造，默认标准实现是`org.apache.catalina.core.StandardThreadExecutor`。

`Executor`可配置项如下：

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>备注</th> 
   <th>默认值</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>name</td> 
   <td>线程池名称，必须唯一，供其他组件直接引用</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>className</td> 
   <td>Executor的实现类名称</td> 
   <td>org.apache.catalina.core.StandardThreadExecutor</td> 
  </tr> 
  <tr> 
   <td>namePrefix</td> 
   <td>指定线程池中线程的名称前缀。</td> 
   <td>tomcat-exec-</td> 
  </tr> 
  <tr> 
   <td>maxThreads</td> 
   <td>最大线程数</td> 
   <td>200</td> 
  </tr> 
  <tr> 
   <td>minSpareThreads</td> 
   <td>核心线程数</td> 
   <td>25</td> 
  </tr> 
  <tr> 
   <td>threadPriority</td> 
   <td>工作线程优先级别</td> 
   <td>NORM_PRIORITY（5）</td> 
  </tr> 
  <tr> 
   <td>daemon</td> 
   <td>工作线程是否为守护线程</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>maxIdleTime</td> 
   <td>非核心工作线程空闲时存活时间</td> 
   <td>60000ms</td> 
  </tr> 
  <tr> 
   <td>prestartminSpareThreads</td> 
   <td>是否在启动Executor时创建核心工作线程</td> 
   <td>false</td> 
  </tr> 
  <tr> 
   <td>maxQueueSize</td> 
   <td>任务队列最大容量</td> 
   <td>Integer.MAX_VALUE</td> 
  </tr> 
  <tr> 
   <td>threadRenewalDelay</td> 
   <td>Context停止时，会销毁重建工作线程，为避免同一时间重建所有线程，该参数指定任意两个线程之间的创建延迟时间</td> 
   <td>1000ms</td> 
  </tr> 
 </tbody> 
</table>

注意：

如果指定`Executor`的实现是`StandardThreadExecutor`，那么`prestartminSpareThreads`无论是true还是false，都会预先创建`minSpareThreads`个核心工作线程。

### 2、连接器Connector ###

`Connector`是`Service`的门户，一个`Service`可以有多个`Connector`。`Connector`定义了多种连接协议，配置较为复杂，现仅提供常见配置说明：

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>备注</th> 
   <th>默认</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>executor</td> 
   <td>引用Executor的名称，如果为空，则会自己新建一个私有的线程池使用。</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>port</td> 
   <td>服务端socket监听的端口号，用于等待请求连接，如果设置为0，则会随机分配一个可用端口。</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>protocol</td> 
   <td>协议，可以填HTTP/1.1或AJP/1.3，也可以填具体的协议实现类如org.apache.coyote.http11.Http11NioProtocol或org.apache.coyote.ajp.AjpNioProtocol等</td> 
   <td>HTTP/1.1</td> 
  </tr> 
  <tr> 
   <td>connectionTimeout</td> 
   <td>接收连接等待超时时间，-1表示不超时。</td> 
   <td>60000ms</td> 
  </tr> 
  <tr> 
   <td>acceptCount</td> 
   <td>当所有请求处理线程都被占用时，socket等待请求队列的最大长度。</td> 
   <td>100</td> 
  </tr> 
  <tr> 
   <td>redirectPort</td> 
   <td>非SSL请求重定向到指定SSL端口。</td> 
   <td>443</td> 
  </tr> 
  <tr> 
   <td>URIEncoding</td> 
   <td>URI解析编码</td> 
   <td>UTF-8</td> 
  </tr> 
  <tr> 
   <td>maxPostSize</td> 
   <td>post请求的最大字节数，0或者负数则没有限制</td> 
   <td>2 * 1024 * 1024（2MB）</td> 
  </tr> 
  <tr> 
   <td>maxHttpHeaderSize</td> 
   <td>HTTP消息头的最大字节数</td> 
   <td>8 * 1024</td> 
  </tr> 
  <tr> 
   <td>maxConnections</td> 
   <td>服务端接收处理的最大连接数，是设置给LimitLatch限流器的，如果超过该值，则会阻塞等待，此时依然会接收连接，但是不能超过acceptCount，否则拒绝连接。</td> 
   <td>8*1024</td> 
  </tr> 
 </tbody> 
</table>

注意：

`Tomcat10.0.6`中`NioEndpoint`已经不能配置`Poller`线程和`acceptor`线程的个数，默认都是一个，同时`AprEndpoint`也标注为不建议使用，所以关于`APR`的配置也可以不用深入了解。后面会详细研究Connector的内部实现，到时讲解其他与源码相关的配置项。

![连接器-容器-来自网络][-_-]

### 3、容器引擎Engine ###

`Engine`是`Servlet`容器最顶端的管理者，负责处理对应Service中所有请求，包含多个Host和其他组件。默认标准实现是`org.apache.catalina.core.StandardEngine`。`Engine`以及其子容器都继承自`ContainerBase`，都有些相似的组件，如`AccessLog`、`Pipeline`、`Cluster`、`Realm`、`Log`、`LifecycleListener`、`ContainerListener`等。

`Engine`、`Host`、`Context`都有一个同名前缀的`LifecycleListener`，如`Engine`的是`EngineConfig`，`Host`的是`HostConfig`，`Context`是`ContextConfig`，分别监听自己感兴趣的生命周期事件，如`EngineConfig`就是在`Engine`启动停止时输出一些日志。

对于Engine节点可选配置有如下几个：

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>备注</th> 
   <th>默认</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>name</td> 
   <td>engine的名称，用于日志输出，必须唯一。</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>defaultHost</td> 
   <td>默认Host名称，当请求找不到Host时，就用该默认Host</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>backgroundProcessorDelay</td> 
   <td>后台线程处理延迟时间。</td> 
   <td>10s</td> 
  </tr> 
  <tr> 
   <td>startStopThreads</td> 
   <td>用于启动和停止子容器的线程数</td> 
   <td>1</td> 
  </tr> 
 </tbody> 
</table>

注意：

*  Engine即其子容器`Host`、`Context`、`Wrapper`都可以设置`backgroundProcessorDelay`这个参数，都可以有自己的后台线程来延迟`backgroundProcessorDelay`时长周期性处理一些事情。如果`backgroundProcessorDelay<=0`则不会创建私有的后台线程，默认Engine中这个参数是10，其他子容器是-1，所以一般情况子容器需要后台处理的事情，都交由Engine启动的后台线程周期性延迟处理。
 *  上层容器启动停止下层容器时，会用一个线程池来做异步处理。

### 4、URI映射器Mapper ###

`Service`中`Mapper`组件主要提供给`Connector`和`Context`使用，`Connector`中处理完连接后需要将请求信息交给对应的`Host`处理，可以通过`Mapper`的解析找到`Host`；`Context`通过`Mapper`找到对应的`Servlet`（`Wrapper`）处理业务。

`Mapper`还有一个对应的生命周期监听器`MapperListener`，其主要监听容器启动后，将容器注册到Mapper的关系中，建立一个树状结构。容器停止后做一些销毁、反注册操作。

（详细的`Mapper`原理后面会单独出文章讲解）

## 四、虚拟主机Host ##

`Host`是`Engine`的子容器，默认标准实现是`org.apache.catalina.core.StandardHost`。它的主要职责就是管理和部署子容器`Context`，比如，Host启动前，预先创建好部署web应用的目录；`Host`启动时，部署web应用；`Host`运行过程中，周期性检查web应用是否需要自动部署，这些监听工作都是在`HostConfig`中做的。

如下是Host的一些常用配置：

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>备注</th> 
   <th>默认</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>name</td> 
   <td>Host名称，必须要有一个Host名称与Engine的defaultHost对应。</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>appBase</td> 
   <td>web应用基础目录，可以是绝对路径，也可以是相对路径（相对于CATALINA_BASE）</td> 
   <td>webapps</td> 
  </tr> 
  <tr> 
   <td>unpackWARs</td> 
   <td>Context启动时是否将appBase目录下的war包解压。</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>autoDeploy</td> 
   <td>开启热部署，即在Tomcat运行阶段，定期检查和自动部署appBase和xmlBase目录下有无新增或者更新的web应用。</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>createDirs</td> 
   <td>若设置为true，Host在启动时预先创建好appBase和xmlBase目录。</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>backgroundProcessorDelay</td> 
   <td>后台线程处理延迟时间。一般不需要配置，直接用Engine的后台线程。</td> 
   <td>-1</td> 
  </tr> 
  <tr> 
   <td>workDir</td> 
   <td>Host下web应用的临时目录。每个web应用都有自己的临时目录，如果Context中设置了workDir，则Host中的配置会被覆盖。web应用中的Servlet将通过ServletContext的jakarta.servlet.context.tempdir属性访问workDir。</td> 
   <td>%CATALINA_BASE%/work/[EngineName]/[HostName]/ContextName</td> 
  </tr> 
  <tr> 
   <td>deployOnStartup</td> 
   <td>若设置为true，Host在启动时自动部署web应用。</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>xmlBase</td> 
   <td>XML基础目录，即context描述文件方式部署的路径，可以是绝对路径，也可以是相对路径（相对于CATALINA_BASE）。</td> 
   <td>%CATALINA_BASE%/conf/[EngineName]/[HostName]/</td> 
  </tr> 
 </tbody> 
</table>

### Host部署web应用 ###

Host部署web应用（Context）的三种方式：

*  `Context`描述文件部署，默认是`%CATALINA_BASE%/conf/[EngineName]/[HostName]/`目录下，可以有多个`Context`配置，后缀必须为`.xml`。可以通过`xmlBase`指定Context配置文件存放目录。
 *  WAR包部署，即将web应用打包成一个`.war`部署，默认放在`%CATALINA_BASE%/webapps`目录下，可以通过`appBase`指定一个绝对路径。
 *  目录部署，默认也是放在`%CATALINA_HOME%/webapps`目录下。

三种部署的过程都是解析实例化`Context`，而后两者web应用可能有自己的`META-INF/context.xml`，则通过解析它来组装生成`Context`，否则就解析全局的`%CATALINA_BASE%/conf/context.xml`。

## 五、Web应用Context ##

`Context`是对Web应用的抽象，相对其他容器有很多组件，且结构上复杂很多。默认标准实现是`org.apache.catalina.core.StandardContext`，其主要的职责有：

*  `Wrapper`管理，`Context`下有很多`Wrapper`，`Wrapper`是对`Servlet`的包装抽象，是最小的容器。
 *  错误页面`ErrorPage`管理，在`web.xml`里可以配置请求处理过程中发生异常重定向的页面路由。
 *  会话`Session`管理。
 *  Jar包扫描和加载，一个Context有一个自定义类加载，扫描和加载`/WEB-INF/lib`下的jar包。
 *  热加载，定期检查`/WEB-INF/lib`和`/WEB-INF/classes`目录下的`.jar`和`.class`文件是否更新，更新了就重新加载。热加载过程较消耗资源，仅适用于开发环境，不可用于生产环境。
 *  `ServletContainerInitializer`的初始化。
 *  除了生命周期监听器外，还有很多其他监听器。
 *  实例管理。
 *  静态资源缓存管理。

Context常用配置如下

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>备注</th> 
   <th>默认</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>path</td> 
   <td>web应用路径，同一个Host下必须唯一。如果path为空字符串，意味着为当前Host指定了默认web应用，该应用会处理根路径下的所有请求。这个属性只有在server.xml里配置Context有用，单独的Context配置文件里不会生效，会通过context文件名或docBase生成path。</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>reloadable</td> 
   <td>若设置为true，则开启热加载，即后台线程会定期检查/WEB-INF/lib和/WEB-INF/classes目录下的.jar和.class文件是否更新，如果更新，则重加载。</td> 
   <td>false</td> 
  </tr> 
  <tr> 
   <td>docBase</td> 
   <td>web应用目录或者war包部署路径。可以是绝对路径，也可以是相对路径（相对于Host的appBase）。</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>workDir</td> 
   <td>web应用的临时目录，如果配置了，会覆盖Host中配置的workDir。</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>backgroundProcessorDelay</td> 
   <td>后台线程处理延迟时间。一般不需要配置，直接用Engine的后台线程。</td> 
   <td>-1</td> 
  </tr> 
 </tbody> 
</table>

### Resources配置 ###

Resources是对静态资源的抽象，可以设置缓存以提高响应性能。默认标准实现是`org.apache.catalina.webresources.StandardRoot`。

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>备注</th> 
   <th>默认</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>cacheMaxSize</td> 
   <td>静态资源缓存最大值</td> 
   <td>10MB</td> 
  </tr> 
  <tr> 
   <td>cacheObjectMaxSize</td> 
   <td>单体静态资源最大值</td> 
   <td>512KB</td> 
  </tr> 
  <tr> 
   <td>cacheTtl</td> 
   <td>缓存失效时间</td> 
   <td>5000ms</td> 
  </tr> 
  <tr> 
   <td>cachingAllowed</td> 
   <td>是否使用缓存</td> 
   <td>true</td> 
  </tr> 
 </tbody> 
</table>

`StandardRoot`中有五种`WebResourceSet`：preResources、mainResources、classResources、jarResources、postResources，支持的配置如下：

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>备注</th> 
   <th>默认</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>base</td> 
   <td>资源的位置，用于指定文件、目录或者jar包的绝对路径。</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>webAppMount</td> 
   <td>当前资源挂载的web应用内部路径，如果添加一个jar包目录，可以将其挂载在/WEB-INF/lib下，必须“/”开头。</td> 
   <td>/</td> 
  </tr> 
  <tr> 
   <td>className</td> 
   <td>资源实现类。可选实现类有：org.apache.catalina.webresources.DirResourceSet，org.apache.catalina.webresources.JarResourceSet，org.apache.catalina.webresources.FileResourceSet</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>internalPath</td> 
   <td>资源的内部路径，通常用于jar内文件的加载。必须“/”开头。</td> 
   <td>/</td> 
  </tr> 
  <tr> 
   <td>readOnly</td> 
   <td>资源是否可读，如果设置为true，资源将不会删除、创建、修改。</td> 
   <td>false</td> 
  </tr> 
 </tbody> 
</table>

## 六、Servlet包装器Wrapper ##

`Wrapper`相对于`Engine`、`Host`、`Context`是最小的容器，其父容器必须是`Context`，没有其他子容器。默认标准实现是`org.apache.catalina.core.StandardWrapper`。一般情况一个`Servlet`对应一个`Wrapper`，这就是为什么`Servlet`不是线程安全的了，`Servlet`以单例的实现存在，多个线程访问肯定不是线程安全的，虽然有`Servlet`对象池的选择，但是`Tomcat10.0.6`已经不建议这样做。

## 七、要点总结 ##

本篇只对`server.xml`常用的配置进行解释，并通过配置文件节点关系，大概梳理了`Tomcat`整体架构。

Tomcat是一个非常优秀的开源项目，值得揉碎了仔细研究的细节实在太多，比如：

*  线程池定制化改造；
 *  连接`Connector`的设计以及如何连接到容器`Engine`的；
 *  `Mapper`组件如何解析映射URI；
 *  一个请求的处理和响应过程；
 *  生命周期框架的设计；
 *  自定义类加载器加载机制，如何做到隔离和共享，如何打破双亲委派；
 *  热部署，热加载的实现细节；
 *  如何解析`server.xml`配置；
 *  部署web应用的细节；
 *  容器之间如何做到有序连接，`Pipeline`和`Valve`的实现细节；
 *  `Servlet`如何实现双向过滤；
 *  各种监听器
 *  等等

后续会一个个详细解读，敬请期待。

非常感谢以下两本书：

*  《Tomcat内核设计剖析》汪建著
 *  《Tomcat架构解析》刘光瑞著
 *  参考源码Tomcat10.0.6和Tomcat8.5.9

Tomcat源码详细注释链接（非推广，持续更新）：[https://gitee.com/stefanpy/tomcat-source-code-learning][https_gitee.com_stefanpy_tomcat-source-code-learning]

*如若文章有错误理解，欢迎批评指正，同时非常期待你的评论、点赞和收藏。*

[Link 1]: https://stefan.blog.csdn.net/
[server.xml]: /images/20221005/e1fb9380d5134c56a095afc8e242eeca.png
[Tomcat_-_Tomcat]: /images/20221005/84ba2ec93f7c4399ba92079d63bc86b5.png
[-_-]: /images/20221005/e988a1e335e5417a80ba950d42f7cfe4.png
[https_gitee.com_stefanpy_tomcat-source-code-learning]: https://gitee.com/stefanpy/tomcat-source-code-learning