【Java Web编程十二】深入理解Tomcat系统架构及工作原理

本文链接：https://blog.csdn.net/sinat_33087001/article/details/118672055

本文详细介绍了Tomcat的目录结构、核心配置文件server.xml和web.xml，以及Tomcat的组件如Connector和Container的工作原理。通过对Tomcat生命周期、JSP处理流程的解析，揭示了Web程序在Tomcat上运行的完整过程，帮助读者深入理解服务器内部运作机制。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

了解了Servlet、JSP等这些模块的使用，学会了这些模块的使用，了解了MVC的基本架构之后总感觉哪里还少了点儿东西，没错，就是原理，我们的Web程序是运行在Tomcat上的，我们只知道该按照什么规范创建什么类型的文件，例如JSP、Servlet，但是不知道为什么这么写，项目就能按照我们预期的样子运行起来，换句话说，Tomcat这个服务器到底是怎么托管Web项目？如何启动和停止Web项目？如何处理请求？这些原理层面的内容我们一概不知。所以非常有必要对Tomcat内部一探究竟，才能通透的理解网站的运行方式。

Tomcat目录结构

好，又回到最初的起点，我们虽然在本专栏开始的博客提到了Tomcat的目录布局，但是并没有详细去聊它的实现，现在再重新回顾下目录结构：
在这里插入图片描述

一级目录结构

各个一级文件目录的主要作用如下：

bin：tomcat 管理命令，所有的可执行命令存放在这里，启动和关闭服务器的命令就在此文件夹中
conf：tomcat 配置文件。其中 server.xml是 tomcat 的核心配置文件，当然还有web.xml -为不同的Tomcat配置的web应用设置缺省值的文件，在webapps下的单个Web程序目录下也包含此文件，优先级更高，tomcat-users.xml- Tomcat用户认证的配置文件
lib：tomcat 应用程序在运行时依赖的第三方jar。
logs：存放 tomcat 的运行日志。
temp：存放 tomcat 运行时生成的临时文件。
webapps：tomcat 在默认情况下，接收到请求之后到 webapps下定位资源文件，Web 应用程序存放的目录，Web 项目保存到此目录中即可发布
work：由Tomcat自动生成，这是Tomcat放置它运行期间的中间(intermediate)文件(诸如编译的JSP文件)地方，tomcat在默认情况下，在work文件夹下将jsp文件编辑为java文件，并编译为.class文件，如果当Tomcat运行时，删除了这个目录那么将不能够执行包含JSP的页面

其中webapps存放的Web程序的目录结构，也是主要的二级目录结构

主要二级目录结构

webapps存放的主要的二级目录结构下单个Web程序目录结构如下：
在这里插入图片描述
其中WEB-INF是较为重点的文件，其余为前端的一些文件或者资源文件，WEB-INF的结构如下：

这里的三个文件含义如下：

classes文件夹: 这个目录及其下的子目录应该包括这个Web应用程序的所有JavaBean及Servlet等编译好的Java类文件（*.class）文件，以及没有被压缩打入JAR包的其他class文件和相关资源，也就是我们项目的Java文件被编译后的类文件存放地。
lib文件夹: 当前项目运行时所依赖的jar包。
web.xml文件：是一个Web应用程序的描述文件。这个文件是一个XML文件，描述了Servlet和这个Web应用程序的其他组件信息，此外还包括一些初始化信息和安全约束等，优先级高于conf文件夹下的默认配置文件

大概了解了目录后，我们可以发现，其实可以通过server.xml的配置来了解整个Tomcat的实际组成模块。

Tomcat核心配置

Tomcat有两个比较关键的配置文件：server.xml和web.xml，通过这两个配置文件我们可以一窥Tomcat的全貌。

server.xml配置文件

从tomcat的server.xml中我们可以看到tomcat的相关模块设计，从server.xml文件中解析出来的各个对象都是容器，比如Server、service、Connector和host等，这些容器都有新建、初始化、启动、停止、失败和销毁等状态

<?xml version="1.0" encoding="UTF-8"?>
<!--Server-->
<Server port="8005" shutdown="SHUTDOWN">
  <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
  <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

  <!-- Naming-->
  <GlobalNamingResources>
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml" />
  </GlobalNamingResources>
  <!-- Service-->
  <Service name="Catalina">
    <!-- Connector-->
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
    <!-- Container-->
    <Engine name="Catalina" defaultHost="localhost">
      <!-- Realm -->
      <Realm className="org.apache.catalina.realm.LockOutRealm">
        <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
               resourceName="UserDatabase"/>
      </Realm>
      <!-- Host -->
      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true">

        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log" suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %b" />

      </Host>
    </Engine>
  </Service>
</Server>

同样在web.xml文件中我们也能看到一些处理模块：

web.xml配置文件

web.xml配置文件也是一个默认的default配置文件，我们也可以在具体项目的目录下找到该目录的配置描述文件。是用来管理一个Context组件中的一些规范：

    <!-- ---------------------------Servlet默认配置模块------------------------------------------------------------->
   <servlet>
        <servlet-name>default</servlet-name>
        <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <init-param>
            <param-name>listings</param-name>
            <param-value>false</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <!-- ---------------------------JSP引擎处理模块------------------------------------------------------------->
    <servlet>
        <servlet-name>jsp</servlet-name>
        <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
        <init-param>
            <param-name>fork</param-name>
            <param-value>false</param-value>
        </init-param>
        <init-param>
            <param-name>xpoweredBy</param-name>
            <param-value>false</param-value>
        </init-param>
        <load-on-startup>3</load-on-startup>
    </servlet>

    <!-- The mapping for the default servlet -->
    <servlet-mapping>
        <servlet-name>default</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>jsp</servlet-name>
        <url-pattern>*.jsp</url-pattern>
        <url-pattern>*.jspx</url-pattern>
    </servlet-mapping>
    <!-- ---------------------------session配置模块------------------------------------------------------------->
    <session-config>
        <session-timeout>30</session-timeout>
    </session-config>
    <!-- ---------------------------欢迎页配置模块------------------------------------------------------------->
    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
        <welcome-file>index.htm</welcome-file>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>

Tomcat核心架构

Tomcat由什么组成的呢，除了上述配置文件我们可以看到的几个核心配置，一个Tomcat的实例由如下几个模块组成，他们共同构成了Tomcat的服务体系：
在这里插入图片描述
各个概念的释义如下，一个Tomcat实例就是一个Server，而一个Server可以包含多个Service，可以理解为包含多个Web项目。

Server：指的就是整个 Tomcat 服务器，包含多组服务，负责管理和启动各个 Service，同时监听 8005 端口发过来的 shutdown 命令，用于关闭整个容器
Service：Tomcat 封装的、对外提供完整的、基于组件的 web 服务，包含 Connectors、Container 两个核心组件，以及多个功能组件，各个 Service 之间是独立的，但是共享同一JVM 的资源，一个 Tomcat 实例支持部署多个彼此端口隔离的站点，这就是通过配置多个 Service 实现的

Service中核心组件

Connector：Tomcat 与外部世界的连接器，监听固定端口接收外部请求，传递给 Container，并将 Container 处理的结果返回给外部，一个Service可以包含多个Connector，这些Connector不仅能处理http、https请求，还能处理别的网络请求，总之类似于一个接口做各种处理后将转换后Container需要的数据传递给它。我们的请求和响应交互仰赖该模块
Container：也就是Catalina，Servlet 容器，内部由多层容器组成，用于管理 Servlet 生命周期，调用 servlet 相关方法。Servlet程序的生命周期皆受控于此模块

Service中其它组件

Loader：封装了 Java ClassLoader，用于 Container 加载类文件
Realm：Tomcat 中为 web 应用程序提供访问认证和角色管理的机制
JMX：Java SE 中定义技术规范，是一个为应用程序、设备、系统等植入管理功能的框架，通过 JMX 可以远程监控 Tomcat 的运行状态
Jasper：Tomcat 的 Jsp 解析引擎，用于将 Jsp 转换成 Java 文件，并编译成 class 文件。我们的JSP文件之所以能编译成可执行的文件就仰赖此模块
Session：负责管理和创建 session，以及 Session 的持久化(可自定义)，支持 session 的集群。我们的Session创建就是该模块负责的
Pipeline：在容器中充当管道的作用，管道中可以设置各种 valve(阀门)，请求和响应在经由管道中各个阀门处理，提供了一种灵活可配置的处理请求和响应的机制。
Naming：命名服务，JNDI， Java 命名和目录接口，是一组在 Java 应用中访问命名和目录服务的 API。命名服务将名称和对象联系起来，使得我们可以用名称访问对象，目录服务也是一种命名服务，对象不但有名称，还有属性。Tomcat 中可以使用 JNDI 定义数据源、配置信息，用于开发与部署的分离。

这些组件保证了Web请求到来时能被正确接收处理和响应。

Connector组件

Connector用于接受请求并将请求封装成Request和Response，然后交给Container进行处理，Container处理完之后在交给Connector返回给客户端，Connector 连接器面向底层数据传输，主要完成以下核心功能：

监听网络端口，接收和响应网络请求
网络字节流处理。处理 socket 通信，按照应用层协议解析处理数据，将网络数据封装成底层 Request/Response 对象，将底层 Request/Response 对象转换为 Servlet 容器能处理的标准 ServletRequest/ServletResponse，并将其投进 Container 容器进行处理

为了实现以上功能，Tomcat 将 Connector 连接器分为两个组件，分别是 ProtocolHandler 和 Adapter。

ProtocolHandler组件 ：协议处理器，将不同的协议和通讯方式组合封装成对应的协议处理器，如Http11NioProtocol 封装的是Http+NIO，目前Tomcat支持的协议和通讯方式如下：

由 EndPoint 和 Processor 组成。从一个请求的处理流程来看：
- Endpoint 负责提供请求字节流给 Processor。通信监听接口，具体的 Socket 接收和发送处理器，是对传输层的抽象
- Processor 负责构建并把 Tomcat 定义的 Request 对象给 Adapter。接收来自 EndPoint 的 Socket，读取字节流解析成 Request 和 Response 对象，是对应用层协议的抽象
Adapter组件：负责提供标准的 ServletRequest 对象给 Servlet 容器。由于 Request 并没有实现 Servlet 规范，而 Servlet 容器只能接收 ServletRequest，因此需要引入一个适配器将 Request 转换成 ServletRequest，再传递给 Servlet 容器

整体的流程结构如下图所示：
在这里插入图片描述

Container组件

每个 Service 会包含一个容器。容器由一个引擎可以管理多个虚拟主机。每个虚拟主机可以管理多个 Web 应用。每个 Web 应用会有多个 Servlet 包装器。Engine、Host、Context 和 Wrapper，四个容器之间属于父子关系
在这里插入图片描述

四个组件的职责如下：

Engine：Servlet 的顶层容器，包含一个或多个Host 子容器
Host：虚拟主机，负责 web 应用的部署和 Context 的创建
Context：Web 应用上下文，包含多个 Wrapper，负责 web 配置的解析，管理所有的 Web 资源；
Wrapper：最底层的容器，是对 Servlet 的封装，负责 Servlet 实例的创建、执行和销毁。

容器的请求处理过程就是在 Engine、Host、Context 和 Wrapper 这四个容器之间层层调用，最后在 Servlet 中执行对应的业务逻辑。各容器都会有一个通道 Pipeline，每个通道上都会有一个 Basic Valve（如StandardEngineValve），类似一个闸门用来处理 Request 和 Response 。其流程图如下：

在这里插入图片描述

请求路径查找流程

了解了两个核心组件后，我们把请求可以简单理解为：连接器的处理流程 + 容器的处理流程 = Tomcat 处理流程。Tomcat 是如何通过请求路径找到对应的虚拟站点？是如何找到对应的 Servlet 呢？我们再来回头看下配置文件里Service的部分：

  <!-- Service-->
  <Service name="Catalina">
    <!-- Connector-->
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
    <!-- Container-->
    <Engine name="Catalina" defaultHost="localhost">
      <!-- Realm -->
      <Realm className="org.apache.catalina.realm.LockOutRealm">
        <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
               resourceName="UserDatabase"/>
      </Realm>
      <!-- Host -->
      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true">

        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log" suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %b" />

      </Host>
    </Engine>
  </Service>

通过配置文件分析tomcat处理一个请求的流程，例如我们请求如下地址：http://localhost:8080/docs/list：

连接器监听的端口是8080。由于请求的端口和监听的端口一致，connector接受了该请求，并将转换好的HttpServletRequest传递给容器
因为引擎的默认虚拟主机是 localhost，并且虚拟主机的目录是webapps。所以请求找到了 tomcat/webapps 目录。
解析的 docs是 web 程序的应用名，也就是context。此时请求继续从 webapps 目录下找 docs目录。有的时候我们也会把应用名省略。
解析的 api 是具体的业务逻辑地址。此时需要从 docs/WEB-INF/web.xml 或者通过注解找映射关系，最后调用具体的函数list进行操作。

以下是一个解析示例：
在这里插入图片描述

Tomcat生命周期

Tomcat 为了方便管理组件和容器的生命周期，定义了从创建、启动、到停止、销毁共 12 中状态，tomcat 生命周期管理了内部状态变化的规则控制，组件和容器只需实现相应的生命周期方法即可完成各生命周期内的操作(initInternal、startInternal、stopInternal、 destroyInternal)。

比如执行初始化操作时，会判断当前状态是否 New，如果不是则抛出生命周期异常；是则设置当前状态为 Initializing，并执行 initInternal 方法，由子类实现，方法执行成功则设置当前状态为 Initialized，执行失败则设置为 Failed 状态。整体生命周期状态变化如下图所示：
在这里插入图片描述
Tomcat 的生命周期管理引入了事件机制，在组件或容器的生命周期状态发生变化时会通知事件监听器，监听器通过判断事件的类型来进行相应的操作。事件监听器的添加可以在 server.xml 文件中进行配置，事实上我们从配置中确实可以看的出一些监听器相关配置：

  <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
  <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

Tomcat 各类容器的配置过程就是通过添加 listener 的方式来进行的，从而达到配置逻辑与容器的解耦。

Tomcat流程管理

Tomcat有两个重要的流程处理，一个是Tomcat的启动流程，一个则是Tomcat的请求处理流程。

Tomcat启动流程

Tomcat的整体启动流程如下，通过如下的方式逐级推动子组件容器的状态变化：

启动从 Tomcat 提供的 start.sh 脚本开始，shell 脚本会调用 Bootstrap 的 main 方法，实际调用了 Catalina 相应的 load、start 方法。
load 方法会通过 Digester 进行 config/server.xml 的解析，在解析的过程中会根据 xml 中的关系和配置信息来创建容器，并设置相关的属性。接着 Catalina 会调用 StandardServer 的 init 、start 方法进行容器的初始化和启动。
StandardServer 完成 init 、 start 方法调用后，会一直监听来自 8005 端口(可配置)，如果接收到 shutdown 命令，则会退出循环监听，执行后续的 stop 和 destroy 方法，完成 Tomcat 容器的关闭。同时也会调用 JVM 的 Runtime.getRuntime().addShutdownHook 方法，在虚拟机意外退出的时候来关闭容器。

按照 xml 的配置关系，server 的子元素是 service，service 的子元素是顶层容器 Engine，每层容器有持有自己的子容器，而这些元素都实现了生命周期管理的各个方法，因此就很容易的完成整个容器的启动、关闭等生命周期的管理。
在这里插入图片描述
所有容器都是继承自 ContainerBase，基类中封装了容器中的重复工作，负责启动容器相关的组件 Loader、Logger、Manager、Cluster、Pipeline，启动子容器(线程池并发启动子容器，通过线程池 submit 多个线程，调用后返回 Future 对象，线程内部启动子容器，接着调用 Future 对象的 get 方法来等待执行结果)

Tomcat请求处理流程

上文中我们提到了Tomcat的路径查找方式，请求如何通过配置文件找到对应的处理逻辑，接下来我们完整的来看到一个请求的处理和响应的流程，用一个流程时序图表示如下：
在这里插入图片描述
假设来自客户的请求为：http://localhost:8080/Golden/loginServlet。

请求被发送到本机端口 8080，被在那里侦听的 Coyote HTTP/1.1 Connector 获得
Connector 把该请求交给它所在的 Service 的 Engine 来处理，并等待来自 Engine 的回应
Engine 获得请求 localhost:8080/Golden/loginServlet，匹配到名为 localhost 的 Host（即使匹配不到也把请求交给该 Host 处理，因为该 Host 被定义为该 Engine 的默认主机）
Host 获得请求/Golden/loginServlet，Host 匹配到路径为 /Golden的 Context
Context 获得请求 /loginServlet，匹配它所拥有的Wrapper
Wrapper 构造 HttpServletRequest 对象和 HttpServletResponse 对象，作为参数调用 JspServlet 的 doGet 或 doPost 方法

返回流程：

Context 把执行完了之后的 HttpServletResponse 对象返回给 Host
Host 把 HttpServletResponse 对象返回给 Engine
Engine 把 Response 对象返回给 Connector
Connector 把字节流数据返回给客户客户端浏览器。

这样就完成了一次整体的请求和响应。

Tomcat对JSP的处理

我们以上提到的整体处理流程其实是对Servlet的处理流程的概述，实际上大多数场景下我们请求的页面是JSP，而JSP需要被解析为Servlet来执行相关的业务逻辑。

Jasper引擎

客户端访问一个 jsp 文件，最终接收到的响应还是静态代码，因此 jsp 可以看做是一个运行在服务端的脚本。而 Jasper 的作用就是对 jsp 语法进行解析，生成 servlet 并生成 class 字节码文件，最终将访问的结果直接响应客户端，上文中我们提到的web.xml配置文件中有如下片段，我们可以看到 web.xml 中配置了一个 JspServlet，用于处理所有的 .jsp 或者 .jspx 结尾的请求：

 <servlet>
        <servlet-name>jsp</servlet-name>
        <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
        <init-param>
            <param-name>fork</param-name>
            <param-value>false</param-value>
        </init-param>
        <init-param>
            <param-name>xpoweredBy</param-name>
            <param-value>false</param-value>
        </init-param>
        <load-on-startup>3</load-on-startup>
    </servlet>

    <!-- The mapping for the default servlet -->
    <servlet-mapping>
        <servlet-name>default</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

    <!-- The mappings for the JSP servlet -->
    <servlet-mapping>
        <servlet-name>jsp</servlet-name>
        <url-pattern>*.jsp</url-pattern>
        <url-pattern>*.jspx</url-pattern>
    </servlet-mapping>