一个应用程序托管具有三个接口的Web服务，用于三个单独和独立的操作，所有这些操作都在应用程序的不同组件中实现，彼此独立，例如，在不同的套餐等中，所以他们对彼此不太了解，只分享应用程序范围内的配置等。
所有这些接口都由每个用户调用多个数据，并且能够至少部分独立地处理这些数据，这就是我目前使用三个线程池进行处理的原因，每个组件一个。
原因是这样每个线程池可以独立优化，具体取决于要处理的事物的负载和目的，并且已知用于哪个目的等。但实际上目前没有关心这些事情和使用合理的默认值。这意味着每个线程池例如限于5个线程。如果需要所有池/线程，可以不对系统施加太多负载，但如果不需要，10核CPU的某些核心可能未被使用，即使一个用户提供可由7处理的数据也是如此。 / 8 / N并行核心。另一方面，目前的行为有点保证＆＃34;如果没有其他任务，那么每个任务总是至少有5个线程可用。
那么，每个应用程序总是只有一个线程池，例如，更好吗？ 10或15或一些任意N个线程，而不是独立的线程池，更动态地使用资源？
或者这个问题没有明确的答案可以做出因为这些事情总是依赖于许多变量，例如系统的整体负载，例如，像备份，cron报告和监控事物以及安装更新等等，有多少用户在什么时候调用哪些接口等。
我的问题有点类似于an already existing one，但并不重复，因为它并不专注于一个具体任务，而是整个应用程序及其可维护性。这只是一个我一遍又一遍地问自己的问题，例如：当我最初只有一个游泳池，甚至可能加上10个。
答案 0 :(得分：1)
正如我所看到的，分裂成多个线程池有三个原因。两者都可能不适用于您的用例。
控制：如果您有一些具有更高优先级的任务，并且您希望增加这些任务运行的机会。您可以创建多个线程池，并为具有更高优先级的线程提供更多线程。
争用：正在运行多少个任务？执行任务的速度有多快？如果答案很多而且速度很快，那么拥有一个线程池可能会导致单个工作队列的争用。相反，您可以对线程池进行条带化并将争用分开。这实际上是ForkJoinPool所做的，每个线程都有自己的工作队列，并以这种方式减少争用（也许你可以使用FJP）。
您不希望应用程序的某个部分的任务干扰应用程序的另一个不相关的部分的任务。想象一下，如果你有一些行动A可能需要一段时间而另一个B不行。将它们分解出来是有意义的，这样所有正在运行的A任务都不会消耗线程池。它与（1）有更多的控制和（2）减少竞争有关。
否则，我认为你创建的线程池和线程的数量非常随意。
编辑：添加了第三个用例