耗时最久的-10s异步任务最先进入list执行，所以在循环过程中获取这个10s的任务结果的时候，get操作会一直阻塞，直到10s异步任务执行完毕。即使 3s、5s的任务早就执行完了，也得阻塞等待10s任务执行完。

看到这里 尤其是做网关业务的同学可能会产生共鸣，一般来说网关RPC会调用下游N多个接口，如下图

如果都按照ExecutorService这种方式，并且恰巧前几个任务调用的接口耗时比较久，同时阻塞等待，那就比较悲催了。所以ExecutorCompletionService应景而出。它作为任务线程的合理管控者，“任务规划师”的称号名副其实。

相同场景 ExecutorCompletionService代码

public static void test2() throws Exception {
    ExecutorService executorService = Executors.newCachedThreadPool();
    ExecutorCompletionService<String> completionService = new ExecutorCompletionService<>(executorService);
    System.out.println("公司让你通知大家聚餐 你开车去接人");
    completionService.submit(() -> {
        System.out.println("总裁：我在家上大号 我最近拉肚子比较慢 要蹲1个小时才能出来 你等会来接我吧");
        TimeUnit.SECONDS.sleep(10);
        System.out.println("总裁：1小时了 我上完大号了。你来接吧");
        return "总裁上完大号了";
    });
    completionService.submit(() -> {
        System.out.println("研发：我在家上大号 我比较快 要蹲3分钟就可以出来 你等会来接我吧");
        TimeUnit.SECONDS.sleep(3);
        System.out.println("研发：3分钟 我上完大号了。你来接吧");
        return "研发上完大号了";
    });
    completionService.submit(() -> {
        System.out.println("中层管理：我在家上大号  要蹲10分钟就可以出来 你等会来接我吧");
        TimeUnit.SECONDS.sleep(6);
        System.out.println("中层管理：10分钟 我上完大号了。你来接吧");
        return "中层管理上完大号了";
    });
    TimeUnit.SECONDS.sleep(1);
    System.out.println("都通知完了,等着接吧。");
    //提交了3个异步任务）
    for (int i = 0; i < 3; i++) {
        String returnStr = completionService.take().get();
        System.out.println(returnStr + "，你去接他");
    }
    Thread.currentThread().join();
}

跑完结果如下：

这次就相对高效了一些，虽然先通知的总裁，但是根据大家上大号的速度，谁先拉完先去接谁，不用等待上大号最久的总裁了（现实生活里 建议采用第一种 不等总裁的后果 emmm 哈哈哈）。

放在一起对比下输出结果：

两段代码的差异非常小 获取结果的时候ExecutorCompletionService 使用了

completionService.take().get();

为什么要用take() 然后再get()呢？？？？我们看看源码

CompletionService接口 以及接口的实现类

1、ExecutorCompletionService是CompletionService接口的实现类

2、接着跟一下ExecutorCompletionService的构造方法，可以看到入参需要传一个线程池对象，默认使用的队列是 LinkedBlockingQueue，不过还有另外一个构造方法可以指定队列类型，如下两张图，两个构造方法。

默认LinkedBlockingQueue的构造方法

可选队列类型的构造方法

3、submit任务提交的两种方式，都是有返回值的，我们例子中用到的就是第一种Callable类型的方法。

4、对比ExecutorService 和 ExecutorCompletionService submit方法 可以看出区别 （1）ExecutorService

（2）ExecutorCompletionService

5、差异就在 QueueingFuture，这个到底作用是啥，我们继续跟进去看

• QueueingFuture 继承自 FutureTask，而且红线部分标注的位置，重写了done()方法。
• 把 task 放到 completionQueue 队列里面，当任务执行完成后，task就会被放到队列里面去了。
• 此时此刻completionQueue队列里面的 task 都是已经 done()完成了的 task，而这个 task 就是我们拿到的一个个的future结果。
• 如果调用 completionQueue 的 task 方法，会阻塞等待任务。等到的一定是完成了的 future，我们调用 .get()方法 就能立马获得结果。

看到这里 相信大家伙都应该多少明白点了

• 我们在使用ExecutorService submit提交任务后需要关注每个任务返回的future，然而CompletionService 对这些 future 进行了追踪，并且重写了done方法，让你等的completionQueue 队列里面 一定是完成了的task。
• 作为网关RPC层，我们不用因为某一个接口的响应慢拖累所有的请求，可以在处理最快响应的业务场景里使用CompletionService。

but 注意、注意、注意 也是本次事故的核心

当只有调用了ExecutorCompletionService下面的3个方法的任意一个时，阻塞队列中的task执行结果才会从队列中移除掉,释放堆内存，由于该业务不需要使用任务的返回值，则没进行调用take，poll方法。从而导致没有释放堆内存，堆内存会随着调用量的增加一直增长。

所以，业务场景中不需要使用任务返回值的 别没事儿使用CompletionService，假如使用了，记得一定要从阻塞队列中 移除掉task执行结果，避免OOM！

总结

知道事故的原因，我们来总结下方法论，毕竟孔子他老人家说过：自省吾身，常思己过，善修其身！

上线前：