java - 在长时间运行的应用程序中运行并行任务

Question

我正在构建一个长期运行的应用程序，该应用程序被建模为基于面向服务的体系结构的服务。将此称为“serviceA”。每当对其进行 API 调用时，它都会执行一个 Activity ，即调用“activityA”。

activityA 有一个 Activity 处理程序，必须并行执行“n”个任务，之后它会合并并将结果返回给调用 serviceA API 的客户端。

我计划使用 ExecutorService 来实现这种并行性。

有两种方法可以实现此目的:

1. 在单例范围内创建 ExecutorService，并将其作为 Activity 处理程序的属性。因此，同一个 ExecutorService 对象在服务的整个生命周期中都可用。当新请求到来时，处理程序使用此 ExecutorService 对象来提交并行任务。然后等待 Future 对象一定的超时时间。所有并行任务完成后，合并并返回activityA响应。

2. 每次在 Activity 处理程序中收到对 ActivityA 的请求时，都会创建新的 ExecutorService 对象。将并行任务提交到该对象，在一定的超时时间内等待Future结果，合并结果，调用ExecutorService对象的shutdown，并返回activityA API响应。

因此，

1. 应遵循上述 2 种方法中的哪一种？两者的主要区别在于 ExecutorService 对象的生命周期。

2. 如果这些数据有助于两种方法的决策，那么该服务的调用量应该约为每秒 15k 个事务？

3. 第一种方法的优点是我们不会有创建和关闭新的 ExecutorService 对象和线程的开销。但是，如果直到超时时间都没有 Future 结果会发生什么？线程会自动关闭吗？它是否可用于任何将进入 ExecutorService 线程池的新请求？或者它会处于某种等待状态，并耗尽内存 - 在这种情况下我们需要手动做一些事情(以及什么)？

4. 此外，我们调用 future.get() 时的超时时间是从我们进行此 get 调用的时间算起还是从我们将任务提交到执行器服务的时间算起？

还请让我知道这两种方法中的任何一种是否是解决此问题的明显方法。

谢谢。

Answer 1

1. 第一种方法看起来是解决此问题的明显且正确的方法，尤其是在给定交易量的情况下。您当然不想重新启动线程。

2. Future.get 超时不会影响执行线程。它将继续运行任务，直到完成或引发异常。在那之前，它不会接受新任务(但同一执行器中的其他线程会接受)。在这种情况下，您可能希望通过调用 Future.cancel 来显式取消它，以释放线程以执行新任务。这要求任务本身正确响应中断(而不是永远循环，或者等待 I/O 阻塞)。但是，这对于任何线程方法都是相同的，因为无论如何中断是终止线程的唯一安全方法。为了缓解此问题，您可以使用最大运行线程数超过 n 的动态线程池。这将允许在卡住的任务终止时处理新任务。

3. 从你调用它的时候开始。