ExecutorService 在休息 API 中使用答案

【问题标题】：ExecutorService using inside a rest APIExecutorService 在休息 API 中使用
【发布时间】：2019-02-26 02:32:46
【问题描述】：

我有一个 API，它执行四项任务。如果我们按顺序执行此 API，则需要更多时间。
为了提高性能，我使用了 Executor 服务框架并使用 executor 服务提交了四个任务。

据我所知，创建线程是一项昂贵的操作，并且在 executor 服务线程中将在提交任务时创建。当我们调用执行器服务的shutdown方法时，线程将被销毁。

这是本场景中每个请求的流程：

API 调用
创建执行器服务
提交四个未来的任务
从所有返回线程创建响应。
调用shutdown executor服务方法。
返回响应

所以我的问题是在每个请求中创建执行器服务和线程是否正确？或者请让我知道这个的替代解决方案。

【问题讨论】：

标签： java multithreading rest

【解决方案1】：

不，频繁终止和重新实例化 ExecutorService 是不明智的。这就是它的全部意义所在。创建一个固定线程池，因为您已经知道要并行执行的任务数。还将您的请求处理程序与 ExecutorService 的创建分离。注意，你调用的是shutdown()，意思是完成当前任务并且不接受任何新任务，它不可重用，它会强制你每次请求恢复池，所以尽量不要终止线程池。

【讨论】：

【解决方案2】：

使用线程池来并行处理传入请求是非常好的。但是每次 API 调用都创建一个新的线程池是不行的。

为了做到这一点，您应该创建一个单独的ExecutorService 实例并简单地重复使用它，并仅在您关闭应用程序时关闭它。

另外，请记住适当调整它的大小，因为如果它饱和，它会降低您的延迟而不是改善它。

【讨论】：

如果我在请求到来之前创建具有四个线程的执行器服务。多次调用API时，第一次调用将使用所有四个线程执行四个任务，同时所有其他请求都将等待。
是的，这就是为什么我添加了关于正确调整大小的注释。
我同意在每个 API 调用中创建和销毁执行器服务是错误的。在这种情况下调整线程池的大小并不容易，或者线程池执行器不适合这种情况？因为，例如，如果我们点击 rest API 1000 次，那么线程池的大小将是多少，或者如果这个数字增加到 1000 万，那么线程池的大小将是多少。
@DeepakGusain 实际上，如果您知道服务的非功能性需求，这很容易
最好让ExecutorService饱和，而不是消耗100%的cpu资源，降低整个系统的性能。

【解决方案3】：

创建一个 ExecutorService 的单例，并为所有请求使用相同的实例。不要一遍又一遍地创建它。您还应该限制 ExecutorService 拥有的最大线程数，以防止您的 REST API 炸毁您的服务器。

【讨论】：