玩框架,promises,非阻塞线程编程

Play framework, promises, non blocking thread programming

function1() 比 function2() 有什么好处(除了执行两个 GET 查询时并行性很小)?在我看来,控制器线程在这两种情况下都是非阻塞的,但是在等待结果时必须阻塞其中一个后台线程。举个更好的例子,当我们查看 function3() 时,我们看到 databaseDao 线程被阻塞,直到操作完成(在 dao 内部使用 JPA)。

public static F.Promise<Result> function1() {
    final F.Promise<WSResponse> twitterPromise = WS.url("http://www.twitter.com").get();
    final F.Promise<WSResponse> typesafePromise = WS.url("http://www.typesafe.com").get();

    return twitterPromise.flatMap((twitter) -> typesafePromise.map((typesafe) -> ok(twitter.getBody() + typesafe.getBody())));
}

public static F.Promise<Result> function2() {
    F.Promise<String> promise = F.Promise.promise(() -> {
        HttpClient client = HttpClientBuilder.create().build();
        HttpGet request1 = new HttpGet("http://www.twitter.com");
        HttpGet request2 = new HttpGet("http://www.typesafe.com");

        HttpResponse response = client.execute(request1);
        HttpResponse response2 = client.execute(request2);

        // result is not important
        return response.toString() + response2.toString();
    });

    return promise.map(Results::ok);
}

public static F.Promise<Result> function3() {
    F.Promise<String> promise = F.Promise.promise(() -> databaseDao.longRunningOperation());

    return promise.map(Results::ok);
}

如果函数阻塞,我们的后台线程池会很快消失。所以非营利组织在 Spring 框架和 tomcat 上发挥框架和承诺?

编辑:

public static F.Promise<Result> function4() {
    F.Promise<String> promise = F.Promise.promise(() -> {
        HttpClient client = HttpClientBuilder.create().build();
        HttpGet request1 = new HttpGet("http://www.twitter.com");
        HttpResponse response = client.execute(request1);

        return response.toString();
    });

    F.Promise<String> promise2 = F.Promise.promise(() -> {
        HttpClient client = HttpClientBuilder.create().build();
        HttpGet request2 = new HttpGet("http://www.typesafe.com");
        HttpResponse response2 = client.execute(request2);
        return response2.toString();
    });

    return promise.flatMap(p1 -> promise2.map(p2 -> ok(p1 + p2)));
}

上面的函数阻塞了两个线程,所以它比 function1 差?但是执行时间可以比较。例如,如果 promise1 需要 5 秒,promise2 需要 4 秒,结果将在 5 秒内到达?

What profit is from function1() over function2() (except little parallelism when two GET query is executing)?

这不仅仅是并行性。 Play WS 建立在 of of AsyncHttpClient 之上,它是一个非阻塞 API。在 function2 中,您似乎正在使用 Apache HttpClient,这是一个阻塞 API。并行性有帮助。正如@Salem 已经说过的那样,function1 只会与最长的请求一样长,而 function2 每次都需要与两个请求一样长的时间。

In my opinion controller thread is non blocked in both cases, ...

是的,只要 Promise 被转移到另一个 ExecutionContext,我们就不会阻止 Play 的内部结构。

...but one of background thread must be blocked when waiting for result.

不正确。由于 function1 仅调用异步的 WS API,因此它不会阻塞 任何 等待响应的线程。 function2 可能不会阻塞负责控制器功能的线程,但它必须在某处阻塞。这并不是说将它包装在 Promise 中是个坏主意——如果它必须阻塞,不妨在其他地方进行。

...look at function3() we see that databaseDao thread is blocked until operation is finished (inside dao JPA is used).

事实上,大多数数据库驱动程序都会阻塞,除了尝试不太流行的异步驱动程序之外,实际上没有任何方法可以解决这个问题。 function2function3 在行为上比 function1function2 更相似。 function 确实属于自己的 class。

If functions are blocking our background thread pool is gone fast.

是的,但大多数时候我们必须在某处进行阻塞,如果您可以选择使用异步 API,那就太好了。例如,出于上述原因,我总是使用 function1 而不是 function2。但是对于数据库调用,我忍受了阻塞API,因为在一个对数据库进行大量读取的应用程序中,如果我的数据库已经因查询而超载,那么节省一些应用程序线程对我来说并没有真正的帮助。

above function [function4] is blocking two threads, so it is worse than function1? But executing time can be comparable. For example if promise1 take 5second, and promise2 take 4 second, result will come in 5 second?

function4 更糟糕,因为它比 function1 阻塞了很多。这是否会立即影响应用程序的性能取决于您是否正在增加线程数。但我看不出有任何理由选择 function4 而不是 function1function4 可以在与 function1 相当的时间内完成, 提供 它具有执行此操作所需的线程。如果池中只有一个线程可用,那么第二个 promise 可能必须等待第一个 promise 完成才能执行。在function1,这不会发生。