话题

通过上一篇我们分析了RxJava的订阅，以及RxJava常见的面试问题，还没有看上一篇点这里RxJava面经一，拿去，不谢!。在上一篇我们分析过多次调用subscribeOn只有第一次调用的时候有效，原因是因为最开始调用的subscribeOn返回的observable会把后面执行的subscribeOn返回的observable给覆盖了，因此我们感官的是只有第一次的subscribeOn能生效。实际中间每一个Observable生成的时候还是会有指定的线程的，只是在最上游的observable只接收第一次的subscribeOn指定的线程，那么我们可以通过doOnSubscribe监测中间的observable确实有自己的线程，这是我们这节探讨的话题。

前一节分析了通过observeOn指定了紧跟其后的observer的线程,如果我们多次调用observeOn，其实是最后一次observeOn才有效指定observer的线程，那我们可以通过doOnNext来监听每一次的observeOn线程的切换，这是我们这节探讨的话题。

如果我们没指定observer的线程，只指定了observable的线程，则observer的线程则会跟observable的线程一起走的，也就是我们只设置了subscribeOn，而没有设置observeOn的情况。这是我们这节探讨的话题。

上一节我们简单的提过背压，那么背压是什么呢，以及Flowable怎么能控制背压也是我们这节讨论的话题。

这节探讨的话题

• doOnSubscribe是怎么做到监听中间的observable的线程？
• doOnNext是怎么做到监听每一次observeOn线程的切换，以及map的apply方法的线程有谁控制？
• 如果不指定observer的线程，也就是指设置subscribeOn，而不设置observeOn，那observer的线程是什么样的？
• 背压是什么，以及Flowable怎么能控制背压？

doOnSubscribe的监听

在上一节我们介绍过subscribeOn是控制上游的observable在哪个线程执行，关于怎么控制上游的observable可以看我上篇文章RxJava面经一，拿去，不谢!，那如果多次执行subscribeOn的时候，Observable接收的是第一次的subscribeOn指定的线程，因为每次设置都会被上一层subscribeOn设置的线程所覆盖了，这里的覆盖是对于最上游的Observable而言的，中间生成的Observable其实是有线程切换的，我们可以通过doOnSubscribe来监听每一次subscribeOn线程的切换，我们还是拿例子来说：

image

image

那什么时候doOnSubscribe的内部类Consumer的accept方法什么调用呢？

我们直接看上面的图，它是在上一个Observable，也就是doOnSubscribe生成的ObservableDoOnLifecycle里面的装饰observer(DisposableLambdaObserver)监听到订阅的时候调用的。而在该例子中②号、④号通过doOnSubscribe生成的observable的上游observable是subscribeOn生成的，而subscribeOn最终是生成了ObservableSubscribeOn的observable，在它的订阅里面是直接给下游的observer添加订阅监听了：

image

所以由上面可知②号处的doOnSubscribe打印是在③号上游的subscribeOn发生订阅的时候，所以它最先打印出结果，再一次是④号打印出结果，最后是最上游的observable的订阅打印。那每一处的doOnSubscribe中accept接收到的线程是怎么回事呢，这个我先说结论，是跟它下面的subscribeOn指定的线程保持一致。所以②号处打印是①号处指定的线程，④号是③号处指定的线程打印，后面我们分析doOnSubscribe时候说。

上一节我们知道subscribeOn是指定它上游的observable订阅发生的线程，而doOnSubscribe操作符最终也是生成了一个ObservableDoOnLifecycle的observable，所以可以这么说ObservableDoOnLifecycle的订阅发生的线程是由紧跟它后面的subscribeOn指定的线程所决定的。

而在ObservableDoOnLifecycle的订阅方法中，它是直接订阅了上游的observable，在上面示例中也就是第二个observable，ObservableDoOnLifecycle的subscribeActual方法如下：
[图片上传失败...(image-5c5f67-1607864098311)]
上一篇介绍了在每一个Observable的订阅方法中，会先创建装饰的observer，并且把下游的observer传到创建的装饰的observer中，接着会给下游的observer添加订阅的回调，接着会给上游的observable添加订阅，而在此处的ObservableDoOnLifecycle订阅方法中先是创建了DisposableLambdaObserver的装饰observer，接着给上游的observable添加订阅。那给下游的obserer添加订阅的监听呢，这就放在了DisposableLambdaObserver的装饰observer的onSubscribe中了。

由于上面我们通过doOnSubscribe生成最下游的observable(ObservableDoOnLifecycle)的订阅线程是io线程，所以它的上游observable也是io线程，我们还没分析完doOnSubscribe传进去的Consumer的accept方法发生的线程，这个需要我们看下上面分析的ObservableDoOnLifecycle订阅中创建的装饰DisposableLambdaObserver：

image

上面一上来就是给传进来的Consumer执行了accept的回调，紧接着给下游的observer添加订阅的监听，方便下游的observer能收到订阅的回调啊，是不是这么回事呢？

那此处装饰的observer(DisposableLambdaObserver)订阅监听是由谁发起的呢，肯定是上游的observable开始订阅的时候发起的下游observer订阅监听啊，而上面我们分析了此处的上游observable订阅线程是由紧挨doOnSubscribe的subscribeOn决定的，所以此处不难看出最终doOnSubscribe中的consumer监听的是subscribeOn指定上游的observable订阅过程中发生的线程，大家可以多理解这句话!!!

下面画张图补补脑：

image

doOnSubscribe小节

上面分析在没有结合源码的情况下，不好分析，整体就是subscribeOn会指定它上游的observable线程，而它上游又正好是doOnSubscribe生成的observable，该observable是ObservableDoOnLifecycle，在它的订阅里面又直接去订阅了它上游的observable，所以此时doOnSubscribe的上游observable线程也是doOnSubscribe它下面的subscribeOn指定的，而doOnSubscribe的上游observable是subscribeOn生成的，它是ObservableSubscribeOn，在它的订阅里面是直接监听了下游的observer订阅回调，也就是doOnSubscribe生成的ObservableDoOnLifecycle订阅中生成的装饰DisposableLambdaObserver，它的订阅监听会调用doOnSubscribe传进来的Consumer的accept方法。

所以这就是多次调用subscribeOn可以通过doOnSubscribe来做线程切换的监听。

doOnNext监听observeOn线程的切换，map的apply方法的线程由谁控制？

首先我们还是通过例子来回答上面你的问题，先来看doOnNext的使用：

image

关于doOnNext其实很好理解，发射数据因为是从上游的observable到下游的observable，而observeOn是指定下游的observer发射数据的线程，这个我在上一篇讲过，而doOnNext实际生成的是一个ObservableDoOnEach的observable，在该订阅方法中，会生成装饰的observer，也就是DoOnEachObserver，所以observeOn实际是控制了DoOnEachObserver发射数据的线程，而在它发射onNext数据的时候，会调用onNext传进来的Consumer的accept方法：

image

observable里面还有onComplete、onError的监听，他们最终都是生成了ObservableDoOnEach的observable

image

doOnNext小节

doOnNext中是通过传进去的Consumer作为上游发射数据过来的监听，在上游observable发射数据的时候，会执行doOnNext的Consumer的accept方法，所以在上面多次通过observeOn指定线程的时候，可以通过doOnNext拿到切换线程的。

所以这就是多次调用observeOn可以通过onNext来做线程切换的监听。

关于map的apply方法的线程由谁来控制，我们这块直接看map的observable，它是一个ObservableMap：

image

image

image

而在每一个subscribeOn发射数据的时候不会改变线程，所以map的线程会保持最上游的observable的线程，也就是io线程，所以打印会有如下：

image

既然subscribeOn不会改变发射数据的线程，导致多次subscribeOn不会改变map的线程，所以只会跟最上游的observable发射数据的线程保持一致，那我们如果中间插入observeOn呢，下面来看下这个例子：

image

image

其他情况大家可以尝试，比如多次指定observeOn线程，看map最终的线程如何

map小节

map将传进去的function作为上游发射数据过来的监听，在上游observable发射数据的时候，会执行function的apply方法来达到转换数据的目的，所以map中function的apply方法是跟上游的observable发射数据的线程有关。

如果不指定observer的线程，也就是指设置subscribeOn，而不设置observeOn，那observer的线程是什么样的？

我感觉理解了整个订阅的过程，其实理解这个问题一点都不难，既然subscribeOn是指定上游的observable的线程，那么最终的上游observable发射数据时候的线程也会被紧挨着它的subscribeOn指定的线程有关啊，并且不设置observeOn指定下游的observer的线程，那么observer的线程是不是跟最上游observable发射数据的线程保持一致啊。

背压是什么，以及Flowable怎么能控制背压？

它是指由于上游的observable发射数据太快，下游observer接收数据跟不上来导致的一种现象。可以形象理解为水坝在存储水的时候为了保持水的平衡，给下游的水库放水，同时会接收上游的水流，如果上游的水流很大，那么水坝中的水位激增，而水坝给下游放水的能力有限，所以就会导致水坝中的水漫过水坝。

RxJava1.0背压

注：说到RxJava背压还得从RxJava1.0开始说起，这里分析的RxJava1.0版本源码是在1.3.8版本分析

在RxJava的1.0版本中Observable是支持背压的，只不过它是以异常的形式展示给用户，下面我们拿上游不断地发送数据的例子来模拟下：

Observable.unsafeCreate(new Observable.OnSubscribe<Integer>() {
    @Override
    public void call(Subscriber<? super Integer> subscriber) {
        int i = 0;
        while (true) {
            subscriber.onNext(i);
            i++;
        }
    }
}).subscribe(new Observer<Integer>() {
    @Override
    public void onCompleted() {
    }
    @Override
    public void onError(Throwable e) {
        Log.d(TAG, "onError:" + e.getMessage());
        e.printStackTrace();
    }
    @Override
    public void onNext(Integer integer) {
        Log.d(TAG, "onNext:" + integer);
    }
});

demo1.gif

在我们日志中，没看到下游处理数据处理不过来的问题，也没出现异常信息啊，这不挺好的，没出现背压的情况，看官，别急啊，背压是发生在多线程中的问题，因为在单线程中，发送数据和接收数据都是在一个线程中，所以每次发送数据前得等到下游处理完数据才发送数据。

好吧，说完这么多，我们还是加上多线程吧，我们再来试试：

Observable.unsafeCreate(new Observable.OnSubscribe<Integer>() {
    @Override
    public void call(Subscriber<? super Integer> subscriber) {
        for (int i = 0; ; i++) {
            subscriber.onNext(i);
        }
    }
}).subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread()).subscribe(new Observer<Integer>() {
    @Override
    public void onCompleted() {
    }
    @Override
    public void onError(Throwable e) {
        Log.d(TAG, "onError:" + e.getMessage());
        e.printStackTrace();
    }
    @Override
    public void onNext(Integer integer) {
        Log.d(TAG, "onNext:" + integer);
    }
});

我们在上游发送数据的时候，做了个死循环，然后指定了上游是io线程，下游是main线程，结果还没接收到数据直接报异常了：

image

image

数据能正常接收，如果我们把数据调整到17呢，是不是会发生异常呢：

image

看吧，不用我说啥吧，看来底层是限制了上游发送数据的个数，其实这个是RxJava1.0背压策略的一种机制，通过数量来控制，我们可以在这里找到定义的数量大小：

image

比如我们在发送第17个数据的时候，在获取索引的时候是通过与对接容量16 进行相与得到索引，相与之后得到一个小于16的索引，发现相与之后得到的索引上还有数据，则发送第17个数据放进队列的时候失败，所以直接抛出onError的信息。核心源码在这里：

image

image

image

所以这就是RxJava1.0中背压策略，通过设置上游发送过来的数据的接收队列容量来达到背压。

RxJava2.0背压

注：RxJava运行版本是2.2.20

在RxJava2.0中不再在Observable支持背压，而是通过Flowable来代替了，也就是说Observable中不再通过异常的形式告诉用户了，也就是不抛MissingBackpressureException异常了，下面来看看RxJava2.0正常发送数据的问题：

Observable.create(new ObservableOnSubscribe<Integer>() {
    @Override
    public void subscribe(@NonNull ObservableEmitter<Integer> emitter) throws Exception {
        for (int i = 0; ; i++) {
            emitter.onNext(i);
        }
    }
}).subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread()).subscribe(new Observer<Integer>() {
    @Override
    public void onSubscribe(@NonNull Disposable d) {
    }
    @Override
    public void onNext(@NonNull Integer integer) {
        Log.d(TAG, "onNext：" + integer);
    }
    @Override
    public void onError(@NonNull Throwable e) {
    }
    @Override
    public void onComplete() {
    }
});

memery.gif

虽然说不抛MissingBackpressureException异常了，但是内存占用很糟糕啊，所以针对RxJava2.0的问题，我们有没有处理办法呢，大家会说RxJava2.0不是已经支持Flowable了吗，直接使用它啊，如果让我们自己来处理啊该怎么办呢，首先我们分析背压产生的原因是什么：

• 上游发送的事件太快，下游处理不过来
• 上游发送的事件太多，下游处理不过来

首先针对第一种我们可以让上游发送速度慢点，怎么慢点呢，让io线程每次发送的时候停留一会：

Observable.create(new ObservableOnSubscribe<Integer>() {
    @Override
    public void subscribe(@NonNull ObservableEmitter<Integer> emitter) throws Exception {
        for (int i = 0; ; i++) {
            emitter.onNext(i);
            Thread.sleep(1000);
        }
    }
}).subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread()).subscribe(new Observer<Integer>() {
    @Override
    public void onSubscribe(@NonNull Disposable d) {
    }
    @Override
    public void onNext(@NonNull Integer integer) {
        Log.d(TAG, "onNext：" + integer);
    }
    @Override
    public void onError(@NonNull Throwable e) {
    }
    @Override
    public void onComplete() {
    }
});

[图片上传失败...(image-c600a8-1607864098311)]

图片来自于关于 RxJava 背压

针对第二种的话，我们可以让下游的observer少接收点数据：

Observable.create(new ObservableOnSubscribe<Integer>() {
    @Override
    public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
        for (int i = 0; ; i++) {   //无限循环发事件
            emitter.onNext(i);

        }
    }
}).filter(new Predicate<Integer>() {
    @Override
    public boolean test(Integer integer) throws Exception {
        return integer % 100 == 0;

    }
})
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(new Consumer<Integer>() {
            @Override
            public void accept(Integer integer) throws Exception {

                Log.d(TAG, "" + integer);
            }
        });

[图片上传失败...(image-8f1812-1607864098311)]

图片来自于关于 RxJava 背压

知道了背压产生的原因后，我们再回头看RxJava本身用Flowable来支持背压策略，而且它的策略比较丰富，下面来一一介绍，我们先从Flowable.create入手：

image

public enum BackpressureStrategy {
    
    MISSING,//如果流的速度无法保持同步，可能会抛出MissingBackpressureException或IllegalStateException。
   
    ERROR,//会在下游跟不上速度时抛出MissingBackpressureException。
   
    BUFFER,//上游不断的发出onNext请求，直到下游处理完，也就是和Observable一样了，缓存池无限大，最后直到程序崩溃
   
    DROP,//会在下游跟不上速度时把onNext的值丢弃。
   
    LATEST//会一直保留最新的onNext的值，直到被下游消费掉。
}

在知道了Flowable这多的策略时候，我们先来看看Flowable在单线程下是什么样的：

image

在策略为error情况下，并且没切换线程的时候，直接报io.reactivex.exceptions.MissingBackpressureException: create: could not emit value due to lack of requests错误，该错误是告诉你没对下游的observer设置request的方法，这个是由于在单线程情况下，没默认给observer设置处理数据的能力，也即是个数，所以上游不知道下游的处理能力，直接抛error错误。

下面怎么设置下游处理能力呢：

image

直接下游接收到订阅方法中添加subscription.request(Long.MAX_VALUE)，官方建议我们使用Long.MAX_VALUE，表示告诉上游，下游的处理能力最大，你尽管发送数据给我吧。

那如果上游发送的数据个数大于下游设置的个数呢：

image

可以看到在发送第4个数据的时候，直接抛异常了，因为下游设置的处理能力是3个，每次在发送完一次的时候，会“削弱”，下游的处理数据的能力，等到发送第四个数据的时候，发现下游已经不能再处理了，直接抛异常。

上面都是在error策略，单线程下的结果，那如果在多线程中结果会是咋样呢，还得从几种策略情况来看：

MISSING

image

在多线程下必须设置下游的处理能力，因为在observeOn给下游发送数据的时候需要知道下游能处理数据的个数。上面我们演示的是上游发送128个数据，结果没有像MISSING策略所说的抛出抛出MissingBackpressureException或IllegalStateException异常信息，这是因为Flowable默认认为128个数据是上游发送最多的数据，我们可以通过这里找到定义的数量：

image

底层其实是跟RxJava1.0点的做法是一样的，也是把这个容量作为队列的大小，只不过RxJava1.0的容量是16个，所以再发送第129个数据的时候，会出现队列放满的问题，一旦放满，再往里面放数据就会出现RxJava中定义的各种策略情况，下面我们把发送数据改为129个，看看MISSING会出现什么情况：

image

看到了吧，直接抛io.reactivex.exceptions.MissingBackpressureException: Queue is full?!异常信息。MISSING内部的发射器里面其实啥都没做，它发送异常是在FlowableObserveOn.ObserveOnSubscriber内部类的onNext时候，发现128个大小的队列满了后，给下游的observer发送onError的信息。

ERROR

测试代码我就不贴了，直接把上面上面的BackpressureStrategy.MISSING改为BackpressureStrategy.ERROR

image

其实和MISSING抛出的异常是一样的，只不过异常的message不一样而已。内部通过发送数据的时候定义一个AtomicLong的计数器，每次在给下游发送完一个数据后，会将该计数器减一，等到减到0的时候，直接在上游给下游发送onError的信息。

BUFFER

这个其实跟RxJava2.0的Observable使用没什么区别，输出的容量没有大小限制，也不会像RxJava1.0一样抛异常，请谨慎使用。

DROP

drop是在第一次拿到128个数据后，第二次从队列中拿数据的时候，中间跟不上速度的数据抛弃了，等到下游处理完先前的128个数据的时候，才能接收后面96个数据，至于这里为什么是96个数字，是因为后面的容量减为this.limit = prefetch - (prefetch >> 2);这个大小了，prefetch是128，大家自己算吧：

image

这里从5118....96个数...从5118算起第96个数

DROP是当给下游发送数据的时候，自己有个限流的策略，通过AtomicLong装载的128大小的计数器，每次发送完一个数据后，会将该计数器减一，那如果发送到了128个数据的时候，由于计数器减到0了，等到下游处理完这128个数据的时候，才会把计数器给调整到96，所以中间会出现丢数据的情况，等到下游处理完先前128个数据的时候，上游再次发数据的时候已经不会从129个数开始了，而且发的这96个数是随机的，因为下游处理前面128个数的时间是不确定的。

LATEST

我们先来看latest是什么样的效果，为了要区分和drop的效果，我们将发射数据改为2000的数据量：

Flowable.create(new FlowableOnSubscribe<Integer>() {
    @Override
    public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
        for (int i = 0; i < 2000; i++) {
            emitter.onNext(i);
        }
    }
}, BackpressureStrategy.LATEST).subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread())
        .subscribe(new Subscriber<Integer>() {
            @Override
            public void onSubscribe(Subscription s) {
                Log.d(TAG, "onSubscribe");
                s.request(Long.MAX_VALUE);
                subscription = s;
            }
            @Override
            public void onNext(Integer integer) {
                Log.d(TAG, "onNext: " + integer);
            }
            @Override
            public void onError(Throwable t) {
                Log.w(TAG, "onError: ", t);
            }
            @Override
            public void onComplete() {
                Log.d(TAG, "onComplete");
            }
        });

这里得到的结果会是这样的：

image

它是这么接收数据的：0-127....96个数...最后一个数，latest是先发送0到127的数据，然后中间发送96个数字，这中间会有丢失数据的，而最后会把最后一个数据发送给下游。

latest没有像drop那样通过计数器的形式限制发送数据的速度，而是在发送数据的时候定义了AtomicReference原子类，把数据放在里面，所以它是每次只能存储一个数据，等处理完前面的128个数据的时候，会将AtomicLong定义的128个数量减到0，所以在下游接收完前面的128个数的时候，上游才能给下游发送后面96个数，等到最后的时候会由于缓存的是最后一个数，所以只能发送给下游的只能是最后一个数。

好了，关于背压的几种策略就那么几种，其实我们总结下来：

• MISSION：上游没有限流，在下游里面发现队列满了，给下游发送onError的信息，该信息是io.reactivex.exceptions.MissingBackpressureException: Queue is full?!。
• ERROR:在上游通过限流的形式给下游发送数据，在发现数据量到了128个的时候，会给下游发送onError的信息，该信息是create: could not emit value due to lack of requests。
• DROP:也是在上游通过限流的形式给下游发送数据，在发现数据量到了128的时候，会等下游处理完这128个数据，等到处理完了，继续处理梳理，所以在等的过程中会有数据丢失的问题。
• LATEST:虽然和DROP都是同样的丢数据，但是它两的做法是不一样的，LATEST通过只能放一个数据的容易来给下游发送数据，最开始丢数据基本是一样的，但是LATEST会保留最后一条数据，是因为最后处理数据的时候，容器里面还有一条数据。
• BUFFER:这个跟RxJava2.0普通发送数据是一样的，它不支持背压，上游发送多少数据，下游会接收多少数据，直到发生OOM。

总结

• 介绍了doOnSubscribe监听每次subscribeOn的线程切换
• doOnNext监听每一次observeOn线程的切换，以及map的apply方法的线程是由上游发送数据的observable决定的。
• 如果不指定observer的线程，也就是指设置subscribeOn，而不设置observeOn，那observer的线程跟上游的observable一起走的。
• 介绍了RxJava1.0和RxJava2.0背压的使用，以及他们的区别。

关于Rxjava第二篇文章就介绍完了，如果还有什么不懂的地方可以直接留言问我。

thanks：

• 背压源码分析
• 关于 RxJava 背压