java - 异步 JAX-RS 的目的是什么

Question

我正在阅读“RESTful Java with JAX-RS 2.0”一书。我对异步 JAX-RS 完全感到困惑，所以我把所有问题都集中在一个问题上。书上是这样写异步服务器的:

@Path("/customers")
public class CustomerResource {

    @GET
    @Path("{id}")
    @Produces(MediaType.APPLICATION_XML)
    public void getCustomer(@Suspended final AsyncResponse asyncResponse,
                            @Context final Request request,
                            @PathParam(value = "id") final int id) {

        new Thread() {
            @Override
            public void run() {
                asyncResponse.resume(Response.ok(new Customer(id)).build());
            }
        }.start();
    }
}

Netbeans 像这样创建异步服务器:

@Path("/customers")
public class CustomerResource {
    private final ExecutorService executorService = java.util.concurrent.Executors.newCachedThreadPool();

    @GET
    @Path("{id}")
    @Produces(MediaType.APPLICATION_XML)
    public void getCustomer(@Suspended final AsyncResponse asyncResponse, 
                            @Context final Request request,
                            @PathParam(value = "id") final int id) {

        executorService.submit(new Runnable() {
            @Override
            public void run() {
                doGetCustomer(id);
                asyncResponse.resume(javax.ws.rs.core.Response.ok().build());
            }
        });
    }

    private void doGetCustomer(@PathParam(value = "id") final int id) {
    }
}

那些不创建后台线程的使用一些锁定方法来存储响应对象以供进一步处理。此示例用于向客户发送股票报价:

@Path("qoute/RHT")
public class RHTQuoteResource {

    protected List<AsyncResponse> responses;

    @GET
    @Produces("text/plain")
    public void getQuote(@Suspended AsyncResponse response) {
        synchronized (responses) {
            responses.add(response);
        }
    }
}

responses 对象将与一些后台作业共享，并在准备就绪时将报价发送给所有客户端。

我的问题:

1. 在示例 1 和 2 中，网络服务器线程(处理请求的那个)死掉了然后我们创建另一个后台线程。背后的整个想法异步服务器是为了减少空闲线程。这些例子是不减少空闲线程。一个线程死亡，另一个线程诞生。
2. 我认为在容器内创建非托管线程不是个好主意。我们应该只使用使用并发实用程序的托管线程Java EE 7。
3. 异步服务器背后的理念之一是扩展。示例 3 没有扩展，是吗？

Answer 1

执行摘要:你想多了。

---

In example 1 and 2 web server thread(the one that handle request) dies and we create another background thread. The whole idea behind asynchronous server is to reduce idle threads. These examples are not reducing idle threads. One threads dies and another one born.

老实说，两者都不是特别好。在生产服务中，您不会像那样将执行程序保存在私有(private)字段中，而是将其作为单独配置的对象(例如，它自己的 Spring bean)。另一方面，如果没有更多的上下文，您将很难理解这样一个复杂的示例；必须从头开始构建由 bean/托管资源系统组成的应用程序。对于小规模的工作来说，非常小心这一点也不是很重要，很多 web 应用程序都是这样。

The gripping hand从服务器重启中恢复实际上并不是首先要担心的事情。如果服务器重新启动，您可能无论如何都会丢失所有连接，并且如果那些 AsyncResponse 对象不是 Serializable 以某种方式(不保证它们是或不是)，您不能将它们存储在数据库中以启用恢复。最好不要太担心，因为你无能为力! (如果客户没有收到任何回复，他们也会在一段时间后超时；您不能无限期地保留他们。)

I thought creating unmanaged threads inside container is a bad idea. We should only use managed threads using concurrency utilities in Java EE 7.

举个例子!从外部为您的精美生产系统提供执行器。

Again one of ideas behind async servers is to scale. Example 3 does not scale, does it?

它只是将一个对象放入列表中，这根本不是一个很慢的操作，尤其是与正在进行的所有网络和反序列化/序列化的成本相比。它没有显示的是应用程序的其他部分，这些部分从该列表中删除内容，执行处理并返回结果；它们可能实现不当并导致问题，或者它们可以谨慎实现并且系统运行良好。

如果您可以在代码中做得更好，一定要这样做。 (请注意，您不能将工作项存储在数据库中，或者至少您不能确定您可以这样做，即使它碰巧实际上是可能的。不过我对此表示怀疑；可能有信息关于那里的 TCP 网络连接，完全存储和恢复绝非易事。)