Scheduler

If you want to introduce multithreading into your cascade of Observable operators, you can do so by instructing
those operators (or particular Observables) to operate on particular Schedulers.

Some ReactiveX Observable operators have variants that take a Scheduler as a parameter. These instruct the
operator to do some or all of its work on a particular Scheduler.

By default, an Observable and the chain of operators that you apply to it will do its work, and will notify
its observers, on the same thread on which its Subscribe method is called. The
SubscribeOn operator changes this behavior by specifying a different Scheduler
on which the Observable should operate. The ObserveOn operator specifies a
different Scheduler that the Observable will use to send notifications to its observers.

As shown in this illustration, the SubscribeOn operator designates which thread
the Observable will begin operating on, no matter at what point in the chain of operators that operator is
called. ObserveOn, on the other hand, affects the thread that the Observable
will use below where that operator appears. For this reason, you may call
ObserveOn multiple times at various points during the chain of Observable
operators in order to change on which threads certain of those operators operate.

meant for computational work such as event-loops and callback processing; do not use this scheduler for I/O (use Schedulers.io( ) instead); the number of threads, by default, is equal to the number of processors

meant for I/O-bound work such as asynchronous performance of blocking I/O, this scheduler is backed by a thread-pool that will grow as needed; for ordinary computational work, switch to Schedulers.computation( ); Schedulers.io( ) by default is a CachedThreadScheduler, which is something like a new thread scheduler with thread caching

queues work to begin on the current thread after any already-queued work

Default Schedulers for RxGroovy Observable Operators

Some Observable operators in RxGroovy have alternate forms that allow you to set which Scheduler the
operator will use for (at least some part of) its operation. Others do not operate on any particular
Scheduler, or operate on a particular default Scheduler. Those that have a particular default Scheduler
include:

Test Scheduler

The
TestScheduler allows you to exercise fine-tuned manual control over how the
Scheduler’s clock behaves. This can be useful for testing interactions that depend on precise
arrangements of actions in time. This Scheduler has three additional methods:

meant for computational work such as event-loops and callback processing; do not use this scheduler for I/O (use Schedulers.io( ) instead); the number of threads, by default, is equal to the number of processors

meant for I/O-bound work such as asynchronous performance of blocking I/O, this scheduler is backed by a thread-pool that will grow as needed; for ordinary computational work, switch to Schedulers.computation( ); Schedulers.io( ) by default is a CachedThreadScheduler, which is something like a new thread scheduler with thread caching

queues work to begin on the current thread after any already-queued work

Default Schedulers for RxJava 1.x Observable Operators

Some Observable operators in RxJava have alternate forms that allow you to set which Scheduler the operator
will use for (at least some part of) its operation. Others do not operate on any particular Scheduler, or
operate on a particular default Scheduler. Those that have a particular default Scheduler include:

Using Schedulers

Aside from passing these Schedulers in to RxJava Observable operators, you can also use them to
schedule your own work on Subscriptions. The following example uses
the schedule method of
the Scheduler.Worker class to schedule work on the newThread Scheduler:

The Worker is also a Subscription and so you can (and should, eventually) call
its unsubscribe method to signal that it can halt work and release resources:

worker.unsubscribe();

Delayed and Periodic Schedulers

You can also use a version of schedule
that delays your action on the given Scheduler until a certain timespan has passed. The
following example schedules someAction to be performed on
someScheduler after 500ms have passed according to that Scheduler’s clock:

someScheduler.schedule(someAction, 500, TimeUnit.MILLISECONDS);

Another Scheduler method
allows you to schedule an action to take place at regular intervals. The following example
schedules someAction to be performed on someScheduler after 500ms
have passed, and then every 250ms thereafter:

Test Scheduler

The
TestScheduler allows you to exercise fine-tuned manual control over how the
Scheduler’s clock behaves. This can be useful for testing interactions that depend on precise
arrangements of actions in time. This Scheduler has three additional methods: