1. 从启动日志反推顶层骨架Server 与 Service 到底各管什么很多人学了 Tomcat 之后能说出 Connector、Container但要问他 Server 和 Service 有什么区别就有点犯迷糊了。这很正常因为这两个对象平时不怎么直接碰业务属于管人的那个人。回到最底层的 server.xml。每次你启动 Tomcat无论通过 startup.sh 还是直接跑 Bootstrap最后都会去解析 conf/server.xml读取的就是下头这段骨架结构Server port8005 shutdownSHUTDOWN Listener classNameorg.apache.catalina.startup.VersionLoggerListener / Listener classNameorg.apache.catalina.mbeans.ServerLifecycleListener / Listener classNameorg.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Service nameCatalina Connector port8080 protocolHTTP/1.1 / Connector port8009 protocolAJP/1.3 / Engine nameCatalina defaultHostlocalhost Host namelocalhost appBasewebapps / /Engine /Service /Server从 XML 层级上看Server 是整个容器的最顶层。它代表一个完整的 JVM 运行实例通常一台机器上只跑一个 Tomcat 进程那这个进程里就只有一个 Server 对象。打个比方Server 就像整个公司总部的法人主体负责整体注册、发牌照、统筹全局。它自身不处理任何业务请求主要工作包括管理全局的命名资源JNDI 资源注册中心比如你在 context.xml 里配的数据源最终挂在全局资源上负责监听一个固定的关闭端口默认 8005当你说执行 shutdown.sh时脚本会往这个端口发送一个约定的 SHUTDOWN 字符串Server 收到后就触发整个 JVM 的优雅关闭流程统一协调所有 Service 的生命周期确切说它内部维护着一组 Service启动时就逐个启动它们而 Service 这个组件是真正干活的组合单元。一个 Service 至少由一组 Connector 加一个 Container具体是 Engine组成。这里有个值得注意的点Service 里的 Engine 是唯一的但 Connector 可以有很多个。比如上面配置里一个 Service 同时配了 HTTP/1.1 的 8080 连接器和 AJP/1.3 的 8009 连接器。两个连接器监听不同协议、不同端口但收到的请求都会交给同一个 Engine 处理。如果你细心观察标准 Tomcat 发行版的 server.xml 里默认只有一个 Service名字固定叫 Catalina。但理论上你完全可以再加一个 Service绑不同的 Connector 和 Engine 组合。我确实在实际项目中见过这种玩法——有人为了在同一进程里跑两类端口给 HTTP API 和内部 RPC 分别配了独立 Service。好处是共享进程坏处是隔离性差后来基本没人敢这么干。补充一句如果你在 server.xml 里把 Server 的 port 改成了 -1那就表示关闭端口不启用。在云原生容器环境里由于启动时无法保证只有一份配置常见做法是把 port 改成 -1避免外部误发 SHUTDOWN 指令把服务搞挂。2. Connector从 TCP 端口到 HttpServletRequest 的完整旅程如果说 Server 和 Service 是骨架那 Connector 就是门面——所有外部流量都必须经过它才能进入 Tomcat 内核。它负责做两件最重要的事在指定端口上等待连接接收 TCP 层的字节流把原始字节流按照 HTTP 协议解析成 Tomcat 内部统一的对象Request 和 Response然后交给后面的 Container 处理。2.1 三种协议实现的选型逻辑我们打开 server.xml 默认看到的 protocol 是HTTP/1.1。但注意这个值并不是说这就是 HTTP 1.1 协议本身而是告诉 Tomcat 你选择哪种连接器实现类来处理 HTTP 请求。BIO阻塞 I/O早期版本默认。一个线程只能持有一个连接到并发上来之后线程数量暴涨。JDK 8 以后基本没人用它了。NIO非阻塞 I/O基于 Java NIO 的 Selector 模型大量连接用少量线程就能管理。Tomcat 8.5 到 Tomcat 9 的默认选择。NIO2异步 I/O基于 JDK 7 的 AsynchronousSocketChannel。在长连接、高并发写多读少的场景下有一定优势。APR/native需要单独装 tcnative 库走 OpenSSL性能最好但部署环境折腾。Tomcat 10 之后被整合成org.apache.coyote.http11.Http11AprProtocol默认发行包也已不包含 APR 组件了。作为一个常年用默认方案的人我的建议是除非你有非常明确的 SSL 卸载、零拷贝优化需求否则直接用 NIO别为了配置 APR 去折腾系统依赖库。2.2 Connector 的核心参数配置连接器时参数远比很多新手的认知要细。看一个典型的 NIO 连接器配置Connector port8080 protocolorg.apache.coyote.http11.Http11NioProtocol connectionTimeout20000 redirectPort8443 acceptCount300 maxThreads400 minSpareThreads20 maxConnections10000 processorCache450 URIEncodingUTF-8 /逐个拆先说最容易被误解的maxThreads。它不是说 Tomcat 最多只能接收这么多请求而是说请求在进入应用线程池时的上限。超过这个数量的请求会先排队队列容量由acceptCount控制如果队列也满了额外连接就会被拒绝直接返回Connection refused。至于maxConnections它表示操作系统层面 Tomcat 最多能接受的 TCP 连接数。NIO 模式下这个值可以远大于 maxThreads因为大量连接可以处于空闲等待状态并不消耗应用线程。我管这个叫连接和线程分离。一个常用的换算思路假设接口平均耗时 200ms并发 100 时每秒吞吐也就 500 QPS。如果你把 maxThreads 设置成 1000接口耗时不降反升反而因为上下文切换性能更差。上面配置里的processorCache是 NIO 的一个内部缓存参数。它缓存协议处理器对象也就是用来解析请求数据的组件。每次创建和销毁都很贵配个合适的容量能减少对象回收压力。不过这个参数实际调控得很微妙Tomcat 官方文档都建议一般情况下别碰它。2.3 一次请求在 Connector 内的处理顺序要理解连接器到底做了什么可以把它拆成四步看Acceptor 线程专门负责在 ServerSocket 上accept()新的 TCP 连接。默认 Acceptor 线程数只有 1但对大多数场景已经够了。Poller 线程NIO 的核心调度者。它管理着一个 Selector扫描所有已建立连接的 Channel 上是否有新数据到达、是否可写等事件。Processor 对象当 Poller 确定某个连接上有数据可读时就会从缓存里取一个 Http11Processor把 Socket 交给它由它来完成 HTTP 协议的解析。请求交给 ContainerProcessor 把解析结果封装成 coyote.Request 和 coyote.Response调用 CoyoteAdapter 的 service 方法正式进入容器阶段。这整个过程链路清晰Acceptor 只负责收人Poller 只负责盯着网络事件真正干活的是 Processor。这种分层协作在长连接场景下特别高效一个空闲连接完全不会占着应用线程不放。3. Container 的四级嵌套Engine、Host、Context、Wrapper 如何层层定位请求Connector 干完自己的活后请求对象就交给 Container。Tomcat 的 Container 设计成一个四级嵌套的树状结构从上到下依次是Engine └── Host (虚拟主机) └── Context (Web 应用) └── Wrapper (Servlet 实例)这种嵌套关系跟我讲过很多次但真正把它和 URL 是怎么定位到某个 Servlet 的 连在一起想清楚的其实不多。3.1 Engine请求的顶层入口Engine 是容器树的老大一个 Service 里只有一个。它负责把已经解析好的 Request 对象的 serverName也就是域名拿出来去匹配下头的某个 Host。默认配置里Engine 的 nameCatalina 只是一个标识符不参与路由决策。真正参与路由的是 defaultHostlocalhost 这个属性——它指明当请求里的 Host 头无法匹配任何 Host 时默认交给谁。3.2 Host虚拟主机的实现Host 对应虚拟主机概念。一个 Engine 下可以配置多个 Host每个 Host 配置一个 name 属性。举个例子Engine nameCatalina defaultHostlocalhost Host namelocalhost appBasewebapps unpackWARstrue autoDeploytrue / Host namewww.example.com appBasewebapps2 / /Engine当浏览器访问 http://www.example.com/xxx 时Connector 解析出来的 Host 头就是 www.example.comTomcat 拿它去匹配 Host 的 name匹配到的这个 Host 才负责后续处理。这里经常被人忽略的点是请求没有匹配到任何 Host 时并不会报错而是落到 defaultHost。所以你在生产上如果想让某个域名不响应光删 Host 配置不够还要注意 defaultHost 指向哪里。Host 层面还有几个影响日常运维的属性appBase存放 Web 应用的位置通常是 webapps 目录。autoDeploy是否在运行时自动检测 appBase 下新增或变更的应用默认 true开发环境很好用生产环境建议谨慎。deployOnStartup启动时是否自动部署所有应用。3.3 Context一个应用的所有资源载体Context 是 Tomcat 里我们平时感知最强的容器因为一个 Context 就是一个 Web 应用。它对应 webapps 下的一个目录或者一个 WAR 包。路由规则很简单取请求 URL 的 path 部分的首段。比如请求 /api/users/list如果 Context 的 path 是 /api那么这个请求就进入这个 Context。默认根路径是或/对应 ROOT 应用。不要把 Context path 和 URL 里的应用上下文搞混。当你请求 /myapp/login.do 时myapp 实际上就是 Context 的 path。而进入 Context 之后Tomcat 会拿着剩余路径/login.do继续向下定位 Wrapper。Context 里有很多关键的配置项在 conf/context.xml 和每个应用的 META-INF/context.xml 里都能看到docBase应用文档根目录指定应用实际位于磁盘的哪个位置。reloadable是否监听 WEB-INF/classes 和 WEB-INF/lib 下的类文件变化变化后自动重新加载。这个功能开发时极其好用但生产环境如果忘记关掉就可能出现奇怪的类热替换问题。parentClassLoader用于指定类加载器层级这是排查 ClassNotFound 异常的重灾区后面会专门讲。3.4 WrapperServlet 的包装层Wrapper 是容器树的叶子节点负责管理一个 Servlet 实例。它做的事情非常纯粹根据请求路径与 Servlet 映射规则WebServlet 注解或 web.xml 中的 servlet-mapping匹配。维护 Servlet 的生命周期init() 只会执行一次service() 执行请求分发destroy() 在移除时调用。处理 load-on-startup是否在应用启动时提前实例化 Servlet。这里有个匹配优先级问题值得记忆。Servlet 路径匹配规则按精确匹配 最长路径前缀匹配 扩展名匹配 默认映射 的顺序逐级检查。如果再配合路径参数和正则映射实际行为会比直觉复杂许多。比如精确匹配 /user/login 路径前缀 /user/* 扩展名 *.do 默认 /请求 /user/profile.do 到底会命中哪个答案是先看有没有精确匹配没有再看路径前缀都没有才轮到扩展名。所以 /user/* 会优先于 *.do。这个细节在多个 Servlet 同时存在时很容易踩坑。用一张路径拆解表可以更直观请求 URL 片段由哪个组件负责/域名后第一段Host 选择/appContext 定位/app/order/listWrapper 匹配 Servlet/app/order/list剩余路径Servlet 内部路由处理4. 组件之间如何协同工作Pipeline-Valve 管道与生命周期机制上面讲了各个组件是什么现在要解决它们之间怎么传递数据。这里就要引出 Tomcat 最核心的机制之一Pipeline-Valve 管道模型。4.1 从 Connector 到 Container 的连接Connector 在 Processor 解析完请求后会调用 CoyoteAdapter.service()。这个 Adapter 是连接器与容器之间的桥它做的事情有两件把 coyote 层的 Request/Response 转换成容器层的 HttpServletRequest/HttpServletResponse调用 Engine 的 pipeline.getFirst().invoke(request, response)。注意关键点请求到达的不是 Engine 代码本身而是 Engine 的管道里的第一个 Valve。4.2 Pipeline 和 Valve每个容器都有内部管道Tomcat 的每个容器组件Engine、Host、Context、Wrapper都自带一条 Pipeline。Pipeline 内部保持着一个 Valve 链表其中第一个 Valve 是基础阀门basic后面可以追加任意多个自定义 Valve。请求进入容器后按链表顺序逐个经过 Valve最终到达基础阀门由基础阀门负责调用下一级容器的 Pipeline。所以一个完整请求经过的容器顺序是Connector → Engine Pipeline → Host Pipeline → Context Pipeline → Wrapper Pipeline → Servlet.service()这个设计的好处是你可以在任意层级插入通用处理逻辑不需要改业务代码。最常用的就是 AccessLogValve它在 Host 层记录访问日志还有 RemoteAddrValve可以通过配置限制来源 IP。自定义 Valve 的样子是一个实现了 Valve 接口的 Java 类核心方法就两个public class TraceValve extends ValveBase { Override public void invoke(Request request, Response response) { long start System.nanoTime(); getNext().invoke(request, response); long cost System.nanoTime() - start; System.out.println(请求路径: request.getRequestURI() , 耗时(ms): cost / 1000000); } }然后在 server.xml 的 Host 节点里挂上它Host namelocalhost appBasewebapps Valve classNamecom.example.TraceValve / /HostValve 的 invoke 是递归调用 getNext().invoke() 的如果你想在所有容器链路走完之后做后置处理就写在 getNext().invoke() 之后。这个模型和过滤器Filter完全不同Filter 是 Servlet 规范定义的属于应用级Valve 是 Tomcat 内部扩展属于容器级。在应用的 web.xml 里配的 Filter 只有在请求达到 Wrapper 前才会被调用而 Valve 从 Engine 层就能介入。4.3 Lifecycle 机制组件不是凭空出现的每个 Tomcat 组件都需要经历 init、start、stop、destroy 这几个阶段。Tomcat 把这些统一抽象成 Lifecycle 接口并以父组件启动顺序为准则向下传播。启动时上层组件先初始化并启动然后触发下一层组件启动。这个顺序是严格固定的Server → Service → Connector/Engine → Host → Context → Wrapper。如果某个 Context 启动时 web.xml 配置有问题它会自己启动失败但不会拖垮整个 Tomcat——这就是为什么生产上明明某个应用报错了Tomcat 主进程还能继续跑。之前排查一个问题时观察过 Tomcat 在 startup 日志里打印的阶段信息。利用生命周期机制你可以比较清晰地看到Initializing ProtocolHandler [http-nio-8080]连接器初始化Server startup in [xxx] milliseconds整个容器启动完成理解这套机制对排错意义很大。比如一个应用老是启动一半就挂你可以通过日志确认是卡在 Context 的哪个阶段——是类加载失败、还是某个 Initializing Servlet 抛异常、还是资源注入失败。到了哪个阶段报错就顺着哪些组件去查。5. 容易被忽略但决定性能与稳定性的辅助组件前面提到的组件都在 server.xml 主线上属于核心中的核心。但 Tomcat 能正常生产运转还依赖一批辅助组件它们平时藏得很好一旦出问题就是关键时刻掉链子。5.1 Executor自定义线程池默认情况下Connector 自己会维护一个线程池来执行请求。但你也可以配置一个全局共享的 Executor让多个 Connector 共用。这在你的 Tomcat 同时开了 HTTP 和 HTTPS 两个连接器时特别有用——否则两边各有一池线程浪费资源且无法动态调配。配置方式如下Executor nametomcatThreadPool namePrefixcatalina-exec- maxThreads400 minSpareThreads20 / Connector port8080 protocolHTTP/1.1 executortomcatThreadPool / Connector port8443 protocolHTTP/1.1 executortomcatThreadPool /注意 connector 上用 executor 属性取代了 maxThreads。一旦指定了 executorConnector 自身的线程池配置就被忽略。这个共享思路对一个端口是普通 HTTP、另一个端口是同协议的 HTTPS场景好看又实用。5.2 Realm安全认证的接入点如果你用过 Tomcat 自带的 manager 应用那你就接触过 Realm 了。Realm 是 Tomcat 提供的认证领域组件它的作用就是从某个数据源读取用户、角色信息用于 HTTP 基本认证或表单认证。常见实现有三种MemoryRealm内存里读 tomcat-users.xmlDataSourceRealm从数据库读取用户表JAASRealm对接 JAAS 认证体系生产环境鲜有人直接用 Tomcat 的 Realm 做登录认证多数是把它放进反代后面统一单点登录。但理解 Realm 对你理解 Tomcat 的安全机制有帮助至少看到 server.xml 里的 Realm 配置你不慌。5.3 JNDI 全局资源数据源配置的经典场景Tomcat 之所以在很多老项目里呆了好多年一个重要原因是它把 JNDI 数据源配置做得很成熟。你在 context.xml 里写一段 Resource 配置应用就能通过java:comp/env/jdbc/ExampleDB拿到连接池。Context Resource namejdbc/ExampleDB authContainer typejavax.sql.DataSource driverClassNamecom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/test usernameroot passwordpassword maxTotal20 maxIdle10 maxWaitMillis10000 / /Context这个机制的核心在于数据源对象是在容器层创建的而不是在应用里 new 出来的。应用侧只需要做一个 JNDI 查找即可。这也是很多人说的Tomcat 作为一个 Servlet 容器把自己做成了应用服务器的样子。5.4 类加载器体系父子委托的边界Tomcat 的类加载器结构和 JVM 双亲委派模型有点区别它要求每个 Web 应用拥有独立的类加载器实例以保证不同应用间类隔离。典型的层级是Bootstrap └── System └── Common (catalina.jar, 公共依赖) ├── WebappClassLoader (app1) └── WebappClassLoader (app2)每个 WebappClassLoader 优先从自己的 WEB-INF/classes 和 WEB-INF/lib 里加载类然后再交给父加载器。这和 JDK 默认的父优先不同是子优先。所以当两个应用自带同一个库的冲突版本时各自加载各自的互不干扰。实际排查中经常遇到的ClassNotFoundException或NoSuchMethodError大部分都能归因到这种加载顺序上。比如你给 Tomcat 的 lib 目录放了一份 mysql-connector-java.jar同时应用里也放了一份两份版本不一致那跑起来的行为就很难预测——因为有时候是父加载器优先有时候是子加载器把它挡住。这类问题排查起来有个通用思路看启动日志里的类加载警告或者主动在应用的某处打印该类的ClassLoader信息也可以开启-verbose:class参数跟踪类的加载来源。5.5 Listener全局事件监听server.xml 顶层那一堆Listener元素平时不太引人注意但实际上相当重要。比如VersionLoggerListener启动时打印 Tomcat 版本和 JVM 信息排查环境问题时先看这里JreMemoryLeakPreventionListener解决 JDK 下 JVM 内存泄漏问题防止取消类加载器时出现问题GlobalResourcesLifecycleListener初始化全局 JNDI 资源这些 Listener 都是基于 Lifecycle 事件机制的属于注册好就不用管的组件。理解它们的存在对你解读启动日志会有帮助。比如你看到JreMemoryLeakPreventionListener启动时的一些怪异输出比如实例化某个 URL 类不必担心那是它在试图修复 JDK 的一个老问题。6. 用组件视角反推线上故障端口、线程、超时的底层逻辑组件结构学完之后最有用的事情是拿这套知识反推线上故障。我用几个常见问题来演示一下怎么用组件模型定位问题根源。6.1 “端口被占用”到底撞了什么启动时报java.net.BindException: Address already in use这通常是两个 Tomcat 实例同时在抢同一个 Connector 端口或者别的进程占着同一端口。但也有一种情况你的 Server 关闭端口8005和另一个实例的端口冲突了启动一样会失败。排查动作netstat -tlnp | grep 8080 lsof -i :8005但如果你发现端口明明没被占用还是报这个错就要考虑是不是同一个 JVM 里加载了两个 Tomcat 实例或者是因为 APR 模式与 NIO 模式的 socket 处理方式不同导致的偶发问题。6.2 线程池满了请求为什么排队Connector 的 acceptCount 和 maxThreads 是配合工作的。当 400 个应用线程全被占住新请求不是直接失败而是进入操作系统 accept 队列。队列长度由 acceptCount 决定。如果队列也排满新连接直接被拒绝。线上表现就是接口从响应慢变成直接连接失败。你通过 jstack 能看到大量线程 stuck 在业务代码里比如数据库连接获取超时、外部接口调用等待。这时候调整 maxThreads 只能治标根因是下游依赖太慢。但这里有个关键认知线程池满了不一定是接口到达量大也可能是线程被长时间占用不释放。比如某个接口在等待一个永不返回的结果那线程就牢牢占住池中的名额。这也是为什么很多负责人宁可 maxThreads 偏小也不愿让线程无限膨胀——线程越多上下文切换越频繁吞吐反而下降。6.3 404 日志出现但应用明明在有时你访问 /myapp/login 返回 404但应用确实部署了。这时的排查顺序恰好就对应容器路由机制Host 是否匹配你访问的域名有没有对应的 Host如果走了 defaultHost它 appBase 下没有这个应用自然 404。Context path 是否准确应用上下文是 /myapp 还是 /myapp/末尾斜杠的区别会影响定位。Wrapper 映射是否配好Servlet 映射是否写了 /login 但实际请求带了 /login/。是否存在静态资源配置问题比如 Spring MVC 的 DispatcherServlet 映射到/它会把很多静态请求也接进来导致没有对应 Handler 就 404。大多数团队花了很多时间在应用层排查 404最后发现根因在 Host 配置就是因为没按容器路由层级走一遍。6.4 应用间互相影响怎么办既然每个 Context 是独立应用那它们分别在独立的类加载器环境里。很多新手以为这样就能完全隔离但其实 JVM 层面依然共享内存堆、线程资源、数据库连接池等系统级资源。如果 app1 把堆打满了app2 即使类加载隔离得再干净也会受影响。在部署架构上我的个人经验是一个 Tomcat 实例里的应用数量不要贪多。除非应用确实很轻量否则拆成多个实例来部署能让故障面大幅缩小。穷根究底Tomcat 的每个组件解决一类问题把它们的关系理清了无论是配置调优还是问题排查都能找到相应的下手点。7. 我常用的组件观测与验证手段最后分享几个我平时用来验证组件状态的具体手段不是教科书上的理论都是实际能上手操作的。7.1 JMX 是观察组件的利器Tomcat 每个核心组件都注册了 JMX MBean。通过 JConsole 或者命令行连上去能看到服务器级别、线程池、连接器、容器、数据源等几十个指标。例如使用 jconsole 连接本地进程进入 MBean 标签页展开 Catalina 节点GlobalRequestProcessor节点可以看到当前连接器处理的请求总数、错误数、处理时间等。ThreadPool节点能看到当前线程数、繁忙线程数、最大线程数。这个数据比任何监控脚本都直观。DataSource节点能看到当前活动连接数、空闲连接数。排查问题的时候我通常先看 ThreadPool 的 currentThreadsBusy 这个指标。如果长时间接近 maxThreads那就不是偶发抖动是系统真的遇到了瓶颈。7.2 直接修改 server.xml 验证组件边界想知道某个组件是不是真的在起作用拿一个小改动测试一下就好。比如你想验证 Valve 的调用链路加一个打印日志的 Valve 到 Host 层重启后访问任意应用观察日志输出顺序。如果它打印的顺序和预想中一致说明链路符合预期如果不打印说明请求根本没进入这个 Host——你就有可能定位到 Host 匹配问题。又比如你怀疑某个应用加载了类冲突临时把应用 WEB-INF/lib 下的某个 jar 删掉重启看是否报 NoClassDefFoundError。注意这会更改应用行为所以动作前要做备份。7.3 学会读 CATALINA_BASE 和 CATALINA_HOMETomcat 区分了两类目录CATALINA_HOME 是安装目录放引擎和公共库CATALINA_BASE 是运行目录存放 conf、logs、webapps、work 等实例相关数据。一个安装目录可以配多个运行目录相当于一份代码、多份配置。这在多实例服务上非常有用。看到这里你其实已经不只是知道组件列表而是理解了 Tomcat 从配置到运行、从连接到容器、从启动到关闭的完整链路。下次再有人问 Tomcat 有哪些核心组件你可以直接对着 server.xml 逐行解释每个标签背后承担了什么职责以及它们之间是怎么配合工作的。这套认知能帮你在部署、调优和排障的路上少走不少弯路。
