java - 异步JAX-RS

Question

我对异步 JAX-RS 的工作有疑问，这对我来说有点新，我正在努力掌握它的优势。我的理解是，客户端发送请求，请求从请求者线程委托(delegate)给工作线程，处理完成后，响应将使用 AsyncResponse 发送回客户端。我还了解到，在整个过程中，客户端等待服务器的响应。 (因此对于客户端而言，它与普通的同步请求相同)

它还指出，当请求线程被发送到工作线程进行进一步处理时，因此通过采用这种方法，I/O 线程可以自由地接受新连接。

我不明白的是，客户端仍在等待响应，因此客户端和服务器之间仍保持 Activity 连接。这不是在 I/O 线程中维护的吗？这里的暂停是什么意思？

此外，即使由于将进程委托(delegate)给与客户端的工作连接而导致 I/O 线程被释放，服务器如何才能接受越来越多的连接？

我的下一个问题是关于这里使用的线程池。 I/O 线程和工作线程来自不同的池？工作线程/处理器线程不是来自服务器管理的池吗？

由于我无法理解这一点，我的下一个思考是，只为 I/O 建立一个单独的池，并且在客户端连接仍然存在的情况下进行处理与在右侧的处理中阻塞 I/O 是一样的？

我还没有很好地理解这个概念。

Answer 1

此场景中使用的线程池是:

1. 请求处理池，由 JAX-RS 容器(例如 Jersey)管理，以及
2. 工作线程池，通常由您自己的代码管理。

可能有一个与连接关联的 IO 线程，但这是一个不会影响此的实现细节。

当您使用AsyncResponse时，一旦从句柄方法返回，请求处理线程(来自池#1)就会被释放，容器可以使用它来处理另一个请求。

关于你的问题:

1. “...服务器如何接受越来越多的连接？” - 与不使用 AsyncResponse 来处理长时间运行的请求相比，它可以接受更多的连接，因为您正在释放有限的资源之一(线程池 #1 中的线程) )。连接本身并没有被释放，而且连接也是有限的资源，因此您仍然可能会耗尽这些资源(并且可能受到 CPU 或内存的限制)。
2. “工作线程/处理器线程不是来自服务器管理的池吗？” - 通常不会。请参阅 Paul Samsotha here 链接中的示例- 应用程序代码本身创建一个新线程。这可能不是你会做的，你很可能想使用 ExecutorService 或类似的，但重点是你自己管理“工作线程”。此处的异常(exception)情况是，如果您使用 Jersey 的 @ManagedAsync 注释。
3. 您的最后一个问题应该由我对 #1 的回答来回答 - 在较低级别，即使您使用 AsyncResponse，仍然存在与连接关联的资源，但是 AsyncResponse 确实释放了容器的请求处理线程，其数量可能比最大连接数更有限。您可以选择通过更改服务器配置而不是使用 AsyncResponse 来处理此问题，但是 AsyncResponse 有两个优点 - 它在应用程序的控制之下，并且是针对每个请求的而不是每台服务器。