Tomcat架构设计与启动流程深度解析

首页

业界动态

Tomcat架构设计与启动流程深度解析

热心网友

转载

2026-05-16

Tomcat的架构设计精髓，在于其模块化、分层与解耦的核心思想。它不仅严格遵循Java Servlet规范，更构建了一套支持高性能、高可扩展性的Web服务体系。上一篇文章我们动手实现了一个迷你版的Tomcat，算是“知其然”。今天，我们将从源码和架构层面深入剖析，真正理解其内部运作机制，做到“知其所以然”。

一、Tomcat和Catalina是什么关系？

许多开发者在初次接触Tomcat源码时，都会对“Catalina”这个名字感到困惑。实际上，Tomcat的前身就是Catalina，它本身是一个轻量级的Servlet容器实现。Catalina这个名字源自美国一个风景优美的小岛，或许其作者希望这个服务器也能设计得同样优雅、轻巧。然而，从4.x版本开始，Tomcat在作为Servlet容器的基础上，陆续集成了JSP引擎、EL表达式、命名服务等众多功能。因此，今天的Tomcat早已超越了单纯的Catalina，演变为一个功能更为全面的Java Web应用服务器。

二、什么是Servlet？

要深入理解Tomcat，首先必须搞清楚Servlet是什么。简单来说，Servlet是Sun公司（现属Oracle）为了将Java引入动态Web编程领域而制定的一套标准API。

回顾互联网发展早期，Sun公司曾推出Applet试图抢占Web前端市场，但并未成功。面对Web服务器端的巨大机遇，Sun自然不会放弃，于是投入精力制定了Servlet规范。那么，一个Servlet具体负责哪些工作呢？它主要完成三件核心任务：

创建并填充Request对象，包括解析URI、获取请求参数、识别HTTP方法、读取头信息及请求体等。
创建Response对象，用于封装向客户端发送的响应数据。
执行业务逻辑，并通过Response的输出流将处理结果返回给客户端浏览器。

Servlet本身没有main方法，它的生命周期和执行必须依赖一个容器（Container）。这个容器的核心价值，就是为了支撑Servlet规范定义的功能。而Tomcat，正是这套规范最经典、应用最广泛的实现之一，是学习和理解Java Web技术的基石。

三、核心架构设计

官方架构文档是理解其设计的最佳入口。Tomcat的整体架构可以概括为经典的“连接器（Connector）- 容器（Container）”双层模型，并通过生命周期管理（Lifecycle）和责任链模式（Pipeline-Valve）来实现组件间的高效协同。

如果用一句话形象地描述Tomcat的组件关系，那就是“俄罗斯套娃”式的嵌套结构：Server → Service → (Connector + Engine) → Host → Context → Wrapper。

我们来逐一拆解这个结构中的核心角色及其职责：

Server：代表整个Tomcat服务器实例，是顶级的生命周期管理容器，负责管理一个或多个Service。
Service：服务单元，将一个或多个Connector与一个唯一的Engine（引擎）绑定起来，形成一个完整的服务。其内部还包含众多支撑组件，如用于管理用户会话的Manager、记录运行日志的Logger、负责类加载的Loader，以及实现过滤器链功能的Pipeline和Valve组合，还有负责安全认证与授权的Realm。
Connector（连接器）：负责“对外沟通”，监听网络端口，处理HTTP、AJP等协议请求，完成网络字节流的解析，并将其转化为标准的ServletRequest对象，交给容器处理。
Container（容器）：负责“内部处理”，加载和管理Servlet，执行业务逻辑。它本身采用四级嵌套的容器结构，实现精细化的管理：
- Engine：请求处理的入口容器，每个Service有且仅有一个Engine。
- Host：虚拟主机，通常对应一个域名或IP地址，用于实现多站点托管。
- Context：Web应用上下文，对应一个WAR包或应用目录，是Web应用部署的基本单位。
- Wrapper：最底层的容器，封装了单个Servlet实例，管理其生命周期。

1. 从web.xml配置和模块对应角度

上述这些核心模块并非抽象概念，它们直接映射到Tomcat的主配置文件server.xml中。将两者结合起来看，理解会更加直观和深刻。

2. 从一个完整请求的角度来看

理解了静态的组件结构后，我们还需要通过一个动态的HTTP请求处理流程，把这些组件“串联”起来，看清它们是如何协作的。

假设有一个请求：https://localhost:8080/test/index.jsp。它在Tomcat内部的完整旅程如下：

请求到达服务器本机的8080端口，被监听于此的Coyote HTTP/1.1 Connector接收并解析。
Connector将解析后的请求对象交给它所属Service的Engine进行处理，并等待响应。
Engine获得请求localhost:8080/test/index.jsp，根据主机名匹配其下配置的所有虚拟主机（Host）。
Engine成功匹配到名为localhost的Host（如果匹配失败，则会交给该Engine配置的默认主机处理）。
localhost Host获得请求路径/test/index.jsp，在其管理的所有Web应用上下文（Context）中进行匹配。
Host成功匹配到路径为/test的Context（如果匹配不到，通常会交给路径名为空字符串""的根Context处理）。
路径为/test的Context获得请求资源路径/index.jsp，在其Servlet映射表中寻找对应的Servlet处理器。
Context根据URL模式*.jsp匹配到对应的Servlet，即JspServlet类。随后构造HttpServletRequest和HttpServletResponse对象，作为参数调用JspServlet的相应方法（如doGet或doPost）。
Context将JspServlet执行完毕后的HttpServletResponse对象返回给其父容器Host。
Host将其返回给其父容器Engine。
Engine将其返回给最初接收请求的Connector。
Connector最终将HttpServletResponse对象中的内容，按照HTTP协议格式组装并返回给客户端浏览器。

3. 从源码的设计角度看

从功能模块划分的角度审视，Tomcat的源码大致可以分为5个核心子模块：

Jasper模块：负责JSP页面的解析、语法验证，以及将JSP动态转换为Java源代码并编译成Class文件。对应org.apache.jasper包及其子包。
Servlet和JSP模块：包含ja vax.servlet包及其子包，定义了Servlet接口、HttpServlet类、HttpJspPage等Java EE Web核心规范接口。
Catalina模块：这是Tomcat架构的心脏，包含所有org.apache.catalina开头的源码。它定义了Server、Service、Host、Connector、Context、Session等关键组件及其实现，大量运用了组合模式（Composite），并规范了Catalina的启动、停止等生命周期事件流程。这是深入阅读Tomcat源码的重点区域。
Connector模块：如果说Catalina实现了应用服务器的业务逻辑容器，那么Connector就实现了高性能的Web服务器功能。它作为用户请求与应用服务器之间的桥梁，负责接收网络连接、解析协议、包装成标准Http请求对象，并按照HTTP协议向客户端发送响应。
Resource模块：包含服务器运行所需的资源文件，如核心配置文件server.xml及web.xml。虽然不包含Java源码，但却是Tomcat编译、部署和运行所必需的。

4. 从后续深入理解的角度

了解了整体组件结构后，后续要深入理解Tomcat的设计精髓，应该重点关注以下几个核心设计理念：

(1) 基于组件的架构

Tomcat本质上是由各种职责单一、边界清晰的组件堆砌而成。每个组件各司其职，组件之间通过定义良好的接口进行通信和协作。这种高度模块化、组件化的设计，是其实现高可扩展性和易于维护的基础。

(2) 基于JMX的管理

阅读Tomcat源码时，你会频繁看到类似下面的管理代码：

Registry.getRegistry(null, null).invoke(mbeans, "init", false);
Registry.getRegistry(null, null).invoke(mbeans, "start", false);

这实际上是基于JMX（Java Management Extensions，Java管理扩展）来动态管理组件对象。JMX是一个为应用程序、系统对象植入管理功能的框架，能够跨越异构操作系统和网络协议，实现灵活的集成与远程管理。

(3) 基于生命周期的管理

如果你查看各组件的源代码，会发现绝大多数核心组件都实现了Lifecycle接口。这就是基于生命周期的统一管理。组件状态的变迁（如初始化init、启动start、停止stop、销毁destroy）被抽象为标准的生命周期事件，通过监听器模式进行传播，使得所有组件的状态管理变得统一、规范和可监控。

四、启动过程详解

1. 总体流程

先通过一张图来俯瞰Tomcat初始化和启动的整体流程，理解时可以将其与前面提到的架构组件一一对应：

2. 启动过程代码浅析

网上很多文章直接陷入代码细节，对初学者并不友好。这里我们将其转化为几个核心问题，帮助你把握主线。

(1) Bootstrap主入口在哪？

Tomcat的启动入口是org.apache.catalina.startup.Bootstrap类的main方法。我们重点关注它的init()方法，它完成了Catalina运行环境的初始化：

public void init() throws Exception {
    // 1. 初始化类加载器（包括catalinaLoader）
    initClassLoaders();
    // 2. 设置当前线程的上下文类加载器为catalinaLoader
    Thread.currentThread().setContextClassLoader(catalinaLoader);
    SecurityClassLoad.securityClassLoad(catalinaLoader);
    // 3. 通过catalinaLoader加载Catalina类并实例化
    Class startupClass = catalinaLoader.loadClass("org.apache.catalina.startup.Catalina");
    Object startupInstance = startupClass.getConstructor().newInstance();
    // 4. 通过反射调用setParentClassLoader方法，传入sharedLoader
    String methodName = "setParentClassLoader";
    Class paramTypes[] = new Class[1];
    paramTypes[0] = Class.forName("ja va.lang.ClassLoader");
    Object paramValues[] = new Object[1];
    paramValues[0] = sharedLoader;
    Method method = startupInstance.getClass().getMethod(methodName, paramTypes);
    method.invoke(startupInstance, paramValues);
    catalinaDaemon = startupInstance;
}

这段代码清晰地展示了Catalina的初始化路径，同时也引出了一个关键问题：Tomcat为什么要设计并初始化多套不同的类加载器？我们稍后详解。

(2) Bootstrap如何初始化Catalina？

从时序图上看，Bootstrap的main方法在调用init()之后，会接着调用load()方法。而load()方法本质上是通过反射调用了catalinaDaemon（即上一步创建的Catalina实例）的load方法。

private void load(String[] arguments) throws Exception {
    Method method = catalinaDaemon.getClass().getMethod("load", paramTypes);
    method.invoke(catalinaDaemon, param); // 本质上就是调用Catalina的load方法
}

3. 启动过程：类加载机制详解

(1) Tomcat初始化了哪些ClassLoader？

在Bootstrap的初始化中，我们看到三个关键的类加载器被创建：

ClassLoader commonLoader = null;
ClassLoader catalinaLoader = null;
ClassLoader sharedLoader = null;

(2) 它们是如何初始化的？

private void initClassLoaders() {
    try {
        commonLoader = createClassLoader("common", null);
        catalinaLoader = createClassLoader("server", commonLoader); // 父加载器是commonLoader
        sharedLoader = createClassLoader("shared", commonLoader);
    } catch (Throwable t) {
        // ... 异常处理
    }
}

可以看出，catalinaLoader（服务器类加载器）和sharedLoader（共享类加载器）的父加载器都是commonLoader（通用类加载器）。

(3) ClassLoader是如何创建的？

创建逻辑封装在createClassLoader方法中：该方法从catalina.properties配置文件中读取common.loader、server.loader、shared.loader对应的类路径，构造成Repository列表，最终通过ClassLoaderFactory.createClassLoader创建URLClassLoader。在默认配置中，server.loader和shared.loader为空，因此这三个加载器在默认情况下实际上是同一个对象（在早期版本中它们是不同的实例）。

common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar"
server.loader=
shared.loader=

初始化后，init()方法使用catalinaLoader加载Catalina类并创建实例，再通过反射设置其父类加载器为sharedLoader。

(4) 深入理解Tomcat类加载体系

这里需要回顾一下Java类加载机制的基础。简单来说，类可以分为三类：Java核心类（由Bootstrap ClassLoader加载）、Java扩展类（由Extension ClassLoader加载）、用户自定义类（由Application ClassLoader加载）。双亲委派模型保证了核心类的安全，但它也带来了灵活性问题，例如在SPI（服务提供者接口）机制中，核心类加载器无法加载位于用户classpath下的第三方实现类。

Tomcat没有完全遵循标准的双亲委派模型，这是为了支持Web应用级别的类隔离。想象一下，两个独立的Web应用可能依赖同一个第三方库（如Spring）的不同版本，如果共享同一个类加载器，必然导致类冲突。Tomcat的解决方案是自定义了一套精巧的、层次化的类加载器体系。

官方文档提供了清晰的类加载器视图：

结合经典的双亲委派模型，Tomcat完整的类加载体系如下：

注意，Catalina类加载器和Shared类加载器是兄弟关系，它们都继承自Common类加载器，而非父子关系。每个加载器职责明确：

Common ClassLoader：加载Tomcat服务器本身以及所有Web应用都可能需要共享的通用类库。
Catalina ClassLoader：加载Tomcat服务器实现私有的类，这些类对Web应用不可见，实现了服务器与应用的隔离。
Shared ClassLoader：加载所有Web应用共享的类库，这些类对Tomcat服务器本身不可见。
WebApp ClassLoader：加载单个Web应用私有的类（位于WEB-INF/classes和WEB-INF/lib），对其他Web应用和Tomcat服务器均不可见，实现了应用间的隔离。
Jsp ClassLoader：为每个JSP页面单独生成，用于支持JSP文件修改后的热部署（热加载）。

Tomcat通过线程上下文类加载器（Thread Context ClassLoader）来巧妙解决某些场景下的类加载委派问题，例如在Bootstrap的init方法中：

Thread.currentThread().setContextClassLoader(catalinaLoader);

(5) WebApp类加载器在哪创建？

你可能注意到，上述启动流程中似乎没有出现WebAppClassLoader。这是因为它是每个Web应用（Context）私有的，并非在服务器启动时统一创建。在Tomcat中，Context的默认实现是StandardContext，在其startInternal()生命周期方法中，我们找到了创建WebappLoader的代码：

protected synchronized void startInternal() throws LifecycleException {
    if (getLoader() == null) {
        WebappLoader webappLoader = new WebappLoader(getParentClassLoader());
        webappLoader.setDelegate(getDelegate());
        setLoader(webappLoader);
    }
}

在setLoader方法中，最终会调用((Lifecycle) loader).start()来启动这个WebappLoader，进而创建其内部的WebAppClassLoader。

4. 启动过程：Catalina的加载

(1) Catalina的引入

前面我们知道了Bootstrap通过catalinaClassLoader加载了Catalina类。那么，Catalina具体是如何加载并初始化整个服务器的呢？先回顾一下整体流程：

Bootstrap的load方法通过反射调用了Catalina实例的load方法，将控制权移交。

(2) Catalina的加载

Catalina的load(String[])方法处理命令行参数后，会调用无参的load()方法。这个方法的核心任务是初始化Server实例：

public void load() {
    if (loaded) return;
    loaded = true;
    initDirs(); // 已弃用
    initNaming(); // 初始化JNDI命名服务
    parseServerXml(true); // 解析server.xml配置文件
    Server s = getServer();
    getServer().setCatalina(this);
    // ... 其他设置
    getServer().init(); // 初始化Server及其所有子组件
}

总体流程如下图所示：

initDirs(): 该方法已标记为弃用，预计在Tomcat 10及以后版本中移除。
initNaming(): 设置JNDI（Java命名和目录接口）相关的系统属性，为可能的JNDI资源访问做准备。

(3) Server.xml的解析

解析过程主要分为三步：定位配置文件（conf/server.xml）、使用SAXParser解析XML、根据解析结果创建并组装对应的组件对象（如Server、Service、Connector、Engine、Host等），形成完整的组件树。

(4) Catalina的启动

在load()方法完成组件的初始化后，start()方法负责启动整个服务：

public void start() {
    if (getServer() == null) load();
    getServer().start(); // 核心启动逻辑，触发整个组件树的生命周期启动
    // 注册JVM关闭钩子，用于优雅关闭
    if (useShutdownHook) {
        shutdownHook = new CatalinaShutdownHook();
        Runtime.getRuntime().addShutdownHook(shutdownHook);
    }
    if (await) { // 如果设置了await标志，主线程将等待关闭命令
        await();
        stop();
    }
}

核心就是调用Server.start()方法，这会触发从Server到最底层Wrapper的整个组件树的生命周期启动过程。之后，主线程会根据await标志决定是否阻塞，等待控制台输入关闭命令（如执行SHUTDOWN）。

(5) Catalina的关闭

关闭逻辑封装在CatalinaShutdownHook（一个线程）中，当JVM因接收到中断信号或System.exit()而正常关闭时，这个钩子线程会运行，调用Catalina.this.stop()，进而调用Server.stop()和Server.destroy()来按生命周期顺序优雅停止Tomcat的所有组件。

(6) 聊聊关闭钩子

JVM的关闭钩子（Shutdown Hook）是通过Runtime.addShutdownHook注册的线程，用于在JVM正常关闭（非强制kill -9）时执行必要的清理工作（如删除临时文件、关闭网络连接、释放数据库连接池等）。Tomcat利用此机制确保服务能平滑、安全地停止。

需要注意的是，关闭钩子应设计为线程安全且尽快完成，避免依赖可能已被其他钩子关闭的服务（如日志服务）。一个最佳实践是使用单个关闭钩子来串行执行所有关闭操作，避免竞争条件。

(7) 使用场景示例

一个典型的应用是临时文件清理：

Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
    public void run() {
        System.out.println("auto clean temporary file");
    }
}));

(8) 小结

Catalina类作为Bootstrap启动类和核心服务器组件之间的桥梁，承接了初始化和启动的调用。它根据配置文件解析server.xml，初始化整个Server及其子组件，并通过统一的生命周期管理机制有序地启动它们，最终构建出完整、可用的Tomcat服务实例。理解这个过程，对于掌握Tomcat内部原理、进行性能调优和故障排查至关重要。

来源:https://www.51cto.com/article/842469.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：蔚来河西走廊换电路线5月10日贯通全程1739公里设20座换电站下一篇：迪士尼2026财年Q2净利润22.47亿美元同比下滑31.39%