Tomcat性能优化：从JVM到连接器的调优指南

Tomcat性能优化没有一劳永逸的配置，核心思路是根据服务器硬件和业务并发量，调整JVM内存、连接器参数和线程池，让Tomcat在稳定运行的前提下处理更多请求。
本文从零基础出发，给出可落地的配置步骤和验证方法。

优化前需要确认的基础信息

动手改配置之前，先确认三件事：

• Tomcat版本与运行模式：执行 catalina.sh version 或查看 bin/version.sh 输出，确认是Tomcat 8、9还是10，不同版本默认连接器实现有差异。
• 服务器硬件：用 free -h 查看内存，nproc 查看CPU核数，后续JVM参数要参考这些数值。
• 当前配置备份：复制 conf/server.xml 和 bin/setenv.sh（如果存在），改错时可以快速回滚。

如果使用宝塔面板，
Tomcat配置文件通常在 /www/server/tomcat/conf/server.xml，
JVM参数在 /www/server/tomcat/bin/setenv.sh。

JVM内存参数怎么调

Tomcat本身是Java应用，堆内存过小会频繁GC，过大会导致单次GC停顿变长。

编辑 bin/setenv.sh（没有就新建），加入以下内容：

export CATALINA_OPTS="$CATALINA_OPTS -Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC"

几个关键点：

• -Xms 和 -Xmx 建议设为相同值，避免堆动态扩容带来额外开销。数值一般取物理内存的50%~70%，例如4G内存可设2G到3G。
• -XX:MetaspaceSize 和 MaxMetaspaceSize 控制元空间，避免类加载过多时频繁Full GC。
• -XX:+UseG1GC 在多数场景下比默认的Parallel GC更平稳，适合堆内存较大的情况。

改完后重启Tomcat，用 jstat -gc 1000 观察GC频率和耗时，如果Full GC频繁且耗时长，说明堆内存或元空间仍偏小。

连接器与线程池配置

连接器负责接收请求，线程池决定同时处理请求的能力。
打开 conf/server.xml，找到 标签，参考以下调整：

参数含义与建议：

• maxThreads：最大工作线程数，决定同时处理的请求上限。不是越大越好，需结合CPU核数，一般设为CPU核数的50到100倍，但不超过1000。
• acceptCount：等待队列长度，当线程忙时新请求进入队列。设为200到500，过大可能导致请求超时。
• maxConnections：最大连接数，NIO模式下可设10000或更高，但受限于系统文件描述符。
• compression：开启压缩可减少传输量，但增加CPU开销。静态资源多或带宽紧张时建议开启。

如果应用并发很高，可以考虑配置共享线程池，在 标签内添加：

然后在 中引用 executor="tomcatThreadPool"。

容易被忽略的系统层限制

Tomcat调优不只是改配置文件，操作系统层面也有几个常见瓶颈：

• 文件描述符限制：用 ulimit -n 查看，如果只有1024，高并发下会报“Too many open files”。在 /etc/security/limits.conf 中增加 * soft nofile 65535 和 * hard nofile 65535，重新登录后生效。
• TCP连接队列：检查 net.core.somaxconn，默认值可能偏小，可调整为 net.core.somaxconn = 65535，修改 /etc/sysctl.conf 后执行 sysctl -p。
• TIME_WAIT过多：如果 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 显示大量TIME_WAIT，可开启 net.ipv4.tcp_tw_reuse = 1，但需确认内核支持。

改完配置怎么验证效果

重启Tomcat后，按以下步骤确认优化是否起作用：

1. 检查Tomcat是否正常启动：查看 logs/catalina.out 末尾有无 Server startup in [xxx] milliseconds。
2. 用 ps -ef | grep tomcat 找到进程PID，执行 jstat -gc 1000 10，观察10秒内GC次数和耗时。若Young GC频繁但耗时短，通常正常；Full GC次数为0或极少，说明内存配置合理。
3. 用 ss -lnt 查看8080端口监听状态，确认连接数未被打满。
4. 用压测工具（如Apache Bench）测试：ab -n 1000 -c 100 http://127.0.0.1:8080/，观察Requests per second和Failed requests。对比优化前后的数值，判断调整是否有效。

如果压测中出现超时或错误，先检查Tomcat日志和系统资源（CPU、内存、网络），再逐步调整参数。

调优中容易踩的坑

• 盲目加大maxThreads：线程数超过CPU处理能力后，上下文切换开销反而降低吞吐量。建议从200开始，逐步增加并观察CPU使用率。
• 忽略应用本身性能：如果数据库查询慢或代码有死循环，调Tomcat参数收效甚微。先用 jstack 查看线程状态，排查应用层问题。
• JVM参数只改-Xmx：不设置Metaspace可能导致类加载过多时Full GC，建议同时设置。
• 不重启就生效：server.xml 和 setenv.sh 修改后必须重启Tomcat，否则配置不会生效。
• 线上直接改配置：建议先在测试环境验证，确认无误后再应用到生产环境，并保留回滚方案。

Tomcat性能优化是一个持续调整的过程，不同业务场景的最佳参数可能不同。
建议每次只改一个维度，记录前后指标，逐步找到适合自己服务器的配置。
如果并发量持续增长，还需要考虑Nginx反向代理、静态资源分离或集群部署等更上层的方案。