AngstEssenSeele开头
在云上做Java应用部署，Tomcat依旧是绕不开的那个“工件”。如果把Spring Boot的内嵌容器也算进去，Tomcat内核在Java服务端的占有率比我见过的大多数中间件都要夸张。但我发现一个现象：不少人把Tomcat部署上去之后，基本保持默认配置，直接怼上生产环境，直到某天大促流量进来，连接池飙红、请求排队、CPU爆表，才开始到处找“为什么我的Tomcat这么弱”。
这篇文章给你说的，是我在HoRain云这类云环境下做Java中间件交付时积累的一套Tomcat调优与集群实战打法。内容会比较长，但都属于能直接落地的硬货，覆盖从单机调优到Nginx+多实例集群、Session共享、故障转移、常见问题排障这整条链路。适合刚接手Tomcat生产环境的人，也适合做了几年开发但没系统性搞过中间件性能调优的同学。
1. 从单机到集群：先摸清Tomcat的底细
1.1 为什么默认配置撑不住生产流量
Tomcat默认配置的目标是“开箱即用”，不是“高压抗揍”。它默认的线程池、连接器参数、JVM参数都是偏保守的，目的是兼容绝大多数低并发场景。我见过不少团队直接把默认的server.xml用到上线，然后压力一上来就报Connection refused或者504。
核心问题在哪里？Tomcat的默认配置里，maxThreads是200，acceptCount是100，maxConnections是8192（NIO下默认）。看着数字不小，但实际生产环境里，请求往往不是匀速到达的，而是突刺型的。一旦瞬时并发超过线程池处理能力，新的请求就会在acceptCount队列里排队，队列满了直接拒绝连接。更糟糕的是，JVM堆内存默认只给了物理内存的1/4，GC策略也是老的Parallel Scavenger，遇到大对象或者高吞吐场景，Full GC一来，整个应用就卡壳。
所以调优的第一步不是改参数，而是理解Tomcat处理一个HTTP请求的完整路径：客户端连接进来，Acceptor接收Socket，交给Executor线程池处理，解析请求、经过Valve管道、Filter、Servlet，最后返回响应。这条路径上任何一个环节成为瓶颈，表现都是请求变慢，但根因可能完全不同，这也是为什么要分层去做调优。
1.2 部署前的基线准备：JDK选择与安装细节
很多人在Tomcat调优时忽略了一个前置条件：JDK版本。Tomcat 9对Java 8支持很好，但如果服务跑在Java 8上，G1收集器其实还不够成熟，推荐直接用Java 11或者Java 17跑Tomcat 9/10。我在云主机上通常选择OpenJDK 11，不是因为版本越新越好，而是因为LTS版本在云环境里的兼容性验证最充分。
安装JDK时有一个细节很多人踩坑：云镜像自带的OpenJDK可能是不完整的headless版本，缺少jps、jstat、jmap这些调优工具。检查方法很简单：
bash复制java -version
jps -l
如果jps命令找不到，说明装的是headless JRE，需要补装完整JDK。在CentOS/RHEL系云主机上，我一般用yum install java-11-openjdk-devel一步到位。装完之后设置好JAVA_HOME和PATH，然后把Tomcat解压到固定目录，比如/opt/tomcat，建议建立软链接，后续升级版本只换软链接指向，不用改一堆脚本里的路径。
1.3 目录结构与关键配置文件的“责任清单”
Tomcat的目录结构虽然简单，但每个目录干什么是必须清楚的。bin目录放启动关闭脚本，conf目录是调优主战场，lib目录放Tomcat自身依赖，logs目录排障要看，webapps是部署目录，work是JSP编译缓存目录。
千万不要把业务JAR包丢进lib目录，不要把多个应用的不同版本JAR混在一起。我在云上排查过太多“类冲突导致诡异报错”的问题，最后发现全是依赖管理混乱惹的祸。
配置文件的优先级和职责也要理清楚：
server.xml：核心引擎配置，连接器、Host、Engine、Cluster都在这里，90%的调优动作都围绕它。web.xml：全局Servlet配置，默认Servlet、Session超时、MIME映射。catalina.properties：类加载器扫描路径控制，有安全加固作用。catalina.sh：JVM参数注入入口，JAVA_OPTS和CATALINA_OPTS的区别要搞清楚，CATALINA_OPTS只在Tomcat启动时生效，更适合放JVM调优参数。
关于CATALINA_OPTS和JAVA_OPTS的区别，有人可能觉得随便放哪个都一样，实际上区别很大。JAVA_OPTS会被Tomcat内部的其他Java进程继承，比如通过Tomcat启动的某些辅助工具，而CATALINA_OPTS只作用于Tomcat主进程。所以像-Xmx、-Xms、-XX:+UseG1GC这类参数，规范做法是放进CATALINA_OPTS，避免影响子进程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Tomcat连接器调优：瓶颈往往堵在入口
2.1 Connector线程模型：BIO/NIO/NIO2/APR怎么选
Tomcat从8.5版本开始移除了BIO模型，原因很简单：一个线程对应一个连接的方式，在高并发场景下线程数被连接数拖死，线程上下文切换消耗大量CPU。现在主流的NIO模型下，Tomcat利用Java NIO的Selector机制，用少量线程处理大量连接，连接和请求解耦，这是生产环境默认的最佳选择。
很多文章推荐APR（Native）模式，理由是性能比NIO高，但我必须说一下实战感受：APR依赖操作系统原生库（tomcat-native），在云主机上编译安装容易出问题，而且Tomcat 9之后APR的性能优势在新版NIO面前并不明显。除非你明确知道自己在做什么，否则不要为了“性能提升”去折腾APR。NIO2和NIO的区别在于NIO2使用异步I/O，性能提升有限，但排查问题时的行为模型更复杂，我在生产环境一律用默认的NIO。
2.2 核心参数逐个拆解：maxThreads/acceptCount/maxConnections
这三个参数是最容易混淆的，但理解了整个请求排队模型后就不难了。
maxThreads是Tomcat内部线程池最多能创建的请求处理线程数。这个值设太小，高并发时请求全部排队；设太大，CPU全部消耗在线程切换上。我一般建议的基准算法是：maxThreads = CPU核数 * 200，然后根据业务耗时调整。如果是纯IO密集型业务（比如频繁查数据库、调外部接口），可以适当放大学生容量；如果是CPU密集型业务（比如加解密、逻辑计算），线程数反而要压低，避免大量线程争抢CPU。
acceptCount是操作系统底层accept队列的长度。当maxThreads用尽后，新请求会进入这个队列等待。我习惯设为maxThreads的1/2左右，太小会直接拒绝连接，太大则让请求等待时间过长，用户端表现就是一直转圈。
maxConnections是Tomcat能同时保持的连接数。对于NIO模式，默认8192一般够用。但要注意，如果请求是短连接，maxConnections消耗很快，因为TIME_WAIT状态的连接还没释放，新连接又在不断进来。这时不能一味调大maxConnections，而是要看keepAliveTimeout和连接回收机制。
2.3 压缩、超时、keepalive与静态资源缓存
很多人调优时只盯着线程池，忽略了连接的超时和压