企业官网建设流程全解析

1. 从一次请求响应慢的排查说起：Catalina到底管什么

很多人第一次接触Tomcat，注意力都放在server.xml里那个8080端口上，觉得改改端口、配配虚拟目录就算会用Tomcat了。直到某天线上接口突然大面积超时，日志里全是线程池打满的告警，翻遍Spring配置也找不到原因，最后才发现问题出在Servlet容器这一层——请求还没进到业务代码，就已经在Catalina的管道里排队了。这个场景我遇到过不止一次，也是从那时候起，我才真正愿意花时间去啃Catalina这个模块。

Catalina是Tomcat的Servlet容器实现，也是整个Tomcat最核心的部分。Tomcat本身可以拆成两大块：一块是Connector，负责网络通信，把字节流解析成HTTP请求；另一块就是Catalina，负责处理这些请求，管理Servlet的生命周期，维护会话，执行过滤器和Servlet。你可以把Connector理解成前台接待，把Catalina理解成后厨——接待把单子递进来，后厨决定这道菜由谁做、怎么做、做完怎么端出去。绝大多数和业务逻辑相关的行为，比如doGet、doPost、Filter、Listener、Session，全部发生在Catalina这一层。

这篇文章适合两类人看。一类是已经会用Tomcat部署应用，但对内部机制一知半解，遇到性能问题或者诡异Bug时无从下手的开发者；另一类是想深入理解Servlet规范落地细节，为后续读源码或者做容器定制打基础的人。我会从Catalina的整体架构讲起，把Server、Service、Engine、Host、Context、Wrapper这条组件链拆开揉碎，再讲请求是怎么在这条链上流转的，最后落到实际使用中最容易踩的几个坑。全程不堆砌源码，但关键机制会讲透，让你看完之后能对着自己的Tomcat实例说出个所以然。

需要提前说明的是，Catalina的组件模型是典型的组合模式，父容器管子容器，层层嵌套。理解了这个嵌套关系，后面看任何配置和源码都不会迷路。下面我们一层一层往下剥。

2. Catalina的组件树：Server到Wrapper的六层嵌套关系

2.1 为什么Tomcat要设计这么多层容器

刚看Tomcat架构图的人都会有一个疑问：不就是处理个HTTP请求吗，为什么要搞出Server、Service、Engine、Host、Context、Wrapper这么多层？直接一个类处理完不行吗？这个问题问得好，答案藏在职责分离和多实例复用这两个需求里。

设想一个场景：一台机器上要跑两个不同的Web应用，它们共享同一个端口，但根据域名或者路径区分。如果没有Host这一层，你就得为每个应用单独起一个Tomcat进程，端口还得错开，运维成本直接翻倍。再设想另一个场景：同一个应用里，你想给不同的Servlet配置不同的类加载器，实现热部署隔离。如果没有Context和Wrapper的区分，类加载器只能全局一份，隔离就无从谈起。所以这些层级不是拍脑袋加的，每一层都对应一个真实的隔离或复用需求。

从最外层往里数，这六层的关系是这样的：Server代表整个Tomcat实例，一个JVM里通常只有一个；Service把Connector和Engine绑在一起，一个Server可以有多个Service，但一般也就一个；Engine是Catalina的入口，负责把请求路由到对应的Host；Host代表一个虚拟主机，也就是一个域名；Context代表一个Web应用，就是你部署的那个war包或者目录；Wrapper代表一个具体的Servlet。每一层都是容器，都可以有自己的管道（Pipeline）和阀门（Valve），请求从外层进来，一层层往里传，每层都有机会对请求做点手脚。

2.2 各层组件的核心职责与配置落点

光说概念容易飘，我们直接对着server.xml看每一层在配置里长什么样，这样印象最深。

这张表建议你对着自己的conf/server.xml看一遍，把每个元素找出来。很多人用了几年Tomcat，从来没打开过这个文件，全靠Spring Boot自动配置，结果一旦需要改线程池或者配虚拟主机就抓瞎。理解这六层之后，你会发现Spring Boot内嵌Tomcat的那些配置项，比如server.tomcat.threads.max，最终都是映射到这张表里的某个组件上的。

这里有个容易混淆的点：Engine和Host之间是父子关系，但一个Engine下可以有多个Host。默认配置里只有一个名为localhost的Host，所以很多人以为它们是一对一的。实际上你完全可以在一个Engine下配多个Host，用不同的域名区分，这就是虚拟主机的实现方式。同理，一个Host下可以有多个Context，对应多个Web应用。这种一对多的关系是理解Catalina路由机制的关键。

2.3 组合模式带来的生命周期联动

这六层组件不是孤立的，它们通过组合模式串成一条生命周期链。父组件启动时会依次启动子组件，父组件停止时也会依次停止子组件。这个机制的好处是，你只需要调用最外层Server的start()方法，整个Tomcat就起来了，不需要手动一个个启动。

具体来说，每个容器组件都实现了Lifecycle接口，有init、start、stop、destroy四个核心阶段。当Server启动时，它会触发Service启动，Service触发Engine启动，Engine触发Host启动，Host触发Context启动，Context触发Wrapper启动。每一层在启动时都会做一些自己的初始化工作，比如Context启动时会解析web.xml、创建Servlet实例、初始化Filter链。这个联动机制是Tomcat能够一键启动的基础，也是理解热部署和优雅停机的关键。

注意：生命周期联动是单向的，父组件启动会带动子组件，但子组件出问题不一定会让父组件停止。比如某个Context启动失败，默认情况下Host会记录错误但继续启动其他Context，不会导致整个Tomcat挂掉。这个设计是为了隔离故障，但也意味着你不能只看Tomcat启动日志的最后一行判断是否一切正常，得往上翻看有没有Context级别的报错。

3. 请求在Catalina管道里的完整流转路径

3.1 从Connector交接到Engine的那一刻

请求到达Tomcat时，最先接触它的是Connector。Connector负责监听端口、接收字节流、按照HTTP协议解析出请求行、请求头和请求体，然后封装成一个Request对象和一个Response对象。做完这些之后，Connector并不会自己处理业务逻辑，而是把这对请求响应对象交给它所属的Service，再由Service转交给Engine。这个交接点就是Catalina开始工作的地方。

Engine拿到请求后，第一件事是确定这个请求应该由哪个Host处理。判断依据是请求头里的Host字段，也就是域名。Engine会遍历自己管理的所有Host，找到名字匹配的那个。如果找不到匹配的Host，就用defaultHost指定的那个兜底。这一步很关键，因为如果域名配置错了，请求可能被路由到错误的虚拟主机，表现出来的现象就是访问A域名却打开了B应用的内容。

找到Host之后，Host会继续往下找Context。Context的匹配依据是请求的URI路径。比如请求路径是/myapp/user/list，Host会先看有没有一个Context的path是/myapp，如果有就把请求交给它，剩下的/user/list作为Servlet路径继续往下传。如果没有任何Context匹配，Host会返回404。这里有个细节：Context的匹配是前缀匹配，而且遵循最长匹配原则。也就是说，如果同时存在/myapp和/myapp/admin两个Context，请求/myapp/admin/xxx会优先匹配到后者。

3.2 Pipeline和Valve：请求处理的拦截器链

请求进入每一层容器后，并不是直接调用目标Servlet，而是要经过一条管道（Pipeline）。管道里装着若干个阀门（Valve），每个Valve都可以对请求做处理，然后决定是否继续往下传递。这个设计模式就是经典的责任链模式，和Servlet规范里的Filter链非常像，但层级更高，作用范围更大。

每一层容器都有自己的Pipeline。Engine的Pipeline里默认有一个StandardEngineValve，负责把请求转发给合适的Host；Host的Pipeline里默认有一个StandardHostValve，负责转发给合适的Context；Context的Pipeline里默认有一个StandardContextValve，负责转发给合适的Wrapper；Wrapper的Pipeline里默认有一个StandardWrapperValve，负责调用最终的Servlet。这些Standard开头的Valve是Tomcat内置的，负责完成核心的路由和调用逻辑。

除了这些内置Valve，你还可以往Pipeline里加自定义Valve。比如你想在请求进入Engine之前记录一下访问日志，就可以写一个Valve加到Engine的Pipeline里。Valve和Filter的区别在于：Valve是Tomcat容器级别的，能访问到容器的内部结构；Filter是Servlet规范级别的，只能访问Servlet API。如果你需要做和容器强相关的操作，比如动态修改Context配置，Valve是更合适的选择。但大多数业务场景下，Filter已经够用了，没必要上Valve。

3.3 StandardWrapperValve如何调用到你的Servlet

请求流转到Wrapper这一层时，离你的业务代码就只有一步之遥了。StandardWrapperValve是负责这最后一步的Valve，它做的事情比看起来要复杂得多。

首先，它会检查对应的Servlet是否已经加载。如果还没加载，它会触发Servlet的加载流程，包括实例化、调用init()方法。这个过程是懒加载的，默认情况下Servlet在第一次被请求时才会初始化，除非你在web.xml里配了load-on-startup。懒加载的好处是启动快，坏处是第一次请求会慢一些。对于核心Servlet，建议配load-on-startup提前初始化，避免第一次请求超时。

Servlet加载好之后，StandardWrapperValve会创建Filter链。它会根据web.xml或注解里配置的Filter映射规则，把所有匹配当前请求的Filter按顺序串起来，形成一个链。然后它调用链头的Filter，Filter处理完再调用下一个，直到最后一个Filter调用到Servlet的service()方法。这个链条的执行顺序是：先按Filter的配置顺序执行doFilter的前半段，然后执行Servlet，最后按相反顺序执行doFilter的后半段。理解这个顺序对排查Filter相关的问题非常重要。

Servlet执行完毕后，StandardWrapperValve会负责把响应写回。如果Servlet抛了异常，它还会根据异常类型决定是返回500错误页还是交给其他错误处理机制。整个过程中，它还负责管理Servlet实例的并发访问，确保service()方法不会被多个线程同时调用同一个实例——这也是为什么Servlet默认是单例多线程的，你的Servlet代码必须保证线程安全。

4. 实际使用中最容易踩的五个坑

4.1 Context路径配置错误导致404

这是新手最常遇到的问题，没有之一。现象是应用明明部署成功了，Tomcat启动日志也没报错，但访问就是404。原因通常是Context的path和docBase配错了，或者war包的名字和访问路径对不上。

Tomcat默认会把webapps目录下的war包自动解压并部署，Context的path就是war包的名字去掉.war后缀。比如你放了一个myapp.war进去，访问路径就是/myapp。但如果你把war包改名为ROOT.war，访问路径就变成了根路径/。很多人不知道这个规则，把war包随便命名，结果访问路径和预期不符。还有一种情况是server.xml里手动配了Context，但path写成了/myapp/（多了个斜杠），导致匹配失败。

排查这个问题的思路很简单：先看Tomcat启动日志里有没有Deploying web application这样的行，确认应用确实被部署了；然后看日志里打印的context path是什么；最后用这个path去访问。如果日志里根本没有部署记录，说明war包没被扫描到，检查appBase配置和文件权限。

4.2 类加载器冲突引发的NoClassDefFoundError

Catalina为每个Context维护了独立的类加载器，这是实现应用隔离的基础。但这也带来了一个经典问题：同一个类被不同的类加载器加载了两次，导致类型转换失败或者静态变量不共享。

最常见的场景是：你把某个jar包同时放在了Tomcat的lib目录和应用的WEB-INF/lib目录下。Tomcat的类加载器会优先加载lib目录下的，但应用代码里引用的可能是WEB-INF/lib下的，两个类虽然名字一样，但在JVM看来是两个不同的类，于是抛出ClassCastException或者NoClassDefFoundError。解决办法是统一jar包的位置，要么全放lib，要么全放WEB-INF/lib，不要两边都放。

另一个常见场景是使用了一些需要和容器交互的框架，比如数据库连接池或者日志框架。这些框架的类如果被应用类加载器加载，可能无法访问容器的内部类，导致初始化失败。这时候需要把相关jar包放到Tomcat的lib目录下，让容器类加载器来加载。判断依据是看异常堆栈里有没有ClassNotFoundException或者NoClassDefFoundError，以及涉及的类是不是容器相关的。

4.3 线程池配置不当导致请求堆积

Catalina的Engine组件有一个线程池，负责处理所有进入的请求。这个线程池的大小直接决定了Tomcat的并发处理能力。默认配置下，最大线程数是200，最小空闲线程数是10，这个配置对于大多数中小型应用够用，但在高并发场景下可能成为瓶颈。

线程池打满的典型现象是：请求响应时间突然变长，日志里出现大量超时，但CPU和内存都不高。这是因为请求在队列里排队，等待空闲线程来处理。排查方法是看Tomcat的线程状态，可以通过JMX或者/manager/status页面查看当前活跃线程数和队列长度。如果活跃线程数长期接近最大值，说明需要调大线程池。

调大线程池不是简单地改个数字就行，得考虑下游系统的承受能力。比如你的应用要调用数据库，数据库连接池只有50个连接，你把Tomcat线程池调到500，结果就是大量线程阻塞在获取数据库连接上，反而更糟。正确的做法是先压测，找到系统的瓶颈点，然后根据瓶颈点来配置线程池。一般来说，Tomcat线程池的最大值应该和下游资源池的大小相匹配，或者略大一些。

4.4 Session持久化配置遗漏导致重启丢会话

Catalina的Context组件负责管理Session。默认情况下，Session是存在内存里的，Tomcat一重启就全没了。对于需要保持登录状态的应用，这会导致用户被强制登出。解决办法是配置Session持久化，让Tomcat在关闭时把Session写到磁盘，启动时再读回来。

配置方式是在Context里加一个Manager元素，指定pathname属性。比如：

<Context path="/myapp" docBase="myapp"> <Manager className="org.apache.catalina.session.StandardManager" pathname="/tmp/myapp-sessions.ser"/> </Context>

这样Tomcat关闭时会把Session序列化到指定文件，启动时再反序列化回来。但要注意，Session里的对象必须实现Serializable接口，否则序列化会失败。另外，如果应用是集群部署的，单机持久化就不够了，需要配置Session共享，比如用Redis或者Tomcat自带的集群方案。

4.5 Valve顺序配错导致逻辑不执行

前面说过，Pipeline里的Valve是按顺序执行的。如果你往Pipeline里加了自定义Valve，但顺序配错了，可能导致逻辑不执行或者执行结果不符合预期。比如你把一个做权限校验的Valve加在了StandardContextValve后面，那它永远不会被执行，因为StandardContextValve已经把请求转发到下一个容器了，不会再把控制权交回来。

Valve的顺序由server.xml里的配置顺序决定，或者由context.xml里的<Valve>元素顺序决定。内置的Standard Valve总是最后执行，自定义Valve应该加在它们前面。如果你不确定顺序，可以在Valve的invoke()方法里打日志，看实际执行顺序是否符合预期。这个坑比较隐蔽，因为配错了不会报错，只是逻辑静默失效，排查起来比较费时间。

5. 从源码视角理解Catalina的设计取舍

5.1 为什么用组合模式而不是继承

Catalina的容器组件用的是组合模式，父容器持有子容器的引用，而不是通过继承来扩展功能。这个选择背后有很实际的考虑。

如果用继承，那么Engine要继承Host，Host要继承Context，Context要继承Wrapper，形成一条继承链。这样做的问题是耦合太紧，每一层都依赖上一层的实现细节，想单独替换某一层几乎不可能。而且Java是单继承的，一旦继承了父容器，就没法再继承其他类了，扩展性大打折扣。

用组合模式就不一样了。每个容器组件都是独立的类，只依赖接口不依赖具体实现。父容器通过接口调用子容器的方法，子容器可以自由替换。比如你可以把默认的StandardContext替换成自定义的Context实现，只要实现了Context接口就行，其他层完全不受影响。这种灵活性是Tomcat能够支持多种部署方式和扩展机制的基础。

5.2 Lifecycle接口的事件驱动机制

Catalina的另一个核心设计是Lifecycle接口。所有容器组件都实现了这个接口，它定义了组件的生命周期状态和状态转换事件。当组件状态发生变化时，会触发相应的事件，注册的监听器会收到通知并执行相应逻辑。

这个机制的好处是解耦。比如Context启动时需要做很多事情：解析web.xml、创建Servlet实例、初始化Filter、启动Session管理器等等。如果把这些逻辑都写在Context的start()方法里，代码会非常臃肿。用事件驱动的方式，每个功能模块注册一个监听器，监听Context的启动事件，各自处理自己的初始化逻辑。Context本身只需要负责状态转换和事件通知，不需要知道具体有哪些功能模块。

这个设计也方便了扩展。你想在Context启动时加点自定义逻辑，不需要改Context的代码，只需要写一个监听器注册进去就行。Tomcat内部的很多功能，比如JSP支持、JMX注册、日志初始化，都是通过监听器实现的。理解了这个机制，你看Tomcat源码时就不会被各种Listener搞晕。

5.3 类加载器层次结构的设计意图

Catalina的类加载器结构是理解Tomcat行为的关键。它不像普通的Java应用那样只有一层类加载器，而是分成了好几层，每层负责加载不同范围的类。

最顶层是Bootstrap类加载器，加载JVM自身的核心类。往下一层是System类加载器，加载CLASSPATH环境变量指定的类，主要是Tomcat启动所需的类。再往下是Common类加载器，加载Tomcat的lib目录下的类，这些类对所有应用可见。然后是Catalina类加载器，加载Tomcat自身的实现类。最后是Webapp类加载器，每个Context一个，加载WEB-INF/classes和WEB-INF/lib下的类，只对当前应用可见。

这个层次结构的设计意图是隔离和共享的平衡。Common类加载器加载的类所有应用共享，节省内存；Webapp类加载器加载的类应用独享，保证隔离。但这也带来了前面提到的类加载器冲突问题。理解这个结构之后，你就能判断一个类应该放在哪个目录下，以及为什么会出现ClassNotFoundException。

提示：Tomcat默认的类加载顺序是先父后子，也就是先尝试用父类加载器加载，加载不到再用自己的。但可以通过配置<Loader delegate="false"/>改成先自己加载再委托父加载器，这就是所谓的Webapp类加载器优先模式。这个配置在某些框架下是必须的，比如应用里用了和Tomcat内置版本冲突的库时。

6. 几个能直接抄的配置模板与调优参数

6.1 生产环境server.xml关键配置

下面这份配置是我在多个生产环境里用过的，去掉了一些不常用的元素，保留了核心部分。你可以直接对照修改自己的server.xml。

<Server port="8005" shutdown="SHUTDOWN"> <Service name="Catalina"> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" maxThreads="400" minSpareThreads="50" acceptCount="200" maxConnections="8000" redirectPort="8443"/> <Engine name="Catalina" defaultHost="localhost"> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false"> <Context path="/myapp" docBase="/data/apps/myapp" reloadable="false" crossContext="false"> <Manager className="org.apache.catalina.session.StandardManager" pathname="/data/sessions/myapp.ser"/> </Context> </Host> </Engine> </Service> </Server>

几个关键参数的解释：maxThreads是最大工作线程数，根据压测结果调整；acceptCount是等待队列长度，当所有线程都在忙时，新请求会进入这个队列，队列满了才会拒绝；maxConnections是最大连接数，NIO模式下可以设得比maxThreads大很多；autoDeploy设为false是为了避免生产环境自动部署带来的不确定性，部署操作应该由运维流程控制；reloadable设为false是为了关闭类变更检测，提升性能。

6.2 线程池与连接数的匹配计算

线程池大小不是拍脑袋定的，有一个粗略的计算公式可以参考：

最大线程数 = (目标QPS × 平均响应时间) / 并发系数

假设你的应用目标QPS是1000，平均响应时间是50毫秒，并发系数取0.8，那么最大线程数大约是(1000 × 0.05) / 0.8 ≈ 62。但这只是理论值，实际还要考虑下游资源的限制。如果数据库连接池只有20个连接，那线程数设到62也没用，多出来的线程都会阻塞在获取连接上。

我的经验是先按理论值配置，然后压测，观察线程池的活跃线程数和队列长度。如果活跃线程数长期低于最大值的70%，说明配置偏大，可以适当调小；如果队列长度经常大于0，说明配置偏小，需要调大。调大之前先确认下游资源是否充足，否则只是把瓶颈从Tomcat转移到了数据库。

6.3 常见问题速查表

这张表建议存下来，遇到问题先对照排查，能省不少时间。很多问题其实都是配置层面的，不需要改代码就能解决。

7. 我在实际运维中总结的几条经验

Catalina这个模块，刚看的时候觉得组件多、关系复杂，但真正理解之后会发现它的设计非常清晰。组合模式加生命周期事件，把复杂的容器管理拆成了一个个独立的关注点，每层只管自己的事，层与层之间通过接口交互。这种设计思路值得在写业务代码时借鉴。

第一条经验是不要轻易改Tomcat的默认配置。很多人一上来就调线程池、改类加载策略，结果引入了新的问题。默认配置是经过大量测试的，适用于大多数场景。只有在明确知道瓶颈在哪、并且有压测数据支撑的情况下，才去调整。我见过太多因为乱调参数导致的问题，最后回滚到默认配置反而好了。

第二条经验是日志级别不要开太细。Catalina的日志在DEBUG级别下会打印大量请求流转信息，对排查问题有帮助，但在生产环境开着会严重影响性能，还会把磁盘写满。建议生产环境用INFO级别，需要排查时临时调到DEBUG，排查完立刻调回来。可以通过JMX动态调整日志级别，不需要重启。

第三条经验是定期检查Context的关闭情况。Tomcat在停止时，如果某个Context没有正常关闭，会导致类加载器泄漏，进而引发内存溢出。判断方法是看Tomcat停止日志里有没有The web application appears to have started a thread but has failed to stop it这样的警告。如果有，说明应用里有线程没有正确关闭，需要检查代码里的线程池和定时任务是否在contextDestroyed时做了清理。

第四条经验是用JMX监控Catalina的关键指标。Tomcat暴露了很多MBean，可以监控线程池、请求处理时间、Session数量等。把这些指标接入监控系统，能在问题发生前发现异常趋势。比如线程池活跃数持续上升，说明可能有慢请求堆积；Session数量异常增长，说明可能有爬虫或者攻击。这些指标比看日志更直观，也更及时。

最后说一个容易被忽略的点：Catalina的版本升级要谨慎。Tomcat不同版本之间，Catalina的实现可能有较大变化，特别是一些内部API。如果你的应用依赖了Tomcat的内部类，升级时可能会编译失败或者运行时报错。升级前一定要在测试环境充分验证，重点测试Servlet、Filter、Listener、Session这些和Catalina强相关的功能。