Tomcat线程池打满本质是处理能力跟不上流量，需配置、业务、架构协同治理：maxThreads设200–500（依CPU与IO类型），minSpareThreads为20%–30%，acceptCount限为0.8–1倍；优化Nginx-Tomcat连接复用与健康检查；消除阻塞点、异步化非关键路径；通过JMX监控+Sentinel限流+系统级ulimit调优实现主动防护。
高并发反代场景下，后端Tomcat线程池被打满，本质是请求处理能力跟不上入口流量。Nginx等反向代理会把大量连接转发过来，而Tomcat若未针对性调优，很容易在短时间内耗尽线程，出现503、响应延迟飙升或请求排队超时。解决不能只靠“加线程”，需从配置、业务、架构三层面协同治理。
精准调整Tomcat线程池参数
反代环境下的线程池配置必须匹配真实负载特征，而非简单放大数值：
- maxThreads：建议设为200–500（非盲目拉高）。CPU密集型服务按CPU核心数×1.5~2设置；I/O密集型（如频繁调外部HTTP/DB）可设为CPU核心数×3~4，并配合压力测试验证。超过500易引发上下文切换开销反噬性能。
- minSpareThreads：设为maxThreads的20%~30%，例如maxThreads=400时，minSpareThreads=80~120。避免冷启动时频繁创建线程，降低首请求延迟。
- acceptCount：必须显式限制，推荐设为maxThreads的0.8~1倍（如320~400）。它不是缓冲池，而是TCP连接等待队列长度；设为Integer.MAX_VALUE或过大（如1000+）会导致连接堆积、内存暴涨甚至OOM。
- maxIdleTime：保持默认60秒即可；若长连接较多（如WebSocket），可延长至300秒，避免频繁销毁重建线程。
优化反代与Tomcat协同机制
Nginx和Tomcat之间的连接管理不当，会放大线程压力：
- Nginx upstream中开启keepalive，并设置keepalive 32（连接复用数），同时在Tomcat
中启用keepAliveTimeout（建议30~60秒），减少连接反复建立开销。 - Nginx侧配置proxy_next_upstream error timeout http_503，避免将已满的Tomcat实例持续导流；搭配健康检查（如health_check interval=3 fails=2 passes=2）实现自动摘除。
- 禁用Tomcat默认的connectionUploadTimeout或调大其值，防止Nginx上传大文件时因超时中断连接，导致Tomcat线程卡在read状态无法释放。
从业务层削减线程占用时长
线程打满往往源于单个请求耗时过长，而非并发数绝对超标：
- 排查并消除同步阻塞点：用jstack -l
抓取线程快照，重点看BLOCKED或长时间WAITING状态的线程，定位数据库锁、远程调用未设超时、日志同步刷盘等问题。 - 慢SQL必须治理：开启MySQL慢查询日志，对执行时间>100ms的SQL强制优化（加索引、拆分复杂查询、引入读写分离）；应用层使用HikariCP连接池，设置connection-timeout=3000、validation-timeout=3000，避免线程死等无效连接。
- 非关键路径异步化：用户行为埋点、短信通知、日志落库等操作，改用消息队列（如RabbitMQ/Kafka）解耦，Tomcat线程不参与后续耗时流程。
建立可观测性与主动防护
依赖告警而非故障后排查，才能守住底线：
- 通过JMX或Spring Boot Actuator暴露ThreadPool.activeCount、ThreadPool.queueSize指标，接入Prometheus+Grafana，当活跃线程持续>90% maxThreads且队列长度>50时触发预警。
- 在网关或Spring Cloud Gateway层集成Sentinel或Resilience4j，对核心接口配置QPS限流（如每秒300次）和熔断规则（异常比例>50%持续10秒则熔断），防止雪崩传导至Tomcat。
- 操作系统层面调大文件描述符限制：ulimit -n 65536，并在/etc/security/limits.conf中持久化，避免因fd耗尽导致accept失败，掩盖真实线程问题。
