线程池的大小应该远大于内核的数量+ 1

自定义线程池的建议大小是number_of_cores + 1（请参阅here和here）。因此，可以说有一个系统上的应用程序春季用2芯和配置是这样的线程池的大小应该远大于内核的数量+ 1

<task:executor id="taskExecutor" 
pool-size="#{T(java.lang.Runtime).getRuntime().availableProcessors() + 1}" /> 
<task:annotation-driven executor="taskExecutor" />

在这种情况下会有多个请求之间共享一个ExecutorService的。所以如果有10个请求到达服务器，其中只有3个可以在ExecutorService中同时执行。这可能会造成瓶颈，并且结果会随着请求数量的增加而变差（请记住，默认情况下，tomcat可以处理多达200个并发请求= 200个线程）。该应用程序可以在没有任何池的情况下执行得更好

通常一个核心可以同时处理多个线程。例如我创建了一个服务，该服务调用两次https://httpbin.org/delay/2。每次通话需要2秒钟执行。所以如果没有使用线程池，服务平均响应4.5秒（用20个同时请求测试）。如果使用线程池，则响应会因池大小和硬件而异。我使用不同池大小的4核心机器运行测试。下面是用最小，最大和平均响应时间测试结果以毫秒为单位

从结果来看，可以得出结论，最好的平均时间与最大池大小。池中有5个（4个核心+ 1）线程的平均时间比没有池的结果更差。所以在我看来，如果一个请求没有花费太多CPU时间，那么将线程池限制为web应用程序中的核心数+ 1是没有意义的。

有没有人发现任何错误的设置池大小为20（或更多）在2或4核心机器上的Web服务是不是CPU要求？

来源

2015-12-14 lolotron

您链接到的两个页面明确表示这仅适用于未封锁的CPU绑定任务。

您有在远程计算机上等待的任务，因此此建议不适用。

忽略不适用于您的建议没有任何问题，因此您可以并且应该增加线程池大小。

好建议自带的理由，所以你可以当它变成不好的建议告诉我们。如果你不明白为什么要做某件事，那么你已经陷入了货物崇拜节目的陷阱，即使它不再需要甚至变得有害时，你也会继续这样做。我清楚地提供的链接的

Raymond Chen，在他的博客“旧的新”

来源

2015-12-14 23:09:15

在我看来既不是国家“畅通，CPU密集型任务”。在网络应用程序（这是当今大多数应用程序）中，很少有代码只是CPU绑定（DB调用，WS调用...），所以Amdahl法则可以在少数情况下应用。无论如何，谢谢你的清楚解释 – lolotron

线程池的大小应该远大于内核的数量+ 1

回答

相关问题