Chapter 5. Reactive from Top to Bottom
“Everything is a stream” is an often cited Zen of RxJava. In Chapter 4, we learned how to deploy RxJava in some places throughout our codebase. But what you will quickly discover is that truly reactive applications use streams pretty much from top to bottom. This approach simplifies reasoning and makes our application very consistent. Nonblocking applications tend to provide great performance and throughput for a fraction of the hardware. By limiting the number of threads, we are able to fully utilize CPU without consuming gigabytes of memory.
One of the limiting factors of scalability in Java is the I/O mechanism. The java.io package is very well designed with lots of small Input/OutputStream and Reader/Writer implementations that decorate and wrap one another, adding one functionality at a time.
As much as I like this beautiful separation of concerns, standard I/O in Java is entirely blocking, meaning every thread that wishes to read or write from a Socket or File must wait indefinitely for the result.
Even worse, threads stuck at an I/O operation due to slow network or an even slower spinning disk are hard to interrupt.
Blocking on its own is not an issue, when one thread is blocked, others can still interact with remaining open Sockets. But threads are expensive to create and manage, and switching between them takes time. Java applications are perfectly capable of handling tens of thousands of concurrent connections, ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access