从许多文章中，我可以阅读有关最大池大小的公式，该公式取决于CPU + 1的数量。这是一个清晰的解释。
但是，如果应用程序定义了许多Executor或ThreadPoolExecutor，该怎么办。然后，我们还必须考虑该应用程序共享相同的硬件。这如何影响池大小的选择。
我们是否需要整体计算大小以及它的划分取决于所定义线程池的数量？
的nosCPUs + 1“经验法则”假定线程将是CPU绑定的（没有I / O的约束），并不会有显著锁争用。对于典型应用而言，这是不现实的。
如果您有多个线程池，则还必须考虑各个池中的线程是否将同时处于繁忙状态。
如果它们是AND并且先前的假设对所有池都适用，那么该nosCPUs + 1规则可以全局应用；否则，该规则可以全局应用。即所有池的大小之和。
否则，找出一个预测池的最佳大小的公式很可能太复杂了。
在实践中，典型的多线程应用程序的行为非常复杂，以至于该nosCPUs + 1规则无法提供最佳的线程数。此外，您通常无法推导可以准确预测最佳线程数的公式。
取而代之的是，通常的做法是将线程池的大小设置为可调参数或属性，并对其进行调整以获得典型工作负载的良好性能。如果您的应用程序只有一个线程池，则将使调整变得更加容易，尽管可能有理由不这样做。
但是好消息是，有限制的线程池对性能的影响太大了，通常影响不大。当池大小太大时会出现问题（内存使用，争用，上下文切换等）。
最后，我认为您应该检查一下决定，让许多执行程序每个都有自己的线程池。由于多个池中（长期）空闲线程的线程堆栈，这容易导致内存浪费。此外，如果您有许多要单独调整的池，则调整池大小的任务将更加困难。相反，如果所有池只有一个“调整旋钮”，则最终会针对所有池的最坏情况调整池的大小。
您需要权衡这些问题/成本与拥有许多执行程序对您的应用程序带来的好处。（我看到在某些用例中会有好处...）
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句