何时使用CompletableFuture的非异步方法？ [英] When to use non-async methods of CompletableFuture?

问题描述

我（大多数）理解 CompletableFuture ：

• 非异步（同步执行）


• 默认异步（使用默认执行程序异步）


• 自定义异步（使用自定义执行程序异步） ）

我的问题是：何时应该支持使用非异步方法？

如果您的代码块调用其他方法也会返回 CompletableFuture s会发生什么？从表面上看，这可能看起来很便宜，但是如果这些方法也使用非异步调用会发生什么？这是否会增加一个可能变得昂贵的长非同步块？

What happens if you have a code block that invokes other methods that also return CompletableFutures? This might look cheap on the surface, but what happens if those methods also use non-async invocation? Doesn't this add up to one long non-async block that could get expensive?

是否应该将非异步执行限制为短的，明确定义的代码 - 不调用其他方法的块吗？

Should one restrict the use of non-async execution to short, well-defined code-blocks that do not invoke other methods?

推荐答案

何时应该支持使用非异步方法？

When should one favor the use of non-async methods?

延续的决定与先行任务本身没有什么不同。您何时选择使操作异步（例如，使用 CompletableFuture ）而不是编写纯同步代码？同样的指导适用于此。

The decision for continuations is no different than for the antecedent task itself. When do you choose to make an operation asynchronous (e.g., using a CompletableFuture) vs. writing purely synchronous code? The same guidance applies here.

如果您只是使用结果或使用完成信号启动另一个异步操作，那么它本身是一个廉价的操作，没有理由不使用同步完成方法。

If you are simply consuming the result or using the completion signal to kick off another asynchronous operation, then that itself is a cheap operation, and there is no reason not to use the synchronous completion methods.

另一方面，如果你将多个长期运行的操作链接在一起每个都是自己的异步操作，然后使用异步完成方法。

On the other hand, if you are chaining together multiple long-running operations that would each be an async operation in their own right, then use the async completion methods.

如果你介于两者之间，相信你的直觉，或者只是去同步完成方法。如果您没有协调数千个任务，那么您将不会增加大量开销。

If you're somewhere in between, trust your gut, or just go with the async completion methods. If you're not coordinating thousands of tasks, then you won't be adding a whole lot of overhead.

是否应该将非异步执行的使用限制为不调用其他方法的简短明确的代码块？

Should one restrict the use of non-async execution to short, well-defined code-blocks that do not invoke other methods?

我会将它们用于不长时间运行的操作。您无需将其使用限制为简单短而简单的回调。但我认为你有正确的想法。

I would use them for operations that are not long-running. You don't need to restrict their use to trivially short and simple callbacks. But I think you have the right idea.

如果你正在使用 CompletableFuture ，那么你已经决定了代码库中至少一些操作需要异步执行，但可能不是所有操作都是异步的。你是如何决定哪个应该异步，哪个不应该？如果你将相同的分析应用于continuation，我认为你会没事的。

If you're using CompletableFuture, then you have decided that at least some operations in your code base necessitate async execution, but presumably not all operations are async. How did you decide which should be async and which should not? If you apply that same analysis to continuations, I think you'll be fine.

如果你有一个调用其他的代码块怎么办？同样返回 CompletableFuture s的方法？从表面上看，这可能看起来很便宜，但是如果这些方法也使用非异步调用会发生什么？这是否会增加一个可能变得昂贵的长非同步块？

What happens if you have a code block that invokes other methods that also return CompletableFutures? This might look cheap on the surface, but what happens if those methods also use non-async invocation? Doesn't this add up to one long non-async block that could get expensive?

返回 CompletableFuture 通常表示基础操作被安排为异步发生，因此不应该是一个问题。在大多数情况下，我希望流程看起来像这样：

Returning a CompletableFuture generally signifies that the underlying operation is scheduled to occur asynchronously, so that should not be a problem. In most cases, I would expect the flow to look something like this:

1. 您同步调用异步方法返回 CompletableFuture 。它会调度一些异步操作以最终提供结果。您的呼叫几乎立即返回，没有阻塞。


2. 完成后，可以调用一个或多个延续。其中一些可能会调用其他异步操作。那些会调用方法来安排额外的异步操作，但和之前一样，它们几乎立即返回。


3. 转到（2）或完成。

1. You synchronously call an async method returning a CompletableFuture. It schedules some async operation to eventually provide a result. Your call returns almost immediately, with no blocking.
2. Upon completion, one or more continuations may be invoked. Some of those may invoke additional async operations. Those will call into methods that will schedule additional async operations, but as before, they return almost immediately.
3. Go to (2), or finish.

这篇关于何时使用CompletableFuture的非异步方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！