java.util.concurrent.ForkJoinPool#registerWorker
你若是想要自己调试的话，那么在这里打上断点之后，可以看一下调用栈，很快就摸清楚这个调用流程了：
另外，我在写文章的过程中还注意到了这个注释：
前面大概就是说 shutdown 和 shutdownNow 对于这个线程池来说没用。
如果，线程池里面的任务需要在程序终止前完成，那么应该在退出前调用 commonPool().awaitQuiescence。
所以，我的程序应该改成这样：
可以，不错，很优雅。
如果，你的异步任务非常重要，必须要执行完成，那么 ForkJoinPool 也给你封装好了一个方法：
java.util.concurrent.ForkJoinPool#quiesceCommonPool
另外，其实 CompletableFuture 也是支持传一个自定义线程池的：
比如，我把前面的程序改成下面这样：
加入指定线程池的逻辑，注释掉主线程 join 的代码，跑起来之后。诶，JVM 一直都在。
你说神奇不神奇？
我想这个原因就不用我来分析了吧？
和 Future 对比CompletableFuture 其实就是 Future 的升级版。
Future 有的，它都有。
Future 的短板，它补上了。
毕竟一个是 JDK 1.5 时代的产物，另一个是 1.8 时代的作品：
中间跨度了整整 10 年，10 年啊！
所以，后来居上。
给大家对比一下 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 获取其返回值：
按理来说也就是可以用了。
但是如果你不需要返回值，它还提供了这样的写法：
正常情况和异常情况分开处理。
优雅，非常优雅。
还有更牛的。
前面我们化妆的线程和化妆完成的线程不是同一个线程吗：
假设我们需要两个不同的线程，一个只负责化妆，一个只负责通知。毕竟女神化完妆之后，更加女神了，搞两个线程我寻思也不过分。
改动点小到令人发指：
只需要把调用的方法从 whenComplete 改为 whenCompleteAysn 即可。
同样，这个方法也支持指定线程池：
你可以去看 CompletableFuture 里面有非常多的 Aysn 结尾的方法，大多都是干这个事儿的，以异步的形式在线程池中执行。
如果说上面的介绍让你觉得不过如此，那么再介绍一个 Future 没有的东西。
假设现在需求是这样的。
女神化完妆之后，还要花个一小会选衣服，不过分吧。
也就是说我们现在有两个异步任务，第一个是化妆，第二个是选衣服。
选衣服要在化妆完成之后进行，这两个任务是串行的，用 CompletableFuture 怎么实现呢？
我把代码贴一下，为了看起来更加直观，我没有用链式调用：
public class MainTest {public static void main(String[] args) throws Exception {
ExecutorService executorService = Executors.newFixedThreadPool(10);
//任务一
CompletableFuture<String> makeUpFuture = CompletableFuture.supplyAsync(() -> {
System.out.println(Thread.currentThread().getName() + "-女神：我开始化妆了。");
try {
TimeUnit.SECONDS.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "化妆完毕了。";
}, executorService);
//任务二（makeUpFuture是方法调用方，意思是等makeUpFuture执行完成后执行再执行）
CompletableFuture<String> dressFuture = makeUpFuture.thenApply(makeUp -> {
System.out.println(Thread.currentThread().getName() + "-女神：" + makeUp + "我开始选衣服啦，好了我叫你。");
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
return makeUp + "衣服也选好啦。靓仔,走去玩儿吧。";
});
//获取结果
dressFuture.thenAccept(result -> {
System.out.println(Thread.currentThread().getName() + "-" + result);
});
}
}
这样输出结果就是这样的：
符合我们的预期。
假设我们想要选衣服的时候换另外一个线程怎么办呢？
别说不知道，这不刚才教你了吗，Async 结尾的方法，得活学活用起来：
前面讲的是多个异步任务串行执行，接下来再说一下并行。
CompletableFuture 里面提供了两个并行的方法：
两个方法的入参都是可变参数，就是一个个异步任务。
allOf 顾名思义就是入参的多个 CompletableFuture 都必须成功，才能继续执行。
而 anyOf 就是入参的多个 CompletableFuture 只要有一个成功就行。
还是举个例子。
假设，我是说假设啊，我是一个海王。
算了，我假设我有一个朋友吧。
他同时追求好几个女朋友。今天他打算约小美和小乖中的一个出门玩，随便哪个都行。谁先化妆完成，就约谁。另外一个就放她鸽子。
这个场景，我们就可以用 anyOf 来模拟，于是就出现了这样的代码：
从输出结果来看，最后和朋友约会的是小美。
都把小美约出来了，必须要一起吃个饭才行，对吧。
那么这个时候朋友问：小美，你想吃点什么呢？
小美肯定会回答：随便，就行，无所谓。
听到这样的回答，朋友心里就有底了，马上给出了一个方案：我们去吃沙县小吃或者黄焖鸡吧，哪一家店等的时间短，我们就去吃哪一家。
于是上面的代码，就变成了这样：
输出结果是这样的：
我把代码都放这里，你粘过去就能跑起来：
public class MainTest {public static void main(String[] args) {
ExecutorService executorService = Executors.newFixedThreadPool(10);
CompletableFuture<String> xiaoMei = CompletableFuture.supplyAsync(() -> {
System.out.println(Thread.currentThread().getName() + "-小美：我开始化妆了，好了我叫你。");
try {
int time = ThreadLocalRandom.current().nextInt(5);
TimeUnit.SECONDS.sleep(time);
System.out.println(Thread.currentThread().getName() + "-小美,化妆耗时:" + time);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "小美：化妆完毕了。";
}, executorService);
CompletableFuture<String> xiaoGuai = CompletableFuture.supplyAsync(() -> {
System.out.println(Thread.currentThread().getName() + "-小乖：我开始化妆了，好了我叫你。");
try {
int time = ThreadLocalRandom.current().nextInt(5);
TimeUnit.SECONDS.sleep(time);
System.out.println(Thread.currentThread().getName() + "-小乖,化妆耗时:" + time);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "小乖：化妆完毕了。";
}, executorService);
CompletableFuture<Object> girl = CompletableFuture.anyOf(xiaoMei, xiaoGuai);
girl.thenAccept(result -> {
System.out.println("我看最后是谁先画完呢 = " + result);
});
CompletableFuture<String> eatChooseOne = girl.thenApplyAsync((result) -> {
try {
TimeUnit.SECONDS.sleep(ThreadLocalRandom.current().nextInt(10));
} catch (InterruptedException e) {
e.printStackTrace();
}
return result + "这里人少,我们去吃沙县小吃吧!";
}, executorService);
CompletableFuture<String> eatChooseTwo = girl.thenApplyAsync((result) -> {
try {
TimeUnit.SECONDS.sleep(ThreadLocalRandom.current().nextInt(10));
} catch (InterruptedException e) {
e.printStackTrace();
}
return result + "这里人少,我们去吃黄焖鸡吧!";
}, executorService);
CompletableFuture.allOf(eatChooseOne, eatChooseTwo).thenAccept(result -> {
System.out.println("最终结果：" + result);
});
}
}
如果你说，小孩子才做选择，大人是全部都要。
那么，你可以试着用一下 allOf，只是需要注意的是，allOf 是不带返回值的。
好了，写到这里我都感觉有点像是 API 教学了，没啥劲。所以 CompletableFuture 还有很多很多的方法，我就不一一介绍了。
最后，再看看 get 方法吧。之前发布的《看完JDK并发包源码的这个性能问题，我惊了！》这篇文章，有朋友看了之后有几个问题，我再串起来讲一下。
CompletableFuture 提交任务的方式有两种：
一种是 supplyAsync 带返回值的。
一种是 runAsync 返回值是 void 的，相当于没有返回值。
比如，我们用 supplyAsync 的时候：
就刻意返回一个 null。
我还可以扩展一下，假设我们的方法用的是 runAsync，本来就没有返回值的。
比如这样：
我们再看一下 get 方法：
你看这里的判断条件是 (r = result) == null。
那么问题就来了，假设这个方法的返回值本来就是 null，也就是我们上面的情况，怎么办呢？
为 null 就有三种情况了：
1.是 runAsync 这种，真的没有返回值，所以就算任务执行完成了，get 出来的确实就是 null。
2.是有返回值的，只是目前任务还没执行完成，所以 result 还是 null。