Java NIO

Stream based IO model of Java

Before we take up NIO its important that we refresh our understanding of the stream based IO model. It forms the core to java.io - the fundamental package which "provides for system input and output through data streams and serialization."

Let us analyse the model with focus on data streams as this is where the need of an improved treatment of IO in Java was felt.

Data Stream is a sequence of data units that can be accessed in order. The unit of data is fundamentally either a byte or a UTF-8 encoded character. Now we can either read from a stream or write to it. Any application that requires to read or write data would ultimately function at the level of data streams. A typical program reads data from a "SOURCE" in the form of an "INPUT" stream and delivers it to the "DESTINATION" as an "OUTPUT" stream. This approach generally translates into a loop that reads the input stream and writes to the output stream byte by byte or character by character. The following diagram attempts to elucidate the same:

Implications of this "stream oriented" approach:

1.) We cannot move back and forth. Data stream is actually a continuous flow of data. Unlike an array it is not indexed and the data units (bytes or characters) are not cached anywhere. So we simply cannot traverse the stream at will. If while writing an output stream you suddenly have to rewrite a portion of it, it becomes virtually impossible. Similarly while reading an input stream if you wish to reread a portion of the former half, you are hopelessly stuck. All that you can do to circumvent this is to cache your data in a buffer and then move back and forth. 2.) The thread remains blocked. In java.io the streams are "blocking". That is, if a thread is performing a read or a write operation it shall remain blocked until there is some new data to read or it is finished with the writing of data. More so, that if two threads attempt to read from a single input stream ,one beginning its read() after another the second thread will be forced to begin from where the first one leaves. 3.) Impedance mismatch. As has already been discussed in the previous blog, "impedance mismatch" is linked to the byte-by-byte or character-by-character treatment of data streams by the JVMs. To put it succinctly, the OS carts data in large chunks. These chunks need to be broken down by java.io before they can be used. As a result there is a huge mismatch in the speed with which data can be delivered by the OS to java.io and the speed with which java.io actually processes it further. To quote,Ron Hitchens from Java NIO, "The operating system wants to deliver data by the truckload. The java.io classes want to process data by the shovelful." This indeed appropriately summarises the performance spoiler java.io can sometimes be. 4.) Every connection has its own thread. In the Stream based model each connection (i.e., your input sources or output destinations) will require a separate thread. It is a direct fallout of the blocking nature "java.io" streams. So to deal with multiple connections at a time you shall need multiple threads. One for each. It turns out be a cumbersome when the amount of data in consideration is small and the connections are in thousands. 5.) Overhead generated by each IO request. Well this is one of the factors that result in the aforementioned mismatch of impedance. While the program loops the data byte-by-byte (or character-by-character) each such read or write request often triggers expensive operations like disk access or network activity. Again if we need to minimize these overheads we need to buffer the data first.

With the vision to rectify the inefficiencies of the stream oriented approach an improved model was developed and packaged as Java NIO!

[References:

Reconsidering IO

Friends,

Input Output, IO for short, hardly ever generates the excitement it deserves. Though indispensable, we often prefer not getting our hands dirty with the guts of the subject. It hardly ever appeals to us, and we wonder if its worth our effort. When Java so beautifully abstracts all the messy details, it appears wiser to quickly wrap it all up in few API calls.

We prefer to focus more on improving the processing of the application, to make it smarter by the day. IO naturally gets pushed away from receiving any serious attention. Given our time restraints, our mind just revolts against any idea of prioritizing this particular aspect.

With our concerns(or rather obsession) for process-optimization we often end up with lapses which have serious performance implications.

IO versus Process Time :

No matter how much effort is invested in optimizing the code, all of it may be belittled if the application suffers from IO inefficiencies. Contrary to the "process-optimization will decide it all" perception, which many of us carry, IO is actually a significant determinant in deciding the overall performance of our application. The singular fact that performing IO operations usually takes many times longer than in-memory processing, calls for its careful evaluation. The following analysis will probably elucidate with greater clarity as to how much I/O is crucial in our application. [The figures have been borrowed from the book "JAVA NIO” by Ron Hitchens]

Consider the case(hypothetical) where the in-memory processing of 1 unit of data requires 5 ms and the IO for the same consumes 100 ms. So the throughput of the application turns out to be 9.52 units/second.

[ Formula: (1/(process time + IO time))X 1000].

Now if we manage to decrease the processing time (keeping the IO expense constant) to 1 ms the gain in throughput will be around 3.96%.

However if the IO consumption is reduced to 75 ms (keeping process time fixed at 5 ms) the throughput gain is a whooping 31.25%.

Even at a slight 10% decrease in IO time (90 ms) the gain jumps considerably to 10.53%

The substantial throughput gains are enough to spur us into action and reconsider our IO approach.

Why this neglect?

However its not all our fault that IO takes a back seat! The ignorance stems from an old habit that should have, but did not die with time. In the early days of java JVMs offered little runtime optimization while interpreting the bytecode. They ran slower than their natively compiled counterparts. So there would have not been any specific benefit in working on IO performance. The latency in in-memory operations had diverted the attention from the need to ensure efficiency in IO. That is, the process was too slow and improving IO would not have resulted in any substantial throughput gain. Programmers instinctively remained preoccupied in reducing the processing time.

Nevertheless with time the runtime optimization improved and the processing time dropped. JVMs performed at speeds approaching that of the natively compiled code.IO obviously got pushed to the center stage in determining application performance.

How could Java help?

It was never the case that the OS failed to transmit data fast enough. It was actually the JVM that lagged behind. There was a huge "impedance-mismatch". Let us understand how.

The stream based model of java.io packages treats data byte by byte or character by character. In contrast the OS carts data in large chunks. These chunks need to be broken down by java.io before they can be used. Consequently there is a huge mismatch in the speed with which data is delivered by the OS to java.io and the speed with which java.io processes it further.

This very impedance-mismatch adversely affected the application performance.

Though java.io increases the probability that our application will be kept waiting for I/O, it is not that notorious! There are implementations that have bridged the lacuna to some extent, but still a paradigm shift in the approach was long overdue.

And then Java NIO emerged!