浅谈CompletableFuture

最新推荐文章于 2024-09-21 21:26:20 发布
最新推荐文章于 2024-09-21 21:26:20 发布
阅读量1.8k 收藏 19
点赞数 28
分类专栏： 多线程与IO 文章标签： java IO 多线程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/smart_an/article/details/134918492
版权
作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

回顾FutureTask

之前我们已经学习过FutureTask以及线程池继承体系，里面介绍了线程池是如何借助FutureTask返回异步结果的：

而FutureTask#run()的作用就是执行任务，并把最终结果设置到FutureTask.outcome中：

FutureTask#get()为了能获取到最终结果，内部会阻塞，直到outcome被赋值：

基于以上原因，实际编程中如果期望得到异步结果，一般有两种方式：

  • FutureTask#get()阻塞等待
  • 判断FutureTask#isDone()，如果为true则返回

第一种大家都比较熟悉，下面演示第二种：

@RunWith(SpringRunner.class)
@SpringBootTest
public class CompletableFutureTest {

    private final ExecutorService executor = Executors.newFixedThreadPool(5);

    /**
     * 轮询异步结果并获取
     *
     * @throws ExecutionException
     * @throws InterruptedException
     */
    @Test
    public void testFutureAsk() throws ExecutionException, InterruptedException {

        // 任务1
        Future<String> runnableFuture = executor.submit(new Runnable() {
            @Override
            public void run() {
                try {
                    System.out.println("Runnable异步线程开始...");
                    TimeUnit.SECONDS.sleep(3);
                    System.out.println("Runnable异步线程结束...");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }, "fakeRunnableResult");

        // 任务2
        Future<String> callableFuture = executor.submit(new Callable<String>() {
            @Override
            public String call() throws Exception {
                System.out.println("Callable异步线程开始...");
                TimeUnit.SECONDS.sleep(3);
                System.out.println("Callable异步线程结束...");
                return "callableResult";
            }
        });

        boolean runnableDone = false;
        boolean callableDone = false;

        // 不断轮询，直到所有任务结束
        while (true) {
            TimeUnit.MILLISECONDS.sleep(500);
            System.out.println("轮询异步结果...");
            if (runnableFuture.isDone()) {
                System.out.println("Runnable执行结果:" + runnableFuture.get());
                runnableDone = true;
            }
            if (callableFuture.isDone()) {
                System.out.println("Callable执行结果:" + callableFuture.get());
                callableDone = true;
            }
            if (runnableDone && callableDone) {
                break;
            }
        }

        System.out.println("任务全部结束");
    }
}

结果

Runnable异步线程开始...

Callable异步线程开始...

轮询异步结果...

轮询异步结果...

轮询异步结果...

轮询异步结果...

轮询异步结果...

Runnable异步线程结束...

Callable异步线程结束...

轮询异步结果...

Runnable执行结果:fakeRunnableResult

Callable执行结果:callableResult

任务全部结束

FutureTask的不足

FutureTask其实各方面都比较完美，初见时甚至让人惊艳，因为它允许我们获取异步执行的结果！但FutureTask#get()本身是阻塞的，假设当前有三个下载任务在执行：

  • task1（预计耗时5秒）
  • task2（预计耗时1秒）
  • task3（预计耗时1秒）

如果阻塞获取时不凑巧把task1.get()排在最前面，那么会造成一定的资源浪费，因为task2和task3早就已经准备好了，可以先拿出来处理，以获得最佳的用户体验。

我们固然可以像上面的Demo一样，结合轮询+isDone()的方式改进，但仍存在以下问题：

  • 轮询间隔多少合适？
  • 为了避免while(true)阻塞主线程逻辑，可能需要开启单独的线程轮询，浪费一个线程
  • 仍然无法处理复杂的任务依赖关系

特别是第三点，使用FutureTask几乎难以编写...也就是说FutureTask很难处理异步编排问题。

CompletableFuture：基于异步回调的Future

CompletableFuture VS FutureTask

废话不多说，直接上代码：

@Test
public void testCallBack() throws InterruptedException, ExecutionException {
    // 提交一个任务，返回CompletableFuture
    CompletableFuture<String> completableFuture = CompletableFuture.supplyAsync(new Supplier<String>() {
        @Override
        public String get() {
            System.out.println("=============>异步线程开始...");
            System.out.println("=============>异步线程为：" + Thread.currentThread().getName());
            try {
                TimeUnit.SECONDS.sleep(10);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("=============>异步线程结束...");
            return "supplierResult";
        }
    });
    
	// 阻塞获取结果
    System.out.println("异步结果是:" + completableFuture.get());
    System.out.println("main结束");
}

结果

=============>异步线程开始...

=============>异步线程为：ForkJoinPool.commonPool-worker-9

=============>异步线程结束...

异步结果是:supplierResult

main结束

整个过程看起来和同步没啥区别，因为我们在main线程中使用了CompletableFuture#get()，直接阻塞了。当然你也可以使用CompletableFuture#isDone()改进，但我们并不推荐你把CompletableFuture当成FutureTask使用。

两者如此相似，有什么区别吗？

CompletableFuture和FutureTask的异同点：

  • 相同：都实现了Future接口，所以都可以使用诸如Future#get()、Future#isDone()、Future#cancel()等方法
  • 不同：
    • FutureTask实现了Runnable，所以它可以作为任务被执行，且内部维护outcome，可以存储结果
    • CompletableFuture没有实现Runnable，无法作为任务被执行，所以你无法把它直接丢给线程池执行，相反地，你可以把Supplier#get()这样的函数式接口实现类丢给它执行
    • CompletableFuture实现了CompletionStage，支持异步回调

总的来说，FutureTask和CompletableFuture最大的区别在于，FutureTask需要我们主动阻塞获取，而CompletableFuture支持异步回调（后面演示）。

如果大家拿上面的代码和之前的线程池+Runnable/Callable对比，就会发现CompletableFuture好像承担的其实是线程池的角色，而Supplier#get()则对应Runnable#run()、Callable#call()。但我们在分析线程池继承体系时从未见过CompletableFuture，Supplier也只是Java8预置的函数式接口而已，并不是任务类。

也就是说，不是线程池的CompletableFuture + 不是任务类的函数式接口实例，竟然把异步任务搞定了！

所以：

  • CompletableFuture底层到底做了什么？
  • 它为什么能把函数式接口的实例作为任务执行？明明既不是Runnable也不是Callable！
  • CompletionStage和异步回调之间有什么关系？

CompletableFuture与CompletionStage

大家可能对于CompletionStage比较陌生，没关系，先看代码：

@Test
public void testCallBack() throws InterruptedException, ExecutionException {
    // 提交一个任务，返回CompletableFuture（注意，并不是把CompletableFuture提交到线程池，它没有实现Runnable）
    CompletableFuture<String> completableFuture = CompletableFuture.supplyAsync(new Supplier<String>() {
        @Override
        public String get() {
            System.out.println("=============>异步线程开始...");
            System.out.println("=============>异步线程为：" + Thread.currentThread().getName());
            try {
                TimeUnit.SECONDS.sleep(10);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("=============>异步线程结束...");
            return "supplierResult";
        }
    });

    // 异步回调：上面的Supplier#get()返回结果后，异步线程会回调BiConsumer#accept()
    completableFuture.whenComplete(new BiConsumer<String, Throwable>() {
        @Override
        public void accept(String s, Throwable throwable) {
            System.out.println("=============>异步任务结束回调...");
            System.out.println("=============>回调线程为：" + Thread.currentThread().getName());
        }
    });

    // CompletableFuture的异步线程是守护线程，一旦main结束就没了，为了看到打印结果，需要让main休眠一会儿
    System.out.println("main结束");
    TimeUnit.SECONDS.sleep(15);
}

结果

=============>异步线程开始...

=============>异步线程为：ForkJoinPool.commonPool-worker-9

main结束

=============>异步线程结束...

=============>异步任务结束回调...

=============>回调线程为：ForkJoinPool.commonPool-worker-9

你可以暂时把每一部分的方法理解为提交一个任务。

到这里，大家应该会有两个疑问：

  • CompletionStage是什么？
  • 它和异步回调有啥关系？

本小节先回答第一个问题，第二个问题留待后续章节阐述（见右侧目录<异步回调的实现机制>）。

主线程调用了CompletableFuture#whenComplete()：

// 异步回调：上面的Supplier#get()返回结果后，异步线程会回调BiConsumer#accept()
completableFuture.whenComplete(new BiConsumer<String, Throwable>() {
    @Override
    public void accept(String s, Throwable throwable) {
        System.out.println("=============>异步任务结束回调...");
    }
});

实际上这个方法定义在CompletionStage接口中（方法超级多）：

public interface CompletionStage<T> {
    // 省略其他方法...
    
    /**
     * Returns a new CompletionStage with the same result or exception as
     * this stage, that executes the given action when this stage completes.
     *
     * <p>When this stage is complete, the given action is invoked with the
     * result (or {@code null} if none) and the exception (or {@code null}
     * if none) of this stage as arguments.  The returned stage is completed
     * when the action returns.  If the supplied action itself encounters an
     * exception, then the returned stage exceptionally completes with this
     * exception unless this stage also completed exceptionally.
     *
     * @param action the action to perform
     * @return the new CompletionStage
     */
    public CompletionStage<T> whenComplete
        (BiConsumer<? super T, ? super Throwable> action);
    
    // 省略其他方法...
}

而CompletableFuture实现了whenComplete()：

public class CompletableFuture<T> implements Future<T>, CompletionStage<T> {
    // 省略其他方法...
    
    public CompletableFuture<T> whenComplete(
        BiConsumer<? super T, ? super Throwable> action) {
        return uniWhenCompleteStage(null, action);
    }
    
    private CompletableFuture<T> uniWhenCompleteStage(Executor e, BiConsumer<? super T, ? super Throwable> f) {
        if (f == null) throw new NullPointerException();
        CompletableFuture<T> d = new CompletableFuture<T>();
        if (e != null || !d.uniWhenComplete(this, f, null)) {
            UniWhenComplete<T> c = new UniWhenComplete<T>(e, d, this, f);
            push(c);
            c.tryFire(SYNC);
        }
        return d;
    }
    
    // 省略其他方法...
}

所以，CompletionStage是什么呢？

我的回答是：

  • 它是一个“很简单”的接口。完全独立，没有继承任何其他接口，所有方法都是它自己定义的。
public interface CompletionStage<T> {
    // 定义了超级多类似whenComplete()的方法
}
  • 它是个不简单的接口。因为CompletableFuture实现Future的同时，还实现了它。Future方法就6、7个，而CompletionStage的方法超级多，所以如果你打开CompletableFuture的源码，目之所及几乎都是它对CompletionStage的实现。
public class CompletableFuture<T> implements Future<T>, CompletionStage<T> {
    // 一些字段
    // 实现Future的方法
    
    // 实现CompletionStage的方法
    // 一些私有方法，配合CompletionStage
    // 一些内部类，配合CompletionStage
}
  • 异步回调其实和CompletionStage有着很大的关系（废话，FutureTask也实现了Future，但不能异步回调）

总而言之，CompletionStage是一个接口，定义了一些方法，CompletableFuture实现了这些方法并设计出了异步回调的机制。

具体怎么做到的，稍后见分晓。

一个小细节

有一个细节，很多人应该都不曾注意：

上面注释说的是：

异步线程会回调BiConsumer#accept()

咋一看没什么神奇，但你如果停下来理一下自己的思路，就会发现刚才你以为的是：

异步线程会回调CompletableFuture#whenComplete()

上面介绍CompletionStage时，我说的是“主线程调用了CompletableFuture#whenComplete()”，而不是异步线程调用。

换句话说，CompletionStage中定义的诸如whenComplete()等方法虽然和异步回调有关系，但并不是最终被回调的方法，最终被回调的其实是whenComplete(BiConsumer)传进去的BiConsumer#accept()。

到这里，你可能懵逼了，那这个CompletionStage定义了那么多方法，到底是干啥用的？异步线程又为何会回调它传入的函数接口的方法呢，BiConsumer#accept()明明不是Runnable#run()、Callable#call()呀！

异步回调的实现机制

上面种种表述，似乎都在暗示CompletableFuture#supplyAsync()会开启一个异步线程，然后才有后面的一系列异步回调操作。

为了更好地理解CompletableFuture的异步回调，我们对现有的疑问进行进一步的拆分：

左边为主线程，右边为异步线程。

异步线程哪来的，Supplier如何被执行？

之前分析过CompletableFuture和FutureTask的异同点，其中有一点提到：

  • CompletableFuture没有实现Runnable，无法作为任务被执行，所以你无法把它直接丢给线程池执行，相反地，你可以把Supplier#get()这样的函数式接口实现类丢给它执行

那么CompletableFuture为什么能执行“任务”，异步线程又是哪来的，为什么Supplier没有实现Runnable/Callable也能被执行？

跟随主线程进入CompletableFuture#supplyAsync()，我们会发现：

注意看Doug Lea大佬写的注释：

返回一个新的CompletableFuture，该future是由运行在{@link ForkJoinPool#commonPool()}中的任务异步完成的，其值是通过调用给定的Supplier获得的。

总的来说，和FutureTask有点像，都是传入某种参数，然后返回Future。

从Doug Lea大佬的注释中，我们可以窥见部分重要的信息：

  • 异步线程来自ForkJoinPool线程池
  • 通过CompletableFuture#supplyAsync(supplier)传入Supplier，返回CompletableFuture对象，它包含一个未来的value，且这个value会在稍后由异步线程执行Supplier#get()产生

如何验证大佬说的是不是正确的呢？

开个玩笑，后端之事，哪轮得到前端插嘴。

来，我们一起看源码~

我们可以看到CompletableFuture#supplyAsync(supplier)内部调用了asyncSupplyStage(asyncPool, supplier)，此时传入了一个线程池asyncPool，它是CompletableFuture的成员变量：

useCommonPool为true时会使用ForkJoinPool，而useCommonPool取决于运行当前程序的硬件是否支持多核CPU，具体大家可以自己看源码。

现在我们已经确定了异步线程来自ForkJoinPool，剩下的问题是，主线程传进来的Supplier压根没有实现Runnable/Callable接口，怎么被异步线程执行呢？

哦~和ExecutorService#submit()一样的套路：包装成Task再执行。只不过这次被包装成了AsyncSupply，而不是FutureTask：

AsyncSupply名字虽然怪异，但和当初的FutureTask颇为相似，都实现了Future和Runnable，具备 任务+结果 双重属性：

然后就是熟悉的配方：

等线程池分配出线程，最终会执行AsyncSupply#run()：

异步线程会执行AsyncSupply#run()并在方法内调用f.get()，也就是Supplier#get()，阻塞获取结果并通过d.completeValue(v)把值设置到CompletableFuture中，而CompletableFuture d已经在上一步asyncSupplyStage()中被返回。最终效果和线程池+FutureTask是一样的，先返回Future实例，再通过引用把值放进去。

所以，completableFuture.get()可以阻塞得到result：

至此，我们搞明白了异步线程是怎么来的，以及Supplier是如何被执行的。

从这个层面上来看，CompletableFuture相当于一个自带线程池的Future，而CompletableFuture#supplyAsync(Supplier)倒像是ExecutorService#submit(Runnable/Callable)，内部也会包装任务，最终丢给Executor#execute(Task)。只不过ExecutorService是把Runnable#run()/Callable#call()包装成FutureTask，而CompletableFuture则把乱七八糟的Supplier#get()等函数式接口的方法包装成ForkJoinTask。

异步回调的原理

阻塞get()已经不足为奇，关键是回调机制如何实现？

在介绍CompletableFuture的回调机制之前，先跟大家说明一下，回调并没有大家想的那么神奇，尤其CompletableFuture的回调机制，其实本质上是对多个CompletableFuture内部函数的顺序执行，只不过发起者是异步线程而不是主线程：

现在第1个问题已经解决：

第2、3两个问题其实是同一个问题，放在一起讲。

为了能更好地说明问题，我们把原本第二部分的CompletableFuture#whenComplete()换成CompletableFuture#thenApply()，本质是一样的，顺便熟悉熟悉其他方法（也是CompletableFuture对CompletionStage的实现）：

@RunWith(SpringRunner.class)
@SpringBootTest
public class CompletableFutureTest {

    @Test
    public void testCallBack() throws InterruptedException {
        // 任务一：把第一个任务推进去，顺便开启异步线程
        CompletableFuture<String> completableFuture1 = CompletableFuture.supplyAsync(new Supplier<String>() {
            @Override
            public String get() {
                System.out.println("=============>异步线程开始...");
                try {
                    TimeUnit.SECONDS.sleep(10);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("=============>completableFuture1任务结束...");
                System.out.println("=============>执行completableFuture1的线程为：" + Thread.currentThread().getName());
                return "supplierResult";
            }
        });
        System.out.println("completableFuture1:" + completableFuture1);

        // 任务二：把第二个任务推进去，等待异步回调
        CompletableFuture<String> completableFuture2 = completableFuture1.thenApply(new Function<String, String>() {
            @Override
            public String apply(String s) {
                try {
                    TimeUnit.SECONDS.sleep(10);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("=============>completableFuture2任务结束 result=" + s);
                System.out.println("=============>执行completableFuture2的线程为：" + Thread.currentThread().getName());
                return s;
            }
        });
        System.out.println("completableFuture2:" + completableFuture2);

        // 任务三：把第三个任务推进去，等待异步回调
        CompletableFuture<String> completableFuture3 = completableFuture2.thenApply(new Function<String, String>() {
            @Override
            public String apply(String s) {
                try {
                    TimeUnit.SECONDS.sleep(10);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("=============>completableFuture3任务结束 result=" + s);
                System.out.println("=============>执行completableFuture3的线程为：" + Thread.currentThread().getName());
                return s;
            }
        });
        System.out.println("completableFuture3:" + completableFuture3);

        System.out.println("主线程结束");
        TimeUnit.SECONDS.sleep(40);
    }
}

结果

completableFuture1:java.util.concurrent.CompletableFuture@76e4212[Not completed]

=============>异步线程开始...

completableFuture2:java.util.concurrent.CompletableFuture@23121d14[Not completed]

completableFuture3:java.util.concurrent.CompletableFuture@72af90e8[Not completed]

主线程结束

=============>completableFuture1任务结束...

=============>执行completableFuture1的线程为：ForkJoinPool.commonPool-worker-9

=============>completableFuture2任务结束 result=supplierResult

=============>执行completableFuture2的线程为：ForkJoinPool.commonPool-worker-9

=============>completableFuture3任务结束 result=supplierResult

=============>执行completableFuture3的线程为：ForkJoinPool.commonPool-worker-9

分析主线程的主干：

  • CompletableFuture#supplyAsync(Supplier)：包装Supplier为AsyncSupply，调用executor.execute()，等待异步线程回调Supplier#get()
  • CompletableFuture#thenApply(Function)
  • CompletableFuture#thenApply(Function)

在之前介绍CompletionStage时，我很对不住这位老哥，隆重介绍了一番，结果发现CompletionStage#whenComplete()、CompletionStage#thenApply()竟然是主线程调用的，而不是异步回调。那么，主线程调用whenComplete(BiConsumer)、thenApply(Function)时到底做了什么，导致异步线程最终会执行BiConsumer#accept()、Function#apply()呢？

请大家把上面代码中的休眠时间统一改为100秒，方便留出分析时间。

然后再跟着我打几个断点：

点进CompletableFuture#thenApply(Function)：

OK，DEBUG模式启动测试案例，多体会几遍Main的执行流程，必要时停止程序熟悉一下代码。

五分钟后...

应该已经走过好几遍了吧？让我们一起来看看。

相信大家对于uniApply()印象很深，因为对于主线程而言这个方法几乎相当于没有执行，每次都返回了false。

CompletableFutureTest目前有三块代码：任务一、任务二、任务三。

主线程在执行“任务一”的CompletableFuture#supplyAsync(Supplier)时，将Supplier包装成AsyncSupply任务，并开启了异步线程，此后异步线程会阻塞在Supplier#get()：

也就是说，Supplier#get()是异步线程开启后执行的第一站！

与此同时，主线程继续执行后面的“任务二”、“任务三”，并且都会到达uniApply()，且都返回false，因为a.result==null。

以“任务二”为例，当主线程从任务二进来，调用thenApply()：

最终会到达uniApply()，通过控制台的日志，我们发现a其实就是completableFuture1：

因为uniApply()的上一步传入的this：

也就是说：

主线程 ---> completableFuture1.thenApply(Function#apply) ---> !d.uniApply(this, f#apply, null)

a.result就是completableFuture1.result，而completableFuture1的值来自Supplier#get()，此时确实还是null（异步线程阻塞100秒后才会）。

所以此时d.uniApply(this, f, null) 为false，那么!d.uniApply(this, f, null) 为true，就会进入if语句：

主要做了3件事：

  • 传入Executor e、新建的CompletableFuture d、当前completableFuture1、Function f，构建UniApply
  • push(uniApply)
  • uniApply.tryFire(SYNC)

任务一做了两件事：

  • 开启异步线程
  • 等待回调

由于要开启线程，自己也要作为任务被执行，所以Supplier#get()被包装成AsyncSupply，是一个Task。而后续的几个任务其实只做了一件事：等待回调。只要能通过实例执行方法即可，和任务一有所不同，所以只是被包装成UniApply对象。

push(uniApply)姑且认为是把任务二的Function#apply()包装后塞到任务栈中。

但uniApply.tryFire(SYNC)是干嘛的呢？里面又调了一次uniApply()：

SYNC=0，所以最终判断!d.uniApply(this, f, this) ==true，tryFire(SYNC)返回null，后面的d.postFire(a, mode)此时并不会执行，等后面异步线程复苏后，带着任务一的结果再次调用时，效果就截然不同了。

总结一下，“任务二”、“任务三”操作都是一样的，都做了3件事：

  • 主线程调用CompletableFuture#thenApply(Function f)传入f，构建UniApply对象，包装Function#apply()
  • 把构建好的UniApply对象push到栈中
  • 返回CompletableFuture d

绿色的是异步线程，此时阻塞等待Supplier#get()，但主线程没闲着，正在努力构建任务栈。

等过了100秒，supplyAsync(Supplier)中的Supplier#get()返回结果后，异步线程继续往下走：

看到了吗，postComplete()也会走uniApply()，但这次已经有了异步结果result，所以流程不会被截断，最终会调用Function#apply(s)，而这个s是上一个函数的执行结果。也就是说，新的CompletableFuture对象调用Function#apply()处理了上一个CompletableFuture产生的结果。

最后，为CompletionStage老哥扳回颜面，你是最棒的：

CompletableFuture#whenComplete(BiConsumer)、CompletableFuture#thenApply(Function)等方法的目的是把BiConsumer#accept()及Function#apply()等回调函数封装成一个个UniApply对象被压入栈，等异步线程执行时，再逐个弹栈并回调。

黑线先行，绿色的异步线程阻塞一会后再走，此时主线程已经成功构建任务栈，引导异步线程去执行即可。

所以，总的来说CompletionStage设计得很巧妙，Doug Lea老爷子不愧是独立设计了JUC的男人，数据结构功底和对编程的理解举世无双。

当然，CompletableFuture还有其他很多的API，甚至回调任务过程中还可以再开异步线程，本文只分析了supplyAsync()+thenApply()，但原理大致相同。老实说，内部的实现机制比较复杂，个人不建议继续深入研究源码，意义不大。

CompletableFuture与FutureTask线程数对比

CompletableFuture和FutureTask耗费的线程数是一致的，但对于FutureTask来说，无论是轮询还是阻塞get，都会导致主线程无法继续其他任务，又或者主线程可以继续其他任务，但要时不时check FutureTask是否已经完成任务，比较糟心。而CompletableFuture则会根据我们编排的顺序逐个回调，是按照既定路线执行的。

其实无论是哪种方式，异步线程其实都需要阻塞等待结果，期间不能处理其他任务。但对于FutureTask而言，在异步线程注定无法复用的前提下，如果想要获取最终结果，需要主线程主动查询或者额外开启一个线程查询，并且可能造成阻塞，而CompletableFuture的异步任务执行、任务结果获取都是异步线程独立完成。

所以：

1个异步线程阻塞执行任务 + 回调异步结果 > 1个异步线程阻塞执行任务 + 1个线程阻塞查询任务

问题

鉴于篇幅较长，内容较深，所以设置一些问题，强制大家去思考整理吧。

假设有以下代码：

public class CompletableFutureTest {

    @Test
    public void testCallBack() throws InterruptedException {
        // 任务一
        CompletableFuture<String> completableFuture1 = CompletableFuture.supplyAsync(new Supplier<String>() {
            @Override
            public String get() {
                return "supplierResult";
            }
        });
        System.out.println("completableFuture1:" + completableFuture1);

        // 任务二
        CompletableFuture<String> completableFuture2 = completableFuture1.thenApply(new Function<String, String>() {
            @Override
            public String apply(String s) {
                return s;
            }
        });
        System.out.println("completableFuture2:" + completableFuture2);

        // 任务三
        CompletableFuture<String> completableFuture3 = completableFuture2.thenApply(new Function<String, String>() {
            @Override
            public String apply(String s) {
                return s;
            }
        });
        System.out.println("completableFuture3:" + completableFuture3);

        System.out.println("主线程结束");
        TimeUnit.SECONDS.sleep(40);
    }
}
  • 主线程在执行任务一和任务二、任务三分别做了什么操作？
  • 哪些方法是主线程执行的，哪些方法是异步线程执行的？
  • Function#apply(String s)被回调时，形参哪来的？
  • 返回值CompletableFuture和异步结果之间的对应关系是怎样的？
作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

进群，大家一起学习，一起进步，一起对抗互联网寒冬

smart哥
关注
专栏目录
使用CompletableFuture的whenComplete和exceptionally函数进行异常处理
2301_79365003的博客
09-23 805
CompletableFuture的whenComplete和exceptionally函数提供了方便的方式来处理异步操作的异常情况。注意，当使用exceptionally函数处理异常时，返回的结果是一个新的CompletableFuture对象。CompletableFuture是Java 8引入的一个强大的异步编程工具，它提供了一种简洁而灵活的方式来处理异步任务的结果。当异步操作完成后，我们可以使用whenComplete和exceptionally函数来处理操作的结果或异常。
浅谈Dubbo的异步调用
WannaRunning的博客
03-25 1053
之前简单写了一下，了解了Dubbo底层是基于NIO的Netty框架实现的，通过IO线程池和Work线程池实现了请求和业务处理之间的异步。这篇文章要写的是Dubbo对于消费端调用和服务端接口业务逻辑处理的异步，在2.7版本中Dubbo实现了基于CompletableFuture的异步支持。
浅谈模拟RPC调用之CompletableFuture
Daeker的博客
01-22 588
浅谈模拟RPC调用之CompletableFuture 浅谈模拟RPC调用之CompletableFuture浅谈模拟RPC调用之CompletableFuture前言一、RPC是什么？1.1 我们这里呢！只是模拟PRC远程调用！二、使用步骤1.pom2.总结 前言 RPC在分布式系统中的系统环境建设和应用程序设计中有着广泛的应用，应用包括如下方面： [1] 1、分布式操作系统的进程间通讯 进程间通讯是操作系统必须提供的基本设施之一,分布式操作系统必须提供分布于异构的结点机上进程间的通讯机制，RPC是
CompletableFuture从入门、踩坑、迷茫、到精通（全网看这一篇够了）
最新发布
likang_1167的博客
09-21 2815
CompletableFuture从入门、踩坑、迷茫、到精通，干货满满，宝剑锋从磨砺出，梅花香自苦寒来，加油！！！
Java并发魔法：CompletableFuture 全解析 CompletableFuture类提供了join()和get() 看这一篇就够了
赵KK的博客
05-29 4184
在Java的世界里，是异步编程的利器，它为开发者提供了强大的异步处理能力。今天，就让我们一起揭开的神秘面纱，深入了解它的使用方法、运行原理、应用场景以及源码分析。
future java get_一文秒懂 Java CompletableFuture ( 上 )
weixin_29818013的博客
02-15 668
本文我们来了解下 Java 8 引入的 CompletableFuture 类，了解下该类提供的功能和用例。Java 中的异步计算异步计算很难推理的，因为我们的大脑是同步的，会将任何计算看成是一系列的同步计算。我们在实现异步计算时，往往会把回调的动作分散在代码中或者深深地嵌套在彼此内部，这种情况下，当我们需要处理其中一个步骤中可能发生的错误时，情况变得更糟。人生的一大悲剧是，尽管 Java 5 已...
CompletableFuture get方法一直阻塞或抛出TimeoutException
weixin_34380948的博客
12-16 1702
2019独角兽企业重金招聘Python工程师标准>>> ...
CompletableFuture.get()指定超时时间注意用异步线程
hct5620的博客
12-04 6474
在某些场景，调用的方法method()其返回值是一个CompletableFuture的对象，需要使用get()方法获取其中的值T，而且要指定超时时间。如果测试get(5, TimeUnit.SECONDS)在长时间阻塞中也不会报超时异常，可能是调用的method()方法内部没有使用异步线程去执行。 如果对method()获取到的结果还要进行链式操作，如thenApply等等，并且在链式操作之后要使用get()方法并指定超时时间的话，那链式操作也要使用异步线程，如 thenApplyAsync。 如果met
浅谈并发编程的业务场景
lt_xiaodou的博客
09-22 340
想必大家都知道，并发编程是一项非常重要的技术，无论在面试，还是工作中出现的频率非常高。当然，如果是个人级别的小玩意，肯定不是特别在意这个。并发编程==多线程编程。但是多线程一定比单线程效率更高？不一定，得看具体的业务环境，多个线程之间，会不断的抢占CPU的资源，所以说有时候多线程也是相对消耗时间的。
java 租户_数据层的多租户浅谈
weixin_36051281的博客
02-25 988
在上一篇“浅析多租户在 Java 平台和某些 PaaS 上的实现”中我们谈到了应用层面的多租户架构，涉及到 PaaS、JVM、OS 等，与之相应的是数据层也有多租户的支持。数据层的多租户综述多租户(Multi Tenancy/Tenant)是一种软件架构，其定义是：在一台服务器上运行单个应用实例，它为多个租户提供服务。在SaaS实施过程中，有一个显著的考量点，就是如何对应用数据进行设计，以支持多租...
浅谈RPC及Netty在RPC中的应用
Megustas_JJC的博客
05-06 608
什么是RPC RPC协议：只是定义数据传输格式和传输方式，是一种应用层协议。 传输方式：有基于HTTP传输数据的RPC Over HTTP，也有基于TCP的RPC Over TCP等。 数据格式：双方协商定义，一般包括以下几点： 1、类名 2、方法名 3、参数类型（用来确定具体执行的方法，有方法重载） 4、参数值 （个人对于网络协议这里了解的不够深入，只能广义上讲下对rpc的认识） 官方说明： 一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP
CompletableFuture用法详解
qq_36042938的博客
08-09 2911
小笔记
CompletableFuture（一）
ZERO
01-23 3179
CompletableFuture是java8中添加的一个类了，这个类主要的作用就是提供了新的方式来完成异步处理,包括合成和组合事件的非阻塞方式。 简单示例： 对于Future可以这样提交任务： ExecutorService executor = Executors.newFixedThreadPool(5); Future result = executor.submit(() -
CompletableFuture的使用
有料，有味，很重要
06-16 7159
CompletableFuture解决的问题: 总的来说，就是 解决future模式的缺点。主要是 a. 为了解决Future虽然可以实现异步获取线程的执行结果，但是future没有提供通知机制，调用方无法得知future什么时候执行完的问题。 b.要么使用阻塞， 在future.get()的地方等待future返回结果，这时会变成同步操作。如果使用isDone()方法进行循环判断，就会消耗...
CompletableFuture——whenComplete与handle、thenApply与thenCompose的区别
DawdleD的博客
02-20 7280
CompletableFuture类提供了使用函数式编程风格来编排异步处理逻辑的方案。 本文将探讨标题所述的几个方法在使用场景方面的区别。
CompletableFuture 多whenComplete操作
lanse_huanxiang的专栏
05-16 837
1. future 多个whenComplete ， 多个whenComplete会执行， 相互间没有影响。2. future.whenComplete 抛出异常， 不同whenComplete之间无影响。
CompletableFuture
Mystogry的博客
08-16 454
主要的四个静态方法执行任务 public static <U> CompletableFuture<U> supplyAsync(Supplier<U> supplier){..} public static <U> CompletableFuture<U> supplyAsync(Supplier<U> supplier,Executor executor){..} public static CompletableFut...
浅谈linuxptp
09-23
Linuxptp是一个用于在Linux系统上实现精确时间同步的软件。它是一个遵循PTP（协议）的守护进程，可用于在计算机网络中同步时钟。它使用PTP协议（即IEEE 1588）来实现高精度的时间同步，以纳秒级别的精确度进行时钟同步。 Linuxptp提供了一组工具和库，用于配置和管理PTP服务器和客户端。它支持多种PTP协议版本，并提供了各种配置选项，以满足不同网络环境和需求的要求。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值