阅读 Subscriber 的实现中关于 backpressure 的部分

rxjava 中最具有挑战性的设计就是 backpresure 。例如 zip 操作符,合并两个 Observable A 和 B 。如果 B 的产生速度比 A 快,那么就需要不停的缓存 B 多余生成出来的数据,这样内存就无限增长了。 backpressure 的机制就是让 B 生成慢一点。

目前为止,我看到 rxjava 的设计是很丑陋的。这种机制是没有强制性的。更糟糕的是, rxjava 暴露了 Observable.create(OnSubscribe<?> onSubscribe) 这个函数,如果不了解这个机制,上来"想当然" 的实现一个 OnSubscribe ,而不管 backpressure 机制,很容易产生 MissingBackpressureException

“想当然” 不是使用者的错,而是库的设计者的错误。可惜的是,太多用户重度使用这个 Observable.create(OnSubscribe<?> onSubscribe) 函数,为了保证现有程序能够继续运行,就不能隐藏这个函数。于是,我们在注释中,可以看到下面一段话

<strong>This method requires advanced knowledge about building operators and data sources; please consider other standard methods first; </strong>

本文试图得到 “advanced knowledge” 。

下面是 backpressure 的协议是如何建立的。

someObservable.subscribe(new Subscriber<T>() {
    @Override
    public void onStart() {
      request(1);
    }

    @Override
    public void onCompleted() {
      // gracefully handle sequence-complete
    }

    @Override
    public void onError(Throwable e) {
      // gracefully handle error
    }

    @Override
    public void onNext(T n) {
      // do something with the emitted item "n"
      // request another item:
      request(1);
    }
});

可见底层 subscriber 在刚刚启动的时候,发起流控请求 onStart , request(1) 。告诉楼上的,哥们,别整太多,一个数据就够了,多了处理不了。
onNext 中,先处理数据,处理完了,告诉楼上的,接着往下放数据,别多,就一个。

这里需要注意的是,不能再 request(n) 函数里面产生数据,否则递归调用 onNext ,可能导致爆栈了。

我们看看 Subscriber 是如何实现这个协议的。

public abstract class Subscriber<T> implements Observer<T>, Subscription {
// represents requested not set yet
private static final long NOT_SET = Long.MIN_VALUE;
private final SubscriptionList subscriptions;
private final Subscriber<?> subscriber;
private Producer producer;
private long requested = NOT_SET; // default to not set
}

本文重点关注 backpressure ,只看和这个相关的变量

  • NOT_SET 表示无效的请求数据量。或者说,还 Subscriber 没有提供请求的数据量时的状态。
  • subscriber ,如果这个值不为 null,那么把 backpressure 相关的处理,交给这个 subscriber 处理。有大多数很多操作符,自己并不能很好的处理这种过载,需要一层层向上传递,一直到数据源,只有产生数据的地方,才能比较好的处理,因为在那里,可以很容易的少产生一些数据。
  • producer 如果本 subscriber 可以处理,那么代理给 producer 来处理。
  • requested ,计数器,记录楼下的请求多少数据。
    • 如果是 NOT_SET ,就是说楼下还不知道请求多少。
    • 如果是 MAX_LONG ,就是说楼下来者不拒,不怕 overload
    • 如果是其他值,就是说楼下的最多能处理多少数据。
 protected final void request(long n) {
       // if producer is set then we will request from it
       // otherwise we increase the requested count by n
       if (producer != null) {
            producer.request(n);
       } else {
            requested = requested + n;
       }  
}

这个函数被我简化了,去掉了关于线程安全的部分。这样代码的可读性好多了。

  • 就是说如果有 producer ,那么计数的功能就交给 producer 了。
  • 如果没有,那么 requested 用来计数。

这里简化了代码,去掉了 requested 溢出的处理,就是说当 requested + nLONG_MAX 还要大的时候,会防止其变成负数。

public void setProducer(Producer p) {
    boolean passToSubscriber = subscriber != null && requested == NOT_SET;
    producer = p;
    if (passToSubscriber) {
        subscriber.setProducer(producer);
    } else {
        if (requested == NOT_SET) {
            producer.request(Long.MAX_VALUE);
        } else {
            producer.request(requested);
        }
    }
}

同样,这里去掉了关于线程安全的代码。

个人认为,setProducer 这个函数名字起的不好,因为这个函数除了设置 producer 成员变量之外,还会调用 produce.request 函数。

再来分析一下这个 setProducer 函数

  • 底层是否掉用过本层的 request(n)
    • 如果调用过,requested != NOT_SET,意味着底层出发了流控请求。
    • 如果没有调用过,requested == NOT_SET,意味着底层没有出发了流控请求。
  • producer 是真正处理流控的逻辑。subscriber 把流控逻辑交给 producer处理。如果没有 producer , subscriber 也就只能简单的计数,根本处理不了流控。
  • 如果在触发流控请求之前,setProducer 函数被调用,那么要看本层是否愿意处理这个流控请求。
    • 如果成员变量 subscriber 不是空,那么表示本层 Subscriber 不愿意,或者不能够处理好这个 backpressure ,交个上层处理 subscriber.setProducer(producer)
    • 上层如果不产生数据,本层的 OnNext 也不会触发。从而达到了流控的目的。这样一层一层往上传,一直要交给数据源那一层才好处理。换句话说,如果你需要创建了一个 Observable,例如你写了一个新的 operator ,但是不能很好地处理 backpressure ,那么最好往上传递。在 OnSubscribe 的时候,把本层 subscriber和上层 subscriber 串起来。
    • 如果本层愿意处理 backpressure 请求,那么就调用 procuder.request 处理请求。
  • 如果是在触发流控请求之后, setProducer 被调用,那么无论本层是否愿意,都要处理这个请求。

代码虽短,这个逻辑太复杂了。

小结

这里刚刚是一个皮毛,真正的 producer 处理流控逻辑还没有提到。下次有时间,专门分析一个真正的流控逻辑。

同时,我们也看到,最好不要自己写 operator 和 OnSubscribe ,而是调用现成的 from 系列函数, createSync 之类的提供流控的工厂方法,构造 Observable。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容