送你一个并发编程的奇淫巧技，很舒服！

本文就来聊聊 CompletionService 这个东西。

先来一起看个例子吧：

public class JDKThreadPoolExecutorTest {

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

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

你想这个代码的输出结果是什么。

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

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

看看你心里想的输出结果是不是这样的：

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

依然是上面的场景，当我们引入了 CompletionService 后就显得不一样了。

先直接看用法：

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

用起来非常的方便，只需要用 ExecutorCompletionService 把线程池包起来。

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

public class ExecutorCompletionServiceTest {

    public static void main(String[] args) throws Exception {
        ExecutorService executorService = Executors.newCachedThreadPool();
        ExecutorCompletionService 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();
    }
}

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

算了，别编译了，直接带大家看结果吧，我已经迫不及待了：

谁先化完妆，就先去接谁。变化不大，甚至说微乎其微。

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

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

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

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

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

根据这个 get ，直觉就告诉我 take 出来的肯定是一个 future 对象。

而这个 future 对象肯定是放在一个队列里面的。

CompletionService原理

首先 CompletionService 是一个接口：

ExecutorCompletionService 是这个接口的实现类：

看一下 ExecutorCompletionService 的构造方法：

可以看到是需要传入一个线程池对象的。队列默认使用的是 LinkedBlockingQueue 

当然，我们也可以指定使用什么队列：

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

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

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

差异就在 execute 方法里面。

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

executor.execute(new QueueingFuture(f));

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

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

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

这个方法的含义就是当任务执行完成后，就会被放到队列里面去了。

也就是说队列里面的 task 都是已经 done 了的 task，而这个 task 就是一个个 future。

如果调用 queue 的 take 方法，就是阻塞等待。等到的一定是就绪了的 future，调用 get 就能立马获得结果。

这不就是在做解耦吗？

之前你提交任务后还需要直接关心每个任务返回的 future。

现在 CompletionService 帮你对这些 future 进行了跟踪。

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

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

why？

因为前面说了，里面有个队列。

当你不关心返回值的时候也就是不会去处理这个队列，

导致这个队列里面的对象堆积的越来越多。

最后，炸了，OOM了。

在开源框架中的应用

除了 JDK 的 ExecutorCompletionService 实现了这个接口。

在开源框架里面也有相应的实现。

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

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

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

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

标号为 ② 的地方在循环体中提交异步任务。

需要几个服务提供者就有几次循环。

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

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

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

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

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

最后说一句(求关注!别白嫖！)

如果这篇文章对您有所帮助，或者有所启发的话，求一键三连：点赞、转发、在看。

关注公众号：woniuxgg，在公众号中回复：笔记  就可以获得蜗牛为你精心准备的java实战语雀笔记，回复面试、开发手册、有超赞的粉丝福利！