src/main/java/io/reactivex/Flowable.java
@CheckReturnValue
    @BackpressureSupport(BackpressureKind.FULL)
    @SchedulerSupport(SchedulerSupport.NONE)
    public final Flowable<T> cacheWithInitialCapacity(int initialCapacity) {
        ObjectHelper.verifyPositive(initialCapacity, "initialCapacity");
        return RxJavaPlugins.onAssembly(new FlowableCache<T>(this, initialCapacity));
    }
@CheckReturnValue
    @BackpressureSupport(BackpressureKind.FULL)
    @SchedulerSupport(SchedulerSupport.NONE)
    public final Flowable<T> cacheWithInitialCapacity(int initialCapacity) {
        ObjectHelper.verifyPositive(initialCapacity, "initialCapacity");
        return RxJavaPlugins.onAssembly(new FlowableCache<T>(this, initialCapacity));
    }
Returns a Flowable that subscribes to this Publisher lazily, caches all of its events
and replays them, in the same order as received, to all the downstream subscribers.
<p>
<img width="640" height="410" src="https://raw.github.com/wiki/ReactiveX/RxJava/images/rx-operators/cache.png" alt="">
<p>
This is useful when you want a Publisher to cache responses and you can't control the
subscribe/cancel behavior of all the {@link Subscriber}s.
<p>
The operator subscribes only when the first downstream subscriber subscribes and maintains
a single subscription towards this Publisher. In contrast, the operator family of {@link #replay()}
that return a {@link ConnectableFlowable} require an explicit call to {@link ConnectableFlowable#connect()}.
<p>
<em>Note:</em> You sacrifice the ability to cancel the origin when you use the {@code cache}
Subscriber so be careful not to use this Subscriber on Publishers that emit an infinite or very large number
of items that will use up memory.
A possible workaround is to apply `takeUntil` with a predicate or
another source before (and perhaps after) the application of cache().
<pre><code>
AtomicBoolean shouldStop = new AtomicBoolean();

source.takeUntil(v -&gt; shouldStop.get())
.cache()
.takeUntil(v -&gt; shouldStop.get())
.subscribe(...);
</code></pre>
Since the operator doesn't allow clearing the cached values either, the possible workaround is
to forget all references to it via {@link #onTerminateDetach()} applied along with the previous
workaround:
<pre><code>
AtomicBoolean shouldStop = new AtomicBoolean();

source.takeUntil(v -&gt; shouldStop.get())
.onTerminateDetach()
.cache()
.takeUntil(v -&gt; shouldStop.get())
.onTerminateDetach()
.subscribe(...);
</code></pre>
<dl>
<dt><b>Backpressure:</b></dt>
<dd>The operator consumes this Publisher in an unbounded fashion but respects the backpressure
of each downstream Subscriber individually.</dd>
<dt><b>Scheduler:</b></dt>
<dd>{@code cacheWithInitialCapacity} does not operate by default on a particular {@link Scheduler}.</dd>
</dl>
<p>
<em>Note:</em> The capacity hint is not an upper bound on cache size. For that, consider
{@link #replay(int)} in combination with {@link ConnectableFlowable#autoConnect()} or similar.

@param initialCapacity hint for number of items to cache (for optimizing underlying data structure)
@return a Flowable that, when first subscribed to, caches all of its items and notifications for the
benefit of subsequent subscribers
@see <a href="http://reactivex.io/documentation/operators/replay.html">ReactiveX operators documentation: Replay</a>