我对Asynchronous JAX-RS的工作感到怀疑，这对我来说是新的，我正在尝试掌握它的优势。
我了解的是，客户端发送请求，将请求从请求者线程委派给工作线程，一旦处理完成，则使用AsyncResponse将响应发送回客户端。我还了解到，在整个过程中，客户端都在等待服务器的响应。 （就客户端而言，它与普通的同步请求相同）
它还指出，当请求线程被发送到工作线程进行进一步处理时，因此，通过采用这种方法，I / O线程可以自由接受新连接。
我不了解的是，客户端仍在等待响应，因此客户端与服务器之间仍保持活动连接。这不是在I / O线程中维护的吗？暂停在这里意味着什么？
另外，即使是由于将进程委派给与客户端的工作者连接而释放I / O线程的情况仍然存在，服务器又如何才能接受越来越多的连接呢？
我的下一个问题是关于此处使用的线程池。 I / O线程和辅助线程来自不同的池？工作线程/处理器线程不是来自服务器管理的池吗？
由于无法理解这一点，因此我的下一个思考是，仅为I / O设置一个单独的池，而客户端连接仍处于打开状态的处理与在内部进行处理的情况下阻止I / O一样吗？
我对这个概念还不太了解。
最佳答案
在这种情况下使用的线程池是：
由JAX-RS容器（例如Jersey）管理的请求处理池，以及
工作线程池，通常由您自己的代码管理。
可能有一个与该连接关联的IO线程，但这是一个实现细节，不会影响此连接。
当您使用AsyncResponse时，从句柄方法返回后，请求处理线程（来自池1）将被释放，容器可以使用它来处理另一个请求。
关于您的问题：
“ ...服务器如何接受越来越多的连接？” -与您不对长时间运行的请求不使用AsyncResponse相比，它可以接受更多的连接，因为您正在释放有限的资源之一（线程池＃1中的线程）。连接本身不会被释放，连接也是有限的资源，因此您仍然可以用尽这些资源（以及可能受到CPU或内存的限制）。
“工作线程/处理器线程不是来自服务器管理的池吗？” -不正常。参见Paul Samsotha here链接中的示例-应用程序代码本身会创建一个新线程。这可能不是您的方式，您很可能希望使用ExecutorService或类似名称，但是重点是您自己管理“工人线程”。如果使用Jersey的@ManagedAsync批注，则是一个例外。
您的最后一个问题应该由我对＃1的回答来回答-在较低级别上，即使您使用的是AsyncResponse，仍然有与连接关联的资源，但是AsyncResponse确实释放了容器的请求处理线程，可以限制的数量比最大连接数更多。您可以选择通过更改服务器配置而不是使用AsyncResponse来解决此问题，但是AsyncResponse有两个优点-它在应用程序的控制下，并且是按请求而不是按服务器。