问题标签 [completable-future]

想象一下，我们有以下虚拟代码：

JVM 是否知道这一点cf1并cf2在这种情况下携带独立的线程？如果线程依赖（例如，使用一个到数据库的连接）会发生什么变化？

更一般的，如何CompletableFuture同步线程？

CompletableFutureJDK 8 中引入的与io.netty.util.concurrent.FutureNetty 提供的相比如何？

Netty 文档提到

JDK 8 添加了 CompletableFuture，它有些重叠 io.netty.util.concurrent.Future http://netty.io/wiki/using-as-a-generic-library.html

我试图得到答案的问题是：

1. 它们的相同点和不同点是什么？
2. 两者的性能特征有何不同？哪一个能够更好地扩展？

关于相似之处/不同之处，我已经能够提出以下几点：

相似之处： 基本相似之处在于与 Java Future 相比，两者都是非阻塞的。这两个类都有可用于向未来添加侦听器、内省任务的失败和成功并从任务中获取结果的方法。

区别： CompletableFuture似乎有一个更丰富的接口，用于组合多个异步活动等。io.netty.util.concurrent.Future另一方面，Netty 允许将多个侦听器添加到同一个 Future，此外还允许删除侦听器。

我正在尝试掌握 Java 8 CompletableFuture。我怎样才能将这些加入到人并在“allOf”之后返回它们。下面的代码不起作用，但可以让您了解我尝试过的内容。

在javascript ES6中我会做

到目前为止我在 Java 方面的努力

我有一个可完成的未来（future1），它创建了 10 个可完成的期货（futureN）。有没有办法将 future1 设置为仅当所有 futureN 都完成时才完成？

我想编写一个返回CompletableFuture. 未来的唯一目的是跟踪方法何时完成，而不是其结果。是返回更好CompletableFuture<Void>还是CompletableFuture<?>？是否有理由偏爱其中一个，或者它们可以互换？

• CompletableFuture本身CompletableFuture<Void>从它的许多方法中返回。
• java.nio有一个：Future<Void>。AsynchronousSocketChannelFuture<Void> connect(SocketAddress remote)
• 另一方面，java.util.concurrent类喜欢ExecutorService和ScheduledExecutorServicereturn Future<?>：例如， with Future<?> submit(Runnable task)。

请注意，我只询问返回类型，而不是参数列表、变量声明或其他上下文。

我试图了解CompletableFutureJava 8 中如何与Java 内存模型交互。在我看来，对于程序员的理智来说，理想情况下，以下内容应该是正确的：

1. 线程中完成CompletableFuture 发生之前的操作，任何与完成相关的阶段都被执行
2. 线程中注册完成的动作会在完成依赖阶段执行之前创建一个依赖阶段

java.util.concurrent 文档中有一条注释说：

线程中的操作在提交Runnable到Executor 发生之前执行之前。同样对于Callables 提交到一个ExecutorService.

这表明第一个属性为真，只要完成未来的线程执行完成依赖阶段或将其提交给Executor. 另一方面，在阅读CompletableFuture 文档后，我不太确定：

为非异步方法的依赖完成提供的操作可以由完成当前的线程执行，也可以由CompletableFuture完成方法的任何其他调用者执行。

这让我想到了我的问题：

1. 上面的两个假设属性是真的还是假的？
2. 是否有任何特定文档说明在使用 时是否存在内存可见性保证CompletableFuture？

附录：

以具体示例的方式，考虑以下代码：

是否保证添加"foo"到list1lambda 函数可见？是否保证添加list1到list2的依赖阶段是可见的future？

我目前有一个 grails 应用程序，在 grails 2.4.2 上运行，它似乎使用 java 期货以阻塞方式进行 REST 调用，如下所示

我的目标是将这段代码重构为异步的，因为上面的代码片段似乎通过立即调用“阻塞”get 函数来破坏使用异步编程的目的。我正在考虑以下选项

1. Grails 承诺
2. Guava 可听的未来
3. Java 8：可完成的未来

我的问题不是要考虑哪些选项，而是更多关于是否有一种简单、简单的方法来衡量指标，以表明使用非阻塞调用将为访问 grails web 应用程序的用户提供更好的响应时间。

我正在尝试通过 CompletableFuture.supplyAsync 将优先级队列添加到使用 ThreadPoolExecutor 和 LinkedBlockingQueue 的现有应用程序中。问题是我无法想出一个设计来分配任务优先级，然后我可以在 PriorityBlockingQueue 的比较器中访问这些优先级。那是因为我的任务被 CompletableFuture 封装到一个名为 AsyncSupply 的私有内部类的实例中，该实例将原始任务隐藏在私有字段中。然后使用这些转换为 Runnables 的 AsyncSupply 对象调用 Comparator，如下所示：

我研究了扩展 CompletableFuture 的可能性，以便我可以将它包装在不同的对象中，但 CompletableFuture 的大部分内容都是封装且不可继承的。因此，扩展它似乎不是一种选择。也不是用适配器封装它，因为它实现了一个非常广泛的接口。

除了复制整个 CompletableFuture 并对其进行修改之外，我不确定如何解决此问题。有任何想法吗？

在 Java 8 中，接口或抽象类定义返回CompletableFuture而不是返回的API 更好Future吗？考虑到转换为丑陋Future的CompletableFuture事实，并且这CompletableFuture将使调用者更灵活地直接使用函数式样式，那么 API 只返回的充分理由是Future什么？

在“Java 8 in action”一书中（由 Urma、Fusco 和 Mycroft 撰写）他们强调并行流在内部使用公共 fork 连接池，虽然这可以全局配置，例如使用 System.setProperty(...)，但不可能为单个并行流指定值。

我已经看到了涉及在定制的 ForkJoinPool 中运行并行流的解决方法。

在本书的后面，他们有一整章专门介绍 CompletableFuture，在此期间他们有一个案例研究，他们比较了使用 parallelStream 与 CompletableFuture 各自的性能。事实证明，它们的性能非常相似——它们强调这样做的原因是它们都默认使用相同的公共池（因此线程数量相同）。

他们继续展示了一个解决方案，并认为 CompletableFuture 在这种情况下更好，因为它可以配置为使用自定义 Executor，线程池大小由用户选择。当他们更新解决方案以利用它时，性能会显着提高。

这让我想到 - 如果使用上面突出显示的解决方法对并行流版本执行相同的操作，性能优势是否会相似，因此这两种方法会在性能方面再次变得相似吗？在这种情况下，当开发人员显然需要更多工作时，为什么要选择 CompletableFuture 而不是并行流。