Tomcat应用中新增ForkJoinPool等额外线程池是否会影响整体性能

1 Tomcat大线程池对ForkJoinPool性能收益的影响 #

首先你需要区分两类线程的运行状态差异：Tomcat线程池里的400个活跃线程，绝大多数时间处于IO阻塞状态（等待数据库、缓存、下游接口响应），并不会持续占用CPU时间片。而你要执行的是计算密集型任务，这类任务的线程会持续占用CPU，两类线程的资源占用逻辑完全不同。

• 不会抵消性能收益：如果不使用独立线程池，直接把计算密集型任务放在Tomcat线程中执行，会直接占住Tomcat工作线程，导致普通Web请求无法获取线程资源，出现响应超时、服务可用性下降的问题。使用独立线程池可以实现请求处理线程和计算任务线程的资源隔离，既保证普通请求的响应稳定性，也能让计算任务按照CPU核心数做最优调度，收益是明确的。
• 正常配置下不会出现额外性能损耗：ForkJoinPool.commonPool默认的线程数是CPU核心数-1，本身就是针对计算密集型场景设计的最优配置。哪怕Tomcat总线程数达到数百，由于大部分处于阻塞态，操作系统调度时只会给就绪态的线程分配时间片，实际同时运行的线程数始终和CPU核心数匹配，不会出现过多上下文切换带来的额外损耗。只有你主动把ForkJoinPool的线程数调整到远大于CPU核心数时，才会出现性能下降的问题。

2 新增额外线程池是否必然带来性能负面影响 #

答案是否定的，是否有负面影响完全取决于线程池的配置逻辑和使用场景：

• 合理配置的线程池只会带来正面收益：按照任务类型匹配线程池参数是基本准则：计算密集型任务线程池大小控制在CPU核心数±2区间，IO密集型任务按照核心数*(1+平均等待时间/平均计算时间)的公式配置大小，不仅不会影响性能，还能实现不同业务的资源隔离，避免慢任务拖垮整个Tomcat的请求处理链路，也方便单独做指标监控和故障排查。
• 只有不合理的配置才会引发问题：如果不区分任务类型随意配置过大的核心线程数、或者创建大量闲置不销毁的线程池，才会导致栈内存占用过高、就绪态线程远多于CPU核心数、上下文切换开销飙升等性能问题，这是使用方式的问题，和新增线程池本身无关。

内容的提问来源于stack exchange，提问作者Brian K