后端项目做久了你迟早会撞上这种场景流量稍微涨一点接口响应时间从几十毫秒冲到几秒CPU开始往上跳线程数节节攀升日志里全是连接超时和线程池拒绝异常。业务代码翻了个底朝天也没找到死循环和死锁最后只能一边重启一边猜。我踩过太多次这种坑之后回头看问题根源往往不在业务代码而在更底层的地方——Tomcat 的线程模型和 Spring 框架对线程、连接、事务这一整套资源的管理方式到底有没有搞懂。Tomcat Spring Boot 是 Java 后端最主流的一套组合也是 Java 并发问题最容易集中爆发的地方。这篇文章我就围绕线程与资源管理这条主线把 Tomcat 的工作线程从哪来、线程池参数怎么配才合理、Spring 的异步线程到底怎么管以及数据库连接池和 ThreadLocal 这些隐性资源一次讲清楚。适合所有 Java 后端开发、刚从 CRUD 往性能优化方向深入的同行也适合准备面试时想把并发和容器知识串起来的同学。1. Tomcat 线程模型拆解一次 HTTP 请求在容器里到底经历了什么1.1 先分清 Connector 和 Container很多人一上来就调线程池参数但从不看请求实际走向。Tomcat 的核心其实就两大部分Connector 负责对外接收连接、解析 HTTP 报文Container 负责真正执行业务代码也就是我们写的 Servlet 和 SpringMVC 接口。两者之间有一层协议适配器把请求从 Connector 的“网络世界”翻译成 Container 认识的 HttpServletRequest。调优之前必须清楚这个边界。你在 server.xml 里改的是 Connector 的线程行为业务代码里的并发问题则是 Container 内部的事。如果连这个分层概念都没有后面看 jstack 时很容易被各种线程名绕晕。1.2 NIO 连接器里的三种各司其职的线程以 Tomcat 9.0 默认的 NIO 连接器为例一次请求能顺利跑到你的 Controller背后有三拨线程接力Acceptor 线程默认 1 个只干一件事调用 ServerSocketChannel.accept() 接收新连接把 socket 丢给 Poller。Poller 线程默认 2 个左右用 Selector 轮询已注册 socket 上的读写事件一旦可读就包装成 SocketProcessor 丢给业务线程池。Worker 线程线程池里的“真打工的”真正去解析 HTTP 请求、调用 Servlet 和 SpringMVC 逻辑。这里有个关键认知NIO 模式下连接数不等于线程数几万个长连接可能只需要几百个线程轮询处理。所以线上看到 socket 连接多不要慌先看执行线程有多少、都在干什么。1.3 Tomcat 线程池和 JDK 线程池的差异这个点我认为是整个 Java 并发知识里被严重低估的。JDK 的 ThreadPoolExecutor 执行策略是核心线程没满时先创建核心线程满了之后新任务进阻塞队列队列满了才尝试创建非核心线程到 max。Web 场景里请求是突发的JDK 这套策略会导致明明线程没到 max任务却在队列里排队用户眼睁睁看着请求超时。Tomcat 的 StandardThreadExecutor 设计思路完全不同。它配套一个 TaskQueue这个队列的 offer 方法被重写了当前线程数没到 maxThreads 时offer 直接返回 false让执行器认为“队列满了”立刻创建新线程只有当线程数已经达到 maxThreadsoffer 才返回 true任务才真正进队列等待。策略对比核心线程满后线程未到 max 时Web 场景下的实际效果JDK 线程池先进阻塞队列不会新建线程直到队列满任务排队请求响应变慢Tomcat 标准线程池队列 offer 返回 false有线程就直接建建到 max请求优先被线程处理拒绝兜底换句话说Tomcat 的优先策略是“先建线程后排队”JDK 默认是“先排队后建线程”。在 web 容器这个场景下Tomcat 的设计明显更符合“别让请求等着”的诉求。你在 Spring Boot 里可以通过 server.tomcat.threads.max 配置去调整这个上限。2. Tomcat 线程池参数不是背数字是按业务算出来的2.1 关键参数逐个说清楚Tomcat 线程模型涉及的参数不算多但每个都容易被误用。先把它们的作用边界搞清楚maxThreads业务线程上限默认 200。这是最重要的参数决定了 Tomcat 同时能处理多少请求。minSpareThreads最小空闲线程数默认 10。相当于线程池的常驻员工启动时就会先建好避免突发流量来临时临时创建线程。acceptCount操作系统 accept 等待队列长度默认 100。超过这个数新连接会被服务端直接拒绝。maxConnections在 NIO 下默认 8192是连接数限制。连接能进来不代表立刻有线程处理可能只是在等待空闲线程。connectionTimeout默认 60 秒。等待接收 HTTP 请求的时间超过就断开。keepAliveTimeout默认 60 秒。长连接里两次请求的最大间隔。这里的常见误区是 maxThreads 和 maxConnections 搞混。maxConnections 管的是“能有多少根线头插进来”maxThreads 管的是“有多少人同时在处理”。NIO 模式下连接数可以远大于线程数这是正常的不要看到连接数接近 maxConnections 就认为线程不够。2.2 线程数到底怎么算才合理网上关于线程池参数合理配置的公式很多我实际用下来最有效的是这两套。CPU 密集型任务线程数 CPU 核数 1。这种任务不会主动释放 CPU线程开多了只会增加上下文切换成本。IO 密集型任务线程数 CPU 核数 × (1 等待时间 / 计算时间)。这个公式需要你知道一个请求里纯计算和等待 IO 的比例比较精确但不好估。工程上更常用简化版CPU 核数 × 2。比如典型的数据库读写、RPC 调用业务8 核机器直接 16 到 24 起步再按压测微调。还有一个更实用的推算方式用 Littles Law系统里的并发请求数 QPS × 平均响应时间秒。这个公式直接告诉你在途请求到底要多少线程承接。某个接口平均 RT 是 100ms目标 QPS 1000那么在途请求大约 1000 × 0.1 100 个。Tomcat 的 maxThreads 至少 100留 30% 余量就可以设到 130。注意 RT 本身包含排队时间如果线程池太小RT 会变大QPS 反而上不去这就是线程池过小导致的自我恶化。运行场景参考线程数4 核 CPU纯计算5 左右4 核 CPUIO 密集DB、RPC 调用8 到 168 核 CPUIO 密集16 到 3232 核 CPUIO 密集、大量短请求64 到 128这些数字只是起点上线前必须靠压测确定最终值。压测工具用 JMeter 或者 wrk 都行关键是观察线程快照里 exec 线程的活跃比例。2.3 线程不是越多越好很多人遇到性能问题第一反应是把 maxThreads 调到很大两千、五千都敢写。这个思路很危险。操作系统让 CPU 从一个线程切到另一个线程要保存寄存器状态、刷新缓存、更新调度器队列线程越多切换成本越高。Java 线程是 1:1 映射到操作系统线程每个线程默认栈空间 1MB200 个线程光栈就占 200MB 内存。线程数提升过头最终换来的可能是 CPU 全部耗尽在上下文切换上业务吞吐反而下降。我见过一个真实案例某团队把 maxThreads 调到 1000请求一上来 CPU 直接 90% 以上但业务 QPS 只有几十。用 jstack 一抓大量线程在锁竞争还有相当一部分线程处于 RUNNABLE 但实际是在空转。把线程数降回 200配合连接池调优后CPU 降到 30%QPS 反而翻倍。另外提醒一点Spring Boot 内嵌 Tomcat 下配置文件写的是 server.tomcat.threads.max外置 Tomcat 就得改 server.xml 里的 Connector 属性。这两套配置经常有人混着改改完又看不出来是否生效。建议配完后通过 JMX 或者启动日志里打印的线程数据验证一下不然白忙一场。3. Spring 容器里的线程管理Async 与 TaskExecutor 是重灾区3.1 Spring 不管理 Tomcat 的工作线程但管理自己的异步线程很多人把 Spring 和 Tomcat 的线程资源混为一谈其实两者的管理边界很清楚Spring MVC 本身不创建也不管理 Tomcat 那些 exec 线程它只是把 Servlet 的处理流程封装成了 DispatcherServlet。真正的 HTTP 工作线程是 Tomcat 在管。Spring 的线程管理权限集中在业务异步场景也就是 Async、EnableAsync 和 TaskExecutor 那一套。想调 Tomcat 线程池改 Spring 配置没用想调 Spring 异步线程池写 server.tomcat.threads.max 也没用。先把边界画清楚后面调参就不会乱套。3.2 ThreadPoolTaskExecutor 的默认配置是个大坑Spring 的 ThreadPoolTaskExecutor 如果不显式设置 queueCapacity默认是无界队列。这意味着任务永远排得进去线程池的 maxPoolSize 形同虚设——实际只会用到 corePoolSize 那些线程其余任务全部堆积在内存在队列里。响应越来越慢内存也可能被撑爆这个坑踩一遍就长记性了。一个生产可用的配置长这样Bean(asyncExecutor) public ThreadPoolTaskExecutor asyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(32); executor.setQueueCapacity(200); executor.setThreadNamePrefix(biz-async-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }队列容量一定不能省。设了有界队列线程池才会在核心线程跑满后按预期扩容到 maxPoolSize达到上限后触发拒绝策略这个行为才可控。拒绝策略的选择也有讲究。默认的 AbortPolicy 直接抛 RejectedExecutionException异步场景里任务会静默丢失调用方没有感知。CallerRunsPolicy 让提交任务的线程自己执行这个任务虽然会堵住调用方但至少任务不丢而且具备天然限流效果。业务异步场景我更推荐 CallerRunsPolicy。3.3 事务与线程的绑定Async 的隐形炸弹Spring 的事务管理底层依赖一个非常重要的机制DataSourceTransactionManager 通过 ThreadLocal 把 Connection 绑定到当前线程同一个事务在同一个线程内复用同一个数据库连接。这本来是高效率的设计但一遇到 Async 就出问题。因为 Async 的方法跑到了另一个线程ThreadLocal 里根本没有绑定好的 Connection事务语义自然传不过去。如果异步方法本身没有标注 Transactional那它执行的所有 SQL 都是自动提交模式数据的原子性、一致性就完全没保障了。所以事务边界要么放在异步方法内部由异步线程自己开事务要么干脆不要在异步线程里依赖调用方的事务语义。类似的还有请求上下文、用户信息传递凡是依赖 ThreadLocal 的东西跨线程都要重新传递或者用 TransmittableThreadLocal 做线程池场景下的上下文续传。4. 连接池与 ThreadLocal比线程池更隐蔽的资源死角4.1 数据库连接池Tomcat 线程和 DB 连接是两套池子很多人盯着 Tomcat 线程池调了半天结果真正的瓶颈在数据库连接池。Spring Boot 2.x 默认数据库连接池是 HikariCPmaximum-pool-size 默认是 10。Tomcat 默认 200 个工作线程抢 10 个数据库连接任何一个慢 SQL 都可能让大量线程卡在等连接上。HikariCP 官方给过一个参考公式connections ((core_count * 2) effective_spindle_count)SSD 条件下 spindles 数可以当成 1。8 核机器算下来大约是 17建议起步设 20。这个公式只解决“够不够”的问题不代表最优。数据库连接比线程更贵每条连接都要占内存、占事务资源开太多会把数据库拖垮。关键还是要和压测数据配合。压测时抓一次 jstack如果看到大量线程卡在 HikariPool.getConnection 上说明连接池确实是瓶颈。这时候先治理慢 SQL再看要不要加连接池而不是一上来就把 maximum-pool-size 翻十倍。4.2 ThreadLocal 在线程池下的内存泄漏Tomcat 的工作线程是复用的一个请求处理完线程不会销毁。ThreadLocalMap 的 key 是 WeakReference但 value 是强引用。如果代码往 ThreadLocal 里塞了大对象请求结束后没人 removevalue 会一直留在 worker 线程里内存占用只增不减。更严重的是这个残留值还可能被下个请求读到产生数据串号。我自己处理过一起线上事故一个拦截器往 ThreadLocal 塞了用户会话对象接口返回后忘了清理。Tomcat 线程复用之后下一个请求竟然读到了上一个用户的信息排查了很久才定位到这个点。ThreadLocal 不是不能用而是要用在“同一线程内短生命周期”的场景并且一定要配合 finally 块做 remove。try { ThreadLocalHolder.set(userInfo); // 业务逻辑 } finally { ThreadLocalHolder.clear(); }这个问题在普通线程里不明显因为线程销毁了 value 也就释放了。但线程池场景下线程存活时间很长泄漏才会真正累积起来。Tomcat 7 之后对 Web 应用类加载器有内存泄漏检测但根治办法只有一个——用完手动删。4.3 Spring 的 IOC 容器与单例对象共享资源的前提Spring 容器本身也可以看成一种资源池默认单例的 Bean在 Tomcat 多线程环境下会被所有请求线程共享。无状态对象可以随便共享但一旦 Bean 里有可写的成员变量多线程下就是竞态条件必须考虑线程互斥的问题。Spring 三级缓存是另一个经常被拿来讨论的点。它解决的是循环依赖通过三个缓存把“早期引用”暴露出去让互相依赖的 Bean 都能完成创建。这个机制巧妙归巧妙但它解决的是对象创建期的资源管理问题跟并发安全完全是两回事。单例 Bean 还是那个单例 Bean多个线程照样共享同一个实例。想让并发安全杠杆不要加在共享单例的可变字段上应该把数据放到请求作用域或方法局部变量里绕开竞争。5. jstack 实战线程堆栈这样读问题基本跑不掉5.1 一份 jstack 拿到手先看三类线程线上出问题的时候我建议先执行 jstack -l 抓几次线程快照间隔两三秒抓两三份对比找出稳定存在的调用栈。Tomcat 的工作线程名都是 http-nio-8080-exec-N 这种格式很好认。大量 WAITING 线程停在 HikariPool.getConnection 上是连接池不够用。线程停在 ThreadPoolTaskExecutor 的队列 take 上说明异步任务没活干这反而是正常现象。大量 RUNNABLE 线程停在你业务代码的同一行大概率是死循环或者某个热点方法。大量 BLOCKED 线程在等同一个 monitor 锁就是锁竞争太严重。另外介绍一下 jstack 里几个容易认错的线程Catalina-utility 是 Tomcat 的后台定时任务线程负责会话清理等RMI TCP Accept、RMI TCP Connection 这些来自 JMX 远程监控或外部诊断工具的连接也是正常线程。如果生产环境不需要远程 JMX最好在启动参数里关掉监听少一个暴露面。5.2 常见线程问题速查表现象线程快照特征常见原因应对方向接口响应有毛刺大量 exec 线程 WAITING 在 HikariPool数据库连接池不够或慢 SQL治理慢 SQL、逐步调大连接池CPU 飙高少数 RUNNABLE 线程占满 CPU死循环、频繁 GC、计算密集抓栈顶业务代码定位优化线程数逼近 maxThreadsexec 线程接近上限新任务排队下游依赖变慢、接口被突发打满加超时、熔断、限流大量 BLOCKED多个线程等同一个 monitor锁竞争严重缩小锁粒度、无锁化改造无法创建新的本地线程进程线程数接近系统上限线程数爆满或系统 ulimit 限制排查线程来源、调整池大小5.3 Tomcat 启动时的线程疑云启动阶段的报错也经常和线程相关这里集中讲几个高频问题。端口被占用是最常见的报 Address already in use说明 Accptor 线程无法绑定端口先查端口占用再考虑其他的。启动后如果发现请求卡住可以看看 minSpareThreads 是否设置合理这个参数决定了启动时预建多少常驻线程建得太少突增流量会全部消耗在线程创建上。还有一种比较隐蔽的情况老项目在 Linux 上启动特别慢线程一直起不来多半和 JVM 启动时随机数取不到熵源有关可以在启动脚本里加上 -Djava.security.egdfile:/dev/./urandom 缓解。调 Tomcat 线程参数和 Spring 线程配置这件事我个人的体会是永远不要凭感觉拍数字也不要只盯着某一个池子。一次请求穿过的资源有 Tomcat 线程、应用异步线程、数据库连接、下游 RPC 连接任何一个环节都可能是瓶颈。你手里的 jstack 和压测数据才是唯一可信的决策依据。先把默认配置跑起来压一遍抓线程快照再按快照里的等待点去调参这个闭环比任何“最佳配置”都靠谱。