J2SE 1.4 New IO API

J2SE 1.4 New IO API

By Todd Stewart, OCI Principal Engineer

December 2002

Introduction

The final release of Java Specification Request (JSR) #51 introduces APIs for scaleable I/O, fast buffered binary and character I/O, regular expressions, and charset conversion. These new APIs introduce four new abstractions:

• Buffers
• Character sets
• Channels
• Selectors

This article will look at each of these abstractions, discuss the motivation for using the new I/O (NIO) APIs, and examine the performance characteristics of an NIO enhanced log parsing application.

Why use the New I/O APIs

There are several motivating reasons to start using the NIO APIs:

• You are a Java or C/C++ network programmer interested in writing high-performance, scalable, and portable socket applications.
• You require improved performance and control when reading and writing data to and from files.
• You desire more sophisticated pattern recognition using regular expressions.

Buffers are designed to be an efficient mechanism for storing and manipulating primitive data types.

Manipulating Strings tends to create a lot of garbage because many temporary objects are created that must be collected by the garbage collector. In high-performance server applications, this can be a noticeable problem due to the overhead of the garbage collector.

Since buffers, in contrast, are a fixed size, they can significantly reduce the amount of garbage produced and, in turn, reduce the amount of work the garbage collector must do.

Buffers can also be declared as direct, which attempts to make use of the operating system's native I/O mechanisms. Direct buffers can be very efficient at moving and copying data because the Java VM is not involved. Since direct buffers have higher allocation and de-allocation costs than non-direct, you should use direct buffers for large, long-lived buffers.

It is also possible to map a region of a file directly into memory using a MappedByteBuffer. This can provide significant performance gains for certain types of applications.

Using Buffers

A buffer has a position, limit, and capacity.

• The position is the index to the next element to read or write.
• The limit is an index of the "virtual end" of the buffer. Attempting to read past or write beyond the limit results in an exception.
• The capacity is the size of the buffer measured in bytes.

When a new buffer is instantiated, the position is zero and the limit is set equal to the capacity.

Buffer buf = new ByteBuffer(10);

As data is written to the buffer (e.g., from a socket or a file), the position is incremented.

buf.putByte(0xBE);
buf.putShort(0xEFEE);

Once data has been inserted into a buffer, it cannot read it until the position is moved back.

Use the flip() method to set the limit to the current position and reset the position to the start of the buffer.

buf.flip();

A call to get() will return the three bytes between position and limit.

There are other methods to change the position and limit attributes.

• Clearing (clear()) sets the position to zero and the limit to its capacity so it can be used like a new buffer (Note: the data is not cleared out).
• Calling mark() will set the mark at the current position.
• Use reset() to reset the position to a previously marked position.

File Channels

File channels support reading and writing to the underlying file. 

FileChannel implements the scattering, gathering, and byte channel interfaces and is interruptible. Since FileChannels are not selectable (see Selectable Channels), they cannot be used for non-blocking I/O. They do support some advanced features that were previously only available to C programmers:

• A file can be mapped into memory, which may provide better performance than the typical read or write methods.
• A region of a file may be locked to prevent access by other programs.
• The FileChannel allows bytes to be transferred from one file to another file (via its channel). Many operating systems can perform this in a very efficient manner by transferring directly from the file system cache.

Selectable Channels

Multiplexed, non-blocking I/O is possible by using selectable channels and selectors. This type of I/O is more scalable and efficient than the standard thread-oriented, blocking I/O.

Traditionally, to serve multiple client connections, a thread is allocated for each connection. This solution wastes system resources, since threads are expensive to create and manage, and, in this case, tend to wait on I/O most of time.

When using a selector and any number of non-blocking channels (each representing a client connection), a single thread can handle all incoming requests. In this model, long running transactions can degrade quality of service. When this is an issue, a pool of worker threads can be used to handle simultaneous requests.

BufferedReader reader = new BufferedReader(new FileReader(theFile));
String line = null;
while((line = reader.readLine()) != null) {
  // process the line 
}

The NIO version gets a FileChannel from the input stream and maps the file into memory by creating a MappedByteBuffer.

// Open the file and then get a channel from the stream
FileInputStream fis = new FileInputStream(theFile);
FileChannel fc = fis.getChannel();
 
// Map the entire file into memory
int size = (int)fc.size();
MappedByteBuffer bb = fc.map(
   FileChannel.MapMode.READ_ONLY, 0, size);

To read a line from the byte buffer, the buffer needs to be decoded into characters and split into lines by searching for the new line character(s). One way to do this is convert the entire byte buffer into a character buffer, create a regular expression to match a line, and iterate across the buffer.

// Regular expression pattern used to match lines
Pattern linePattern = Pattern.compile(".*\r?\n");
 
// Decode the file into a char buffer 
CharBuffer cb = 
   Charset.forName("ISO-8859-15").newDecoder().decode(bb);
 
// Create the matcher and iterate over the buffer
Matcher lm = linePattern.matcher(cb);
while ( lm.find() ) {
  String line = lm.group();
    // process the line
}

This new implementation was slower than the initial version. After profiling the code (using Java's profiler), this solution required significantly more memory due to decoding the entire file into a character buffer.

In addition to the memory increase, a significant amount of time was spent executing the group method that returns the string matched by the find.

An alternative is to create a Reader from the channel using the Channels utility class.

BufferedReader reader = 
  new BufferedReader(Channels.newReader( fc, "ISO-8859-15" ) );
String line = null;
while((line = reader.readLine()) != null) {
  // process the line 
}

This solution performed better than the line matcher approach but did not show an improvement over the original buffered-reader approach.

In general, the original buffered-reader approach suffers from creating many temporary objects and demanding a lot of memory. The simple attempt to improve the application by mapping the file into memory did not improve the performance.

A more complete solution is to concentrate on reducing the number of temporary objects and making use of direct buffers when possible. This example demonstrates that memory-mapped files are not going to improve performance of sequentially accessed, line-based data.

Memory mapped files, however, can be much more efficient when dealing with large binary data sets or randomly accessed data. This is because the operating system handles the paging of the data and can perform very fast copy and move operations.

Test Results

The tests were run on a Windows 98 machine with JRE 1.4.1_01, a Sun Solaris 2.8 machine with JRE 1.4.0_01, and a Linux machine with JRE 1.4.1. Some tests were run using the -server option which enables the server HotSpot^TM VM. Times are in milliseconds.

For all test cases, the buffered I/O was faster than the memory-mapped file. The memory-mapped solution was from 2% to 20% slower.

For nearly all test cases, the server HotSpot™ performed worse, especially on Linux. The one exception is the 4M file on Solaris.

An interesting note is when running with the server HotSpot™ on Linux, the memory mapped solution performed better for file sizes 500K and above.

Summary

The NIO APIs introduce facilities for scaleable I/O, fast buffered binary and character I/O, regular expressions, and charset conversion. They are not intended to replace but to augment Java's current I/O.

The Java community is excited because some of these capabilities were only available to C programmers (e.g., multiplexed, non-blocking I/O, file locking, and memory-mapped files). This will likely enable the migration of high-performance C applications to the Java platform with similar performance characteristics.

References

• [1] JSR 51 - New I/O APIs for the Java™ Platform
  http://jcp.org/en/jsr/detail?id=051
• [2] Master Merlin's new I/O classes
  http://www.javaworld.com/javaworld/jw-09-2001/jw-0907-merlin.html
• [3] Java™ 2 Platform, Standard Edition (J2SE™), Version 1.4 Overview
  http://developer.java.sun.com/developer/technicalArticles/releases/j2se1.4
• [4] Non-Blocking Socket I/O in JDK 1.4
  http://www.owlmountain.com/tutorials/NonBlockingIo.htm
• [5] Regular Expressions in Java
  https://objectcomputing.com/resources/publications/sett/regular-expressions-java
• [6] Put Java in the fast lane
  http://www.javaworld.com/javaworld/jw-08-2002/jw-0802-performance.html
• [7] The Java Developers Almanac 1.4
  http://javaalmanac.com/
• [8] New I/O (NIO) APIs (JavaLive Transcript)
  http://developer.java.sun.com/developer/community/chat/JavaLive/2002/jl0919.html