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

Angular 4应用程序向已部署在WebSphere8servlet容器中的JavaSpringMVC应用程序发送记录列表。然后将该列表插入临时表中。批插入后，将进行过程调用，以便执行一些计算并返回结果。根据插入到临时表中的列表的大小，它可能需要3000ms（N~500）、6000ms（N~1000）、50000+ms（N>2000）之间的任意时间

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

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

---

你能帮我理解哪种方法更好，为什么更好吗？

我想说你的方法更好

由应用程序逻辑创建的线程不是应用程序容器线程，仅受操作系统的限制。而每个AJAX请求都使用来自应用程序容器的线程。因此，第二种方法降低了吞吐量，增加了达到应用程序容器限制的可能性，而第一种方法则没有。还应该考虑性能，因为创建线程比通过网络发送请求便宜得多。另外，每个网络请求都会使用额外的资源进行身份验证/授权/加密等

编写正确的多线程代码显然比较困难，而且很容易出错。但是，它不应该阻止您这样做，因为并发可以显著提高您的性能。使用Future处理中断和超时是非常简单的，当然这里不需要信号量

向客户机公开此逻辑看起来像是破坏了封装。假设您使用RESTAPI，它通过将数据分块来强制您发送多个请求。我应该使用什么块大小？如何处理超时/中断？我应该发送多少请求？在这两种方法中，您将面临几乎相同的挑战，但使用专门为此库（如ExecutorService和Future）设计的库处理这些挑战要容易得多

---

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