深入拆解 Jetty & Tomcat：Connector 架构差异与设计精髓

系列文章目录

第一章 HTTP协议必知必会详解
第二章 一文读懂 Servlet 规范与 Servlet 容器加粗样式
第三章 深入拆解 Servlet 实战：纯手工打造与运行
第四章 深入拆解 Tomcat 系统架构：连接器如何设计
第五章 深入拆解Tomcat架构：多层容器设计原理
第六章 深入拆解 Tomcat 架构：一键启停与生命周期设计
第七章 深入拆解 Tomcat 架构：高层组件与启动流程设计

文章目录

• 系列文章目录
• 前言
• 一、思维导图
• [二、Jetty 整体定位与架构概览](#二、Jetty 整体定位与架构概览)
• [三、Java NIO 核心基础回顾](#三、Java NIO 核心基础回顾)
• [四、Jetty Connector 三大核心组件](#四、Jetty Connector 三大核心组件)
• • [4.1 Acceptor](#4.1 Acceptor)
  • [4.2 SelectorManager](#4.2 SelectorManager)
  • [4.3 Connection + EndPoint](#4.3 Connection + EndPoint)
• [五、Connector 完整工作流程](#五、Connector 完整工作流程)
• • [5.1 连接监听：](#5.1 连接监听：)
  • [5.2 事件注册：](#5.2 事件注册：)
  • [5.3 事件检测：](#5.3 事件检测：)
  • [5.4 请求处理：](#5.4 请求处理：)
  • [5.5 响应返回：](#5.5 响应返回：)
• [六、Jetty Connector 核心设计特点](#六、Jetty Connector 核心设计特点)
• • [6.1 纯 NIO 模型设计：](#6.1 纯 NIO 模型设计：)
  • [6.2 全局线程池共享：](#6.2 全局线程池共享：)
  • [6.3 回调模拟异步 I/O：](#6.3 回调模拟异步 I/O：)
  • [6.4 高度可定制化：](#6.4 高度可定制化：)
• 七、常见问题

---

前言

本文对比Tomcat与Jetty两款 Servlet 容器的架构差异，核心讲解Jetty 整体架构由多 Connector 连接器、多 Handler 处理器、全局共享线程池三大核心组件构成，重点拆解 JettyConnector 组件的设计实现，其基于 Java NIO 模型，通过Acceptor监听连接、SelectorManager管理 I/O 事件、Connection完成协议解析与请求处理，同时明确 Jetty仅支持 NIO 模型、全局线程池资源共享、回调函数模拟异步 I/O三大核心设计特点。

---

一、思维导图

二、Jetty 整体定位与架构概览

• 核心定位：Jetty 是 Eclipse 基金会开源项目，与 Tomcat 一致，是HTTP 服务器 + Servlet 容器，核心特点是小巧轻量、高度可定制化，被 Google App Engine 等场景广泛采用。
• 核心架构组成 ：Jetty Server 由三大核心组件构成，由 Server 类统一管理启动与初始化：
  • Connector：负责对外网络通信，封装 I/O 模型与应用层协议，可配置多个 Connector 监听不同端口。
  • Handler：负责内部请求处理，对应 Tomcat 的 Container 容器，可按需选配（如 ServletHandler、SessionHandler），实现功能裁剪。
  • ThreadPool：全局共享线程池，Connector 与 Handler 的所有线程资源均从该线程池获取。
• Jetty 与 Tomcat 的核心架构差异

对比维度	Jetty	Tomcat
顶层架构	无 Service 概念，Connector 被所有 Handler 共享	用 Service 封装多连接器 + 单容器，支持多 Service 配置
线程池设计	所有 Connector 共享一个全局线程池	每个 Connector 拥有独立的线程池
I/O 模型支持	Jetty9 版本仅支持 NIO	支持 NIO、NIO2、APR 三种 I/O 模型
功能定制	可通过 Handler 选配实现功能裁剪，轻量化程度高	容器层级固定，定制化复杂度更高

三、Java NIO 核心基础回顾

Jetty 的 Connector 设计完全基于 Java NIO 实现，NIO 三大核心组件如下：

• Channel：对应一个 Socket 连接，负责数据的读写，不可直接操作数据，需通过 Buffer 中转。
• Buffer：数据读写的中转缓冲区。
• Selector ：可同时监听多个 Channel 的 I/O 事件（连接就绪、读就绪、写就绪），单线程即可管理大量连接，大幅降低线程上下文切换开销。
  服务端 NIO 编程核心流程：创建 ServerSocketChannel 并绑定端口 → 创建 Selector 并注册连接事件 → 循环查询 I/O 事件 → 根据事件类型执行对应操作。

四、Jetty Connector 三大核心组件

Connector 的核心职责是封装 I/O 模型与应用层协议，对应 NIO 通信的三大核心动作（监听连接、I/O 事件查询、数据读写），Jetty 设计了三个核心组件分别实现。

4.1 Acceptor

• 核心职责：阻塞方式监听并接受客户端 TCP 连接请求，与 Tomcat 的 Acceptor 设计一致。
• 实现细节：
  • 是 ServerConnector 的内部类，实现 Runnable 接口，由全局线程池启动执行。
  • 支持配置 Acceptor 线程数量，启动时根据配置创建对应个数的 Acceptor 线程，共享同一个 ServerSocketChannel。
  • 接受连接成功后，将 SocketChannel 设置为非阻塞模式，交给 SelectorManager 处理。

4.2 SelectorManager

• 核心职责：管理 Selector 实例，处理 Channel 的 I/O 事件注册与查询，是 Jetty 对 Java NIO 原生 Selector 的封装。
• 实现细节：
  • 内部维护ManagedSelector 数组，真正执行 I/O 事件处理的是 ManagedSelector。
  • 接收到 Channel 后，通过轮询策略选择一个 ManagedSelector，提交 Accept 任务。
  • ManagedSelector 完成两个核心动作：①将 Channel 注册到 Selector 上；②创建 EndPoint 和 Connection，与 Channel、SelectionKey 完成绑定。

4.3 Connection + EndPoint

• EndPoint：与 Channel 一一绑定，负责数据的实际读写，是对传输层的抽象。
• Connection：对应 Tomcat 的 Processor 组件，负责应用层协议解析，核心实现类为 HttpConnection。
  • 请求处理：向 EndPoint 注册读回调函数，数据就绪时触发回调，读取并解析字节流生成 Request 对象。
  • 响应处理：Handler 业务处理完成后，通过 Response 写入数据，再由 EndPoint 将数据写回 Channel。

五、Connector 完整工作流程

5.1 连接监听：

Acceptor 线程阻塞监听端口，接收到新的 TCP 连接后，生成 SocketChannel 并交给 SelectorManager。

5.2 事件注册：

SelectorManager 选择 ManagedSelector，将 Channel 注册到 Selector，同时创建并绑定 EndPoint 与 Connection。

5.3 事件检测：

ManagedSelector 持续循环检测 I/O 事件，当读事件就绪时，从 EndPoint 获取 Runnable 任务，提交至全局线程池。

5.4 请求处理：

线程池执行 Runnable，触发 Connection 注册的回调函数，读取并解析数据生成 Request 对象，交给 Handler 组件处理。

5.5 响应返回：

Handler 处理完成后，通过 Response 写入响应数据，由 EndPoint 将数据写回 Channel，完成一次请求响应。

六、Jetty Connector 核心设计特点

6.1 纯 NIO 模型设计：

Jetty9 仅支持 NIO 模型，代码更精简，内存占用更低，贴合 Java NIO 的编程模型。

6.2 全局线程池共享：

所有 Connector 与 Handler 共用一个全局线程池，便于统一控制线程总数，减少线程上下文切换开销。

6.3 回调模拟异步 I/O：

通过向 EndPoint 注册回调函数的方式，在应用层模拟异步 I/O 模型，实现事件驱动的请求处理。

6.4 高度可定制化：

组件化设计支持按需选配，可灵活调整 Acceptor、Selector 数量，适配不同业务场景。

七、常见问题

• 问题 1（架构对比侧重）：Jetty 与 Tomcat 在 Connector 架构设计上的核心差异是什么？
  答案：核心差异主要有三点：
  • 线程池设计不同：Tomcat 每个 Connector 拥有独立的线程池，而 Jetty 所有 Connector 共享一个全局线程池，统一分配线程资源，更便于控制总线程数。
  • I/O 模型支持不同：Tomcat 支持 NIO、NIO2、APR 三种 I/O 模型，而 Jetty9 版本仅支持 NIO 模型，代码更精简，轻量化程度更高。
  • 架构耦合度不同：Tomcat 的 Connector 与 Container 通过 Service 组件绑定，不同 Service 的 Connector 相互隔离；而 Jetty 的 Connector 被所有 Handler 共享，无 Service 中间层，架构更简洁，定制化更灵活。
• 问题 2（组件流程侧重）：Jetty 的 Connector 组件中，Acceptor、SelectorManager、Connection 三个组件分别承担什么职责，如何协作完成请求处理？
  答案：三个组件分工明确，基于 Java NIO 模型完成全流程请求处理，职责与协作方式如下：
  • Acceptor：负责连接监听与接收，以阻塞方式接受客户端 TCP 连接，生成 SocketChannel 后设置为非阻塞模式，交给 SelectorManager 处理，是请求处理的入口。
  • SelectorManager：负责I/O 事件管理，内部维护 ManagedSelector 数组，将 Channel 注册到 Selector 上，创建并绑定 EndPoint 与 Connection，持续检测 I/O 事件，事件就绪后生成任务提交至线程池。
  • Connection：负责协议解析与请求转发，向 EndPoint 注册回调函数，数据就绪时触发回调读取数据，解析 HTTP 协议生成 Request 对象，最终交给 Handler 组件完成业务处理，处理完成后再通过 EndPoint 完成响应写入。
  • 三者协作流程：Acceptor 接连接 → SelectorManager 管 I/O 事件 → Connection 解析协议并处理请求，形成完整的网络通信闭环。
• 问题 3（选型设计侧重）：Jetty 的 Connector 设计有哪些核心优势，分别适配什么业务场景？
  答案：Jetty 的 Connector 设计核心优势与适配场景如下：
  • 轻量化与可裁剪优势：仅支持 NIO 模型，代码量小、内存占用低，同时支持通过 Handler 组件按需裁剪功能，适配嵌入式设备、资源受限的容器化环境，以及需要定制化精简 Web 容器的场景。
  • 异步事件驱动优势：通过回调函数模拟异步 I/O，事件驱动的设计在高并发短连接场景下性能表现优异，适配高并发 API 网关、实时通信类 Web 应用。
  • 灵活定制化优势：组件化设计支持灵活调整 Acceptor、Selector 线程数量，全局线程池便于统一调优，适配需要深度定制 Web 容器行为的中间件、自研框架开发场景。
    与之相对，Tomcat 更成熟稳定，企业级特性支持更完善，更适配传统企业级 Web 应用的稳定运行场景。