从内核到应用：Tomcat/Jetty 生产环境深度调优实践

作者： /

本文旨在为有经验的工程师提供一份关于 Tomcat/Jetty 这类 Java Web 容器在生产环境下的深度调优指南。我们将绕开基础概念，直击问题的核心：如何将高层的配置参数与底层的操作系统、JVM、网络协议栈行为进行关联，从而做出科学、可量化的调优决策。本文的目标不是一份参数清单，而是一套贯穿“现象-原理-实现-权衡-演进”的完整方法论，适用于高并发、低延迟的严肃业务场景，如交易系统、实时风控或大型电商后端。

现象与问题背景

在未经过深度调优的生产环境中，我们经常会遇到一系列令人困惑的性能问题。这些问题通常表现为系统在面临压力时的“非线性”行为，而不是简单的性能下降：

  • 吞吐量瓶颈（TPS Plateau）：当流量增加时，系统的 TPS（Transactions Per Second）达到某个阈值后不再增长，甚至开始下降，同时 CPU 使用率飙升至 100%。
  • 延迟毛刺（Latency Spikes）：系统平均响应时间（Average Latency）看似正常，但 P99 或 P999 延迟却出现无法忍受的尖峰，导致上游服务频繁超时，引发雪崩效应。
  • 内存溢出（OOM Killer）：在长时间运行或流量高峰后，服务因 OutOfMemoryError 而崩溃，即便物理内存看似充裕。容器化环境中，这通常表现为 Pod 被 OOMKilled。
  • 连接超时/拒绝：客户端或上游负载均衡（如 Nginx）日志中出现大量 “Connection timed out” 或 “Connection refused”，但应用服务器的日志却毫无异常，仿佛请求从未到达。

这些现象的根源，往往不是业务代码的逻辑缺陷，而是对 Web 容器工作模型的理解不足，导致其配置与底层系统资源（CPU、内存、网络）之间产生了严重的错配。默认配置的 Tomcat/Jetty 是为通用场景设计的，它无法预知你的应用是 CPU 密集型还是 I/O 密集型，也无法知晓你的部署环境是 2 核 4G 的容器还是 64 核 256G 的物理机。

关键原理拆解

要理解调优，我们必须回归第一性原理。Web 容器本质上是一个基于 Java 的网络服务器，其性能受限于 I/O 模型、线程模型、内存管理和 TCP 协议栈这四个基本面。这部分我们切换到严谨的学术视角。

I/O 模型：从 BIO 到 NIO/epoll

Web 容器的核心是处理网络连接。早期 Web 容器（如 Tomcat 5 之前）采用的是 BIO（Blocking I/O）模型，即一个线程处理一个连接。这种模型的致命缺陷在于，当连接上的数据未就绪时，处理线程会进入阻塞（`BLOCKED`）状态，放弃 CPU 执行权，直到数据到达。在 C10K（并发一万个连接）的场景下，这意味着需要上万个线程，操作系统内核在线程调度上的开销将压垮整个系统。每个线程栈本身也会消耗大量内存（通常是 1MB）。

现代 Web 容器（Tomcat 8+、Jetty）普遍采用 NIO（Non-Blocking I/O）模型。其核心是事件驱动机制，依赖于操作系统的 `select`、`poll` 或更高效的 `epoll`（Linux）/`kqueue`（BSD）系统调用。在 Linux 环境下，NIO Connector 的底层实际上是 `epoll`。它允许一个或少数几个线程（称为 Poller/Selector 线程）监控成千上万个 Socket 连接。只有当某个 Socket 的状态变为“可读”或“可写”时，`epoll_wait` 系统调用才会返回，并将这个事件通知给应用程序。此时，应用程序才从线程池中取出一个工作线程来处理这个“真正有事可做”的连接。这种模式下，线程数量与连接数量解耦，少量线程即可支撑海量连接，极大地降低了资源消耗和上下文切换的开销。

线程池模型：资源隔离与任务执行

即使在 NIO 模型下，实际的业务逻辑处理（例如执行 Servlet 的 `service` 方法）仍然需要线程。Tomcat/Jetty 使用 Executor 组件（一个标准的线程池实现）来管理这些工作线程。理解线程池的行为至关重要：

  • 核心线程数（Core Pool Size）：线程池中始终保持存活的线程数量，即使它们处于空闲状态。这是为了应对突发流量，避免了创建新线程的开销。
  • 最大线程数（Maximum Pool Size）：线程池能够容纳的最大线程数量。当工作队列满了之后，如果当前线程数小于最大线程数，线程池会创建新线程。
  • 工作队列（Work Queue）：当所有核心线程都在忙时，新来的任务会进入这个队列排队。队列的存在起到了缓冲作用，但也是延迟的来源之一。
  • 拒绝策略（Rejection Policy）：当工作队列已满且线程数达到最大值时，新任务的处理方式。默认是抛出异常。

一个请求从被接收到处理完成，其生命周期与线程池状态息息相关。线程池的配置直接决定了系统的并发处理能力和响应延迟。

TCP 协议栈：被忽视的瓶颈

在 Tomcat/Jetty 接收到一个连接之前，这个连接请求必须先经过操作系统的 TCP 协议栈。这里有一个关键的队列：TCP Backlog Queue。当应用程序调用 `listen(socket, backlog)` 系统调用时，`backlog` 参数指定了这个队列的大小。这个队列分为两部分：

  • SYN Queue (半连接队列)：存放已收到客户端 SYN 包，但尚未完成三次握手的连接。
  • Accept Queue (全连接队列)：存放已完成三次握手，等待被应用程序 `accept()` 的连接。

当 Tomcat 的 Acceptor 线程因为繁忙（例如，工作线程池已满，无法接收新任务）而来不及调用 `accept()` 时，新完成握手的连接就会在 Accept Queue 中排队。如果这个队列满了，内核会拒绝新的连接请求，这正是客户端看到 “Connection refused” 的直接原因。

系统架构总览

为了将原理与实践结合，我们必须在脑中构建一幅清晰的请求处理流程图。以 Tomcat 的 NIO Connector 为例，一个 HTTP 请求的旅程如下：

  1. 网络 -> OS 内核: 客户端发起 TCP 连接请求。内核 TCP/IP 协议栈处理三次握手，成功后将连接放入 Accept Queue。
  2. Acceptor 线程: Tomcat Connector 中有一个或多个 Acceptor 线程，它们的唯一职责就是循环调用 `accept()` 从 Accept Queue 中取出连接，并将其封装成一个 SocketChannel 对象。
  3. Poller 线程: Acceptor 将 SocketChannel 注册到一个 Poller 线程维护的 Selector 上。Poller 线程循环调用 `select()` (底层是 `epoll_wait`) 来监听其负责的所有 SocketChannel 的 I/O 事件。
  4. 事件派发: 当某个 SocketChannel 上有数据可读时，Poller 线程将其封装成一个任务（SocketProcessor），并提交给 Executor（即工作线程池）。
  5. Executor (工作线程池): 线程池从任务队列中取出一个任务。
  6. Worker 线程: 一个空闲的 Worker 线程获得该任务，开始读取 HTTP 请求报文、解析、执行 Servlet 容器的 Filter 链和最终的业务 Servlet，生成响应，并通过 SocketChannel 写回客户端。
  7. 生命周期结束: 请求处理完毕，Worker 线程归还给线程池。如果是 Keep-Alive 连接，SocketChannel 会被 Poller 线程继续监控。

从这个流程可以看出，瓶颈可能出现在任何一个环节：TCP Accept Queue 溢出、Acceptor 处理不过来、Poller 负载过高、或者最常见的——Executor 工作线程池耗尽。

核心模块设计与实现

现在，我们切换到极客工程师的视角，看看这些原理如何映射到 Tomcat `server.xml` 的具体配置参数上。Jetty 的参数名称不同，但核心思想是相通的。

Connector 参数调优

Connector 是处理网络连接的第一道关卡，这里的配置决定了容器能“接住”多大的流量。


<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           maxConnections="10000"
           acceptCount="100"
           maxThreads="200"
           minSpareThreads="25" />
  • `protocol`: 在现代 Tomcat 中，`HTTP/1.1` 默认就是 NIO。如果你需要启用 OpenSSL 的原生能力（例如为了更高的 TLS 性能），可以配置为 `org.apache.coyote.http11.Http11AprProtocol`，但这需要安装 APR (Apache Portable Runtime) 库。对于绝大多数应用，默认的 NIO 已经足够好。
  • `acceptCount`: 这直接控制了内核 TCP Accept Queue 的大小。默认值是 100。如果你的应用瞬间并发很高，并且后端 Worker 线程池可能被打满，适当调高 `acceptCount`（如 200-500）可以为系统提供一个缓冲，避免客户端立即收到 “Connection refused”。但这是一个危险的参数，调得太高会掩盖后端处理能力的不足，导致请求在队列中长时间等待，客户端虽然没有被拒绝，但会经历漫长的延迟，最终可能因超时而失败，问题反而更难排查。
  • `maxConnections`: Tomcat 能够接收和处理的最大连接数。当连接数达到此值时，Acceptor 线程会暂停接受新连接。这个值必须大于 `maxThreads`。对于高并发长连接（如 WebSocket）或大量 Keep-Alive 连接的场景，这个值需要设置得相对较大（如 10000 或更高），因为它代表的是“持有”的连接数，而不是“正在处理”的连接数。

Executor (线程池) 参数调优

这是性能调优的核心，直接决定了业务代码的并发执行能力。


<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
    maxThreads="200" minSpareThreads="25" maxIdleTime="60000" />
  • `maxThreads`: 工作线程池的最大线程数。这是最关键但最容易被误解的参数。它不是越大越好。一个理想的 `maxThreads` 值应该基于应用的特性和部署环境来计算：
    • CPU 密集型应用：例如，进行大量计算、图像处理、复杂算法。在这种场景下，理想的线程数应该约等于 CPU 的核心数。多余的线程只会因为争抢 CPU 时间片而增加上下文切换的开销，导致性能下降。
    • I/O 密集型应用：例如，应用的大部分时间都在等待数据库返回数据、调用外部 RPC 服务或读写文件。在这种场景下，线程在等待 I/O 时处于 `BLOCKED` 或 `WAITING` 状态，不消耗 CPU。因此，线程数可以远大于 CPU 核心数。一个经典的估算公式是：`线程数 = CPU 核心数 * (1 + 平均等待时间 / 平均计算时间)`。在实践中，对于一个典型的 Web 应用（大量数据库交互），将 `maxThreads` 设置为 CPU 核心数的 5 到 10 倍（例如，在 8 核机器上设置为 40-80）是一个不错的起点，然后通过压力测试进行微调。

    一个常见的错误是无脑设置为 1000 或 2000，这在高负载下几乎必然会导致 CPU 疲于线程调度，系统整体性能急剧下降。

  • `minSpareThreads`: 核心线程数，或称“热备”线程数。Tomcat 启动后会创建这么多线程等待请求。当流量高峰到来时，这些线程可以立即投入工作，无需经历创建线程的延迟。这个值可以根据应用的日常负载来设定，确保能平滑处理平均流量。
  • `maxIdleTime`: 当线程数超过 `minSpareThreads` 时，空闲线程在被回收之前可以存活的时间（毫秒）。默认 60 秒。这个设置可以在流量高峰过后，平缓地缩减线程池，释放资源。

JVM 内存调优

对于 Java 应用，JVM 调优是绕不开的话题。对于 Web 容器，我们的目标是：让绝大多数请求创建的短生命周期对象在 Young Generation（新生代）就被回收，避免进入 Old Generation（老年代），从而减少昂贵的 Full GC。


# catalina.sh or setenv.sh
export CATALINA_OPTS="-server -Xms4g -Xmx4g -Xmn1536m \
-XX:+UseG1GC -XX:MaxGCPauseMillis=200 \
-XX:+ParallelRefProcEnabled -XX:+UnlockExperimentalVMOptions \
-XX:+AggressiveOpts -XX:G1HeapRegionSize=16m"
  • `-Xms` 和 `-Xmx`: 设置堆的初始大小和最大大小。在生产环境中，强烈建议将两者设置为相同的值。这可以避免在运行时动态扩展堆内存带来的性能抖动和暂停。
  • `-Xmn` (或 `-XX:NewRatio`): 新生代的大小。这是针对 Web 应用调优的关键。你需要估算系统在满负荷运行时，一个请求周期内（从开始到结束）会创建多少兆的临时对象。然后，`新生代大小` 应该大于 `(maxThreads * 每个请求的对象大小)`。这样可以确保在高并发下，所有请求的对象都能在新生代分配，并在下一次 Minor GC 时被回收。如果新生代太小，会导致对象过早地“晋升”到老年代，最终频繁触发 Full GC，造成长时间的 STW (Stop-The-World) 暂停，表现为延迟毛刺。通常，对于一个 4GB 的堆，分配 1-1.5GB 给新生代是一个合理的开始。
  • `-XX:+UseG1GC`: 使用 G1 垃圾收集器。G1 是为大内存（4GB以上）和低延迟应用设计的。相比于 CMS，它能更好地控制最大暂停时间（通过 `-XX:MaxGCPauseMillis`），避免长时间的 Full GC，非常适合 Web 服务。

性能优化与高可用设计

除了核心参数，一些周边配置也对性能和可用性有显著影响。

  • Keep-Alive: HTTP Keep-Alive 允许客户端在同一个 TCP 连接上发送多个请求，避免了每次请求都重新进行三次握手的开销。Tomcat 默认开启。`keepAliveTimeout` 参数控制一个空闲的 Keep-Alive 连接在被关闭前能保持多久。这个值需要权衡：太长会占用过多连接资源（`maxConnections`），尤其是在面对大量不活跃客户端时；太短则失去了 Keep-Alive 的优势。通常可以与上游负载均衡（如 Nginx）的 `keepalive_timeout` 保持一致。
  • Gzip 压缩: 通过在 Connector 上配置 `compression=”on”` 和 `compressableMimeType` 可以开启 Gzip 压缩，极大地减少传输内容的大小，节省带宽。这是一个典型的 CPU 与带宽的权衡。对于文本类响应（JSON、HTML、JS、CSS），压缩效果显著，值得开启。
  • 健康检查与优雅停机: 在现代架构（特别是微服务和容器化）中，服务必须能向注册中心或负载均衡器报告其健康状况。你需要一个轻量级的健康检查端点（如 `/health`），并且这个端点不应占用宝贵的业务处理线程。对于优雅停机，Tomcat 提供了 shutdown hook 机制。当收到 `SIGTERM` 信号时，它会停止接受新连接，并等待已有的请求处理完成，在超时后强制关闭。这对于保证部署更新时不丢失用户请求至关重要。
  • 监控先行: 任何没有监控的调优都是盲人摸象。你必须通过 JMX、Prometheus Exporter 或 APM 工具（如 SkyWalking、New Relic）来持续监控关键指标：
    • 线程池: `currentThreadCount` (当前线程数), `currentThreadsBusy` (繁忙线程数), `maxThreads`。观察繁忙线程数是否经常触及 `maxThreads` 是判断线程池是否足够的关键。
    • JVM 内存/GC: 堆内存各分代的使用情况、GC 的频率和耗时（尤其是 Full GC）。
    • Connector: `bytesReceived`, `bytesSent`, `processingTime`, `errorCount`。

架构演进与落地路径

调优不是一蹴而就的活动，而是一个持续迭代的过程。一个务实的落地策略如下：

  1. 阶段一：基线建立与监控
    • 在初始阶段，不要过度调优。使用一个相对保守的配置。例如，`maxThreads` 设置为 CPU 核心数的 2-4 倍。
    • 最重要的一步是建立完善的监控体系。确保你能看到上述所有关键性能指标。
    • 设置合理的 JVM 内存参数，特别是 `-Xms` 和 `-Xmx` 相等，并选择 G1 GC。
  2. 阶段二：压力测试与瓶颈分析
    • 在预生产环境中，使用 JMeter、Gatling 等工具模拟真实的线上流量模式进行压力测试。
    • 观察监控数据，定位瓶颈。是 CPU 耗尽？是 Full GC 频繁？还是数据库响应慢导致线程池耗尽？
    • 根据瓶颈类型进行针对性调优。如果是 I/O 密集型导致线程池耗尽，逐步增加 `maxThreads`，观察 TPS 和延迟的变化曲线，找到拐点。如果是 GC 问题，分析 GC 日志，调整新生代大小。
  3. 阶段三：生产环境灰度与持续优化
    • 将优化后的配置灰度发布到一小部分生产实例上。
    • 密切关注生产环境的监控数据和业务指标，与未优化的实例进行对比，验证调优效果。
    • 根据线上真实流量的反馈，进行微调。例如，你可能会发现早晚高峰需要不同的线程池水位，这可能需要更动态的调控机制或结合云环境的自动伸缩（HPA）。
  4. 阶段四：云原生环境下的新思考
    • 在 Kubernetes 等容器编排环境中，调优的思路有所转变。除了“垂直”地调优单个 Pod 内的 Tomcat 参数，“水平”扩展变得更加容易和重要。
    • 此时，单个 Pod 的配置目标可能不是追求极致的单机性能，而是追求“稳定可预测”的性能。通过 HPA (Horizontal Pod Autoscaler)，当 CPU 或内存利用率超过阈值时，系统会自动增加 Pod 数量。
    • 在这种模式下，JVM 内存设置需要与 K8s 的 `resources.limits.memory` 紧密配合，线程池大小也需要与 `resources.limits.cpu` 对应，避免单个 Pod 过度消耗资源，保证整个集群的稳定性。

总而言之，对 Tomcat/Jetty 的调优是一项系统工程，它要求架构师不仅理解应用本身，更要洞察其运行的底层环境。通过将高层配置与操作系统、JVM 和网络协议的深层原理相结合，我们才能摆脱经验主义的猜测试错，实现真正科学、高效的性能工程。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部