你好呀，我是歪歪。
填个坑吧，把之前一直欠着的 CompletableFuture 给写了，因为后台已经收到过好几次催更的留言了。
这玩意我在之前写的这篇文章中提到过：《面试官问我知不知道异步编程的Future》
因为是重点写 Future 的，所以 CompletableFuture 只是在最后一小节的时候简单的写了一下：
我就直接把当时的例子拿过来改一下吧，先把代码放在这里了：
public class MainTest { public static void main(String[] args) throws Exception { CompletableFuture.supplyAsync(() -> { System.out.println(Thread.currentThread().getName() + "-女神：我开始化妆了，好了我叫你。"); try { TimeUnit.SECONDS.sleep(5); } catch (InterruptedException e) { e.printStackTrace(); } return "化妆完毕了。"; }).whenComplete((returnStr, exception) -> { if (exception == null) { System.out.println(Thread.currentThread().getName() + returnStr); } else { System.out.println(Thread.currentThread().getName() + "女神放你鸽子了。"); exception.printStackTrace(); } }); System.out.println(Thread.currentThread().getName() + "-等女神化妆的时候可以干点自己的事情。"); Thread.currentThread().join(); } }
核心需求就是女神化妆的时候，我可以先去干点自己的事情。
上面的程序运行结果是这样的：
符合我们的预期，没有任何毛病。
但是当你自己去编写程序的时候，有可能会遇到这样的情况
是的，这就是我要说的第一个关于 CompletableFuture 的知识点：守护线程。
守护线程
你仔细观察前面提到的两个截图，对比一下他们的第 28 行，第二个截图少了一行代码：
Thread.currentThread().join();
这行代码是在干啥事呢？
目的就是阻塞主线程，哪怕你让主线程睡眠也行，反正目的就是把主线程阻塞住。
如果没有这行代码，出现的情况就是主线程直接运行完了，程序也就结束了。
你想想，会是什么原因？
这个时候你脑海里面应该啪的一下，很快就想到“守护线程”这个概念。
主线程是用户线程，这个没啥说的。
所有的用户线程执行完成后， JVM 也就退出了。
因此，出现上面问题的原因我有合理的理由猜测：CompletableFuture 里面执行的任务属于守护线程。
有了理论知识的支撑，并推出这个假设之后，就有了证实的方向，问题就很简单了。
啪的一下在这里打上一个断点，然后 Debug 起来，表达式一写就看出来了，确实是守护线程：
我一般是想要看到具体的代码的，就是得看到把这个线程设置为守护线程的那一行代码，我才会死心。
所以我就去找了一下，还是稍微花了点时间，过程就不描述了，直接说结论吧。
首先 CompletableFuture 默认的线程池是 ForkJoinPool，这个是很容易就能在源码里面找到的：
在 ForkJoinPool 里面，把线程都设置为守护线程的地方就在这里：
java.util.concurrent.ForkJoinPool#registerWorker
前面大概就是说 shutdown 和 shutdownNow 对于这个线程池来说没用。
如果，线程池里面的任务需要在程序终止前完成，那么应该在退出前调用 commonPool().awaitQuiescence。
所以，我的程序应该改成这样：
可以，不错，很优雅。
如果，你的异步任务非常重要，必须要执行完成，那么 ForkJoinPool 也给你封装好了一个方法：
java.util.concurrent.ForkJoinPool#quiesceCommonPool
加入指定线程池的逻辑，注释掉主线程 join 的代码，跑起来之后。诶，JVM 一直都在。
你说神奇不神奇？
和 Future 对比
CompletableFuture 其实就是 Future 的升级版。
Future 有的，它都有。
Future 的短板，它补上了。
毕竟一个是 JDK 1.5 时代的产物，另一个是 1.8 时代的作品：
所以，后来居上。
给大家对比一下 Future 和 CompletableFuture。
首先对于我个人而言，第一个最直观的感受是获取结果的姿势舒服多了。
我不得不又把这张图拿出来说说了，主要关注下面的两种 future 和 callback：
当我们用 Future 去实现异步，要获取异步结果的时候，是怎么样操作的？
是不是得调用 future.get() 方法去取值。
如果这个时候值已经准备就绪，在 future 里面封装好了，那么万事大吉，直接拿出来就可以用。
但是如果值还没有准备好呢？
是不是就阻塞等待了？
所以我常常说 Future 是一种阉割版的异步模式。
比如还是最开始的例子，如果我用 Future 来做，那么是这样的：
你仔细看我框起来的地方，是 main 线程开始获取结果，获取结果的这个动作把 main 线程给阻塞住了。
你就去洗不了头了，老弟。
好，你说你把获取结果的操作放到最后，没问题。
但是，无论你放在哪里，你都有一个 get 的动作，且你执行这个动作的时候，你也不知道值到底准备好了没，所以有可能出现阻塞等待的情况。
好，那么问题来了：如果消除这个阻塞等待呢？
很简单，换个思路，我们从主动问询，变成等待通知。
女神化妆好了之后，主动通知一下我不就好了吗？
用程序员的话说就是：运行结果出来了，你执行一下我留给你的回调函数不就好了吗？
CompletableFuture 就可以干这个事儿。
用 CompletableFuture 写一遍上面的程序就是这样的：
pool-1-thread-1，女神化妆的这个线程，她好了之后会主动叫你，你明白吗？
这就是我第一次接触到 CompletableFuture 后，学到的第一个让我感到舒服的地方。
这种写法你注意，whenComplete(returnStr, exception) 返回信息和异常信息在这里都有了。
除此之外，这个方法还是带返回值的，你也完全可以像是用 Future 那样通过 get 获取其返回值：
