2.x: BoundedReplayBuffer temporarily leaks memory

[nhaarman]

When using Observable.replay(N), the BoundedReplayBuffer keeps up to N+1 items in its buffer. When using replay(1) for example, it keeps a reference to the most recent item, but also the previous, stale item.

Take for example this trivial snippet of code that provides an available Android View as a stream:

val eventsSubject = BehaviorSubject.create<Event<View>>()
val view: Observable<Option<View>> = eventsSubject
    .map { event ->
        when(event) {
            is Attached<View> -> Option.just(event.view)
            is Detached -> Option.empty()
        }
    }
    .replay(1).refCount()

The replay(1) call suggests a single value is cached, but the implementation keeps a strong reference to the previous item as well.
Since this happens as a hidden side effect and rather counter intuitively, it is easy to accidentally leak memory -- even when the client code seems to be careful about it. Especially with Android Views referencing Activity contexts this is problematic.

---

#5282 proposed a fix for this at the cost of an extra Node allocation, which turned out to be unwanted.
The proposed alternative there refers to RxJava2Extensions#cacheLast, but this only emits the very last item, not intermediates.

[akarnokd]

This is a known limitation of the standard replay. Either you can use a ReplaySubject that exposes a cleanupBuffer() method or write a custom replay that does what #5282 proposed. The third option is to not cache things that are lifecycle sensitive.

[nhaarman]

Right, those options seem valid workarounds for now.

I suppose the fact that this happens somewhat surprisingly and hidden in the implementation details makes it feel like it's a bug. Even when being careful and supposedly 'clearing the buffer' by propagating an empty object it still results in leakage. Without knowing that this happens it's easy to accidentally run into this problem and possibly never find out.

[akarnokd]

Item lifecycle is not part of the Reactive Streams model, thus the operator only guarantees one gets up to a number of items when subscribing to cold replay. People have been using LeakCanary to detect such cases and most likely reworked their flow to not use replay.

[nhaarman]

Seems absolutely fair 👍 The pattern above just really 'works well' to go with a 'streams all the way' flow, though I understand this may not be RxJava's responsibility.

[akarnokd]

I plan to resolve this in 3.x via an extra operator parameter.