一（大）的线程池每个应用的组分（更小）的线程池

Question

一种应用承载有用于三个单独和独立行动三个接口的web服务，所有这些动作在该应用程序的不同的组件来实现，彼此独立，例如在不同的软件包中，所以他们彼此不太了解，只能共享应用程序的宽泛配置等等。

所有这些接口称为与由每个用户的多个数据，并且能够至少部分地独立地处理这些数据，这就是为什么我目前使用用于处理3个线程池，一个用于每个组件。

原因是这样每个线程池可以独立进行优化，取决于负载和处理事物的目的，并且已知用于哪些目的等。但是在实践中，目前没有关心这样的事情并使用合理的默认值。这意味着每个线程池例如限制为5个线程。如果需要所有池/线程，则不会对系统造成过多负载，但如果不是，则即使一个用户提供的数据可能被7/8/N处理，10核CPU的某些内核也可能未被使用核心并行。另一方面，目前的行为有些“保证”，如果没有其他事情完成，每个任务至少有5个线程可用。

因此，最好是每个应用程序只有一个线程池，例如， 10或15或某些任意N个线程（而不是独立线程池）更动态地使用资源？

或者是这个东西都没有明确的答案，可以作出，因为这样的事情总是依赖于像系统的一般整体负载，对于例如许多变量诸如备份和cron报告和监视事件和安装更新等等，有多少用户在什么时候调用哪些接口等等。

我的问题是有点类似an already existing one，但不重复，因为它不集中在一个具体的任务，但整个应用和可维护性。这只是我一遍又一遍地问自己的一个问题，例如，当我最初只有一个游泳池，甚至在其上添加10

Answer 1

当我看到有三个方面的原因，以分割出成多个线程池。这两者可能都不适用于你的用例。

1. 控制：如果您有一些任务具有更高的优先级，并且希望增加这些任务运行的可能性。您可以创建多个线程池，并为具有更高优先级的线程提供更多线程。

2. 争用：正在运行多少个任务？执行任务有多快？如果答案很多且很快，那么拥有一个线程池可能会导致争用单个工作队列。相反，你可以分割你的线程池并将争用分开。这实际上就是ForkJoinPool所做的事情，每个线程都有自己的工作队列，并通过这种方式减少了争用（也许您可以使用FJP）。

3. 你不想从应用程序的一部分任务与应用程序的其它不相关的，部分的任务干扰。想象一下，如果你有一些行动A可能需要一段时间，而另一个B却没有。将它们分解出来是有意义的，这样线程池就不会被所有运行的A任务使用。它与（1）有更多的控制和（2）减少竞争有关。

否则，我觉得你创建的线程池和线程的数量是非常随意的。

编辑：添加了第三个用例