Tomcat 源码学习大纲 (以 IntelliJ + AI 为辅助)

Tomcat 本质上由两部分组成：
1. Connector/Coyote，负责网络通信、协议解析、连接管理；
2. Catalina/Container，负责 Web 应用管理和 Servlet 调用。

容器体系是树形结构：
Server -> Service -> Engine -> Host -> Context -> Wrapper。

请求从 Connector 进入，经过 Coyote 解析后交给 Catalina，
再按 Engine、Host、Context、Wrapper 逐层定位，最终调用目标 Servlet。

Server：代表整个 Tomcat 进程中的顶级服务管理器
└── Service：连接器和容器的组合
    ├── Connector(8080)：
    ├── Connector(8009)
    └── Engine
        ├── Host(www.example.com)
        │   ├── Context(/app1)
        │   │   ├── Wrapper(ServletA)
        │   │   └── Wrapper(ServletB)
        │   └── Context(/app2)
        └── Host(admin.example.com)
            └── Context(/)
                └── Wrapper(AdminServlet)

Bootstrap 负责构造 Tomcat 的类加载器环境，并反射创建 Catalina。
Catalina.load() 负责解析 server.xml，通过 Digester 规则把 XML 装配成 Server/Service/Engine/Host/Context 组件树，然后调用 Server.init() 完成初始化。
Catalina.start() 再触发 Server.start()，由 Server 递归启动 Service。
Service 的启动顺序是先 Engine、再 Executor 和 Mapper、最后 Connector，确保请求入口打开前，容器和映射体系已经就绪。
最后主线程进入 await()，服务器进入稳定运行状态。

Connector 是 Tomcat 的网络入口，负责监听端口、接收 socket、解析协议，并通过 Coyote 处理 HTTP/AJP 等请求。
其中 Endpoint 负责底层网络通信，Processor 负责协议解析和请求状态机，Adapter 负责把 Coyote 请求交给 Catalina 容器。
所以请求主线是：
Connector -> ProtocolHandler -> Endpoint -> Processor -> Adapter -> Catalina

请求从 CoyoteAdapter 进入 Catalina 后，会先完成 URL 到 Host、Context、Wrapper 的映射，然后依次经过 Engine、Host、Context、Wrapper 四层 Pipeline/Valve 处理。
在 Wrapper 层，Tomcat 会为当前请求创建 FilterChain，先执行所有匹配的 Filter，最后调用目标 Servlet 的 service() 方法。

Engine：整个引擎，管理多个 Host
Host：虚拟主机，管理多个 Context
Context：Web 应用，管理多个 Wrapper
Wrapper：Servlet 包装器，管理具体 Servlet 执行

Tomcat 的容器体系是一棵树，核心层级是 Engine -> Host -> Context -> Wrapper。
Engine 表示整个 Servlet 引擎，Host 表示虚拟主机，Context 表示一个 Web 应用，Wrapper 表示一个具体 Servlet。
Tomcat 通过这棵容器树统一完成请求分发、组件管理和生命周期传播。

一个真实的 Web 应用，是怎样挂到这棵容器树上的。


Host：应用部署的承载层
HostConfig：发现和管理应用部署
Context：应用部署后的运行容器
ContextConfig：完成应用配置解析和装配

Tomcat 的 Web 应用部署，本质上是把一个 WAR、目录或配置文件转换成一个可运行的 Context。
Host 负责承载和管理多个应用，HostConfig 负责发现和部署应用，ContextConfig 负责解析 web.xml、注解和组件配置，最终完成 Filter、Listener、Servlet 的注册和应用启动。

Servlet：真正处理业务请求
Filter：对请求和响应进行拦截、增强、预处理、后处理
Listener：监听容器或请求相关事件

Tomcat 中，Servlet、Filter、Listener 都由 Context 统一管理。
Servlet 通过 Wrapper 进行生命周期和请求执行管理，Filter 在请求到来时动态组装成 FilterChain，Listener 则在应用、请求、Session 等事件发生时由容器触发回调。

Session：单个用户会话数据
Session ID：会话唯一标识
Cookie：客户端携带 Session ID 的方式
Manager：服务端管理 Session 的组件
Context：Session 所属的应用范围

Tomcat 通过 Session 机制为无状态的 HTTP 请求建立会话状态。Session 数据保存在服务端，Cookie 通常只负责保存和传递 Session ID（如 JSESSIONID）。每个 Web 应用都有自己的 Session 管理器，由 Manager 负责 Session 的创建、查找、失效和回收。

Tomcat 为了同时运行多个 Web 应用，设计了分层类加载体系，用来解决应用隔离、公共类共享、容器安全和热部署问题。每个 Web 应用通常都有自己的 WebappClassLoader，用于加载 WEB-INF/classes 和 WEB-INF/lib。Tomcat 整体基于父子委派，但对 Web 应用类加载做了定制，以避免应用覆盖 JDK、Servlet API 和容器内部核心类。

Lifecycle：统一生命周期接口
LifecycleBase：生命周期骨架实现
LifecycleState：状态机
LifecycleEvent：生命周期事件对象
LifecycleListener：生命周期事件监听者

Tomcat 为核心组件设计了统一的生命周期机制，用 Lifecycle 和 LifecycleBase 来管理 init、start、stop、destroy 等阶段，并通过 LifecycleState 维护状态机。组件在生命周期变化时会发出事件，由 LifecycleListener 监听处理。这样 Tomcat 就能以统一、可扩展的方式管理整套容器和连接器组件。

Acceptor：负责“接人”
Poller：负责“盯着谁有事”
Worker：负责“真正干活”

Tomcat 的线程模型把连接接入、I/O 监听和请求处理分成不同角色。典型的 NIO 模式下，Acceptor 负责接收新连接，Poller 负责监听连接上的读写事件，Worker 线程负责执行协议解析和容器请求处理。Executor 线程池则用于统一管理工作线程，从而提高并发处理能力和资源利用率。

Realm：认证与角色数据来源
Authenticator：执行认证流程
SecurityConstraint：定义资源访问规则
LoginConfig：定义登录方式和登录配置
Context：承载应用级安全配置

Tomcat 的安全体系用于在容器层统一处理认证、授权和资源访问控制。Realm 负责提供用户身份和角色信息，Authenticator 负责执行认证流程，SecurityConstraint 定义受保护资源的访问规则，LoginConfig 定义认证方式。这样请求在进入业务 Servlet 之前，就可以完成统一的安全检查。

Jasper：JSP 引擎
JSP：最终转换为 Servlet 执行
WebSocket：通过 HTTP 接入并升级为双向长连接通信
Context：承载这些能力所属的 Web 应用边界
Connector/Container：为它们提供底层支撑

Tomcat 不仅能运行普通 Servlet，还通过 Jasper 支持 JSP，并通过协议升级机制支持 WebSocket。JSP 会先被转换并编译成 Servlet，再按普通 Servlet 方式运行；WebSocket 则通常先通过 HTTP 请求进入 Tomcat，再升级为持续的双向通信连接。它们都建立在 Tomcat 的连接器、容器、类加载和应用部署机制之上。

负载均衡：把请求分到不同节点
Cluster：协调多个 Tomcat 节点
Session 复制：同步会话状态
Context/Manager：会话所属的应用和管理边界
高可用：节点故障时尽量不中断服务

Tomcat 的集群与高可用能力主要用于支持多节点协作运行。负载均衡负责把请求分发到不同节点，而集群能力负责协调节点之间的状态，尤其是 Session 复制。这样当某个节点不可用或请求被转发到其他节点时，用户会话状态仍能尽量保持连续。不过这种能力会带来额外的网络、内存和同步开销。