躬行笔记
首页 » 运维知识 » 深度拆解Tomcat：从架构设计到生产实践，这些年踩过的坑都在这里了
运维知识
悠悠
2026年4月8日

深度拆解Tomcat：从架构设计到生产实践，这些年踩过的坑都在这里了

说起Tomcat，估计每个搞Java开发和运维的同学都不陌生。但是真要问你Tomcat的内部工作原理，能完整说清楚的人其实不多。我在生产环境摸爬滚打这些年，从最开始的小白到现在能独当一面，Tomcat这个"老朋友"没少让我吃苦头。

今天就把我这些年对Tomcat的理解和实战经验分享给大家，不是那种照本宣科的理论，而是真正在生产环境中能用得上的干货。

为什么要深入了解Tomcat

前段时间公司新来了个小伙子，部署应用的时候直接用默认配置就上线了。结果呢？服务刚上线没几天，用户量一上来就开始各种502、504错误。领导找过来问情况，那个场面...想想都尴尬。

这种事情其实很常见，很多人觉得Tomcat嘛，下载下来启动就能用，有什么难的？但实际上，默认配置的Tomcat在生产环境基本上就是个定时炸弹。

Tomcat的核心架构到底是怎么回事

我记得刚开始接触Tomcat的时候，各种概念搞得我云里雾里的。什么Connector、Container、Engine、Host...听起来就头大。后来慢慢摸索，发现其实Tomcat的架构设计还是很有意思的。

Server - 最顶层的管理者

Server就是整个Tomcat实例，一个JVM进程里只有一个Server。你可以把它理解成一个大管家，负责管理下面所有的组件。在server.xml里面，最外层的<Server>标签就是它。

我之前遇到过一个问题，就是在同一台机器上部署多个Tomcat实例的时候，Server的shutdown端口冲突了。默认是8005端口，如果不改的话，第二个实例启动就会报错。这种小细节在生产环境特别容易被忽略。

Service - 服务的组织者

Service在Server下面，主要作用是把Connector和Engine组织在一起。通常情况下，一个Server里只有一个Service，叫做"Catalina"。

Connector - 网络通信的门面

Connector是Tomcat对外提供服务的入口，负责监听端口、接收请求。这里面有两个重要的组件：

Coyote - 这是Tomcat的HTTP连接器，专门处理HTTP协议。它支持多种I/O模型，比如BIO、NIO、NIO2、APR。我在生产环境一般都用NIO，性能和稳定性都不错。

记得有一次线上出现了大量的TIME_WAIT连接，排查了半天发现是BIO模式下的连接没有及时释放。后来切换到NIO模式，问题就解决了。

Jasper - 这是JSP引擎，负责把JSP页面编译成Servlet。虽然现在前后端分离比较多，JSP用得少了，但在一些老项目里还是经常能见到。

Container - 业务处理的核心

Container是一个层次结构，从外到内分别是Engine、Host、Context、Wrapper。

Engine - 整个Servlet引擎，一个Service只有一个Engine。它负责处理所有的请求，并将请求分发给合适的Host。

Host - 代表一个虚拟主机，可以配置多个域名指向同一个Tomcat实例。比如你可以让www.example.com和api.example.com都指向同一个Tomcat，但处理不同的应用。

Context - 代表一个Web应用，也就是我们部署的WAR包或者目录。每个Context有自己独立的类加载器，这样不同应用之间就不会互相影响。

Wrapper - 代表一个Servlet，是最小的处理单元。

请求处理的完整流程

理解了架构，我们来看看一个HTTP请求在Tomcat中是怎么被处理的。

当用户在浏览器输入网址访问我们的应用时，请求会这样流转：

  1. Connector接收请求 - Coyote监听到8080端口有请求进来，创建Request和Response对象
  2. 协议解析 - 解析HTTP协议，提取请求头、请求体等信息
  3. 请求分发 - Engine根据Host头信息找到对应的虚拟主机
  4. 应用定位 - Host根据URL路径找到对应的Context（Web应用）
  5. Servlet匹配 - Context根据URL模式匹配到具体的Servlet
  6. 业务处理 - Wrapper调用Servlet的service方法处理业务逻辑
  7. 响应返回 - 处理结果通过Connector返回给客户端

这个过程看起来复杂，但实际上Tomcat内部有很多优化。比如对象池、连接池等技术，避免频繁创建销毁对象。

生产环境的配置优化

说了这么多理论，现在来点实际的。我把这些年在生产环境踩过的坑和总结的经验分享一下。

JVM参数调优

这是最基础也是最重要的。我见过太多因为JVM参数配置不当导致的生产事故。

export JAVA_OPTS="-server -Xms4g -Xmx4g -XX:NewRatio=1 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0"

这里几个关键点：

  • -Xms和-Xmx设置成一样大，避免堆内存动态扩展的性能损耗
  • NewRatio=1表示新生代和老年代1:1，对于Web应用比较合适
  • 使用CMS垃圾收集器，减少Full GC的停顿时间

我之前遇到过一个案例，应用经常出现几秒钟的停顿，用户体验很差。后来发现是默认的Serial GC导致的，换成CMS后问题就解决了。

Connector优化

默认的Connector配置在高并发场景下肯定是不够用的：

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
           connectionTimeout="30000"
           maxConnections="2000"
           maxThreads="500"
           minSpareThreads="50"
           acceptCount="200"
           enableLookups="false"
           compression="on"
           compressionMinSize="2048"
           compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json"/>

这些参数的含义：

  • maxConnections: 最大连接数，超过这个数的连接会被放到队列里等待
  • maxThreads: 最大工作线程数，处理请求的核心参数
  • acceptCount: 当所有线程都忙的时候，队列中等待的连接数
  • compression: 开启压缩，能显著减少网络传输量

内存和线程池调优

Thread Pool的配置直接影响并发处理能力：

<Executor name="tomcatThreadPool" 
          namePrefix="catalina-exec-"
          maxThreads="500" 
          minSpareThreads="50"
          maxIdleTime="60000"
          prestartminSpareThreads="true"/>

我一般会根据服务器的CPU核心数来设置线程数。经验值是CPU核心数的2-4倍，但具体还是要根据业务特点来调整。I/O密集型的应用可以设置更多线程，CPU密集型的就要控制一下。

APR模式的使用

如果你的服务器并发量特别大，建议使用APR模式。APR（Apache Portable Runtime）是Apache的可移植运行库，用C语言实现，性能比Java NIO还要好。

安装APR：

# CentOS
yum install apr-devel openssl-devel
# Ubuntu
apt-get install libapr1-dev libssl-dev

然后在Connector中配置：

<Connector port="8080" protocol="org.apache.coyote.http11.Http11AprProtocol" />

我在一个高并发的电商项目中使用APR，QPS从原来的3000提升到了8000+，效果还是很明显的。

实际部署中的坑和解决方案

多实例部署

单机部署多个Tomcat实例是很常见的需求，但要注意端口冲突问题。除了HTTP端口（8080），还有shutdown端口（8005）和AJP端口（8009）都要修改。

我写了个简单的脚本来批量创建多实例：

#!/bin/bash
BASE_PORT=8080
SHUTDOWN_PORT=8005
AJP_PORT=8009

for i in {1..3}; do
    INSTANCE_NAME="tomcat$i"
    HTTP_PORT=$((BASE_PORT + i - 1))
    SHUTDOWN=$((SHUTDOWN_PORT + i - 1))
    AJP=$((AJP_PORT + i - 1))
  
    cp -r $CATALINA_HOME $INSTANCE_NAME
    sed -i "s/8080/$HTTP_PORT/g" $INSTANCE_NAME/conf/server.xml
    sed -i "s/8005/$SHUTDOWN/g" $INSTANCE_NAME/conf/server.xml
    sed -i "s/8009/$AJP/g" $INSTANCE_NAME/conf/server.xml
done

日志管理

默认的日志配置在生产环境是不够用的。我一般会这样配置：

# logging.properties
handlers = 1catalina.org.apache.juli.AsyncFileHandler, 2localhost.org.apache.juli.AsyncFileHandler

1catalina.org.apache.juli.AsyncFileHandler.level = INFO
1catalina.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina.
1catalina.org.apache.juli.AsyncFileHandler.maxDays = 30
1catalina.org.apache.juli.AsyncFileHandler.rotatable = true

特别要注意的是日志轮转，不然日志文件会越来越大，最后把磁盘撑爆。我就遇到过这种情况，某天早上收到监控报警，磁盘使用率100%，查看发现catalina.out文件有20多G...

监控和诊断

生产环境必须要有完善的监控。我一般会监控这些指标：

  1. JVM指标：堆内存使用率、GC频率、线程数
  2. Tomcat指标：活跃线程数、请求处理时间、错误率
  3. 系统指标：CPU、内存、磁盘I/O、网络I/O

可以使用JConsole、VisualVM等工具，也可以集成Prometheus + Grafana做监控大盘。

性能调优实战案例

去年有个项目，用户反馈页面加载很慢。我们排查发现是数据库连接池配置有问题：

<!-- 原来的配置 -->
<Resource name="jdbc/MyDB" 
          type="javax.sql.DataSource"
          maxTotal="20"
          maxIdle="10"
          maxWaitMillis="10000"/>

<!-- 优化后的配置 -->
<Resource name="jdbc/MyDB" 
          type="javax.sql.DataSource"
          maxTotal="100"
          maxIdle="50"
          minIdle="20"
          maxWaitMillis="30000"
          testOnBorrow="true"
          validationQuery="SELECT 1"/>

调整后响应时间从平均2秒降到了500ms以内。

容器化部署的注意事项

现在很多公司都在用Docker部署应用，Tomcat的容器化也有一些需要注意的地方。

Dockerfile优化

FROM openjdk:8-jre-alpine

# 安装APR支持
RUN apk add --no-cache apr-dev openssl-dev

# 复制Tomcat
COPY tomcat /opt/tomcat

# 设置环境变量
ENV CATALINA_HOME=/opt/tomcat
ENV CATALINA_BASE=/opt/tomcat
ENV JAVA_OPTS="-server -Xms2g -Xmx2g -XX:+UseG1GC"

# 暴露端口
EXPOSE 8080

CMD ["/opt/tomcat/bin/catalina.sh", "run"]

资源限制

在K8s中部署时要合理设置资源限制：

resources:
  requests:
    memory: "2Gi"
    cpu: "1000m"
  limits:
    memory: "4Gi"
    cpu: "2000m"

内存限制要和JVM堆内存设置匹配，不然容器可能会被OOMKilled。

故障排查经验

这些年遇到的Tomcat故障不少，分享几个典型的排查思路：

内存溢出

最常见的就是OutOfMemoryError。遇到这种问题，要先看是哪种类型的OOM：

  • java.lang.OutOfMemoryError: Java heap space - 堆内存不够
  • java.lang.OutOfMemoryError: PermGen space - 永久代不够（Java 8以前）
  • java.lang.OutOfMemoryError: Metaspace - 元空间不够（Java 8及以后）

可以通过添加JVM参数来生成堆转储文件：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/

然后用MAT或者VisualVM分析内存泄漏的原因。

线程死锁

有时候应用会突然卡住不响应，这时候要检查是否有死锁：

# 获取进程PID
jps

# 生成线程转储
jstack <pid> > thread_dump.txt

在转储文件中搜索"BLOCKED"关键字，通常能找到死锁的线程。

响应时间慢

这种问题比较复杂，需要从多个角度排查：

  1. 检查GC日志，看是否有长时间的停顿
  2. 查看数据库慢查询日志
  3. 分析应用日志，找出耗时的操作
  4. 使用APM工具做链路追踪

写在最后

Tomcat作为Java Web应用的重要基础设施，深入理解它的工作原理对我们的日常运维工作帮助很大。这篇文章总结了我这些年的实战经验，希望能帮到大家少踩一些坑。

当然，技术是不断发展的，Tomcat也在持续更新。现在Tomcat 10已经支持Jakarta EE了，还有很多新特性值得关注。我们做运维的，就是要保持学习的心态，不断提升自己的技能。

如果你在生产环境中遇到了Tomcat相关的问题，欢迎留言讨论。大家一起交流，共同进步！

记得关注@运维躬行录，我会持续分享更多实战经验和技术干货。如果这篇文章对你有帮助，别忘了点赞转发哦~

公众号：运维躬行录
个人博客：躬行笔记

文章目录

博主介绍

热爱技术的云计算运维工程师，Python全栈工程师，分享开发经验与生活感悟。
欢迎关注我的微信公众号@运维躬行录，领取海量学习资料

微信二维码