gpt4 book ai didi

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

转载 作者:塔克拉玛干 更新时间:2023-11-02 19:21:14 28 4
gpt4 key购买 nike

function1() 相对于 function2() 有什么好处(除了执行两个 GET 查询时的并行性很小)?在我看来, Controller 线程在这两种情况下都是非阻塞的,但是在等待结果时必须阻塞其中一个后台线程。举个更好的例子,当我们查看 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);
}

如果函数阻塞,我们的后台线程池就会很快消失。所以非营利组织玩框架和 promise 优于 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 建立在 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 可能不会阻塞负责 Controller 函数的线程,但它必须在某处阻塞。这并不是说将它包装在 Promise 中是个坏主意——如果它必须阻塞,不妨在其他地方进行。

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

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

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 中,这不会发生。

关于java - 玩框架,promises,非阻塞线程编程,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28832034/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com