1. 为什么需要Tomcat调优Tomcat作为Java Web应用最常用的容器之一其性能直接影响着线上服务的稳定性和响应速度。在实际生产环境中我们经常遇到以下典型问题高并发时请求响应时间明显变长服务频繁出现OOMOutOfMemoryError异常CPU使用率异常飙升线程阻塞导致请求堆积这些问题往往源于默认配置无法适应实际业务场景。Tomcat出厂配置通常只适合开发和测试环境直接用于生产环境就像开着家用轿车上赛道——勉强能跑但性能完全发挥不出来。提示调优不是一次性工作而是需要根据业务增长持续优化的过程。建议每次配置变更后至少观察24小时系统表现。2. JVM内存调优实战2.1 内存参数核心配置修改Tomcat启动脚本catalina.sh/catalina.bat中的JVM参数是最基础的调优手段。以下是一个生产环境典型配置示例JAVA_OPTS-server -Xms4g -Xmx4g -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -Xmn1g -XX:UseG1GC -XX:MaxGCPauseMillis200关键参数解析-Xms和-Xmx必须设置为相同值避免堆内存动态调整带来的性能损耗。建议不超过物理内存的70%-Xmn年轻代大小G1收集器下建议设为堆内存的1/4到1/3-XX:UseG1GCJDK9默认收集器适合大内存多核场景-XX:MaxGCPauseMillis目标最大GC停顿时间需要根据SLA调整2.2 内存泄漏排查技巧即使配置了合理的JVM参数内存泄漏仍可能发生。通过以下命令可以快速定位问题# 生成堆转储文件 jmap -dump:formatb,fileheap.hprof pid # 实时监控内存变化 jstat -gcutil pid 1000使用Eclipse Memory Analyzer分析heap.hprof文件时重点关注重复创建的相同类型大对象被静态集合引用的对象未关闭的I/O流和数据库连接3. 线程池深度优化3.1 Connector线程模型配置在server.xml中配置Connector是调优的重点Connector port8080 protocolorg.apache.coyote.http11.Http11Nio2Protocol maxThreads500 minSpareThreads50 acceptCount100 connectionTimeout20000 maxConnections1000 executortomcatThreadPool/关键参数说明maxThreads最大工作线程数建议公式CPU核心数 * (1 平均等待时间/平均处理时间)acceptCount等待队列长度超过后返回503executor引用下方配置的线程池3.2 定制化线程池配置在server.xml的Service标签内添加Executor nametomcatThreadPool namePrefixhttp-exec- maxThreads500 minSpareThreads50 maxIdleTime60000 prestartminSpareThreadstrue/生产环境常见问题处理线程饥饿当慢请求阻塞线程时增加maxThreads同时优化业务代码线程泄漏使用jstack pid检查线程状态关注WAITING和BLOCKED线程CPU飙高用top -H -p pid找到高CPU线程转为16进制后在jstack结果中搜索4. 高级调优技巧4.1 文件描述符优化Linux系统下需要调整内核参数# 查看当前限制 ulimit -n # 修改limits.conf echo * soft nofile 65535 /etc/security/limits.conf echo * hard nofile 65535 /etc/security/limits.conf4.2 KeepAlive优化在Connector中添加keepAliveTimeout30000 maxKeepAliveRequests100合理设置可以减少TCP连接建立开销但过长会占用线程资源建议超时时间设置在30-60秒4.3 监控与动态调整推荐使用PrometheusGranfa监控以下指标tomcat_threads_busy活跃线程数tomcat_sessions_active活跃会话数jvm_memory_used_bytes内存使用情况tomcat_global_request_seconds请求处理时间根据监控数据动态调整当threads_busy持续80%时考虑增加maxThreads当内存使用率70%时检查是否存在内存泄漏请求时间突增时检查依赖服务状态5. 调优检查清单每次发布前建议检查[ ] JVM参数是否根据机型配置[ ] 线程池参数是否匹配业务特性[ ] 文件描述符限制是否足够[ ] 监控告警是否配置完备[ ] 是否有慢SQL或外部接口拖累性能[ ] 日志级别是否合理生产环境避免DEBUG实际调优中我发现与其追求极致的参数优化不如先确保代码质量。曾经有个性能问题困扰了我们两周最后发现只是某个同事在循环里误加了同步锁。所以调优要遵循先查代码再调参数的原则