来自C＃，当我使用RX并且有背压时，项目将不断添加到内部队列，直到应用程序内存不足（据我所知）。
在ReactiveX（RXJava）中，看起来他们采取了不同的立场，在背压开始建立时抛出异常。
这意味着我必须使用onBackpressureBuffer()之类的内容，并在subscribe()中调用Subscriber<? super T>传递，这会使请求在流中释放压力。
也许是因为我使用了RX.NET方法来解决这个问题，但这对我来说似乎很精神。
首先，我是否理解正确？
其次，无论如何我可以＆＃34;禁用＆＃34;这个功能，所以它的行为方式与RX.NET相同，因为我不想通过检查是否已实施其中一个背压操作符来查看我是否有subscribe()调用复杂化是否致电request()。
答案 0 :(得分：8)
在scala中（我不懂Java语法，但方法调用会一样），你只需要转
fastHotObservable.subscribe(next => slowFunction(next))
到
fastHotObservable.onBackpressureBuffer.subscribe(next => slowFunction(next))
应该这样做。当然，运行它时必须有一段时间不活动，因此该过程偶尔会有时间赶上并处理缓冲元素。
我不认为这是精神上的，我觉得很好，你可以选择自己处理未处理背压的策略，而不是强迫你选择一个。我也更喜欢明确指定它。
事实上，RX.net使用的策略并不总是最好的。我最近一直在使用一些onBackpressureDrop来忘记鼠标移动我没有时间处理，我很高兴我可以避免让它们很容易缓冲。
答案 1 :(得分：5)
如果源Observable不支持背压，则会发生与背压相关的异常，很少有与时间相关的运算符具有此行为，并且许多Observable都是针对0.20之前的版本实现的。另一方面，订阅者默认以无限制模式运行（他们请求Long.MAX_VALUE并且从不打扰请求更多）。对于这种情况，大多数操作员都有快速通道，或者只是不干扰背压。
例外的最常见来源是observeOn和merge运算符。你需要重新实现它们。 ObserveOn可以切换到无界队列，合并可以完全跳过队列。这两个运营商中的Here is an example implementation。
答案 2 :(得分：0)
大多数情况下，正确的方法是使用像onBackPressureDrop这样的良好背压策略。但是，记住这样做很容易出错。
当我们转换为RxJava2时，我们意识到大约100％的Observable只想使用onBackPressureBuffer。鉴于这种情况，我们增加了rx.ring-buffer.size尺寸，防止了所有背压崩溃并继续我们的生活。