future相比于其他并发设计模式的优势（“回调驱动（多线程环境下）”、“消息/事件驱动（Actor模型中））

与其它并发设计模式的对比

除了Future外，其它比较常见的并发设计模式还包括“回调驱动（多线程环境下）”、“消息/事件驱动（Actor模型中）”等。

回调是最常见的异步并发模式，它有即时性高、接口设计简单等有点。但相对于Future，其缺点也非常明显。首先，多线程环境下的回调一般是在触发回调的模块线程中执行的，这就意味着编写回调方法时通常必须考虑线程互斥问题；其次，回调方式接口的提供者在本模块的线程中执行用户应用的回调也是相对不安全的，因为你无法确定它会花费多长时间或出现什么异常，从而可能间接导致本模块的即时性和可靠性受影响；再者，使用回调接口不利于顺序流程的开发，因为回调方法的执行是孤立的，要与正常流程汇合是比较困难的。因此回调接口适合于在回调中只需要完成简单任务，并且不必与其它流程汇合的场景。

上述这些回调模式的缺点恰恰正是Future的长项。由于Future的使用是将异步的数据驱动天然的融入顺序流程中，因此你完全不必考虑线程互斥问题，Future甚至可以在单线程的程序模型（例如协程）中实现（参见下文将要提到的“Lazy Future”）。另一方面，提供Future接口的模块完全不必担心像回调接口那样的可靠性问题和可能对本模块的即时性影响。

另一类常见的并发设计模式是“消息（事件）驱动”，它一般运用在Actor模型中：服务请求者向服务提供者发送消息，然后继续进行后续不依赖服务处理结果的任务，在需要依赖结果前终止当前流程并记录状态；在等到回应消息后根据记录的状态触发后续流程。这种基于状态机的并发控制虽然比回调更适合于有延续性的顺序流程，但开发者却不得不将连续流程按照异步服务的调用切断为多个按状态区分的子流程，这样又人为的增加了开发的复杂性。运用Future模式可以避免这个问题，不必为了异步调用而打碎连续的流程。但是有一点应当特别注意：Future.get()方法可能会阻塞线程的执行，所以它通常无法直接融入常规的Actor模型中。（基于协程的Actor模型可以较好的解决这个冲突）

Future的灵活性还体现在其同步和异步的自由取舍，开发者可以根据流程的需要自由决定是否需要等待[Future.isDone()]，何时等待[Future.get()]，等待多久[Future.get(timeout)]。比如可以根据数据是否就绪而决定要不要借这个空档完成点其它任务，这对于实现“异步分支预测”机制是相当方便的。