Flowable

 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())指定背压策略
  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Flowable 是一个基于 Reactive Streams 标准的响应式编程库,它是 RxJava 2.x 的背压实现。Flowable 提供了一种异步、非阻塞的编程模型,可以处理大量的数据流,并且能够有效地处理背压问题。 在面试中,可能会涉及到以下几个方面的问题: 1. 什么是 FlowableFlowable 是 RxJava 2.x 中的一个类,它实现了 Reactive Streams 标准,用于处理异步数据流。与 Observable 不同,Flowable 支持背压(Backpressure)机制,可以控制数据流的速率,避免数据产生速度过快而导致的内存溢出等问题。 2. Flowable 与 Observable 的区别是什么? Flowable 和 Observable 都是 RxJava 中用于处理数据流的类,但它们之间有一些区别。最主要的区别是 Flowable 支持背压机制,而 Observable 不支持。Flowable 在处理大量数据流时更加稳定,能够控制数据的生产和消费速率,避免内存溢出等问题。 3. 如何处理 Flowable 的背压问题? Flowable 提供了多种处理背压问题的策略,可以根据实际需求选择合适的策略。常见的策略包括: - BackpressureStrategy.BUFFER:缓存所有数据,直到消费者准备好接收。 - BackpressureStrategy.DROP:如果消费者无法及时处理数据,丢弃一部分数据。 - BackpressureStrategy.LATEST:只保留最新的数据,丢弃旧的数据。 - BackpressureStrategy.ERROR:如果消费者无法及时处理数据,抛出异常。 4. Flowable 的使用场景有哪些? Flow 适用于处理大量的异步数据流,特别是在数据产生速度和消费速度不一致的情况下。常见的使用场景包括网络请求、数据库查询、文件读写等需要处理大量数据的场景。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值