Java 创建大型固定线程池的后果

我正在开发一个标准的服务器应用程序。每个请求的处理都分为几个阶段（第二阶段要求完成第一阶段，依此类推）。现在，其中一个阶段需要相当长的时间，但它本身可以分解为几十个左右的任务，这些任务彼此不依赖，因此是可并行的。我想在

SlowStageService

中添加一个线程池，我想知道如何最好地调整它的大小。线程池最好在大多数情况下至少有一个空缺，这意味着它处理任务的速度必须与服务器接收请求的速度相同或更快；这会产生线程池大小的合理下限。然而，我想慷慨地确定尺寸，因为计算中涉及的许多数字可能会发生变化

所以我的问题是：让我的池太大（比如3或4倍），并且有很多空闲线程，有什么坏处？我知道它浪费了一些资源，但它实际上并没有保留任何CPU，从而使它无法用于其他请求，对吗？一个人在实践中通常可以有多少懈怠？假设我已经计算出6个线程是我所需要的最小值；在中等负载下，在24芯盒上使用12芯是否安全

---

在我写这篇文章时，听起来我需要的可能是一个范围相当窄（3或4倍）的

ThreadPoolExecutor

您应该参考Brian Goetz的《Java并发实践》一书中的第8.2节

如果您的阶段是计算密集型阶段，并且只有很少的I/O，那么线程池的最佳大小=CPU核心数+1（因此在您的情况下，它将是25）。 但是，如果阶段中存在I/O绑定任务，那么线程池实现最佳响应时间的最佳适用大小取决于各种因素：

CPU数量-N

CPU的目标利用率-UC

I/O操作的等待时间（阻塞状态）与计算时间（C）的比率

线程数=N*UC*（1+（W/C））

除上述指标外，影响池大小计算的其他因素还有内存需求、连接池大小、文件句柄和套接字句柄

考虑到上述调整线程池大小的理论；我的经验表明，获得最佳池大小的最佳方法是在各种工作负载下分析应用程序，并为轻、中、重工作负载提供池大小

此外，永远不要硬编码最大线程池大小-它应该始终是一个可配置的参数，以便可以根据遇到的工作负载在现场进行调整