11.1 Future 接口
Future接口在Java5中被引人，设计初衷是对将来某个时刻会发生的结果进行建模。它建模了一种异步计算，返回一个执行运算结果的引用，当运算结束后，这个引用被返回给调用方。在Future中触发那些潜在耗时的操作把调用线程解放出来，让它能继续执行其他有价值的工作，不再需要呆呆等待耗时的操作完成。打个比方，你可以把它想象成这样的场景:你拿了一袋子衣服到你中意的干洗店去洗。干洗店的员工会给你张发票，告诉你什么时候你的衣服会洗好(这就是一个Future事件)。衣服干洗的同时，你可以去做其他的事情。Future的另一个优点是它比更底层的+hread更易用。要使用Future，通常你只需要将耗时的操作封装在一个callable对象中，再将它提交给Executorservice，就万事大吉了。下面这段代码展示了Java8之前使用Future的一个例子。

正像图11-3介绍的那样，这种编程方式让你的线程可以在Executorservice以并发方式调用另一个线程执行耗时操作的同时，去执行一些其他的任务。接着，如果你已经运行到没有异步操作的结果就无法继续任何有意义的工作时，可以调用它的get方法去获取操作的结果。如果操作已经完成，该方法会立刻返回操作的结果，否则它会阻塞你的线程，直到操作完成，返回相应的结果。
你能想象这种场景存在怎样的问题吗?如果该长时间运行的操作永远不返回了会怎样?为了处理这种可能性,虽然Future提供了一个无需任何参数的get方法,我们还是推荐大家使用重载版本的get方法，它接受一个超时的参数，通过它，你可以定义你的线程等待Future结果的最长时间，而不是像代码清单11-1中那样永无止境地等待下去。

11.1.1 Future 接口的局限性
通过第一个例子，我们知道Future接口提供了方法来检测异步计算是否已经结束(使用ispone方法)，等待异步操作结束，以及获取计算的结果。但是这些特性还不足以让你编写简洁的并发代码。比如，我们很难表述Future结果之间的依赖性;从文字描述上这很简单，“当长时间计算任务完成时，请将该计算的结果通知到另一个长时间运行的计算任务，这两个计算任务都完成后，将计算的结果与另一个查询操作结果合并”。但是，使用Future中提供的方法完成这样的操作又是另外一回事。这也是我们需要更具描述能力的特性的原因，比如下面这些。
口将两个异步计算合并为一个--这两个异步计算之间相互独立，同时第二个又依赖于第一个的结果。
口等待Future集合中的所有任务都完成
口仅等待Future集合中最快结束的任务完成(有可能因为它们试图通过不同的方式计算同一个值)，并返回它的结果。
口通过编程方式完成一个Future任务的执行(即以手工设定异步操作结果的方式)。口应对Future的完成事件(即当Future的完成事件发生时会收到通知，并能使用Future计算的结果进行下一步的操作，不只是简单地阻塞等待操作的结果)。这一章中，你会了解新的completableFuture类(它实现了Future接口)如何利用Java8的新特性以更直观的方式将上述需求都变为可能。stream和completableFuture的设计都遵循了类似的模式:它们都使用了Lambda表达式以及流水线的思想。从这个角度，你可以说CompletableFuture和Future的关系就跟stream和collection的关系一样。
11.1.2 使用 Completableruture 构建异步应用
为了展示completableFuture的强大特性，我们会创建一个名为“最佳价格查询器(best-price-finder)的应用，它会查询多个在线商店，依据给定的产品或服务找出最低的价格。这

个过程中，你会学到几个重要的技能。
口首先，你会学到如何为你的客户提供异步API(如果你拥有一间在线商店的话，这是非常有帮助的)。
口其次，你会掌握如何让你使用了同步API的代码变为非阻塞代码。你会了解如何使用流水线将两个接续的异步操作合并为一个异步计算操作。这种情况肯定会出现，比如，在线商店返回了你想要购买商品的原始价格，并附带着一个折扣代码--最终，要计算出该商品的实际价格，你不得不访问第二个远程折扣服务，查询该折扣代码对应的折扣比率。口你还会学到如何以响应式的方式处理异步操作的完成事件，以及随着各个商店返回它的商品价格，最佳价格查询器如何持续地更新每种商品的最佳推荐，而不是等待所有的商店都返回他们各自的价格(这种方式存在着一定的风险，一旦某家商店的服务中断，用户可能遭遇白屏)。
同步API与异步API
同步API其实只是对传统方法调用的另一种称呼:你调用了某个方法，调用方在被调用方运行的过程中会等待，被调用方运行结束返回，调用方取得被调用方的返回值并继续运行。即使调用方和被调用方在不同的线程中运行,调用方还是需要等待被调用方结束运行，这就是阻寨式调用这个名词的由来。
与此相反，异步API会直接返回，或者至少在被调用方计算完成之前，将它剩余的计算任务交给另一个线程去做，该线程和调用方是异步的--这就是非阻寒式调用的由来。执行剩余计算任务的线程会将它的计算结果返回给调用方。返回的方式要么是通过回调函数，要么是由调用方再次执行一个“等待，直到计算完成”的方法调用。这种方式的计算在IO系统程序设计中非常常见:你发起了一次磁盘访问，这次访问和你的其他计算操作是异步的，你完成其他的任务时，磁盘块的数据可能还没载入到内存，你只需要等待数据的载入完成。