非主流并发工具之 CompletionService

CompletionService 接口的实例可以充当生产者和消费者的中间处理引擎，从而达到将提交任务和处理结果的代码进行解耦的目的。生产者调用 submit 方法提交任务，而消费者调用 poll （非阻塞）或 take （阻塞）方法获取下一个结果：这一特征看起来和阻塞队列（BlockingQueue ）类似，两者的区别在于 CompletionService 要负责任务的处理，而阻塞队列则不会。

在 JDK 中，该接口只有一个实现类 ExecutorCompletionService ，该类使用创建时提供的 Executor 对象（通常是线程池）来执行任务，然后将结果放入一个阻塞队列中：果然本就是一家亲啊！ExecutorCompletionService 将线程池和阻塞队列糅合在一起，仅仅通过三个方法，就实现了任务的异步处理，可谓并发编程初学者的神兵利器！

接下来看一个例子。楼主有一大堆 *.java 文件，需要计算它们的代码总行数。利用 ExecutorCompletionService 可以写出很简单的多线程处理代码：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

public int countLines(List<Path> javaFiles) throws Exception {      // 根据处理器数量创建线程池。虽然多线程并不保证能够提升性能，但适量地      // 开线程一般可以从系统骗取更多资源。      ExecutorService es = Executors.newFixedThreadPool(              Runtime.getRuntime().availableProcessors() * 2 );      // 使用 ExecutorCompletionService 内建的阻塞队列。      CompletionService cs = new ExecutorCompletionService(es);        // 按文件向 CompletionService 提交任务。      for ( final Path javaFile : javaFiles) {          cs.submit( new Callable<Integer>() {              @Override              public Integer call() throws Exception {                  // 略去计算单个文件行数的代码。                  return countLines(javaFile);              }          });      }        try {          int loc = 0 ;          int size = javaFiles.size();          for ( int i = 0 ; i < size; i++) {              // take 方法等待下一个结果并返回 Future 对象。不直接返回计算结果是为了              // 捕获计算时可能抛出的异常。              // poll 不等待，有结果就返回一个 Future 对象，否则返回 null。              loc += cs.take().get();          }          return loc;      } finally {          // 关闭线程池。也可以将线程池提升为字段以便重用。          // 如果任务线程（Callable#call）能响应中断，用 shutdownNow 更好。          es.shutdown();      } }

最后，CompletionService 也不是到处都能用，它不适合处理任务数量有限但个数不可知的场景。例如，要统计某个文件夹中的文件个数，在遍历子文件夹的时候也会“递归地”提交新的任务，但最后到底提交了多少，以及在什么时候提交完了所有任务，都是未知数，无论 CompletionService 还是线程池都无法进行判断。这种情况只能直接用线程池来处理。