Tomcat部署到生产环境后，如果直接使用解压后的默认配置，既容易被扫描工具识别出版本漏洞，也无法充分利用服务器资源。安全加固和性能调优是Tomcat上线前必须认真对待的两个环节，前者决定服务能不能经受住外部攻击，后者决定服务在高并发下能不能稳定运行。本文结合实际生产经验，从安全和性能两个维度给出完整的配置方案。
一、Tomcat安全加固：把攻击面缩到最小
1. 隐藏版本信息，避免暴露指纹
默认情况下，Tomcat返回的404错误页面和HTTP响应头中会包含具体的版本号，攻击者可以据此查找对应版本的已知漏洞。处理方式是修改conf/server.xml中Host节点的配置，添加ErrorReportValueClass：
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="false">
<Valve className="org.apache.catalina.valves.ErrorReportValve"
showReport="false"
showServerInfo="false"/>
</Host>同时修改conf/server.xml中Connector的server属性，把响应头中的Server字段改掉：
<Connector port="8080" protocol="HTTP/1.1"
server="AppName"/>这样即使出现错误页，也不会泄露Tomcat的具体版本。另外注意删除webapps目录下自带的docs、examples、manager、host-manager等应用，这些示例应用本身存在已知的漏洞入口，生产环境保留它们没有任何意义。
2. 关闭或保护管理页面
manager应用如果确实需要保留用于发布操作，必须强密码加IP白名单双重防护。编辑conf/tomcat-users.xml时不要使用弱口令，同时通过RemoteAddrValve限制只有内网IP可以访问：
<Context docBase="manager" path="/manager">
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="192\.168\.1\..*"/>
</Context>注意allow属性中的点号要用反斜杠转义。更稳妥的做法是把manager应用直接删除，改用脚本或CI/CD流水线完成发布。
3. 降低运行权限与禁用不必要功能
Tomcat绝对不要用root账号运行，应该创建独立的低权限用户来启动服务。配合setenv.sh设置UMASK="0077"，收紧日志和工作目录的文件权限。同时考虑在Connector上禁用不安全的HTTP方法与TRACE请求，可以在web.xml中配置安全约束拒绝TRACE、PUT、DELETE等方法，只保留GET和POST。
HTTPS加密也是必须项，通过JDK的keytool生成密钥库后配置SSL Connector：
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="200" SSLEnabled="true" scheme="https" secure="true"
keystoreFile="/opt/tomcat/conf/.keystore" keystorePass="yourPassword"
clientAuth="false" sslProtocol="TLS"
ciphers="TLS_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"/>同时建议在8080端口配置maxParameterCount和maxPostSize，限制请求参数数量和POST体积，防止恶意大报文拖垮服务。
二、Tomcat性能调优：让线程和内存各司其职
1. 连接器线程池参数调整
性能调优的第一站是conf/server.xml中的Executor和Connector。默认的maxThreads是200，并发较高的业务需要根据CPU核数和请求耗时来估算。经验公式是：如果请求大部分是IO等待，线程数可以设为CPU核数的几倍；如果是CPU密集型，线程数接近核数即可。参考配置：
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="500" minSpareThreads="50"
maxQueueSize="200" prestartminSpareThreads="true"/>
<Connector executor="tomcatThreadPool" port="8080"
protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
maxConnections="10000"
acceptCount="150"
maxKeepAliveRequests="10000"
keepAliveTimeout="20000"
compression="on" compressibleMimeType="text/html,text/xml,text/css,application/javascript,text/plain,application/json"
noCompressionUserAgents="gozilla, traviata"
URIEncoding="UTF-8"/>几个关键参数的含义需要理解清楚：maxConnections是同一时刻能建立的最大连接数，NIO模式下远大于线程数；acceptCount是连接满了之后等待队列的长度，队列太长会导致请求大量超时，一般设为100到200；maxKeepAliveRequests建议设置一个上限，避免个别连接长期占用。开启gzip压缩可以显著减少文本类响应的传输体积，但图片和视频不要再压缩，白白消耗CPU。
2. JVM内存分配策略
线程池调好后，瓶颈往往会转移到JVM内存。在setenv.sh中配置启动参数，堆大小根据服务器内存来定，一般设为物理内存的一半到三分之二，并保持初始堆和最大堆一致以避免动态扩容带来的抖动：
JAVA_OPTS="-server -Xms4g -Xmx4g -Xmn1536m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/tomcat/logs/ -Djava.security.egd=file:/dev/./urandom"
JDK 8及以上推荐使用G1收集器，它通过Region化管理能有效降低大堆下的停顿时间。MaxGCPauseMillis设为100毫秒左右对Web应用比较友好。年轻代大小的设置要结合对象的生命周期特征，如果业务有大量短生命周期的请求对象，适当增大年轻代可以减少对象过早晋升到老年代的情况。务必开启HeapDumpOnOutOfMemoryError，内存溢出时留下的堆转储文件是排查问题最重要的依据。
3. 日志与部署层面的细节优化
日志输出往往是容易被忽视的性能消耗点。访问日志的AccessLogValve如果pattern过于复杂、且写入频繁，会占用可观的IO。访问量特别大的服务可以考虑关闭访问日志，改由前置的Nginx记录。另外把autoDeploy设为false、reloadable设为false，避免Tomcat周期性扫描war包和class文件带来的额外开销，热加载功能应该只出现在开发环境。
最后不要忘记操作系统层面的配合：调整文件描述符上限（ulimit -n至少设为65535）、开启TCP的TIME_WAIT复用、适当增大端口范围，这些设置与Tomcat配置共同决定了服务能承载的连接规模。调优完成后，建议使用JMeter或wrk做压测，观察QPS、P99延迟和GC日志，用数据验证每一项配置的实际效果，而不是凭感觉改参数。
三、常见误区与排查思路
实际运维中有几个高频误区值得提醒。一是盲目调大maxThreads，线程数超过几千后上下文切换的开销反而会拉低吞吐量，CPU利用率高但QPS上不去往往就是这个原因，可以用jstack观察线程状态确认。二是堆内存给得过大，认为内存越多越好，实际上超大堆会让GC单次停顿时间变长，G1的Region回收优势也会被稀释。三是只调Tomcat不看数据库连接池，应用层的Druid或HikariCP配置不当，线程池再大也白搭，两者需要匹配。
排查性能问题时建议按顺序看三层：先看监控指标确认瓶颈在网络、CPU还是内存；再用arthas或jstack定位慢线程；最后结合GC日志分析内存行为。安全方面则可以定期用nmap扫描端口、检查manager是否暴露、核对tomcat-users.xml的账号列表，形成常态化的巡检机制。
总的来说，Tomcat的安全加固与性能调优没有一次到位的万能配置，核心是理解每个参数背后的原理，结合自身业务流量特征做针对性调整，并通过压测和监控持续验证，这样才能让服务既安全又高效地运行。
Tomcat安全加固Tomcat性能调优Tomcat配置优化修改时间：2026-09-13 15:24:55