RPC 请求分为 sync，future，callback，oneway，能异步就不要同步。优化业务场景：一次页面展示中，需要调用 5 个 RPC 接口，导致页面响应很慢。
一、慢？多线程加速
大多数开源的 RPC 框架实现远程调用的方式都是同步，假设 [ 接口1，…，接口5]的每一次调用耗时为 200ms （其中接口2依赖接口1，接口5依赖接口3，接口4），串行的过程总耗时为 1s。
多线程，那么[1=>2]编为一组，[3,4]=>5]编为一组，两组并发执行，[1=>2]串行执行耗时400ms，[3,4]并发执行耗时200ms，[[3,4]=>5]总耗时400ms ，最终[[1=>2],[[3,4]=>5] 总耗时400ms（理论耗时）。实际编写接口花了不少功夫：创建线程池，管理资源，分析依赖关系…代码不优雅。
优点：RPC中，多线程着重考虑的点是在客户端优化代码
缺点：给客户端带来复杂性，并发代码对程序员要求高，且不利于调试。
二、异步调用
RPC 中异步调用：保证速度，又像同步 RPC 调用那样方便
先回顾一下java.util.concurrent中的基础知识：Callable和Future
result = 15, total cost 413 ms
异步优势，submit任务之后立刻返回，只调用future.get()方法会阻塞。
三、RPC 异步调用
项目用Motan 作为 RPC 框架，查看其 changeLog ，0.3.0(2017-03-09) 该版本已经支持了 async 特性。方便实现 RPC 异步调用。
1 为接口增加 @MotanAsync 注解
2 添加 Maven 插件
安装插件后，可以借助它生成一个和 DemoApi 关联的异步接口 DemoApiAsync 。
3 注入接口即可调用
<1> DemoApiAsync 生成和 DemoApi 没有功能性的区别，仅同步异步调用差别，DemoApiAsync 实现的的复杂性由 RPC 框架完成，无需编写 Callable 接口。
<2> ResponseFuture 是 RPC 中 Future 抽象，本身也是 juc 中 Future 的子类， responseFuture.getValue() 调用时会阻塞。
总结
异步调用中，发起一次异步调用后，立刻使用 future.get() ，则大致和同步调用等同。优势：submit 和 future.get() 之间混杂一些非依赖性的耗时操作，不同步等待，充分利用时间片。
异步调用涉及数据修改，多个异步操作直接不能保证 happens-before 原则，谨慎使用。查询操作没有这样限制。
