呵呵，面试官问我知不知道CompletionService？

时间  2020-09-20
标签 呵呵 面试 问我 知不 知道 completionservice 栏目 快乐工作 繁體版
原文   原文链接

https://mp.weixin.qq.com/s/qyKVA6VeqxQmQmltk-CaFA面试

image.png

荒腔走板


你们好，我是 why，欢迎来到我连续周更优质原创文章的第 61 篇。
编程

老规矩，先荒腔走板聊聊其余的。app

上面这图是上周六，成都叁缺壹演唱会的现场。正在唱歌的这个男人叫作李志。去年他由于某些缘由被 404 了。上周六他忽然出如今成都，忽然宣告着解除封印。框架

我知道这个消息是由于周六的晚上我正在看《乐队的夏天》。恰好是达达乐队正在唱《南方》，而后上面有一个弹幕：李志在成都复出啦！异步

因而我打开了微博，搜索：李志成都。果真看到了他的演出视频。视频里面唱的是《关于郑州我知道的很少》。ide

只是李志把歌词里面的郑州都改为了“成都”。一边是达达乐队唱着《南方》，一边是李志的《关于“成都”我知道的很少》。那一刻，我把这个消息分享给坐在旁边的女友，我张了张口，居然忽然一下有点说不出话来，只好把手机在她面前晃了一晃。异步编程

记得我以前在网抑云听李志的《梵高先生》的时候，无心间看了一下下面的评论，有一个评论的 ID 叫作放羊的壮年，他说：编码

今年五月十六日被确诊肺癌晚期，医生说还有三到五个月，然而到今天我还呼吸着这世界的空气，人生大起大落每每都是本身体会，这算是一种孤独吗？也许有一天我女儿也会爱上这首歌，那是否是比我更加孤独？怎么去想…url

《梵高先生》的第一句歌词是：谁的父亲死了，请你告诉我如何悲伤。spa

他的留言日期是 2015 年 12 月 30 日。

我点进他的主页查看，他的头像是一个很可爱的小女孩，扎着两个小辫子。可能就是他的女儿吧，我看了他的听歌排行，点了最近一周，显示没有听歌排行数据。看了他的仅有的一条动态，里面有 4000 多个评论，

热评第一是这样说的：多少人和我同样看到梵高先生下的评论而后点进来点进最近一周听歌为空白心头一凉，不知道你如今还好很差，衷心祝愿你的女儿幸福。

他的评论里面充满了陌生人，言语之间充满了关怀和爱，有人和他像朋友同样留言聊天，有人说他换了播放器，有人说但愿你是骗咱们的...

评论看着看着就以为很温暖。

隔了几天以后我也去留言了：咱们生来就是孤独，可是人间温暖。

好了，说回文章。

再谈Future


上周不是写了《笑了，面试官问我知不知道异步编程的Future》这一篇文章聊 Future 嘛。

而后有读者就给我留言了：why 哥，你都写到 Future 了，应该再写一下 CompletionService 的。上次面试就被面试官追问了。

我笑着说：哎呀，实在是没有时间写了。文章已经很长了，再把这个东西补充上去，更长了，没人看的。

读者说：没事，我就是一个小建议。

好的，接受建议。本文就来聊聊 CompletionService 这个东西。

image.png

在聊它以前，咱们先回顾一下 Future 的用法。

我先问问你，当你往线程池里面提交了一组计算任务之后，你想要得到返回值。

你应该用 Executor 的什么提交方法？这个提交方法的什么重载类型？

什么？你答不上来？呸，你个渣男，上周白嫖完了就忘了？

image.png

上周的文章里面写了啊：

image.png

用 submit 的任务类型为 Callable 的或者任务类型为 Runable，还能够再传一个返回值的：

image.png

因为是一组计算任务，你想拿到返回值去搞事情。这个返回值就被封装在 Future 里面。

怎么获取呢？

调用 Future 的 get 方法，有不带超时时间的无限等待的舔狗类型的 get，也有带超时时间、到点就放弃的渣男类型的 get：

image.png

来一块儿看个例子吧：

public class JDKThreadPoolExecutorTest {

    public static void main(String[] args) throws Exception {
        ExecutorService executorService = Executors.newCachedThreadPool();
        ArrayList<Future<Integer>> list = new ArrayList<>();
        Future<Integer> future_15 = executorService.submit(() -> {
            TimeUnit.SECONDS.sleep(15);
            System.out.println("执行时长为15s的执行完成。");
            return 15;
        });
        list.add(future_15);
        
        Future<Integer> future_5 = executorService.submit(() -> {
            TimeUnit.SECONDS.sleep(5);
            System.out.println("执行时长为5s的执行完成。");
            return 5;
        });
        list.add(future_5);
        
        Future<Integer> future_10 = executorService.submit(() -> {
            TimeUnit.SECONDS.sleep(10);
            System.out.println("执行时长为10s的执行完成。");
            return 10;
        });
        list.add(future_10);
        
        System.out.println("开始准备获取结果");
        for (Future<Integer> future : list) {
            System.out.println("future.get() = " + future.get());
        }
        Thread.currentThread().join();
    }
}

如今有三个任务，执行时间分别是 15s/10s/5s 。经过 JDK 线程池的 submit 方法提交了这三个 Callable 类型的任务。

你先眼神编译一下，内心输出一下，你想这个代码的输出结果是什么。

首先主线程把三个任务提交到线程池里面去，把对应返回的 Future 放到 List 里面存起来，而后执行“开始准备获取结果”的输出语句。

接着进入 for 循环，在循环里面执行 future.get() 操做，阻塞等待。

看看你内心想的输出结果是否是这样的：

image.png

从这个输出结果里面，咱们能够看出问题了。很明显的木桶效应。

三个异步任务，耗时最长的最早执行，因此最早进入 list，所以当在循环中获取这个任务结果的时候 get 操做会一直阻塞，即便执行时间为 5s/10s 的任务已经执行完成。

image.png

好的，举个例子。想象一个场景：

假设你是一个海王，你拥有众多普通女性朋友。你同时邀约了三位女性朋友一块儿吃饭。分别给她们说：你先化妆吧，好了给我说一声，我开车来接你。

image.png

小红化妆要 2 小时。小花化妆要 1小时。小媛化妆要 30 分钟。

因为你最早给小红说的，你就一直在小红家门口等小红化妆完成。当小红化妆完成后，你接到车上，其余两位朋友早就准备好了，在家干巴巴的等着你来接她。

这不是一个合格的海王应该有的样子。

这就是 future 在这种场景下的局限性。

根据上面的场景编码可得（代码都是直接复制粘贴就能够用的，建议你拿出来跑一下）：

public class JDKThreadPoolExecutorTest {

    public static void main(String[] args) throws Exception {
        ExecutorService executorService = Executors.newCachedThreadPool();
        ArrayList<Future<String>> list = new ArrayList<>();
        System.out.println("约几个妹子一块儿吃个饭吧。");
        Future<String> future_15 = executorService.submit(() -> {
            System.out.println("小红：好的，哥哥。我化妆要2个小时。等一下哦。");
            TimeUnit.SECONDS.sleep(15);
            System.out.println("小红：我2个小时准时化好了，哥哥来接我吧。");
            return "小红化完了。";
        });
        list.add(future_15);
        Future<String> future_5 = executorService.submit(() -> {
            System.out.println("小媛：好的，哥哥。我化妆要30分钟。等一下哦。");
            TimeUnit.SECONDS.sleep(5);
            System.out.println("小媛：我30分钟准时化好了，哥哥来接我吧。");
            return "小媛化完了。";
        });
        list.add(future_5);

        Future<String> future_10 = executorService.submit(() -> {
            System.out.println("小花：好的，哥哥。我化妆要1个小时。等一下哦。");
            TimeUnit.SECONDS.sleep(10);
            System.out.println("小花：我1个小时准时化好了，哥哥来接我吧。");
            return "小花化完了。";
        });
        list.add(future_10);
        TimeUnit.SECONDS.sleep(1);
        System.out.println("都通知完,等着吧。");
          for (Future<String> future : list) {
            System.out.println(future.get()+"我去接她。");
        }
        Thread.currentThread().join();
    }
}
输出结果以下；

image.png

说好都是同样的普通朋友的，为何你恰恰要一直等化妆时间最长的小红？为何不谁动做快，就先接谁？

你看你这样操做，让小媛、小花怎么想？只能说：你是一个好人了。

image.png

什么？你个中央空调还问我“什么是海王”？

image.png

CompletionService拯救海王


仍是上面的场景，当咱们引入了 CompletionService 后就显得不同了。

先直接看用法：

ExecutorService executorService = Executors.newCachedThreadPool();
ExecutorCompletionService<String> completionService = new ExecutorCompletionService<>(executorService);

用起来很是的方便，只须要用 ExecutorCompletionService 把线程池包起来。

而后提交任务的时候用 competitionService 的 submit 方法。代码以下：

public class ExecutorCompletionServiceTest {

    public static void main(String[] args) throws Exception {
        ExecutorService executorService = Executors.newCachedThreadPool();
        ExecutorCompletionService<String> completionService =
                new ExecutorCompletionService<>(executorService);
        System.out.println("约几个妹子一块儿吃个饭吧。");
        completionService.submit(() -> {
            System.out.println("小红：好的，哥哥。我化妆要2个小时。等一下哦。");
            TimeUnit.SECONDS.sleep(15);
            System.out.println("小红：我2个小时准时化好了，哥哥来接我吧。");
            return "小红化完了。";
        });
        completionService.submit(() -> {
            System.out.println("小媛：好的，哥哥。我化妆要30分钟。等一下哦。");
            TimeUnit.SECONDS.sleep(5);
            System.out.println("小媛：我30分钟准时化好了，哥哥来接我吧。");
            return "小媛化完了。";
        });
        completionService.submit(() -> {
            System.out.println("小花：好的，哥哥。我化妆要1个小时。等一下哦。");
            TimeUnit.SECONDS.sleep(10);
            System.out.println("小花：我1个小时准时化好了，哥哥来接我吧。");
            return "小花化完了。";
        });
        TimeUnit.SECONDS.sleep(1);
        System.out.println("都通知完,等着吧。");
        //循环3次是由于上面提交了3个异步任务
        for (int i = 0; i < 3; i++) {
            String returnStr = completionService.take().get();
            System.out.println(returnStr + "我去接她");
        }
        Thread.currentThread().join();
    }
}

你先眼神编译一下，内心输出一下...

算了，别编译了，直接带你们看结果吧，我已经火烧眉毛了：

image.png

谁先化完妆，就先去接谁。

写到这里，看到这个输出结果的时候我不由鼓起掌来。

image.png

真正的海王应该是一个时间管理大师。

先对比一下输出结果，全体起立，一块儿鼓掌：

image.png


而后对比一下两个版本代码的差别：

image.png变化不大甚至说微乎其微。

执行 submit 方法的对象变成了 ExecutorCompletionService 。

获取任务结果的方法变成了：

String returnStr = completionService.take().get();

先不看原理。你就细细的品这个获取结果的方法。

completionService.take() 了个什么玩意出来，而后调用了 get 方法。

根据这个 get ，直觉就告诉我 take 出来的确定是一个 future 对象。而这个 future 对象确定是放在一个队列里面的。

下一小节，带你们去证明一下。

CompletionService原理


首先 CompletionService 是一个接口：

image.png

ExecutorCompletionService 是这个接口的实现类：

image.png

看一下 ExecutorCompletionService 的构造方法：

image.png

能够看到是须要传入一个线程池对象的。队列默认使用的是 LinkedBlockingQueue 。

固然，咱们也能够指定使用什么队列：

image.png

而后再看一下它的任务提交方式：

image.png

因为用 ExecutorCompletionService 主要是为了优雅的处理返回值。因此它支持两种 submit 类型的提交，都是有返回值的。

上面时间管理大师版本海王使用的就是 Callable 类型的方法。

咱们先对比一下 Executor 直接提交和 ExecutorCompletionService 提交的差别：

image.png

差别就在 execute 方法里面。

ExecutorCompletionService 提交任务的时候是这样的：

executor.execute(new QueueingFuture(f));

差别就在 execute 方法里面的 Runable：

image.png

看一下这个 QueueingFuture 是个什么东西：

image.png

秘密基本上就在这个里面了。

QueueingFuture 继承自 FutureTask。重写了 done 方法，而后把 task 放到 queue 里面。

这个方法的含义就是当任务执行完成后，就会被放到队列里面去了。也就是说队列里面的 task 都是已经 done 了的 task，而这个 task 就是一个个 future。

若是调用 queue 的 task 方法，就是阻塞等待。等到的必定是就绪了的 future，调用 get 就能立马得到结果。

你说这一套操做是在干啥？

这不就是在作解耦吗？

以前你提交任务后还须要直接关心每一个任务返回的 future。如今 CompletionService 帮你对这些 future 进行了跟踪。

完成了调用者和 future 之间的解耦。

原理分析完了，说一个须要注意的地方。

当你的使用场景是不关心返回值的时候千万不要闲的蛋疼的用 CompletionService 去提交任务。

为何？

由于前面说了，里面有个队列。而当你不关心返回值的时候也就是不会去处理这个队列，致使这个队列里面的对象堆积的愈来愈多。

最后，炸了，OOM了。

image.png

在开源框架中的应用


前面说了 CompletionService 是一个接口。除了 JDK 的 ExecutorCompletionService 实现了这个接口。

在开源框架里面也有相应的实现。好比 Redisson：

image.png

你去看这个实现，和 ExecutorCompletionService 思想是如出一辙的，可是实现是有些许的不同。

它把 future 放到队列面的时候，没有重写 done 方法，而是使用了响应式编程的 onComplete：

image.png

而 CompletionService 的思想核心是：Executor 加 Queue 。

这个思想，让我想起了在 Dubbo 中看到过的一个类：

image.png

我曾经在《Dubbo Cluster集群那点你不知道的事》这篇文章中提到过这个类。

image.png

这个类的 doInvoker 方法中的核心逻辑以下：

image.png

首先标号为 ① 的地方定义了一个队列。

标号为 ② 的地方在循环体中提交异步任务。须要几个服务提供者就有几回循环。

子线程在标号为 ③ 的地方把返回结果放到队列里面。

只要一放进去，就能被标号为 ④ 的地方获取到（指定时间内），而后程序当即返回。

这样就能实现并行调用多个服务提供者，只要有一个服务提供者返回就当即返回的功能。

我以为这个思想和 CompletionService 的思想有一点点的相通之处的。

咱们要学 CompletionService ，也要学它的思想。

image.png

最后说一句（求关注）


嗯，写完了。这周是疯狂连轴旋转的一周，我在公司里面走动，都不是走路，都是在一路小跑的，停更一周的想法从周一就出现了无数次。最后昨天加班加点的把公司安排的“政治编程任务”完成以后，开始快马加鞭的准备这篇文章，我仍是怼出来了，毕竟我也是一个时间管理大师。

下周就是连续周更文章一年整啦。过去的 365 天，过去的 52 周，我保持了一周至少输出一篇优质原创文章的节奏。虽然没有多少粉丝（一年了都没过一万关注，真的是没脸见人），可是立下的 flag 算是超额完成了。

坚持不住的时候再坚持一下，确实是一种难能难得的品质。

好啦，都看到这里啦，你们安排个 “一键三连”（转发、在看、点赞） 吧，周更很累的，不要白嫖我，须要一点正反馈。

image.png

才疏学浅，不免会有纰漏，若是你发现了错误的地方，因为本号没有留言功能，还请你在后台留言指出来，我对其加以修改。

感谢您的阅读，我坚持原创，十分欢迎并感谢您的关注。

image.png

我是 why，一个被代码耽误的文学创做者，不是大佬，可是喜欢分享，是一个又暖又有料的四川好男人。

还有，重要的事情说三遍：

欢迎关注我呀。

欢迎关注我呀。

欢迎关注我呀。

image.png

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程