使用多个线程服务单个 HTTP 请求答案

【问题标题】：Serving single HTTP request with multiple threads使用多个线程服务单个 HTTP 请求
【发布时间】：2017-11-04 00:55:17
【问题描述】：

Angular 4 应用程序将记录列表发送到已部署在 Websphere 8 Servlet 容器中的 Java spring MVC 应用程序。然后将该列表插入到临时表中。在批量插入之后，进行过程调用以进行一些计算并返回结果。根据插入临时表的列表的大小，它可能需要以下任何时间：3000 毫秒（N ~ 500）、6000 毫秒（N ~ 1000）、50,000+毫秒（N > 2000）。

我的任务是创建数据块并同时将它们发送到数据库进行处理。在线程（期货）返回结果后，我会将它们聚合并返回给客户端。总而言之，我会将同步调用拆分为多个异步进程（同时执行）并通过发起 HTTP 调用的同一线程返回到客户端 - 登陆到我的控制器中。

一切都会好起来的，如果我的一位更有经验的同事没有强烈反对这种方法，我就不会问这个问题。他的推理是，使用这种方式容易因为线程中断/超时/信号量等原因而出现异常。嗨，甚至说应该避免在 Web 容器中使用多线程，因为它可能会使 Servlet 容器崩溃，以防线程用完。他建议我们应该让浏览器发送多个 AJAX 请求并以块的形式聚合/呈现数据。

您能帮我了解哪种方法更好吗？为什么？

【问题讨论】：

听起来发送并行请求比编写一堆服务器端代码更简单，但这并不是因为将工作从 servlet 卸载到多个线程上存在任何固有问题。
在这种情况下，客户端不仅要处理呈现数据，还要处理聚合。这不会增加客户端的开销吗？我已经编写了服务器端代码（未经测试），但如果这不是这样做的方法，我准备放弃它......
我不认为这两种方法在客观上是对还是错

标签： java multithreading spring-mvc websphere

【解决方案1】：

我会说你的方法要好得多。

应用程序逻辑创建的线程不是应用程序容器线程，仅受操作系统限制。虽然每个 AJAX 请求都使用来自应用程序容器的线程。因此，第二种方法会降低吞吐量并增加达到应用程序容器限制的可能性，而第一种方法则不会。还应该考虑性能，因为创建线程比通过网络发送请求便宜得多。此外，每个网络请求都会使用额外的资源进行身份验证/授权/加密等。
编写正确的多线程代码肯定更难，而且很容易出错。但是，它不应该阻止您这样做，因为并发可以显着提高您的性能。使用 Future 处理中断和超时非常简单，而且您肯定在这里不需要信号量。
将此逻辑暴露给客户端看起来像是破坏了封装。想象一下，您使用 rest api，它通过将数据分成块来强制您发送多个请求。我应该使用什么块大小？如何处理超时/中断？我应该发送多少个请求？等等。在这两种方法中您将面临几乎相同的挑战，但是使用专门为此库设计的 ExecutorService 和 Future 来处理它们要容易得多。

【讨论】：