---- https://www.jianshu.com/p/893f036071fe ----
Exploring reactive programming in Java by Miro Cupak
最近学习RxJava。RxJava 在 GitHub 主页上的自我介绍:
RxJava is a Java VM implementation of Reactive Extensions: a library for composing asynchronous and event-based programs by using observable sequences.
翻译：RxJava是Reactive Extensions(响应式扩展)在 Java VM 上的实现，是一个使用可观测的序列来组成异步的、基于事件的程序的库。
两个关键词：Reactive Extensions，asynchronous 。
RxJava 的核心是响应式编程，所解决的问题是“异步”。
所以在学习Rx库之前，有必要了解下什么是响应式编程。
RX
Reactive Extensions是指什么。
Rx取自于ReactiveX,ReactiveX是Reactive Extensions的缩写。RxJava是ReactiveX在Java端的一种实现。所以还有RxJs,Rx.Net,RxSwift等多种实现。
官网对其的介绍如下:
An API for asynchronous programming with observable streams
一个带有可观察的流的异步编程的API
还是离不开“异步”，提到异步就不得不提到线程。
所以，线程是响应式编程的第一步！
响应式的由来
故事从上古时期说起：
Java 1：
众所周知，Java在设计之初就是一门支持多线程的语言。在Java1.0版本中，要想开辟一个新线程，需使用Thread：
Thread thread = new Thread(() -> System.out.println("hello world"));
thread.start()
除此之外，它几乎不能做任何复杂的事情。
你可以说它有异步，但是他的整个异步系统处于“瘫痪”状态，简陋至极。当然也没有“响应”可言，可以叫他“零响应式”。
Java 5：
这个版本中为我们新增了三个很实用的接口：ExcutorService、Future和Callable。
Callable使Runnable有了返回值；ExecutorService.submit(callable)方法返回一个Future<T>,便可以从Future中获取异步执行返回的结果。
ExecutorService e = Executors.newSingleThreadExecutor();
Future<String> future = e.submit(() -> "hello world");
future.get();
这样一来，我们有能力提供一个复杂的“异步”系统，但是“被动”且“低廉”。不管怎么说，它有了自己的一个异步系统，我们姑且称之为“一级响应式”。
Java 7
Java 7开始引入了一种新的Fork/Join线程池(Pool)，它可以执行一种特殊的任务：把一个大任务拆成多个小任务并行执行。
同样的代码可以如下执行：
ExecutorService e = ForkJoinPool.commonPool();
Future<String> future = e.submit(() -> "hello world");
future.get();
在此支持下，我们可以很好的做到各个线程的同步。我们称之为“二级响应式”。
但是饶是如此，使用Future获得异步执行结果时，要么调用阻塞方法get()，要么轮询看isDone()是否为true，主线程会被迫等待。
Java 8
从Java 8开始引入了CompletableFuture，它针对Future做了改进，可以传入回调对象，当异步任务完成或者发生异常时，自动调用回调对象的回调方法。
CompletableFuture cf = new CompletableFuture<String>();
//cf.complete("hello");
cf.completeExceptionally(new Exception("error"));
cf.get();
等待、成功、异常，都可以作为方法传给CompletableFuture。
CompletableFuture中还内置很多方法，分为三类；
- What kind of task is this;
- What kind of an Opreation is it support;
- What thread should run for the task.
其中，task可以是runnable、consumer或者function。 3种。
Opretion可以是Chain（链接操作）、compose（组合）、combine AND( AND结合)、combine OR（OR结合）。4种。
thread可以是：当前线程、主线程 和 自己定义的某线程。3种。
一番排列组合下来，一共有3 × 4 × 3 = 36 种方法。
高效，漂亮，易使用，非阻塞。可以是“三级响应式”了
后续版本种还加入了延时方法，completeOnTimeOut()和orTime(),已经做到了很好的异步操作。
Java 9
到此为止这个异步系统还差点什么。比如当出线“生产者”比“消费者”快的情况下【背压问题】，不能很好的解决。
所以，Java 9 引入了Flow接口。
SimpleSubscriber sub = new SimpleSubscriber();
SubmissionPublisher<String> publisher = new SubmissionPublisher<>();
publisher.subscribe(sub);
publisher.submit("msg");
publisher.close();
这一套接口使用下来，越发接近我们想要的模型了，是“四级响应式”
但是它并不完美，因为一般异步都涉及到网络请求。
Java 9 到 Java 11
这其中新增了Http2接口，除了支持webSocket外，还对Flow进行了很好的适配，使得网络的响应更加容易了。至此我们称之为“五级响应式”。
这些在API的种种变化，使得我们操作异步更加方便优雅，响应式的程度也就越高。
不过这些改变都在JDK的层面上。
Reactive Libraries
在往上走就是Library层面的故事了。我们的RxJava库，就属于这个层面。
框架
Library往上走就是框架层面，框架中也有响应的支持。
综上，最后结论如图：
什么是响应式编程（Reactive Programming）
In computing, reactive programming is an asynchronous programming paradigm concerned with data streams and the propagation of change. This means that it becomes possible to express static (e.g. arrays) or dynamic (e.g. event emitters) data streams with ease via the employed programming language(s), and that an inferred dependency within the associated execution model exists, which facilitates the automatic propagation of the change involved with data flow.
-- Wikipedia
以上解释来自维基百科，在计算机领域，响应式编程是一个专注于数据流和变化传递的异步编程范式。这意味着可以使用编程语言很容易地表示静态（例如数组）或动态（例如事件发射器）数据流，并且在关联的执行模型中，存在着可推断的依赖关系，这个关系的存在有利于自动传播与数据流有关的更改。
抛开大段大段的概念，我们先搞清楚一件事情：什么是编程范式？
通俗的说：编程是为了解决问题，而解决问题可以有多种视角和思路，其中具有普适性的模式被归结为范式。我们常说的：“面向对象”，“面向过程”都是编程范式。
响应式编程是一种从数据流和变化出发的解决问题的模式。所以要研究响应式编程，一定要牢记已经掌握的OO（面向对象，笔者妄断大家OO的思想都是很根深蒂固了）来做对比，也一定要抛开OO避免钻牛角尖。
为什么是异步？
在展开这个问题前，我们先看一个故事，引自知乎：小故事
摘抄如下：
老张爱喝茶，废话不说，煮开水。
出场人物：老张，水壶两把（普通水壶，简称水壶；会响的水壶，简称响水壶）。
1 老张把水壶放到火上，立等水开。（同步阻塞）
老张觉得自己有点傻2 老张把水壶放到火上，去客厅看电视，时不时去厨房看看水开没有。（同步非阻塞）
老张还是觉得自己有点傻，于是变高端了，买了把会响笛的那种水壶。水开之后，能大声发出嘀~~~~的噪音。3 老张把响水壶放到火上，立等水开。（异步阻塞）
老张觉得这样傻等意义不大4 老张把响水壶放到火上，去客厅看电视，水壶响之前不再去看它了，响了再去拿壶。（异步非阻塞）
老张觉得自己聪明了。所谓同步异步，只是对于水壶而言。普通水壶，同步；响水壶，异步。虽然都能干活，但响水壶可以在自己完工之后，提示老张水开了。这是普通水壶所不能及的。同步只能让调用者去轮询自己（情况2中），造成老张效率的低下。
所谓阻塞非阻塞，仅仅对于老张而言。立等的老张，阻塞；看电视的老张，非阻塞。情况1和情况3中老张就是阻塞的，媳妇喊他都不知道。虽然3中响水壶是异步的，可对于立等的老张没有太大的意义。所以一般异步是配合非阻塞使用的，这样才能发挥异步的效用。
上面这个小故事还是有点问题，但基本可以说明问题了。
响应，一定是对一个事件、一个信号（诸如此类的描述）产生了反应。响水壶的响应是什么呢？水温达到一定程度,水壶的反应是会响。水壶响了，声音传递给老张，老张的反应是去关水壶。
再看普通水壶，水温达到一定程度，水壶没有反应，水的反应是冒气泡，冒水雾。只是这个信号不太容易传递，要跑过来看，所以老张只能以轮训的方式来办事情，没法跑到一边等通知。
对于两个水壶而言，烧水都是阻塞的，水没烧完就干不了其他的事情（比如说拿来砸胡桃？？？）
ok,回到我们的问题：为什么是异步？
回归到本质回答这个问题：响应式编程，本质上是对数据流或某种变化所作出的反应，但是这个变化什么时候发生是未知的，所以他是一种基于异步、回调的方式在处理问题。
怪圈：似乎绝大多数博客说着说着就开始讲解RxAndroid
正如副标题，在网上搜索到的绝大多数的博客都会说着说着就在教你如何使用RxAndroid。各位，请记住以下几点：
-
RxAndroid(或RxJava)是很优秀的响应式编程框架。
-
你并非一定需要使用RxAndroid。
-
RxAndroid并不像那些博客里面说的那样会让你的代码变得更可读。
这里我直接进入第三点。取用扔物线推荐RxJava中的例子：如下这段代码：
Observable.from(folders)
.flatMap((Func1) (folder) -> { Observable.from(file.listFiles()) })
.filter((Func1) (file) -> { file.getName().endsWith(".png") })
.map((Func1) (file) -> { getBitmapFromFile(file) })
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe((Action1) (bitmap) -> { imageCollectorView.addImage(bitmap) });
就这段代码，是否需要从上到下仔细阅读一遍之后才能才会知道他的意图？
甚至，为了精读代码，他可能是这样：
Observable.from(folders)
.flatMap(new Func1<File, Observable<File>>() {
@Override
public Observable<File> call(File file) {
return Observable.from(file.listFiles());
}
})
.filter(new Func1<File, Boolean>() {
@Override
public Boolean call(File file) {
return file.getName().endsWith(".png");
}
})
.map(new Func1<File, Bitmap>() {
@Override
public Bitmap call(File file) {
return getBitmapFromFile(file);
}
})
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Action1<Bitmap>() {
@Override
public void call(Bitmap bitmap) {
imageCollectorView.addImage(bitmap);
}
});
ok,请允许我再问一个问题，如此简介的代码，您打算单独用一个类来放吗？
如果对于任何一个处理类似业务逻辑的rx代码段都使用类来放，可能类数量会爆炸，而且这些类的命名看起来会很奇葩。若不这样，您的业务实现类中将充斥诸如此类不精读不敢确定语义、容易被误修改、不容易测试的代码。面对这样的代码的时候只会是如履薄冰战战兢兢。
我是在反对使用RxAndroid吗？
No，我只是反对滥用Rx，我赞成对某些高度抽象的异步行为使用Rx构建具有语义性的框架代码，例如：编写MVVM分层框架。反对对任何业务细节都去做“一切皆流”的无脑工作。毕竟：业务是需要逐渐迭代发展的，对于有测试代码支撑的、同时有较强语义性的类，我们泛读代码就可以“闻弦歌而知雅意”，对于需要重构何处代码，修改何处逻辑心中有数，而不必将“流”再反转回“实际的相互关系”，再打乱，修改，再组织成流，再恶心下一次迭代，而且，最关键的是“你可能要从很多的流中找出这一个流”。
--- https://segmentfault.com/a/1190000017548728 ---
摘要：响应式宣言如何解读，Java中如何进行响应式编程，Reactor Streams又该如何使用？从响应式理解，到Reactor项目示例，再到Spring Webflux框架解读，本文带你进入Java响应式编程。
本文围绕以下三部分进行介绍：
1.Reactive
2.Project Reactor
3.Spring Webflux
一．Reactive
1.Reactive Manifesto
下图是Reactive Manifesto官方网站上的介绍，这篇文章非常短但也非常精悍，非常值得大家去认真阅读。
响应式宣言是一份构建现代云扩展架构的处方。这个框架主要使用消息驱动的方法来构建系统，在形式上可以达到弹性和韧性，最后可以产生响应性的价值。所谓弹性和韧性，通俗来说就像是橡皮筋，弹性是指橡皮筋可以拉长，而韧性指在拉长后可以缩回原样。这里为大家一一解读其中的关键词：
1）响应性：快速/一致的响应时间。假设在有500个并发操作时，响应时间为1s，那么并发操作增长至5万时，响应时间也应控制在1s左右。快速一致的响应时间才能给予用户信心，是系统设计的追求。
2）韧性：复制/遏制/隔绝/委托。当某个模块出现问题时，需要将这个问题控制在一定范围内，这便需要使用隔绝的技术，避免连锁性问题的发生。或是将出现故障部分的任务委托给其他模块。韧性主要是系统对错误的容忍。
3）弹性：无竞争点或中心瓶颈/分片/扩展。如果没有状态的话，就进行水平扩展，如果存在状态，就使用分片技术，将数据分至不同的机器上。
4）消息驱动：异步/松耦合/隔绝/地址透明/错误作为消息/背压/无阻塞。消息驱动是实现上述三项的技术支撑。其中，地址透明有很多方法。例如DNS提供的一串人类能读懂的地址，而不是IP，这是一种不依赖于实现，而依赖于声明的设计。再例如k8s每个service后会有多个Pod，依赖一个虚拟的服务而不是某一个真实的实例，从何实现调用1 个或调用n个服务实例对于对调用方无感知，这是为分片或扩展做了准备。错误作为消息，这在Java中是不太常见的，Java中通常将错误直接作为异常抛出，而在响应式中，错误也是一种消息，和普通消息地位一致，这和JavaScript中的Promise类似。背压是指当上游向下游推送数据时，可能下游承受能力不足导致问题，一个经典的比喻是就像用消防水龙头解渴。因此下游需要向上游声明每次只能接受大约多少量的数据，当接受完毕再次向上游申请数据传输。这便转换成是下游向上游申请数据，而不是上游向下游推送数据。无阻塞是通过no-blocking IO提供更高的多线程切换效率。
2.Reactive Programming
响应式编程是一种声明式编程范型。下图中左侧显示了一个命令式编程，相信大家都比较熟悉。先声明两个变量，然后进行赋值，让两个变量相加，得到相加的结果。但接着当修改了最早声明的两个变量的值后，sum的值不会因此产生变化。而在Java 9 Flow中，按相同的思路实现上述处理流程，当初始变量的值变化，最后结果的值也同步发生变化，这就是响应式编程。这相当于声明了一个公式，输出值会随着输入值而同步变化。
响应式编程也是一种非阻塞的异步编程。下图是用reactor.ipc.netty实现的TCP通信。常见的server中会用循环发数据后，在循环外取出，但在下图的实现中没有，因为这不是使用阻塞模型实现，是基于非阻塞的异步编程实现。
响应式编程是一种数据流编程，关注于数据流而不是控制流。下图中，首先当页面出现点击操作时产生一个click stream，然后页面会将250ms内的clickStream缓存，如此实现了一个归组过程。然后再进行map操作，得到每个list的长度，筛选出长度大于2的，这便可以得出多次点击操作的流。这种方法应用非常广泛，例如可以筛选出双击操作。由此可见，这种编程方式是一种数据流编程，而不是if else的控制流编程。
之前有提及消息驱动，那么消息驱动（Message-driven）和事件驱动（Event-driven）有什么区别呢。
1）消息驱动有确定的目标，一定会有消息的接受者，而事件驱动是一件事情希望被观察到，观察者是谁无关紧要。消息驱动系统关注消息的接受者，事件驱动系统关注事件源。
2）在一个使用响应式编程实现的响应式系统中，消息擅长于通讯，事件擅长于反应事实。
3.Reactive Streams
Reactive Streams提供了一套非阻塞背压的异步流处理标准，主要应用在JVM、JavaScript和网络协议工作中。通俗来说，它定义了一套响应式编程的标准。在Java中，有4个Reactive Streams API，如下图所示：
这个API中定义了Publisher，即事件的发生源，它只有一个subscribe方法。其中的Subscriber就是订阅消息的对象。
作为订阅者，有四个方法。onSubscribe会在每次接收消息时调用，得到的数据都会经过onNext方法。onError方法会在出现问题时调用，Throwable即是出现的错误消息。在结束时调用onComplete方法。
Subscription接口用来描述每个订阅的消息。request方法用来向上游索要指定个数的消息，cancel方法用于取消上游的数据推送，不再接受消息。
Processor接口继承了Subscriber和Publisher，它既是消息的发生者也是消息的订阅者。这是发生者和订阅者间的过渡桥梁，负责一些中间转换的处理。
Reactor Library从开始到现在已经历经多代。第0代就是java包Observable 接口，也就是观察者模式。具体的发展见下图：
第四代虽然仍然是RxJava2，但是相比第三代的RxJava2，其中的小版本有了不一样的改进，出现了新特性。
Reactor Library主要有两点特性。一是基于回调（callback-based），在事件源附加回调函数，并在事件通过数据流链时被调用；二是声明式编程（Declarative），很多函数处理业务类似，例如map/filter/fold等，这些操作被类库固化后便可以使用声明式方法，以在程序中快速便捷使用。在生产者、订阅者都定义后，声明式方法便可以用来实现中间处理者。
二．Project Reactor
Project Reactor，实现了完全非阻塞，并且基于网络HTTP/TCP/UDP等的背压，即数据传输上游为网络层协议时，通过远程调用也可以实现背压。同时，它还实现了Reactive Streams API和Reactive Extensions，以及支持Java 8 functional API/Completable Future/Stream /Duration等各新特性。下图所示为Reactor的一个示例：
首先定义了一个words的数组，然后使用flatMap做映射，再将每个词和s做连接，得出的结果和另一个等长的序列进行一个zipWith操作，最后打印结果。这和Java 8 Stream非常类似，但仍存在一些区别：
1）Stream是pull-based，下游从上游拉数据的过程，它会有中间操作例如map和reduce，和终止操作例如collect等，只有在终止操作时才会真正的拉取数据。Reactive是push-based，可以先将整个处理数据量构造完成，然后向其中填充数据，在出口处可以取出转换结果。
2）Stream只能使用一次，因为它是pull-based操作，拉取一次之后源头不能更改。但Reactive可以使用多次，因为push-based操作像是一个数据加工厂，只要填充数据就可以一直产出。
3）Stream#parallel()使用fork-join并发，就是将每一个大任务一直拆分至指定大小颗粒的小任务，每个小任务可以在不同的线程中执行，这种多线程模型符合了它的多核特性。Reactive使用Event loop，用一个单线程不停的做循环，每个循环处理有限的数据直至处理完成。
在上例中，大家可以看到很多Reactive的操作符，例如flatMap/concatWith/zipWith等，这样的操作符有300多个，这可能是学习这个框架最大的压力。如何理解如此繁多的操作符，可能一个归类会有所帮助：
1）新序列创建，例如创建数组类序列等；
2）现有序列转换，将其转换为新的序列，例如常见的map操作；
3）从现有的序列取出某些元素；
4）序列过滤；
5）序列异常处理。
6）与时间相关的操作，例如某个序列是由时间触发器定期发起事件；
7）序列分割；
8）序列拉至同步世界，不是所有的框架都支持异步，再需要和同步操作进行交互时就需要这种处理。
上述300+操作符都有如下所示的弹珠图（Marble Diagrams），用表意的方式解释其作用。例如下图的操作符是指，随着时间推移，逐个产生了6个元素的序列，黑色竖线表示新元素产生终止。在这个操作符的作用下，下方只取了前三个元素，到第四个元素就不取了。这些弹珠图大家可以自行了解。
三．Spring Webflux
1.Spring Webflux框架
Spring Boot 2.0相较之前的版本，在基于Spring Framework 5的构建添加了新模块Webflux，将默认的web服务器改为Netty，支持Reactive应用，并且Webflux默认运行在Netty上。而Spring Framework 5也有了一些变化。Java版本最低依赖Java 8，支持Java 9和Java 10，提供许多支持Reactive的基础设施，提供面向Netty等运行时环境的适配器，新增Webflux模块（集成的是Reactor 3.x）。下图所示为Webflux的框架：
左侧是通常使用的框架，通过Servlet API的规范和Container进行交互，上一层是Spring-Webmvc，再上一层则是经常使用的一些注解。右侧为对应的Webflux层级，只要是支持NIO的Container，例如Tomcat，Jetty，Netty或Undertow都可以实现。在协议层的是HTTP/Reactive Streams。再上一层是Spring-Webflux，为了保持兼容性，它支持这些常用的注解，同时也有一套新的语法规则Router Functions。下图显示了一个调用的实例：
在Client端，首先创建一个WebClient，调用其get方法，写入URL，接收格式为APPLICATION_STREAM_JSON的数据，retrieve获得数据，取得数据后用bodyToFlux将数据转换为Car类型的对象，在doOnNext中打印构造好的Car对象，block方法意思是直到回调函数被执行才可以结束。在Server端，在指定的path中进行get操作，produces和以前不同，这里是application/stream+json，然后返回Flux范型的Car对象。传统意义上，如果数据中有一万条数据，那么便直接返回一万条数据，但在这个示例返回的Flux范型中，是不包含数据的，但在数据库也支持Reactive的情况下，request可以一直往下传递，响应式的批量返回。传统方式这样的查询很有可能是一个全表遍历，这会需要较多资源和时间，甚至影响其他任务的执行。而响应式的方法除了可以避免这种情况，还可以让用户在第一时间看到数据而不是等待数据采集完毕，这在架构体验的完整性上有了很大的提升。application/stream+json也是可以让前端识别出，这些数据是分批响应式传递，而不会等待传完才显示。
现在的Java web应用可以使用Servlet栈或Reactive栈。Servlet栈已经有很久的使用历史了，而现在又增加了更有优势的Reactive栈，大家可以尝试实现更好的用户体验。
2.Reactive编程模型
下图中是Spring实现的一个向后兼容模型，可以使用annotation来标注Container。这是一个非常清晰、支持非常细节化的模型，也非常利于同事间的交流沟通。
下图是一个Functional编程模型，通过写函数的方式构造。例如下图中传入一个Request，返回Response，通过函数的方法重点关注输入输出，不需要区分状态。然后将这些函数注册至Route。这个模型和Node.js非常接近，也利于使用。
3.Spring Data框架
Spring Data框架支持多种数据库，如下图所示，最常用的是JPA和JDBC。在实践中，不同的语言访问不同的数据库时，访问接口是不一样的，这对编程人员来说是个很大的工作量。
Spring Data便是做了另一层抽象，使你无论使用哪种数据库，都可以使用同一个接口。具体特性这里不做详谈。
下图展示了一个Spring Data的使用示例。只需要写一个方法签名，然后注解为Query，这个方法不需要实现，因为框架后台已经采用一些技术，直接根据findByFirstnameAndLastname就可以查询到。这种一致的调用方式无疑提供了巨大的方便。
现在Reactive对Spring Data的支持还是不完整的，只支持了MongoDB/Redis/Cassandra和Couchbase，对JPA/LDAP/Elasticsearch/Neo4j/Solr等还不兼容。但也不是不能使用，例如对JDBC数据库，将其转为同步即可使用，重点在于findAll和async两个函数，这里不再展开详述，具体代码如下图所示：
Reactive不支持JDBC最根本的原因是，JDBC不是non-blocking设计。但是现在JavaOne已经在2016年9月宣布了Non-blocking JDBC API的草案，虽然还未得到Java 10的支持，但可见这已经成为一种趋势。
四．总结
Spring MVC框架是一个命令式逻辑，方便编写和调试。Spring WebFlux也具有众多优势，但调试却不太容易，因为它经常需要切换线程执行，出现错误的栈可能已经销毁。当然这也是现今Java的编译工具对WebFlux不太友好，相信以后会改善。下图中列出了Spring MVC和Spring WebFlux各自的特性及交叉的部分。最后也附上一些参考资料。