RxJava2背壓問題描述
場景
簡單一點說，還是引用以前的那個場景，在zip操作符的兩個水管中，如果出現一個水管A發送事件特別快，而另一個水管B發送事件特別慢，那就可能出現發得快的水管A已經發送了大量的事件，而發送慢的水管B才發出一個事件。在這種情況下，zip給我們的每一根水管都弄了一個水缸，用來保存這些事件。水缸的特點是按順序保存，先進來的事件先取出來，這個特點就是隊列，而zip的實現也是采用隊列的形式。使用一個長度為128的隊列來存儲事件。
在這種情況下，隨著內存占用的不斷升高，就會造成內存的溢出，也就是我們所說的oom
- 所謂的背壓Backpressure 就是生產者的生產速率大于消費者的速率后產生的問題
- 同步和異步的情況
當上下游工作在同一個線程中時, 這時候是一個同步的訂閱關系, 也就是說上游每發送一個事件必須等到下游接收處理完了以后才能接著發送下一個事件.
當上下游工作在不同的線程中時, 這時候是一個異步的訂閱關系, 這個時候上游發送數據不需要等待下游接收, 為什么呢, 因為兩個線程并不能直接進行通信, 因此上游發送的事件并不能直接到下游里去, 這個時候就需要一個田螺姑娘來幫助它們倆, 這個田螺姑娘就是我們剛才說的水缸 ! 上游把事件發送到水缸里去, 下游從水缸里取出事件來處理, 因此, 當上游發事件的速度太快, 下游取事件的速度太慢, 水缸就會迅速裝滿, 然后溢出來, 最后就OOM了.
解決方案
Flowable
RxJava提供給我們Flowable、Subscriber分別表示生成者和消費者或者是上、下游
Flowable<Integer> upstream = Flowable.create(new FlowableOnSubscribe<Integer>() {
@Override
public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
Log.d(TAG, "emit 1");
emitter.onNext(1);
Log.d(TAG, "emit 2");
emitter.onNext(2);
Log.d(TAG, "emit 3");
emitter.onNext(3);
Log.d(TAG, "emit complete");
emitter.onComplete();
}
}, BackpressureStrategy.ERROR); //增加了一個參數
Subscriber<Integer> downstream = new Subscriber<Integer>() {
@Override
public void onSubscribe(Subscription s) {
Log.d(TAG, "onSubscribe");
s.request(Long.MAX_VALUE); //注意這句代碼
}
@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");
}
};
upstream.subscribe(downstream);
- 在創建Flowable的時候增加了一個參數，這個參數是用來選擇背壓策略的
- onSubscribe方法中傳給我們的不再是Disposable了，而是Subscription。他倆都是上下游中檢的一個開關。之前我們說調用Disposable的dispose()方法可以切斷水管，同樣的調用Subscription.cancel()也可以切斷水管。不同的地方在于Subscription增加了一個void request(long n)方法，這個方法
s.request(Long.MAX_VALUE)
Flowable在設計的時候采用了一種新的設計思路就是響應式拉取的方式，來解決上下游流蘇不均衡的問題，就是下游會提供處理能力來告知上游，當調用Subscription.request(1)時，就代表下游的處理能力是1個，然后上游就拿出一個來供下游使用。這是完美的解決背壓問題的方法
同樣的如果下游沒有調用request()方法時，上游就會認為下游沒有處理問題的能力，既然下游處理不了，上游又無法繼續等待，所以就會拋出異常，在異步中，由于水缸的大小是有限制的128所以在存放的事件或者數據超過128后，再繼續存數據就會
導致拋出異常。
背壓的處理策略
- BackpressureStrategy.BUFFER 增加Flowable中維持的隊列的容量大小
- BackpressureStrategy.DROP 這種策略就是將無法存儲的事件直接丟棄
- BackpressureStrategy.LATEST 只會保留最新的事件
public static void request() {
mSubscription.request(128);
}
public static void demo3() {
Flowable.create(new FlowableOnSubscribe<Integer>() {
@Override
public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
for (int i = 0; ; i++) {
emitter.onNext(i);
}
}
}, BackpressureStrategy.DROP).subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Subscriber<Integer>() {
@Override
public void onSubscribe(Subscription s) {
Log.d(TAG, "onSubscribe");
mSubscription = 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");
}
});
}
對于使用操作符直接返回的情況，RxJava給我們提供了對應的方法來指定不同的策略
- onBackpressureBuffer()
- onBackpressureDrop()
- onBackpressureLatest()
Flowable.interval(1, TimeUnit.MICROSECONDS)
.onBackpressureDrop() //加上背壓策略
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Subscriber<Long>() {
@Override
public void onSubscribe(Subscription s) {
Log.d(TAG, "onSubscribe");
mSubscription = s;
s.request(Long.MAX_VALUE);
}
@Override
public void onNext(Long aLong) {
Log.d(TAG, "onNext: " + aLong);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
@Override
public void onError(Throwable t) {
Log.w(TAG, "onError: ", t);
}
@Override
public void onComplete() {
Log.d(TAG, "onComplete");
}
});
FlowableEmitter
FlowableEmitter是個接口，繼承Emitter，Emitter里面就是我們的onNext(),onComplete()和onError()三個方法。我們看到FlowableEmitter中有這么一個方法：
long requested()
該方法的作用就是獲取當前外部請求的數量，調用該方法就會獲取到下游所調用的request(count)返回count書
下游調用request(n) 告訴上游它的處理能力，上游每發送一個next事件之后，requested就減一，注意是next事件，complete和error事件不會消耗requested，當減到0時，則代表下游沒有處理能力了，這個時候你如果繼續發送事件，會發生什么后果呢？當然是MissingBackpressureException
- 異步情況
當上下游工作在不同的線程里時，每一個線程里都有一個requested，而我們調用request（1000）時，實際上改變的是下游主線程中的requested，而上游中的requested的值是由RxJava內部調用request(n)去設置的，這個調用會在合適的時候自動觸發。
- 當下游每消費96個事件便會自動觸發內部的request()去設置上游的requested(可以理解為水缸的3/4)的值
