Tomcat Service 服务原理

1. TomcatService 概述

在 Tomcat 的整体架构中，Service 是承上启下的调度者。它一方面要对接多个 Connector（负责协议通信，如 HTTP、AJP）；另一方面又要绑定一个 Engine（负责请求的具体处理逻辑）。如果把 Tomcat 比作一支军队，那么：

• Server 就是总司令部（统筹整个 JVM 内的所有服务）。

• Service 就是战区总指挥（调度协调该 Service 下所有兵力）。

• Connector 就像前线的“哨兵与传令兵”，负责接收外部消息（网络请求）。

• Engine 就是作战部队，负责执行具体的战术（Servlet 执行、Web 应用调度）。

也就是说，Service 的职责是把 Connector 和 Engine 绑在一起，形成一个有机整体。

---

1.1 Service 在 Tomcat 架构中的地位

在 Tomcat 架构分层中：

1. Server：最顶层容器，管理一个或多个 Service。

2. Service：中间层，负责 连接器（Connector） 与 容器（Engine） 的协作。

3. Connector：负责网络通信，解析请求并转交给容器。

4. Engine：顶层容器，内部包含 Host → Context → Wrapper 层级，最终找到并调用 Servlet。

👉 因此，Service 的定位就是：

• 把一个或多个 Connector 和一个 Engine“绑定”起来，形成一个完整的“请求处理流水线”。

---

1.2 Service 的核心职责与作用

我们可以用三个关键字来概括 Service 的功能：

1. 协调：

   • 协调多个 Connector，将请求统一交给唯一的 Engine 处理。

   • 协调线程池（Executor），实现高效的任务调度。

2. 桥梁：

   • Service 就像一个“桥梁”，把“通信端点（Connector）”和“处理逻辑（Engine）”对接起来。

   • 没有 Service，Connector 就不知道该把请求交给哪个 Engine。

3. 管理：

   • Service 还承担 生命周期管理：它需要启动/停止所有关联的 Connector 和 Engine。

   • 作为 Server 的子组件，Service 接口也扩展了 Tomcat 的 Lifecycle。

---

1.3 Service 与 Server、Engine、Connector 的协作关系

我们通过一个“数据流”的视角来看 Service 的协作：

1. 客户端请求进入 Connector（例如 HTTP/1.1 Connector）。

2. Connector 解析请求（协议解码、Socket 处理），并交给 Service。

3. Service 将请求分派给 Engine，Engine 再根据虚拟主机（Host）、上下文（Context）、Wrapper 层层定位。

4. Engine 执行 Servlet，产生响应。

5. Service 把响应交还 Connector，Connector 再返回给客户端。

用一句话概括：
👉 Service 是请求流转的总调度，既负责请求的进，也负责响应的出。

---

源码印象（接口定义，Tomcat 9.0.76，org.apache.catalina.Service）

public interface Service extends Lifecycle {
    // 设置和获取 Server
    public Server getServer();
    public void setServer(Server server);

    // 设置和获取 Engine
    public Engine getContainer();
    public void setContainer(Engine engine);

    // 管理 Connector
    public void addConnector(Connector connector);
    public Connector[] findConnectors();
    public void removeConnector(Connector connector);

    // 获取/设置名称
    public String getName();
    public void setName(String name);

    // Executor 管理
    public void addExecutor(Executor ex);
    public Executor[] findExecutors();
    public void removeExecutor(Executor ex);
}

在这里我们可以看到：

• Service 直接继承了 Lifecycle，说明它有 init、start、stop、destroy 等生命周期方法。

• Service 的核心操作主要是 管理 Engine 和 管理 Connector。

• 同时它还管理 Executor，这为后续的线程池优化打下基础。

---

小结（第 1 章回顾）

在这一章里，我们明确了：

1. Service 的定位：在 Tomcat 中作为 Connector 与 Engine 的桥梁，是请求调度的“总指挥官”。

2. Service 的职责：协调（Connector 与 Engine）、桥梁（请求流转）、管理（生命周期与资源）。

3. 协作关系：Server 统一管理多个 Service，每个 Service 下有多个 Connector 和一个 Engine。

2. Service 接口定义与核心方法

在第 1 章我们已经知道，Service 是 Tomcat 架构中承上启下的调度者，它一方面要管理多个 Connector，另一方面要绑定唯一的 Engine。要理解 Service 的作用，我们必须从它的 接口定义 入手，看看它暴露了哪些方法、承担了哪些职责。

---

2.1 Service 接口源码解析

下面是 Tomcat 9.0.76 中 org.apache.catalina.Service 接口的源码片段（去掉注释）：

public interface Service extends Lifecycle {

    // 管理所属的 Server
    public Server getServer();
    public void setServer(Server server);

    // 管理唯一的 Engine（容器）
    public Engine getContainer();
    public void setContainer(Engine engine);

    // 管理多个 Connector
    public void addConnector(Connector connector);
    public Connector[] findConnectors();
    public void removeConnector(Connector connector);

    // 管理线程池 Executor
    public void addExecutor(Executor ex);
    public Executor[] findExecutors();
    public void removeExecutor(Executor ex);

    // Service 名称
    public String getName();
    public void setName(String name);

    // 日志 & 配置相关
    public void setLogName(String logName);
    public String getLogName();
}

👉 可以看到，这个接口其实就像一个 资源管理总表，它主要负责三类资源：

1. 容器（Engine）

2. 连接器（Connector）

3. 线程池（Executor）

---

2.2 核心方法详解

接下来我们逐个拆解关键方法，并结合实际场景和类比来理解。

2.2.1 容器相关

public Engine getContainer();
public void setContainer(Engine engine);

• 作用：绑定一个 Engine（请求处理的核心容器）。

• 限制：每个 Service 只能绑定一个 Engine，这样才能保证 Connector 收到的请求有且仅有一个处理出口。

👉 类比：Service 就像一个机场调度中心，它可以有多个登机口（Connector），但只有一条航线指向目的地（Engine）。

---

2.2.2 连接器相关

public void addConnector(Connector connector);
public Connector[] findConnectors();
public void removeConnector(Connector connector);

• 作用：

  • addConnector：为 Service 添加一个新的协议处理器（比如 HTTP/1.1、AJP）。

  • findConnectors：查询当前所有绑定的 Connector。

  • removeConnector：移除一个 Connector。

• 实际应用场景：

  1. 在 server.xml 里配置多个 <Connector>，例如同时支持 HTTP 和 HTTPS。

  2. 在运行时动态添加/删除 Connector，实现灵活扩展。

👉 类比：Connector 就像“耳朵”，负责接收不同频道的声音，Service 则负责把这些声音统一转给大脑（Engine）。

---

2.2.3 线程池（Executor）相关

public void addExecutor(Executor ex);
public Executor[] findExecutors();
public void removeExecutor(Executor ex);

• 作用：

  • 管理 Service 级别的线程池资源。

  • 每个 Connector 可以选择使用 Service 中定义的 Executor，而不是自己创建线程池。

• 优势：

  • 资源复用：多个 Connector 可以共享一个线程池，避免重复创建资源。

  • 调优便利：统一调控线程池大小，适配不同场景下的并发压力。

👉 类比：Executor 就像一个“劳务派遣公司”，Service 可以派遣工人（线程）给不同的 Connector 使用。

---

2.2.4 名称与日志

public String getName();
public void setName(String name);

public void setLogName(String logName);
public String getLogName();

• 作用：给 Service 设置名称和日志前缀。

• 应用场景：在多实例环境下，多个 Service 可以共存，因此需要名字区分。

👉 类比：这就像“战区代号”，在大型演习时不同战区需要一个标识。

---

2.3 设计模式与接口解耦思路

1. 接口隔离：

   • Service 不直接实现 Connector 或 Engine 的功能，而是通过接口定义清晰的职责边界。

2. 组合优于继承：

   • Service 内部通过“组合”方式来管理 Connector、Engine、Executor，而不是继承它们。

   • 这种设计保证了灵活性：Connector 和 Engine 可以自由替换。

3. 模板方法模式（Lifecycle）：

   • 因为 Service 继承了 Lifecycle，所以它必须遵循 init → start → stop → destroy 的模板方法流程。

   • 具体实现由 StandardService 来完成（下一章展开）。

---

小结（第 2 章回顾）

在这一章我们重点解析了 Service 接口：

1. Service 的核心方法分三类：

   • 容器管理（setContainer/getContainer）

   • 连接器管理（addConnector/findConnectors/removeConnector）

   • 线程池管理（addExecutor/findExecutors/removeExecutor）

2. Service 的设计思想：

   • 接口解耦：让 Connector、Engine、Executor 都通过接口隔离。

   • 组合模式：Service 通过组合来管理资源，而不是继承。

   • 生命周期模板：通过继承 Lifecycle 统一管理 init/start/stop。

3. StandardService 实现类深度解析

在 Tomcat 的源码中，org.apache.catalina.core.StandardService 是 Service 接口的默认实现，也是实际运行中最常用的实现类。
理解 StandardService，就等于真正掌握了 Tomcat Service 的运行逻辑。

---

3.1 核心属性

源码位置：org.apache.catalina.core.StandardService（Tomcat 9.0.76）

protected Server server = null;              // 所属的 Server
protected Engine engine = null;              // 唯一的 Engine
protected final List<Connector> connectors = new ArrayList<>();  // 多个 Connector
protected final List<Executor> executors = new ArrayList<>();    // 线程池 Executor
protected final MapperListener mapperListener = new MapperListener(this); // Mapper 监听器
protected String name = null;                // Service 名称

• server：指向上层的 Server，表明自己归属于哪个 Server。

• engine：绑定唯一的 Engine 容器。

• connectors：存储所有该 Service 管理的 Connector。

• executors：管理 Service 下配置的线程池资源。

• mapperListener：用于监听 Engine/Host/Context 的变化，并实时更新 Mapper（请求映射表）。

• name：Service 的名称，用于区分多实例。

👉 可以看出，StandardService 的核心就是围绕 Connector + Engine + Executor + MapperListener 展开。

---

3.2 构造器与初始化原理

public StandardService() {
    super();
    setName("StandardService");
}

• 构造器逻辑很简单，只是给 Service 取了个默认名字 "StandardService"。

• 真正的初始化逻辑并不是在构造器里完成的，而是在 initInternal() 方法中完成（遵循 Lifecycle 模板方法模式）。

👉 这也是 Tomcat 的一大特色：构造器只做最小化操作，实际初始化放在 initInternal 里执行。

---

3.3 生命周期方法

3.3.1 initInternal()

源码位置：org.apache.catalina.core.StandardService

@Override
protected void initInternal() throws LifecycleException {
    super.initInternal();

    // 初始化 Executor
    for (Executor executor : executors) {
        if (executor instanceof LifecycleMBeanBase) {
            ((LifecycleMBeanBase) executor).setDomain(getDomain());
        }
        executor.init();
    }

    // 初始化 Engine
    if (engine != null) {
        engine.init();
    }

    // 初始化 Connector
    for (Connector connector : connectors) {
        connector.init();
    }
}

• 依次初始化 Executor → Engine → Connector。

• 顺序很重要：先准备线程池，再准备容器，最后准备通信通道。

• 每一步都遵循 Lifecycle 的 init 模板方法。

👉 类比：像一场演出，先准备工作人员（Executor），再搭建舞台（Engine），最后开门迎客（Connector）。

---

3.3.2 startInternal()

@Override
protected void startInternal() throws LifecycleException {
    super.startInternal();

    // 启动所有 Executor
    for (Executor executor : executors) {
        executor.start();
    }

    // 启动 Engine
    if (engine != null) {
        engine.start();
    }

    // 启动 MapperListener，负责请求映射的动态更新
    mapperListener.start();

    // 启动所有 Connector
    synchronized (connectors) {
        for (Connector connector : connectors) {
            connector.start();
        }
    }
}

• 启动顺序：Executor → Engine → MapperListener → Connector。

• 注意这里：mapperListener.start() 在 Connector 之前启动，保证 Connector 收到请求时，Mapper 已经准备好路径映射。

👉 类比：演出开始前，先让工作人员就位（Executor）、舞台准备好（Engine）、节目单确定（MapperListener），最后开门放观众进来（Connector）。

---

3.3.3 stopInternal()

@Override
protected void startInternal() throws LifecycleException {
    super.startInternal();

    // 启动所有 Executor
    for (Executor executor : executors) {
        executor.start();
    }

    // 启动 Engine
    if (engine != null) {
        engine.start();
    }

    // 启动 MapperListener，负责请求映射的动态更新
    mapperListener.start();

    // 启动所有 Connector
    synchronized (connectors) {
        for (Connector connector : connectors) {
            connector.start();
        }
    }
}

• 停止顺序：Connector → MapperListener → Engine → Executor。

• 这是 startInternal() 的逆序，保证先关闭对外服务，再逐步释放内部资源。

👉 类比：演出结束后，先封场（Connector）、撤节目单（MapperListener）、收舞台（Engine）、最后遣散工作人员（Executor）。

---

3.4 Executors、Connectors 与 Engine 的协作

1. Executor

   • 为 Connector 提供线程池。

   • 多个 Connector 可以共享一个 Executor，实现资源复用。

2. Connector

   • 监听端口（如 8080、8443），接收请求后交给 Service。

   • Service 把请求交给 Engine 处理。

3. Engine

   • 真正的请求处理核心，内部还有 Host/Context/Wrapper 分层。

   • Engine 的生命周期由 Service 驱动。

👉 总结：

• Executor 是幕后工作组（线程池），

• Connector 是前台服务台（请求入口），

• Engine 是后台执行团队（请求处理），

• Service 是调度总指挥。

---

3.4 事件机制与监听器

Tomcat 的 StandardService 内部支持 事件通知机制，用于在 Service 生命周期变化时向外部广播。

• 核心字段

  protected final PropertyChangeSupport support = new PropertyChangeSupport(this);
  

  PropertyChangeSupport 是 JDK 提供的事件广播工具，允许监听器订阅属性变更。

• 关键方法

  public void addPropertyChangeListener(PropertyChangeListener listener) {
      support.addPropertyChangeListener(listener);
  }
  
  public void removePropertyChangeListener(PropertyChangeListener listener) {
      support.removePropertyChangeListener(listener);
  }
  
  protected void firePropertyChange(String property, Object oldValue, Object newValue) {
      support.firePropertyChange(property, oldValue, newValue);
  }
  

👉 这套机制的典型应用：

• 当 Connector 添加/移除时，StandardService 会触发属性变更事件，通知管理工具（如 JMX）进行同步。

• 这为 外部监控和动态配置 提供了扩展点。

---

3.5 线程安全与并发控制

在 Tomcat 的运行过程中，Connector 的注册/注销、生命周期切换，可能由不同线程并发调用。

• 设计思路

  1. 最小化共享状态：StandardService 仅维护 connectors、container 等少数关键字段。

  2. 同步操作：

     public void addConnector(Connector connector) {
         synchronized(connectors) {
             connectors.add(connector);
         }
     }
     

     确保多线程环境下 connectors 的一致性。

  3. 生命周期方法串行化：
     LifecycleBase 内部通过 state 字段控制状态切换，避免多线程同时 start() / stop() 引发冲突。

👉 这样保证了 Service 在高并发场景下的稳定性。

---

3.6 与外部组件的交互

StandardService 是 Tomcat 架构中的 桥梁角色，它通过以下几种方式与外部组件交互：

1. 与 Server

   • 通过 setServer(Server server) 与顶层 StandardServer 建立父子关系。

   • 生命周期由 Server 驱动，Server 启动时依次启动 Service。

2. 与 Container

   • 通过 setContainer(Container container) 设置顶层容器（通常是 Engine）。

   • 每个请求处理流程：

     Connector 接收请求 → 交给 ProtocolHandler → 通过 Mapper 映射到 Container → Engine/Host/Context/Wrapper 执行业务逻辑
     

3. 与 Connector

   • addConnector(Connector c) 时，Service 会调用：

     c.setService(this);
     

     确保 Connector 反向持有 Service 引用，用于回调请求到容器。

4. 与 JMX / 监控

   • StandardService 会通过事件机制 + JMX MBean，将 Service 的运行状态暴露给外部管理工具。

第 4 章：Mapper 与 MapperListener 协作机制

4.1 Mapper 的定位与作用

在 Tomcat 中，Mapper 的职责是完成 请求 URI 到 Servlet 的映射。它处于 Connector → CoyoteAdapter → Mapper → Container 的关键链路中，主要功能包括：

• 根据 Host（虚拟主机）、Context（Web 应用）、Wrapper（Servlet） 的层次结构，维护映射关系；

• 在请求到来时，快速查找对应的 Servlet；

• 支持 动态增删 映射（例如热部署应用、Servlet 动态注册等）。

形象理解：Mapper 就像一本“路由字典”，把域名、路径、Servlet 名称等信息组织起来，保证 Tomcat 能迅速找到要执行的 Servlet。

---

4.2 Mapper 内部数据结构

Mapper 内部维护了多层 Map 结构，用于高效查找：

1. hostMap

   • key：虚拟主机名（如 localhost, www.example.com）

   • value：Mapper.Host 对象，包含该 Host 下的所有 Context

2. contextMap

   • key：Context 路径（如 /, /app1, /myweb）

   • value：Mapper.Context 对象，包含该应用的所有 Servlet 映射

3. wrapperMap

   • key：URL Pattern（如 /hello, /api/*, *.jsp）

   • value：Mapper.Wrapper 对象，指向具体的 Servlet

层级关系示意图：

hostMap
 └── "localhost" → ContextMap
       ├── "/"        → DefaultServlet
       ├── "/examples" → WrapperMap
       │       ├── "/hello"  → HelloServlet
       │       └── "/user/*" → UserServlet
       └── "/docs"     → ...

这种 三层映射表 保证了查找效率，同时清晰地反映了 Tomcat Container 的层次结构。

---

4.3 MapperListener 的监听机制与动态更新流程

Mapper 本身并不主动感知容器变化，它只是存储映射关系。
MapperListener 的作用是 监听容器事件，并实时更新 Mapper。

• MapperListener 监听的事件包括：

  • Host 添加 / 移除；

  • Context 启动 / 停止；

  • Wrapper（Servlet）添加 / 删除；

  • Context 中的 Filter/Servlet 映射变化。

• 动态更新流程：

  1. 应用启动时，MapperListener 监听到 Context 初始化；

  2. 从 Context 中提取 Servlet 映射信息（url-pattern）；

  3. 调用 mapper.addWrapper(...) 更新映射表；

  4. 之后的请求就能直接被 Mapper 命中。

这样，Tomcat 在运行时也能保持 映射关系与容器结构的一致性，支持动态部署和卸载。

---

4.4 请求路径映射的执行流程（findMapping 等）

当请求到来时，Tomcat 通过 Mapper 的 findMapping 方法完成查找，流程如下：

1. 确定 Host

   • 从请求头中的 Host 字段提取主机名；

   • 在 hostMap 中查找匹配的 Host；

   • 如果找不到，则使用默认 Host。

2. 匹配 Context

   • 从 URI 中提取 Context 路径（如 /app1/user/login → /app1）；

   • 在对应 Host 的 contextMap 中查找最长匹配的 Context。

3. 匹配 Wrapper

   • 去掉 Context 前缀后，获取剩余路径（如 /user/login）；

   • 按以下优先级查找 Wrapper：

     • 精确匹配（/user/login）

     • 路径匹配（/user/*）

     • 后缀匹配（*.jsp）

     • 默认 Servlet（/）

4. 返回 MappingData

   • 最终封装成 MappingData，包含 Host、Context、Wrapper 信息；

   • 交由容器执行对应的 Servlet。

流程示意图：

Request URI → [解析Host] → hostMap
                   ↓
               [匹配Context] → contextMap
                   ↓
               [匹配Wrapper] → wrapperMap
                   ↓
           找到目标Servlet（执行）

第 5 章：生命周期管理

Tomcat 作为一个容器型服务器，核心组件均实现了 统一的生命周期接口（Lifecycle），从而确保 Server → Service → Connector/Container 之间能够以一致的模式完成初始化、启动、关闭和销毁操作。本章将重点剖析 Service 组件的生命周期管理，并结合源码，展示模板方法模式与异常处理机制在其中的应用。

---

5.1 Tomcat 生命周期接口回顾

Tomcat 所有主要组件（如 Server、Service、Connector、Engine、Host、Context）都实现了 org.apache.catalina.Lifecycle 接口。该接口定义了四个基本阶段：

• init()：完成组件的初始化工作（如资源加载、内部数据结构创建）。

• start()：启动对外服务（如启动线程、监听端口、加载 WebApp）。

• stop()：停止服务，但保留部分资源，便于重启。

• destroy()：彻底释放资源，组件进入不可复用状态。

同时，Lifecycle 定义了 状态枚举（LifecycleState），如 NEW、INITIALIZED、STARTING、STARTED、STOPPING、DESTROYED，确保生命周期具有可控性和可追踪性。

👉 小结：Service 生命周期的执行，是 Tomcat 生命周期框架的一个缩影。

---

5.2 Service 的 init → start → stop → destroy 流程

StandardService 继承了 LifecycleBase，通过模板方法完成统一的生命周期调度。其主要流程如下：

（1）init 阶段

• 初始化 Executor（线程池）。

• 初始化所有子组件：Engine、MapperListener、Connector。

• 建立 Mapper 与 Container 的映射关系。

  @Override
  protected void initInternal() throws LifecycleException {
      super.initInternal();
      if (engine != null) {
          engine.init();
      }
      for (Connector connector : connectors) {
          connector.init();
      }
  }
  

（2）start 阶段

• 启动 Engine（容器开始接受请求）。

• 启动 MapperListener（监听容器变化，更新映射规则）。

• 启动 Connector（绑定端口，监听网络请求）。

  @Override
  protected void startInternal() throws LifecycleException {
      if (engine != null) {
          engine.start();
      }
      mapperListener.start();
      for (Connector connector : connectors) {
          connector.start();
      }
  }
  

（3）stop 阶段

• 先关闭 Connector，避免新的请求进入。

• 停止 MapperListener，冻结映射规则。

• 停止 Engine，等待正在处理的请求完成。

  @Override
  protected void stopInternal() throws LifecycleException {
      for (Connector connector : connectors) {
          connector.stop();
      }
      if (mapperListener != null) {
          mapperListener.stop();
      }
      if (engine != null) {
          engine.stop();
      }
  }
  

（4）destroy 阶段

• 清理子组件（Engine、Connector）。

• 释放线程池资源。

• 彻底标记 Service 为不可用。

---

5.3 模板方法模式在生命周期中的应用

LifecycleBase 是 Tomcat 生命周期框架的核心，它通过 模板方法模式 统一管理 init/start/stop/destroy 四个阶段：

public final synchronized void start() throws LifecycleException {
    if (state == LifecycleState.NEW) {
        init();
    }
    startInternal(); // 子类实现
    setState(LifecycleState.STARTED);
}

特点：

• 父类 LifecycleBase：定义生命周期公共逻辑（状态管理、异常捕获、事件触发）。

• 子类 StandardService：仅需关注自身业务逻辑（engine.start()、connector.start() 等）。

• 解耦：保证了所有组件生命周期的一致性，而不需要每个类都重复编写状态管理代码。

👉 小结：LifecycleBase = 模板方法骨架，StandardService = 具体实现。

---

5.4 生命周期与异常处理机制

Tomcat 的生命周期管理高度强调 异常可控性：

• 若 init() 或 start() 失败，会触发 LifecycleException，并阻止继续启动。

• 如果某个子组件异常，Service 会记录日志并尽量保证其它子组件可用（例如某个 Connector 失败，但 Engine 仍能启动）。

• 在 stop() 与 destroy() 阶段，异常不会阻断整个流程，而是逐步清理。

例如：

try {
    connector.start();
} catch (Exception e) {
    log.error("Failed to start connector", e);
}

这种机制保证了 健壮性：

• 启动阶段 → 严格一致性，失败即中断。

• 关闭阶段 → 尽量清理，避免资源泄露。

第六章 源码解析与设计模式剖析

6.1 StandardService 中的模板方法模式

在 Service 的生命周期管理中（init → start → stop → destroy），StandardService 并没有完全自己实现所有逻辑，而是依赖父类 LifecycleBase 提供的 模板方法。

• 父类 LifecycleBase 提供公共的流程控制：

  public final synchronized void start() throws LifecycleException {
      if (state == LifecycleState.NEW) {
          init();
      }
      startInternal();   // 模板方法：子类实现
  }
  

• 子类 StandardService 实现了核心的挂钩（hook method）：

  @Override
  protected void startInternal() throws LifecycleException {
      // 1. 启动所有 Connector
      for (Connector connector : connectors) {
          connector.start();
      }
      // 2. 启动 Engine
      if (engine != null) {
          engine.start();
      }
      setState(LifecycleState.STARTING);
  }
  

➡️ 模式总结：父类固定骨架流程，子类只负责实现具体步骤。这是典型的 模板方法模式。

---

6.2 Mapper 中的责任链与高效查找机制

Mapper 负责根据请求 URI，逐步找到 Host → Context → Wrapper。

请求查找链路（责任链模式的影子）：

1. 先从 hostMap 查找匹配的虚拟主机；

2. 再进入该 Host 的 contextMap，匹配应用上下文；

3. 最后进入 wrapperMap，定位具体 Servlet。

核心代码：

public void map(MessageBytes uri, MappingData mappingData) {
    // 1. 查找 Host
    Host host = hostMap.getHost(serverName);
    // 2. 查找 Context
    Context context = host.findContext(uri);
    // 3. 查找 Wrapper
    Wrapper wrapper = context.map(uri);
}

➡️ 这相当于一个 逐级传递的责任链：请求先给 Host 处理，不行再给 Context，最后由 Wrapper 完成。

高效查找机制

• hostMap 使用 HashMap 存储虚拟主机；

• contextMap 使用 TreeMap（基于前缀匹配） 处理 /app/* 路径；

• wrapperMap 支持 精确匹配、前缀匹配、扩展名匹配 三类规则。

---

6.3 Service 与 Engine 的桥接模式类比

Service 负责统一管理多个 Connector，并通过一个 Engine 处理所有请求。

• 桥接模式类比：

  • Abstraction（抽象层）：Service（对外提供统一接口，隐藏底层复杂性）。

  • Implementor（实现层）：Engine（具体实现请求分发与容器管理）。

这样，Service 屏蔽了 Engine 的复杂性，让上层用户只需要面对 Service，就能驱动 Tomcat 的全部请求处理能力。

➡️ 可以理解为：Service 是桥梁，Engine 是执行者。

---

6.4 源码精华片段逐行讲解

例子：StandardService.addConnector()

@Override
public void addConnector(Connector connector) {
    synchronized (connectorsLock) {
        // 1. 保存 Connector
        Connector[] results = Arrays.copyOf(connectors, connectors.length + 1);
        results[connectors.length] = connector;
        connectors = results;

        // 2. 设置容器绑定
        connector.setService(this);

        // 3. 如果 Service 已经启动，则直接启动该 Connector
        if (getState().isAvailable()) {
            try {
                connector.start();
            } catch (LifecycleException e) {
                log.error("Connector.start", e);
            }
        }
    }
}

🔎 逐行解读：

1. 扩容数组：用 Arrays.copyOf 动态增加 connector 数组。

2. 反向绑定关系：connector.setService(this)，形成 Service → Connector 的双向依赖。

3. 懒加载特性：如果 Service 已经启动，直接启动新加的 Connector（支持运行时热加 Connector）。

➡️ 设计亮点：

• 线程安全（synchronized）；

• 运行时扩展性（Connector 可动态添加）；

• 生命周期解耦（交由模板方法管理）。

第七章 实践案例与应用场景

7.1 配置多个 Connector（HTTP + HTTPS）

Tomcat 的一个典型应用场景是同时支持 HTTP 和 HTTPS。
通过在 server.xml 中为同一个 Service 配置多个 Connector，就能让请求分别通过不同协议进入同一个 Engine：

<Service name="Catalina">
    <!-- HTTP Connector -->
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

    <!-- HTTPS Connector -->
    <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               SSLEnabled="true">
        <SSLHostConfig>
            <Certificate certificateKeystoreFile="conf/keystore.jks"
                         type="RSA" />
        </SSLHostConfig>
    </Connector>

    <Engine name="Catalina" defaultHost="localhost">
        <Host name="localhost"  appBase="webapps" />
    </Engine>
</Service>

运行效果

• http://localhost:8080/app → 明文请求

• https://localhost:8443/app → TLS 加密请求

• 两者最终都会进入同一个 Engine，依靠 Mapper 进行 Host/Context 映射。

👉 关键点：Service 作为桥梁，将多个协议的 Connector 聚合到同一个 Engine。

---

7.2 自定义 Service 实现（继承 StandardService）

有些高级应用场景下，我们可能需要扩展 Service 的行为。例如：

• 在 Service.start() 时做一些额外的监控注册

• 在 Service.stop() 时释放额外的资源

可通过继承 StandardService 来实现：

public class CustomService extends StandardService {

    @Override
    protected void startInternal() throws LifecycleException {
        super.startInternal();
        System.out.println("[CustomService] Service 启动后，注册监控...");
        // 注册额外的监控、日志收集
    }

    @Override
    protected void stopInternal() throws LifecycleException {
        System.out.println("[CustomService] Service 停止前，清理资源...");
        // 清理资源
        super.stopInternal();
    }
}

配置时只需替换 server.xml 中的 <Service> 实现类：

<Service name="CustomCatalina" className="com.example.CustomService">
    <Connector port="8080" protocol="HTTP/1.1" />
    <Engine name="CustomEngine" defaultHost="localhost" />
</Service>

这样，我们就能在不修改 Tomcat 内核的情况下，增强 Service 行为。

---

7.3 多实例部署下的 Service 管理

在企业场景中，有时会在同一 JVM 中部署多个独立的 Web 容器实例。
例如：一个 Tomcat 里跑 两个 Service，每个 Service 有独立的 Connector + Engine：

<Server port="8005" shutdown="SHUTDOWN">
    <!-- Service A -->
    <Service name="ServiceA">
        <Connector port="8080" />
        <Engine name="EngineA" defaultHost="localhost">
            <Host name="localhost" appBase="appsA" />
        </Engine>
    </Service>

    <!-- Service B -->
    <Service name="ServiceB">
        <Connector port="9090" />
        <Engine name="EngineB" defaultHost="127.0.0.1">
            <Host name="127.0.0.1" appBase="appsB" />
        </Engine>
    </Service>
</Server>

效果：

• http://localhost:8080/app1 → 部署在 ServiceA → EngineA

• http://127.0.0.1:9090/app2 → 部署在 ServiceB → EngineB

👉 应用场景：多租户、隔离部署、灰度测试。

---

7.4 动态配置与运行时扩展

在某些 SaaS 平台中，用户可能需要 运行时动态添加应用 或 修改 Connector，而无需重启 Tomcat。
Tomcat 提供了 Service 和 Engine 的动态扩展能力：

// 获取 Server
Server server = Tomcat.getServer();

// 获取 Service
Service service = server.findService("Catalina");

// 动态新增 Connector
Connector newConnector = new Connector("org.apache.coyote.http11.Http11NioProtocol");
newConnector.setPort(8181);
service.addConnector(newConnector);

// 动态新增 Host
Engine engine = (Engine) service.getContainer();
Host newHost = new StandardHost();
newHost.setName("dynamic.local");
newHost.setAppBase("dynamicApps");
engine.addChild(newHost);

此时，Tomcat 无需重启，即可监听新端口、挂载新 Host，做到真正的运行时扩展。

👉 典型应用：

• 动态添加租户（新增 Host）

• 动态扩展端口（新增 Connector）

• SaaS 平台的应用热部署

第八章 性能优化与调优建议

8.1 Mapper 查找性能优化思路

Mapper 是请求路由的核心组件，它决定了一个请求 URI 能否在最短时间内匹配到对应的 Wrapper（Servlet）。在高并发场景下，查找性能至关重要。优化思路如下：

1. 哈希结构优化

   • Tomcat 内部通过 ConcurrentHashMap 保存 hostMap、contextMap、wrapperMap。

   • 开发者可在自定义 Mapper 实现中使用 前缀树（Trie） 或 Radix Tree 优化长路径的匹配性能。

2. 路径规范化

   • 对请求路径进行预处理（小写化、去除多余 /）可减少重复计算，提升匹配效率。

   • 尤其是在 findMapping() 方法执行前，可通过缓存路径归一化结果。

3. 热路径缓存

   • Tomcat 内部支持 请求到 Wrapper 的缓存。如果大量请求集中在少数 Servlet 上，可利用缓存显著降低查找成本。

   • 可结合 LRU 缓存策略，避免内存无限膨胀。

---

8.2 线程池（Executor）与 Service 的调优

Service 下的 Connector 与线程池绑定，线程池配置直接决定了请求吞吐量与响应延迟。

1. 核心参数

   • maxThreads: 并发线程数上限。

   • minSpareThreads: 启动时的预热线程数。

   • acceptCount: 当线程池已满时，Socket 等待队列的长度。

   • maxConnections: 控制单个 Connector 最大连接数。

   调优思路：

   • CPU 密集型任务：maxThreads ≈ CPU核心数 * 2

   • I/O 密集型任务：maxThreads 可以设置为核心数的数倍，但要配合合理的 acceptCount。

2. Executor 共享机制

   • 多个 Connector 可复用同一个 Executor，避免线程池过多带来的上下文切换开销。

   • 在 HTTP + HTTPS 双协议场景下，推荐共用线程池。

3. 动态调整

   • 可通过 JMX 或 tomcat-juli 日志监控线程池状态，发现饱和情况时动态扩容。

   • 实践中建议设置 maxThreads 稍大于 95% 峰值，避免线程频繁创建销毁。

---

8.3 高并发场景下的 Service 配置建议

当部署场景面临高并发请求时，可以从以下几个层面优化 Service：

1. Connector 层优化

   • 使用 NIO 或 APR（基于本地库的异步 IO）替代传统 BIO，减少线程阻塞。

   • 在 server.xml 中启用 asyncTimeout，支持 Servlet 3.0 异步处理，提升并发吞吐。

2. Service 与 Engine 的解耦

   • 一个 Service 可挂载多个 Connector，但尽量减少跨 Service 的 Engine 共享，避免锁竞争。

   • 推荐“一个 Service 对应一个 Engine”的模式，保证独立性。

3. 负载均衡与多实例

   • 在高并发场景下，单个 Service 即使优化到极限，也可能成为瓶颈。

   • 可采用多实例 Tomcat + Nginx 负载均衡方案，进一步分摊压力。

   • 配合 Sticky Session 或 Session 共享（如 Redis Session Manager），保证用户体验。

4. 监控与调优闭环

   • 使用 JVisualVM、Prometheus + Grafana 对线程池、GC、QPS 进行实时监控。

   • 根据监控数据反向调整 maxThreads、maxConnections 等参数。

   • 建立压测 + 调优 + 验证的闭环流程，而非静态配置。