认识异步编程
本章主要介绍异步编程的概念和作用，Java中异步编程的场景以及不同异步编程场景应使用什么技术实现。
1.1 异步编程概念与作用
通常Java开发人员喜欢使用同步代码编写程序，因为这种请求(request)/响应
(response)的方式比较简单，并且比较符合编程人员的的思维习惯；这种做法很好，直到
系统出现性能瓶颈。在使用同步编程方式时，由于每个线程同时只能发起一个请求并同步等
待返回，所以为了提高系统性能，此时我们就需要引入更多的线程来实现并行化处理。但是
多线程下对共享资源进行访问时，不可避免会引入资源争用和并发问题；另外，操作系统层
面对线程的个数是有限制的，不可能通过无限制的增加线程来提供系统性能；而且，使用同
步阻塞的编程方式还会浪费资源，比如发起网络IO请求时，调用线程就会处于同步阻塞等待
响应结果的状态，而这时候调用线程明明可以去做其他事情，等网络IO响应结构返回后再对
结构进行处理。
可见通过增加单机系统线程个数的并行编程方式并不是“灵丹妙药”。通过编写异步、非
阻塞的代码，则可以使用相同的底层资源将执行切换到另一个活动任务，然后在异步处理完
成后再返回到当前线程继续处理，从而提高系统性能。
异步编程是可以让程序并行运行的一种手段，其可以让程序中的一个工作单元与主应用
程序线程分开独立运行，并且在工作单元运行结束后，会通知主应用程序线程它的运行结果
或者失败原因。使用异步编程可以提高应用程序的性能和响应能力等。
比如当调用线程使用异步方式发起网络IO请求后，调用线程就不会同步阻塞等待响应结
果，而是在内存保存请求上下文后，马上返回去做其他事情，等网络IO响应结果返回后再使用
IO线程通知业务线程响应结果已经返回，由业务线程对结果进行处理。可见，异步调用方式提高
了线程的利用率，让系统有更多的线程资源来处理更多的请求。
比如在移动应用程序中，在用户操作移动设备屏幕发起请求后，如果是同步等待后台服务器
返回结果，则当后台服务操作非常耗时时，就会造成用户看到移动设备屏幕冻结(一直处于请求处
理中)，在结果返回前，用户不能操作移动设备的其他功能，这对用户体验非常不好。而使用异步
编程时，当发起请求后，调用线程会发生返回，具体返回结果会通过UI线程异步进行渲染，且在这
期间用户可以使用移动设备的其他功能。
1.2 异步编程场景
在日常开发中我们经常会遇到这样的情况，即需要异步处理一些事情，而不需要
知道异步任务的结果。比如在调用线程里面异步打日志，为了不让日志打印阻塞调用线程
，会把日志设置为异步方式。如图1-1所示的日志异步化打印，使用一个内存队列把日志
打印异步化，然后使用单一消费线程异步处理内存队列中的日志事件，执行具体的日志
落盘操作(本质是一个多生产单消费模型)，在这种情况下，调用线程把日志任务放入队
列后会继续执行其他操作，而不再关心日志任务具体是什么时候入盘的。
图 1-1 日志异步打印
在Java中，每当我们需要执行异步任务时，可以直接开启一个线程来实现，也可以
把异步任务封装为任务对象投递到线程池中来执行。在Spring框架中提供了@Async注解
把一个任务异步化来进行处理，具体会在后面的章节详细讲解。
有时候我们还需要在主线程等待异步任务的执行结果，这时候Future就派上用场了。
比如调用线程要等任务A执行完毕后再顺序执行任务B，并且把两者的任务结果拼接起来供
前端展示使用，如果调用线程是同步调用两次任务(如图 1-2所示)，则整个过程耗时为执
行任务A的耗时加上执行任务B的耗时。
图 1-2 同步调用
如果使用异步编程(如图 1-3所示)，则可以在调用线程内开启一个异步运行单元来执
行任务A，开启异步运行单元后调用线程会马上返回一个Future对象(futureB)，然后调用
线程本身来执行任务B，等任务B执行完毕后，调用线程可以调用futureB的get()方法获取
任务A的执行结果，最好再拼接两者的结果。这时由于任务A和任务B是并行运行的，所以整个
过程耗时为max(调用线程执行任务B的耗时，异步运行单元执行任务A的耗时)。
图 1-3 异步调用
可见整个过程耗时显著缩短，对于用户来说，页面响应时间缩短，用户体验会更好，其
中异步单元的执行一般是由线程池中的线程执行。
使用Future确实可以获取异步任务的执行结果，但是获取其结果还是会阻塞调用线程的，
并没有实现完全的异步化处理，所以在JDK8中提供了CompletableFuture来弥补其缺点。CompletableFuture
类允许非阻塞方式和基于通知的方式处理结果，其通过设置回调函数方式，让主线程彻底解放出来，实现了实际意义上的异步处理。
如图 1-4 所示，使用CompletableFuture时，当异步单元返回futureB后，调用线程可以在其上调用whenComplete方法设置一个回调函数action，
然后调用线程就会马上返回，等异步任务执行完毕后会使用异步线程来执行回调函数action，而无须调用线程干预。如果你对CompletableFuture不了解
，没关系，后面章节我们会详细讲解，这里你只需要知道其解决了传统Future的缺陷就可以了。
图 1-4 CompletableFuture异步执行
JDK8还引入了Stream，旨在有效地处理数据流(包括原始类型)，其使用声明式编程让我们可以写出可读性、可维护性很强的代码，并且结合CompletableFuture
完美地实现异步编程。但是它产生的流只能使用一次，并且缺少与实际相关的操作(例如RxJava中基于时间窗口的缓存元素)，虽然可以执行并行计算，但无法指定要
使用的线程池。同时，它也没有设计用于处理延迟的操作(例如RxJava中的defer操作)，所以Reactor、RxJava等Reactive API就是为了解决这些问题而生的。
Reactor、RxJava等反应式API也提供Java 8 Stream 的运算符，但它们更适用于流序列(不仅仅是集合)，并且允许定义一个转换操作的管道，该管道将应用于通过它的数据(这要归功于方便的流畅API和Lambda表达式的使用)。Reactive旨在处理同步或异步操作，
并允许你对元素进行缓存(buffer)、合并(merge)、连接(join)等各种转换。
上面我们讲解了但JVM内的异步编程，那么对于跨网络的交互是否也存在异步编程范畴呢？对于网络请求来说，同步调用是比较直截了当的。比如我们在一个线程A
中通过RPC请求获取服务B和服务C的数据，然后基于两者的结果做一些事情。在同步调用情况下，线程A需要调用服务B，然后同步等待服务B结果返回后，才可以对
服务C发起调用，等服务C结果返回后才可以结合服务B和C的结果执行其他操作。
如图 1-5所示，线程A同步获取服务B的结果后，再同步调用服务C获取结果，可见在同步调用情况下业务执行语义比较清晰，线程A顺序地对多个服务请求进行调用；但是同步调用意味着当前发起请求的调用线程在远端机器返回结果前必须阻塞等待，这明细很浪费资源。好的做法应该是在发起请求的调用线程发起请求后，注册一个回调函数，然后马上返回去执行其他操作，当远端把结果返回后再使用IO线程或者框架线程池中的线程执行回调函数。
图 1-5 同步RPC调用
那么如何实现异步调用？在Java中NIO的出现让实现上面的功能变得简单，而高性能异步、基于事件驱动的网络编程框架Netty的出现让我们从编写繁杂的Java NIO
程序中解放出来，现在的RPC框架，比如Dubbo底层网络通信，就是基于Netty实现的。Netty框架将网络编程逻辑与业务逻辑处理分离开来，在内部帮我们自动处理
好网络与异步处理逻辑，让我们专心写自己的业务处理逻辑，而Netty的异步非阻塞能力与CompletableFuture结合则可以轻松地实现网络请求的异步调用。
在执行RPC(远程过程调用)调用时，使用异步编程可以提高系统的性能。如图 1-6所示，在异步调用情况下，当线程A调用服务B后，会马上返回一个异步的futureB
对象，然后线程A可以在futureB上设置一个回调函数；接着线程A可以继续访问服务C，也会马上返回一个futureC对象，然后线程A可以在futureC上设置一个回调函数。
图 1-6 RPC异步调用
如图 1-6 可知，在异步调用情况下，线程A可以并发地调用服务B和服务C，而不再是顺序的。由于服务B和服务C是并发运行，所以相比同步调用，线程A获取到
服务B和服务C结果的时间会缩短很多(同步调用情况下的耗时为服务B和服务C返回结果耗时的，异步调用情况下函数为max(服务B耗时，服务C耗时))。另外，
这里可以借助CompletableFuture的能力等两次RPC调用都异步返回结果后再执行其他操作，这时候调用流程如图 1-7所示。
图 1-7 合并RPC调用结果
如图 1-7 所示，调用线程A首先发起服务B的远程调用，会马上返回一个futureB对象，然后发起服务C的远程调用，也会马上返回一个futureC对象，最好调用
线程A使用代码futureB.thenCombine(futureC,action)等futureB和futureC结果可用时执行回调函数action。这里我们只是简单概述下基于Netty的异步
非阻塞能力以及CompletableFuture的可编排能力，基于这些能力，我们可以实现功能很强大的异步编程能力。在后面章节，我们会以Dubbo框架为例讲解其
借助Netty的非阻塞异步API实现服务消费端的异步调用。
其实，有了CompletableFuture实现异步编程，我们可以很自然地使用适配器来实现Reactive风格的编程。当我们使用RxJava API时，只需要使用Flowable的
一些函数转转CompletableFuture为Flowable对象即可，这个我们在后面章节也会讲述。
上节讲解了网络请求中RPC框架的异步请求，其实还有一类，也就是Web请求，在Web应用中Servlet占有一席之地。在Servlet3.0规范前，Servlet容器对Servlet
的处理都是每个请求对应一个线程这种1:1的模式进行处理的(如果 1-8 所示)，每当收到一个请求，都会开启一个Servlet容器内的线程来进行处理，如果
Servlet内处理比较耗时，则会把Servlet容器内线程使用耗尽，然后容器就不能再处理新的请求了。
图 1-8 Servlet的阻塞处理模型
Servlet 3.0 规范中则提供了异步处理的能力，让Servlet容器中的线程可以及时释放，具体Servlet业务处理逻辑是在业务自己的线程池内来处理；虽然
Servlet 3.0 规范让Servlet的执行变为异步，但是其IO还是阻塞式的。IO阻塞是说在Servlet处理请求时，从ServletInputStream中读取请求体时是阻塞的，
而我们想要的是当书记就绪时直接通知我们去读取就可以了，因为这可以避免占用我们自己的线程来进行阻塞读取，好在Servlet 3.1 规范提供了非阻塞IO来解决
这个问题。
虽然Servlet技术栈的不断发展实现了异步处理与非阻塞IO，但是其异步是不彻底的，因为受制于Servlet规范本身，比如其规范是同步的(Filter，Servlet)或
阻塞的(getParameter，getPart)。所以新的使用少量线程和较少的硬件资源来处理并发的非阻塞Web技术栈应运而生-WebFlux，其是与Servlet技术栈并行存在
的一种新技术，基于JDK8函数式编程与Netty实现天然的异步、非阻塞处理，这些我们在后面的章节会具体介绍。
为了更好的实现异步编程，降低异步编程的成本，一些框架也应运而生，比如高性能线程间消息传递库Disruptor，其通过为事件(event)预先分配内存、无锁CAS
算法、缓存行填充、两阶段协议提交来实现多线程并发地处理不同的元素，从而实现高性能的异步处理。比如Akka基于Actor模式实现了天然支持分布式的使用消息进行异步处理的服务；比如高性能分布式消息中间件Apache RocketMetaQ实现了应用间的异步解耦、流量肖锋。
一些新兴的语言对异步处理的支持能力让我们忍不住称赞，Go语言就是其中之一，其通过语言层面内置的goroutine与channel可以轻松实现复杂的异步处理能力。
以上就是本书要讨论的内容。
1.3 总结
本章我们首先概要介绍了异步编程的概念与作用，让大家对异步编程有一个大致的了解；然后讲解了Java中异步编程的场景，让大家通过实际场景案例进一步了解
异步编程是什么，以及不同异步编程场景应使用什么技术来实现。