Flowable.create(new FlowableOnSubscribe<Integer>() {
@Override
public void subscribe(FlowableEmitter<Integer> e) {
for (int i = 1; i <= 1000000; i++) {
if(e.requested()==0)continue;
e.onNext(i);
}
e.onComplete();
}
}, BackpressureStrategy.BUFFER).subscribeOn(Schedulers.io())
.observeOn(Schedulers.io())
.subscribe(new Subscriber<Integer>() {
@Override
public void onSubscribe(Subscription s) {//响应式拉取数据
s.request(Long.MAX_VALUE);每次拉取数据的个数//不论设置多少上游缓存池初始值就是128 上游会一直发送数据直到发送完毕 // 但是我们设置必须要大于发射的数据值 才能保证数据全部接受完 所以设置大于上游数据值即可 暂时设置最大值
// s.request与发射器e.request不一样 代表获取缓存池的可使用数据
//下面是另一个大神测试出来的结果,我只是大概验证了一下
我们发现通过e.requested()获取到的上游当前未完成请求数量并不是一直递减的, 在递减到33时,又回升到了128.而回升的时机正好是在下游接收了96条数据之后。我们之前说过,异步缓存池中的数据并不是向下游发射一条便清理一条,而是每等累积到95条时, 清理一次。通过e.requested()获取到的值,正是在异步缓存池清理数据时,回升的。 也就是,异步缓存池每次清理后,有剩余的空间时,都会导致上游未完成请求数量的回升,这样既不会引发背压异常,也不会导致数据遗失。上游在发送数据的时候并不需要考虑下游需不需要,而只需要考虑异步缓存池中是否放得下,放得下便发,放不下便暂停。所以,通过e.requested()获取到的值,并不是下游真正的数据请求数量, 而是异步缓存池中可放入数据的数量。数据放入缓存池中后,再由缓存池按照下游的数据请求量向下传递,待到传递完的数据累积到95条之后, 将其清除,腾出空间存放新的数据。如果下游处理数据缓慢,则缓存池向下游传递数据的速度也相应变慢,进而没有传递完的数据可清除, 也就没有足够的空间存放新的数据,上游通过e.requested()获取的值也就变成了0, 如果此时,再发送数据的话,则会根据BackpressureStrategy背压策略的不同, 抛出MissingBackpressureException异常,或者丢掉这条数据。 所以上游只需要在e.requested()等于0时,暂停发射数据,便可解决背压问题。
}
@Override
public void onNext(Integer integer) {
try {
Thread.sleep(10*1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Log.e("TAG","接受"+integer + "个\n");
}
@Override
public void onError(Throwable t) {
Log.e("TAG",""+t.getMessage() + "\n");
}
@Override
public void onComplete() {
}
});
}
// ERROR, 抛出背压异常
// BUFFER, //缓存池没有限制 直至oom 但是速率要满很多
// DROP, 丢弃
// LATEST 取最后一条数据必定放入缓存池
MISSING 此策略表示,通过Create方法创建的Flowable没有指定背压策略,
不会对通过OnNext发射的数据做缓存或丢弃处理,需要下游通过背压操作符
(onBackpressureBuffer()/onBackpressureDrop()/onBackpressureLatest())指定背压策略
Flowable
最新推荐文章于 2024-10-05 20:10:25 发布