Tomcat是什么？

Tomcat 服务器Apache软件基金会项目中的一个核心项目，是一个免费的开放 源代码的Web 应用服务

器，属于轻量级应用服务器，在中小型系统和并发访问 用户不是很多的场合下被普遍使用，是开发和调

试JSP 程序的首选。

Tomcat的缺省端口是多少，怎么修改

找到Tomcat目录下的conf文件夹

进入conf文件夹里面找到server.xml文件

打开server.xml文件

在server.xml文件里面找到下列信息

把Connector标签的8080端口改成你想要的端口

tomcat 有哪几种Connector 运行模式(优化)？

下面，我们先大致了解Tomcat Connector的三种运行模式。

BIO：同步并阻塞 一个线程处理一个请求。缺点：并发量高时，线程数较 多，浪费资源。

Tomcat7或以下，在Linux系统中默认使用这种方式。

配制项：protocol=”HTTP/1.1”

NIO：同步非阻塞IO 利用Java的异步IO处理，可以通过少量的线程处理大量的请求，可以复用同一

个线程处理多个connection(多路复用)。

Tomcat8在Linux系统中默认使用这种方式。

Tomcat7必须修改Connector配置来启动。

配制项：protocol=”org.apache.coyote.http11.Http11NioProtocol”

备注：我们常用的Jetty，Mina，ZooKeeper等都是基于java nio实现.

APR：即Apache Portable Runtime，从操作系统层面解决io阻塞问 题。AIO方式，异步非阻塞

IO(Java NIO2又叫AIO) 主要与NIO的区别 主要是操作系统的底层区别.可以做个比喻:比作快递，

NIO就是网购后要自 己到官网查下快递是否已经到了(可能是多次)，然后自己去取快递；AIO就 是

快递员送货上门了(不用关注快递进度)。

配制项：protocol=”org.apache.coyote.http11.Http11AprProtocol”

备注：需在本地服务器安装APR库。Tomcat7或Tomcat8在Win7或以上的系统 中启动默认使用这

种方式。Linux如果安装了apr和native，Tomcat直接启动就 支持apr。

Tomcat有几种部署方式？

在Tomcat中部署Web应用的方式主要有如下几种：

利用Tomcat的自动部署。

把web应用拷贝到webapps目录。Tomcat在启动时会加载目录下的应用，并将 编译后的结果放入

work目录下。

使用Manager App控制台部署。

在tomcat主页点击“Manager App” 进入应用管理控制台，可以指定一个 web应用的路径或war文

件。

修改conf/server.xml文件部署。

修改conf/server.xml文件，增加Context节点可以部署应用。

增加自定义的Web部署文件。

在conf/Catalina/localhost/ 路径下增加 xyz.xml文件，内容是Context节点， 可以部署应用

tomcat容器是如何创建servlet类实例？用到了什么 原

理？

1. 当容器启动时，会读取在webapps目录下所有的web应用中的web.xml 文件，然后对 xml文件进

行解析，并读取servlet注册信息。然后，将每个 应用中注册的servlet类都进行加载，并通过 反射

的方式实例化。（有时候 也是在第一次请求时实例化）

2. 在servlet注册时加上1如果为正数，则在一开始就实例化，如果不写或 为负数，则第一次请求实例

化。

Tomcat工作模式

1 <Service name="Catalina">

2 <Connector port="8080" protocol="HTTP/1.1"

3 connectionTimeout="20000"

4 redirectPort="8443" />

Tomcat作为servlet容器，有三种工作模式：

1. 独立的servlet容器，servlet容器是web服务器的一部分；

2. 进程内的servlet容器，servlet容器是作为web服务器的插件和java容器的实 现，web服务器插件在

内部地址空间打开一个jvm使得java容器在内部得以运行。反 应速度快但伸缩性不足；

3. 进程外的servlet容器，servlet容器运行于web服务器之外的地址空间，并作 为web服务器的插件

和java容器实现的结合。反应时间不如进程内但伸缩性和稳定性 比进程内优； 进入Tomcat的请求

可以根据Tomcat的工作模式分为如下两类：

Tomcat作为应用程序服务器：请求来自于前端的web服务器，这可能是 Apache, IIS, Nginx等；

Tomcat作为独立服务器：请求来自于web浏览器；

面试时问到Tomcat相关问题的几率并不高，正式因为如此，很多人忽略了对 Tomcat相关技能的掌握，

下面这一篇文章整理了Tomcat相关的系统架构，介 绍了Server、Service、Connector、Container之间

的关系，各个模块的功 能，可以说把这几个掌握住了，Tomcat相关的面试题你就不会有任何问题了！

另外，在面试的时候你还要有意识无意识的往Tomcat这个地方引，就比如说常 见的Spring MVC的执行

流程，一个URL的完整调用链路，这些相关的题目你是 可以往Tomcat处理请求的这个过程去说的！掌握

了Tomcat这些技能，面试官 一定会佩服你的！

学了本章之后你应该明白的是：

Server、Service、Connector、Container四大组件之间的关系和联系，以及他 们的主要功能点；

Tomcat执行的整体架构，请求是如何被一步步处理的；

Engine、Host、Context、Wrapper相关的概念关系；

Container是如何处理请求的；

Tomcat用到的相关设计模式；

Tomcat顶层架构

俗话说，站在巨人的肩膀上看世界，一般学习的时候也是先总览一下整体，然后 逐个部分个个击破，最

后形成思路，了解具体细节，Tomcat的结构很复杂，但 是 Tomcat 非常的模块化，找到了 Tomcat 最

核心的模块，问题才可以游刃而 解，了解了 Tomcat 的整体架构对以后深入了解 Tomcat 来说至关重

要！ 先上一张Tomcat的顶层结构图（图A），如下：

Tomcat中最顶层的容器是Server，代表着整个服务器，从上图中可以看出，一 个Server可以包含至少

一个Service，即可以包含多个Service，用于具体提供服 务。

Service主要包含两个部分：Connector和Container。从上图中可以看出 Tomcat 的心脏就是这两个组

件，他们的作用如下：

Connector用于处理连接相关的事情，并提供Socket与Request请求和 Response响应相关的转化;

Container用于封装和管理Servlet，以及具体处理Request请求；

一个Tomcat中只有一个Server，一个Server可以包含多个Service，一个 Service只有一个Container，

但是可以有多个Connectors，这是因为一个服务 可以有多个连接，如同时提供Http和Https链接，也可

以提供向相同协议不同端 口的连接，示意图如下（Engine、Host、Context下面会说到）：

多个 Connector 和一个 Container 就形成了一个 Service，有了 Service 就可 以对外提供服务了，但是

Service 还要一个生存的环境，必须要有人能够给她生 命、掌握其生死大权，那就非 Server 莫属了！所

以整个 Tomcat 的生命周期由 Server 控制。

另外，上述的包含关系或者说是父子关系，都可以在tomcat的conf目录下的 server.xml配置文件中看

出，下图是删除了注释内容之后的一个完整的 server.xml配置文件（Tomcat版本为8.0）

详细的配置文件内容可以到Tomcat官网查看：Tomcat配置文件

上边的配置文件，还可以通过下边的一张结构图更清楚的理解：

Server标签设置的端口号为8005，shutdown=”SHUTDOWN” ，表示在 8005端口监听“SHUTDOWN”命

令，如果接收到了就会关闭Tomcat。一个 Server有一个Service，当然还可以进行配置，一个Service有

多个Connector， Service左边的内容都属于Container的，Service下边是Connector。

Tomcat顶层架构小结

1. Tomcat中只有一个Server，一个Server可以有多个Service，一个 Service可以有多个Connector和

一个Container；

2. Server掌管着整个Tomcat的生死大权；

3. Service 是对外提供服务的；

4. Connector用于接受请求并将请求封装成Request和Response来具体 处理；

5. Container用于封装和管理Servlet，以及具体处理request请求；

知道了整个Tomcat顶层的分层架构和各个组件之间的关系以及作用，对于绝大 多数的开发人员来说

Server和Service对我们来说确实很远，而我们开发中绝大 部分进行配置的内容是属于Connector和

Container的，所以接下来介绍一下 Connector和Container。

Connector和Container的微妙关系

由上述内容我们大致可以知道一个请求发送到Tomcat之后，首先经过Service然 后会交给我们的

Connector，Connector用于接收请求并将接收的请求封装为 Request和Response来具体处理，

Request和Response封装完之后再交由 Container进行处理，Container处理完请求之后再返回给

Connector，最后在 由Connector通过Socket将处理的结果返回给客户端，这样整个请求的就处理 完

了！

Connector最底层使用的是Socket来进行连接的，Request和Response是按照 HTTP协议来封装的，所

以Connector同时需要实现TCP/IP协议和HTTP协议！

Tomcat既然需要处理请求，那么肯定需要先接收到这个请求，接收请求这个东 西我们首先就需要看一

下Connector！

Connector架构分析

Connector用于接受请求并将请求封装成Request和Response，然后交给 Container进行处理，

Container处理完之后在交给Connector返回给客户端。 因此，我们可以把Connector分为四个方面进行

理解：

1. Connector如何接受请求的？

2. 如何将请求封装成Request和Response的？

3. 封装完之后的Request和Response如何交给Container进行处理的？

4. Container处理完之后如何交给Connector并返回给客户端的？ 首先看一下Connector的结构图，

如下所示：

Connector就是使用ProtocolHandler来处理请求的，不同的ProtocolHandler 代表不同的连接类型，比

如：Http11Protocol使用的是普通Socket来连接的， Http11NioProtocol使用的是NioSocket来连接

的。

其中ProtocolHandler由包含了三个部件：Endpoint、Processor、Adapter。

1. Endpoint用来处理底层Socket的网络连接，Processor用于将 Endpoint接收到的Socket封装成

Request，Adapter用于将Request交给 Container进行具体的处理。

2. Endpoint由于是处理底层的Socket网络连接，因此Endpoint是用来实 现TCP/IP协议的，而

Processor用来实现HTTP协议的，Adapter将请求适 配到Servlet容器进行具体的处理。

3. Endpoint的抽象实现AbstractEndpoint里面定义的Acceptor和 AsyncTimeout两个内部类和一个

Handler接口。Acceptor用于监听请 求，AsyncTimeout用于检查异步Request的超时，Handler用

于处理接收 到的Socket，在内部调用Processor进行处理。

至此，我们应该很轻松的回答1，2，3的问题了，但是4还是不知道，那么我们 就来看一下Container是

如何进行处理的以及处理完之后是如何将处理完的结果 返回给Connector的？

Container架构分析

Container用于封装和管理Servlet，以及具体处理Request请求，在Container 内部包含了4个子容器，

结构图如下：

4个子容器的作用分别是：

1. Engine：引擎，用来管理多个站点，一个Service最多只能有一个 Engine；

2. Host：代表一个站点，也可以叫虚拟主机，通过配置Host就可以添加 站点；

3. Context：代表一个应用程序，对应着平时开发的一套程序，或者一个 WEB-INF目录以及下面的

web.xml文件；

4. Wrapper：每一Wrapper封装着一个Servlet； 下面找一个Tomcat的文件目录对照一下，如下图所

示：

Context和Host的区别是Context表示一个应用，我们的Tomcat中默认的配置 下webapps下的每一个文

件夹目录都是一个Context，其中ROOT目录中存放着 主应用，其他目录存放着子应用，而整个

webapps就是一个Host站点。

我们访问应用Context的时候，如果是ROOT下的则直接使用域名就可以访问， 例如：

www.baidu.com，如果是Host（webapps）下的其他应用，则可以使 用www.baidu.com/docs进行访

问，当然默认指定的根应用（ROOT）是可以 进行设定的，只不过Host站点下默认的主应用是ROOT目

录下的。

看到这里我们知道Container是什么，但是还是不知道Container是如何进行请 求处理的以及处理完之后

是如何将处理完的结果返回给Connector的？别急！下 边就开始探讨一下Container是如何进行处理

的！

Container如何处理请求的

Container处理请求是使用Pipeline-Valve管道来处理的！（Valve是阀门之 意）

Pipeline-Valve是责任链模式，责任链模式是指在一个请求处理的过程中有很多 处理者依次对请求进行

处理，每个处理者负责做自己相应的处理，处理完之后将 处理后的结果返回，再让下一个处理者继续处

理。

但是！Pipeline-Valve使用的责任链模式和普通的责任链模式有些不同！区别主 要有以下两点：

每个Pipeline都有特定的Valve，而且是在管道的最后一个执行，这个 Valve叫做BaseValve，BaseValve

是不可删除的；

在上层容器的管道的BaseValve中会调用下层容器的管道。

我们知道Container包含四个子容器，而这四个子容器对应的BaseValve分别

在：StandardEngineValve、StandardHostValve、StandardContextValve、

StandardWrapperValve。

Pipeline的处理流程图如下：

Connector在接收到请求后会首先调用最顶层容器的Pipeline来处 理，这里的最顶层容器的

Pipeline就是EnginePipeline（Engine的管 道）；

在Engine的管道中依次会执行EngineValve1、EngineValve2等等， 最后会执行

StandardEngineValve，在StandardEngineValve中会调用 Host管道，然后再依次执行Host的

HostValve1、HostValve2等，最后在 执行StandardHostValve，然后再依次调用Context的管道和

Wrapper的 管道，最后执行到StandardWrapperValve。

当执行到StandardWrapperValve的时候，会在 StandardWrapperValve中创建FilterChain，并调

用其doFilter方法来处 理请求，这个FilterChain包含着我们配置的与请求相匹配的Filter和

Servlet，其doFilter方法会依次调用所有的Filter的doFilter方法和Servlet 的service方法，这样请

求就得到了处理！

当所有的Pipeline-Valve都执行完之后，并且处理完了具体的请求， 这个时候就可以将返回的结果

交给Connector了，Connector在通过 Socket的方式将结果返回给客户端。