ReactiveX/RxJava V3.0.0版本
最近使用加载文本数据到内存中，提供web服务的方式，由于文件比较大，导致load数据非常消耗内存，4G的文本，每行数据封装对象存在hashmap中运行期竟然消耗了23G内存。后改用JDK8的stream.map.foreach的方式，效果也不好，最终被要求用rxJava来处理数据流。
GITHub原文：https://github.com/ReactiveX/RxJava，
API文档：http://reactivex.io/documentation/operators.html#utility
现摘取部分内容稍作翻译，权当读书笔记了。
RXjava是一个基于事件驱动的异步库，使用的观察者模式（消费订阅模式）。
截至目前已经到3.x.x版本了。1.x已经在2018年3月31日停止维护，2.x版本截止到2021年2月28日只接受bug修正，新特性也不会在这个系列出现了。
GitHub上介绍了如何使用Gradle编译，由于我是使用maven，就只贴出maven的依赖方式：
io.reactivex.rxjava3
rxjava
3.0.0
Hello World
package rxjava.examples;
import io.reactivex.rxjava3.core.*;
public class HelloWorld {
public static void main(String[] args) {
Flowable.just("Hello world").subscribe(System.out::println);
}
}区别于之前的版本，3.0之后的组件类都移动到io.reactivex.rxjava3，核心类和接口都移动到io.reactivex.rxjava3.core，不过好像也没什么人在乎这个。
Base Class
io.reactivex.rxjava3.core.Flowable: 0..N flows, supporting Reactive-Streams and backpressureio.reactivex.rxjava3.core.Observable: 0..N flows, no backpressure,io.reactivex.rxjava3.core.Single: a flow of exactly 1 item or an error,io.reactivex.rxjava3.core.Completable: a flow without items but only a completion or error signal,io.reactivex.rxjava3.core.Maybe: a flow with no items, exactly one item or an error.
专有名词
上游和下游
RxJava中的数据流包括一个数据源、0个或多个中间步骤，然后是一个数据消费者或组合子步骤：
source.operator1().operator2().operator3().subscribe(consumer);
source.flatMap(value -> source.operator1().operator2().operator3());以上面那段代码，我们把自己想象成是operator2，那么左侧的指向数据源头的就叫做上游，右侧的指向消费者的就是下游。我们经常把每段操作都换行写：
source
.operator1()
.operator2()
.operator3()
.subscribe(consumer)会动的对象
在RxJava的文档里，emission，emits，item，event，signal，data，message都被认作是近义词，表示了对象沿着数据流移动的状态。
backpressure
这个概念有点难理解，很多人把它译作“背压”，“反压”，其实这个“压”我觉得刚开始确实不好理解，不如直接看作是feedback（反馈）。
当数据流中有异步的操作步骤时（source和subscribe中间的operator有异步的，operator暂时叫做步骤），每个步骤的处理能力以及处理速度都不同。它们常表现为由于临时缓冲或需要跳过/删除数据而导致内存使用量增加，为了避免这些步骤过多，就应用了所谓的反压（反馈）机制。反压机制是由步骤来表明可以处理多少数据的数据流处理格式。允许在通常无法知道上游将向数据流发送多少项的情况下限制数据流的内存使用。
在RxJava中，Flowable类是支持反压机制的，Observable不支持。其他类型，Single，Maybe，Completable也不支持背压。
装配时状态
我们把通过使用多个operator创建数据流的过程叫做装配时：
Flowable flow = Flowable.range(1, 5)
.map(v -> v * v)
.filter(v -> v % 3 == 0)
; 此刻，数据流只是准备好了，但是它还没有流动起来，也没有什么负面作用。
订阅时状态
这是在flow上面调用subscribe方法时建立链式处理的一个临时状态。
flow.subscribe(System.out::println)在这种状态下，阅触发后，一些阻塞代码或者会动的对象会立刻发送。
运行时状态
当流已经开始发送会动的对象时的状态。
Observable.create(emitter -> {
while (!emitter.isDisposed()) {
long time = System.currentTimeMillis();
emitter.onNext(time);
if (time % 2 != 0) {
emitter.onError(new IllegalStateException("Odd millisecond!"));
break;
}
}
})
.subscribe(System.out::println, Throwable::printStackTrace);简单的后台计算
一个很普通的场景就是用一个后台线程去做一些计算或者网络请求，然后由另一个前端线程来显示请求结果：
import io.reactivex.rxjava3.schedulers.Schedulers;
Flowable.fromCallable(() -> {
Thread.sleep(1000); // imitate expensive computation
return "Done";
})
.subscribeOn(Schedulers.io())
.observeOn(Schedulers.single())
.subscribe(System.out::println, Throwable::printStackTrace);
Thread.sleep(2000); // <--- wait for the flow to finish这种链式调用风格称作 fluent API，和构建者模式有点类似。然而RxJava的每个返回的对象都是不可变的（独立的），每个步骤都会返回一个新的增加了新的行为的Flowable对象。为了解释这一点，上面的代码可以写成这样：
Flowable source = Flowable.fromCallable(() -> {
Thread.sleep(1000); // imitate expensive computation
return "Done";
});
Flowable runBackground = source.subscribeOn(Schedulers.io());
Flowable showForeground = runBackground.observeOn(Schedulers.single());
showForeground.subscribe(System.out::println, Throwable::printStackTrace);
Thread.sleep(2000); 其实，你可以通过subscribeOn，把密集型计算或者阻塞IO放到其它线程中。一旦数据处理完成，就可以通过observeOn把处理结果显示到界面上。
Scheduler（调度器）
RxJava中的operators没有直接使用线程，或者线程池，但是使用了被称作调度器的东西，它抽象了统一API背后的并发。在RxJava3中有一些标准的调度器，可以通过Schedulers工具类访问。
Schedulers.computation(): 在后台的固定数量的专用线程上运行计算密集型工作。大多数异步operators都用这个调度器作为它们默认的调度器。Schedulers.io(): 在一组动态变化的线程上运行IO或者阻塞operatorSchedulers.single(): 以单线程的先进先出的方式运行Schedulers.trampoline(): 以有序的先进先出的方式在一协程中运行工作，通常用于测试目的。
值得一提的是，还可以通过Schedulers.from(Executor)的方式把线程池包装成Scheduler。
默认的Scheduler是作为一个后台线程运行的，这意味着如果Java主线程退出，后台线程就会停掉，上面代码Thread.sleep(2000)是为了不让主线程退出，否则就看不到计算结果了。
流并发
RxJava中的流本质上是连续的，它们被划分为可以彼此并发运行的处理状态：
Flowable.range(1, 10)
.observeOn(Schedulers.computation())
.map(v -> v * v)
.blockingSubscribe(System.out::println);这个流对计算型调度器上的数字进行平方，从1到10，然后使用主线程拿到结果(更准确地说，是调用blockingSubscribe的线程)。然而 map这个步骤并不是并行的（扩展：并发是指如果单核CPU且只有一个线程，两个请求来了，CPU会按两个请求到的时间片来执行，本质还是时间分片，并没有真的平行的处理多个请求；并行是指请求数不大于CPU核数或者线程数，是真的在平行的处理请求），它是从1到10依次传给同一个线程来计算的，而不是给10个线程去计算然后在合并结果（类似java的fork/join思想）。
并行处理
Flowable.range(1, 10)
.flatMap(v ->
Flowable.just(v)
.subscribeOn(Schedulers.computation())
.map(w -> w * w)
)
.blockingSubscribe(System.out::println);并行处理，也就意味着每个流都要独立处理，然后把结果合并成一个，作为一个流返回。flatMap（flat有扁平化的意思，把map扁平化，也就是D&C了）操作符就是干这个的。
需要注意：flatMap不能保证内部流的顺序。下面有两个可替换的操作符：
concatMap它每次映射并运行一个内部流concatMapEager它将“一次”运行所有内部流，但是输出流将按照这些内部流的创建顺序运行。
另外，flow .parallel()操作符和ParallelFlowable类型有助于实现相同的并行处理模式:
Flowable.range(1, 10)
.parallel()
.runOn(Schedulers.computation())
.map(v -> v * v)
.sequential()
.blockingSubscribe(System.out::println);流的依赖
flatMap能解决很多问题。例如请求第一个服务会返回一个FLowable对象，然后想调用另一个服务并使用第一个服务的result：
Flowable inventorySource = warehouse.getInventoryAsync();
inventorySource
.flatMap(inventoryItem -> erp.getDemandAsync(inventoryItem.getId())
.map(demand -> "Item " + inventoryItem.getName() + " has demand " + demand))
.subscribe(System.out::println); 流的连续性