【问题标题】:One (larger) thread pool per app vs. mulitple (smaller) thread pools per app-component每个应用程序一个(较大)线程池与每个应用程序组件多个(较小)线程池
【发布时间】:2016-10-18 01:28:25
【问题描述】:

一个应用托管一个具有三个接口的网络服务,用于三个单独且独立的操作,所有这些操作都在应用的不同组件中实现,彼此独立,例如在不同的包等中,所以他们对彼此了解不多,只共享应用范围的配置等。

所有这些接口都由每个用户调用多个数据,并且能够至少部分独立地处理这些数据,这就是为什么我目前使用三个线程池进行处理,每个组件一个。

原因是这样每个线程池都可以独立优化,具体取决于要处理的事物的负载和目的,并且已知用于哪个目的等。但实际上目前没有关心这些事情和改为使用合理的默认值。这意味着每个线程池例如限制为 5 个线程。如果需要所有池/线程,则可以不给系统施加过多负载,但如果不需要,则 10 核 CPU 中的某些内核可能未使用,即使一个用户提供的数据可以由 7/8/N 处理核心并行。另一方面,当前的行为在某种程度上“保证”了每个任务至少有 5 个线程可用,如果没有做任何其他事情的话。

所以,最好只为每个应用程序拥有一个线程池,例如10个或15个或一些任意N个线程,而不是独立的线程池,以更动态地使用资源?

或者这是无法给出明确答案的事情,因为这些事情总是取决于许多变量,例如系统的总体负载,例如诸如备份、cron 报告、监控和安装更新等,有多少用户调用了哪些接口等等。

我的问题有点类似于an already existing one,但不是重复的,因为它不关注一项具体任务,而是关注整个应用程序及其可维护性。这只是我一遍又一遍地问自己的一个问题,例如当我最初只有一个池时,甚至可能添加了 10 个。

【问题讨论】:

  • 似乎没有明确的答案。我想知道这个web服务应该是三个web服务,但是没有办法真正回答这个问题
  • 3 个 Web 服务,也就是 3 个应用程序,也就是 3 个池?最终将再次成为每个应用程序一个池...在我的情况下,这些 Web 服务实际上形成了一个应用程序,它只是提供许多不同的 Web 服务。

标签: java multithreading performance threadpool maintenance


【解决方案1】:

正如我所见,拆分为多个线程池的三个原因。两者可能都不适用于您的用例。

  1. 控制:如果您有一些具有更高优先级的任务,并且您希望增加这些任务运行的机会。您可以创建多个线程池,并为具有更高优先级的线程池分配更多线程。

  2. 争用:有多少任务正在运行?任务的执行速度有多快?如果答案很多且速度很快,那么拥有一个线程池可能会导致对单个工作队列的争用。相反,您可以对线程池进行条带化并分散争用。这本质上是 ForkJoinPool 所做的,每个线程都有自己的工作队列并以这种方式减少争用(也许您可以使用 FJP)。

  3. 您不希望应用程序的某个部分的任务干扰应用程序的另一个不相关部分的任务。想象一下,如果你有一些动作 A 可能需要一段时间,而另一个 B 不需要。将它们分开是有意义的,这样线程池就不会被所有正在运行的 A 任务消耗。它与 (1) 拥有更多控制权和 (2) 减少竞争有关。

否则,我认为您创建的线程池和线程的数量非常随意。

编辑:添加第三个用例

【讨论】:

    猜你喜欢
    • 2012-09-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-11-25
    • 1970-01-01
    • 2023-03-26
    • 2011-03-28
    • 2012-12-28
    相关资源
    最近更新 更多