 |
| | Contents: | | |
|
| | Related content: | | |
|
| | Subscriptions: | | |
|
|
New addition greatly reduces thread overhead
Aruna Kalagnanam
(kaaruna@in.ibm.com), Software engineer, IBM
Balu G
(gbalu@in.ibm.com), Software engineer, IBM
01 Mar 2002
The Java technology platform is long overdue for a nonblocking I/O mechanism. Fortunately, Merlin (JDK 1.4) has a magic wand for almost every occasion, and unblocking blocked I/O is this magician's specialty. Software engineers Aruna Kalagnanam and Balu G introduce the nonblocking features of Merlin's new I/O package, java.nio (NIO), and employ a socket-programming example to show you just what NIO can do.
A server's ability to handle numerous client requests within a reasonable time is dependent on how effectively it uses I/O streams. A server that caters to hundreds of clients simultaneously must be able to use I/O services concurrently. Until JDK 1.4 (aka Merlin), the Java platform did not support nonblocking I/O calls. With an almost one-to-one ratio of threads to clients, servers written in the Java language were susceptible to enormous thread overhead, which resulted in both performance problems and lack of scalability. To address this issue, a new set of classes have been introduced to the Java platform with the latest release. Merlin's java.nio package is chock full of tricks for resolving thread overhead, the most important being the new SelectableChannel and Selector classes. A channel represents a means of communication between a client and a server. A selector is analogous to a Windows message loop, in which the selector captures the various events from different clients and dispatches them to their respective event handlers. In this article, we'll show you how these two classes function together to create a nonblocking I/O mechanism for the Java platform. I/O programming before Merlin
We'll start with a look at a basic, pre-Merlin server-socket program. In the lifetime of a ServerSocket class, the important functions are as follows:
- Accept incoming connections
- Read requests from clients
- Service those requests
Let's take a look at each of these steps using code snippets to illustrate. First, we create a new ServerSocket:
ServerSocket s = new ServerSocket();
|
Next, we want to accept an incoming call. A call to accept() should do the trick here, but there's a little trap you have to watch for:
Socket conn = s.accept( );
|
The call to accept() blocks until the server socket accepts a client request for connection. Once a connection is established, the server reads the client requests, using LineNumberReader. Because LineNumberReader reads data in chunks until the buffer is full, the call blocks on a read. The following snippet shows LineNumberReader in action (blocks and all).
InputStream in = conn.getInputStream();
InputStreamReader rdr = new InputStreamReader(in);
LineNumberReader lnr = new LineNumberReader(rdr);
Request req = new Request();
while (!req.isComplete() )
{
String s = lnr.readLine();
req.addLine(s);
}
|
InputStream.read() is another way to read data. Unfortunately, the read method also blocks until data is available, as does the write method.
Figure 1 depicts the typical workings of a server. The bold lines represent blocking operations. Figure 1. A typical server in action
 Prior to JDK 1.4, liberal use of threads was the most typical way of getting around blocking. But this solution created its own problem -- namely thread overhead, which impacts both performance and scalability. With the arrival of Merlin and the java.nio package, however, everything has changed. In the sections that follow, we'll look at the foundations of java.nio, and then apply some of what we've learned to revising the server-socket example described above. The Reactor pattern
The principal force behind the design of NIO is the Reactor design pattern. Server applications in a distributed system must handle multiple clients that send them service requests. Before invoking a specific service, however, the server application must demultiplex and dispatch each incoming request to its corresponding service provider. The Reactor pattern serves precisely this function. It allows event-driven applications to demultiplex and dispatch service requests, which are then delivered concurrently to an application from one or more clients.
The Reactor pattern is closely related to the Observer pattern in this aspect: all dependents are informed when a single subject changes. The Observer pattern is associated with a single source of events, however, whereas the Reactor pattern is associated with multiple sources of events. See Resources to learn more about the Reactor pattern. Channels and Selectors
NIO's nonblocking I/O mechanism is built around selectors and channels. A Channel class represents a communication mechanism between a server and a client. In keeping with the Reactor pattern, a Selector class is a multiplexor of Channels. It demultiplexes incoming client requests and dispatches them to their respective request handlers. We'll look closely at the respective functions of the Channel class and the Selector class, and at how the two work together to create a nonblocking I/O implementation. What the Channel does
A channel represents an open connection to an entity such as a hardware device, a file, a network socket, or a program component that is capable of performing one or more distinct I/O operations, such as reading or writing. NIO channels can be asynchronously closed and interrupted. So, if a thread is blocked in an I/O operation on a channel, another thread can close that channel. Similarly, if a thread is blocked in an I/O operation on a channel, another thread can interrupt that blocked thread. Figure 2. Class hierarchy for java.nio.channels
 As Figure 2 shows, there are quite a few channel interfaces in the java.nio.channels package. We're mainly concerned with the java.nio.channels.SocketChannel and java.nio.channels.ServerSocketChannel interfaces. These channels can be treated as replacements for java.net.Socket and java.net.ServerSocket, respectively. Channels can be used in a blocking or a nonblocking mode, though of course we will focus on using channels in nonblocking mode. Creating a nonblocking channel
We have two new classes to deal with in order to implement basic nonblocking socket read and write operations. These are the InetSocketAddress class from the java.net package, which specifies where to connect to, and the SocketChannel class from the java.nio.channels package, which does the actual reading and writing operations. The code snippets in this section show a revised, nonblocking approach to creating a basic server-socket program. Note the changes between these code samples and those used in the first example, starting with the addition of our two new classes:
String host = ......;
InetSocketAddress socketAddress = new InetSocketAddress(host, 80);
SocketChannel channel = SocketChannel.open();
channel.connect(socketAddress);
|
| The role of the buffer
A is an abstract class that contains data of a specific primitive data type. It is basically a wrapper around a fixed-size array with getter/setter methods that make its contents accessible. The Buffer class has a number of subclasses, as follows:
ByteBuffer CharBuffer DoubleBuffer FloatBuffer IntBuffer LongBuffer ShortBuffer
ByteBuffer is the only class that supports reading and writing from and to the other types, since the other classes are type specific. Once connected, data can be read from or written to the channel with a ByteBuffer object. See Resources to learn more about the ByteBuffer.
|
To make the channel nonblocking, we call configureBlockingMethod(false) on the channel, as shown here:
channel.configureBlockingMethod(false);
|
In blocking mode, a thread will block on a read or a write until the operation is completely finished. If during a read, data has not completely arrived at the socket, the thread will block on the read operation until all the data is available. In nonblocking mode, the thread will read whatever amount of data is available and return to perform other tasks. If configureBlockingMethod() is passed true, the channel's behavior will be exactly the same as that of a blocking read or write on a Socket. The one major difference, mentioned above, is that these blocking reads and writes can be interrupted by other threads. The Channel alone isn't enough to create a nonblocking I/O implementation. A Channel class must work in conjunction with the Selector class to achieve nonblocking I/O. What the Selector does
The Selector class plays the role of a Reactor in the Reactor pattern scenario. The Selector multiplexes events on several SelectableChannels. Each Channel registers events with the Selector. When events arrive from clients, the Selector demutliplexes them and dispatches the events to the corresponding Channels. The simplest way to create a Selector is to use the open() method, as shown below:
Selector selector = Selector.open();
|
Channel meets Selector
Each Channel that has to service client requests must first create a connection. The code below creates a ServerSocketChannel called Server and binds it to a local port:
ServerSocketChannel serverChannel = ServerSocketChannel.open();
serverChannel.configureBlocking(false);
InetAddress ia = InetAddress.getLocalHost();
InetSocketAddress isa = new InetSocketAddress(ia, port );
serverChannel.socket().bind(isa);
|
Each Channel that has to service client requests must next register itself with the Selector. A Channel should be registered according to the events it will handle. For instance, a Channel that accepts incoming connections should be registered as shown here:
SelectionKey acceptKey =
channel.register( selector,SelectionKey.OP_ACCEPT);
|
A Channel's registration with the Selector is represented by a SelectionKey object. A Key is valid until one of these three conditions is met:
- The
Channel is closed. - The
Selector is closed. - The
Key itself is cancelled by invoking its cancel() method.
The Selector blocks on the select() call. It then waits until a new connection is made, another thread wakes it up, or another thread interrupts the original blocked thread. Registering the Server
Server is the ServerSocketChannel that registers itself with the Selector to accept all incoming connections, as shown here:
SelectionKey acceptKey = serverChannel.register(sel, SelectionKey.OP_ACCEPT);
while (acceptKey.selector().select() > 0 ){
......
|
After the Server is registered, we iterate through the set of keys and handle each one based on its type. After a key is processed, it is removed from the list of ready keys, as shown here:
Set readyKeys = sel.selectedKeys();
Iterator it = readyKeys.iterator();
while (it.hasNext())
{
SelectionKey key = (SelectionKey)it.next();
it.remove();
....
....
....
}
|
If the key is acceptable, the connection is accepted and the channel is registered for further events such as read or write operations. If the key is readable or writable, the server indicates it is ready to read or write data on its end:
SocketChannel socket;
if (key.isAcceptable()) {
System.out.println("Acceptable Key");
ServerSocketChannel ssc = (ServerSocketChannel) key.channel();
socket = (SocketChannel) ssc.accept();
socket.configureBlocking(false);
SelectionKey another =
socket.register(sel,SelectionKey.OP_READ|SelectionKey.OP_WRITE);
}
if (key.isReadable()) {
System.out.println("Readable Key");
String ret = readMessage(key);
if (ret.length() > 0) {
writeMessage(socket,ret);
}
}
if (key.isWritable()) {
System.out.println("Writable Key");
String ret = readMessage(key);
socket = (SocketChannel)key.channel();
if (result.length() > 0 ) {
writeMessage(socket,ret);
}
}
|
Abracadabra -- nonblocking server socket appear!
The final part of this introduction to nonblocking I/O in JDK 1.4 is left to you: running the example. In this simple nonblocking server-socket example, the server reads a file name sent from the client, displays the file contents, and writes the contents back to the client. Here's what you need to do to run the example:
- Install JDK 1.4 (see Resources).
- Copy both source files onto your directory.
- Compile and run the server as
java NonBlockingServer.
- Compile and run the client as
java Client.
- Input the name of a text or java file in the directory where the class files are present.
- The server will read the file and send its contents to the client.
- The client will print out the data received from the server. (Only 1024 bytes will be read since that is the limit of the
ByteBuffer used.)
- Close the client by entering the command to quit or shutdown.
Conclusion
The new I/O packages from Merlin cover a broad scope. The major advantage of Merlin's new nonblocking I/O implementation is twofold: threads no longer block on reads or writes and the Selector is able to handle multiple connections, greatly reducing server application overhead. We have highlighted these two primary advantages of the new java.nio package. We hope that you will apply what you've learned here to your real-time application development efforts. Resources
- Download the source files to run the example for this article.
- Install JDK 1.4.
- Learn about all the new nonblocking I/O APIs on the NIO home page.
- For a more general introduction to JDK 1.4, see the Java 2 platform, Standard Edition, v1.4 overview.
- See the Java Community Process to learn about the process by which the java.nio package became part of the Java platform.
- For an in-depth discussion of the Java platform's long-standing problem with thread overhead, see Allen Holub's proposal for fixing the Java platform's threading problems, including a section on Java I/O (developerWorks, October 2000).
- Learn more about the ByteBuffer class.
- If you want to learn about design patterns, take "Java design patterns 101" (developerWorks, January 2002).
- Get more information on the Reactor pattern.
- If you want to learn more about socket programming, try "Java sockets 101" (developerWorks, August 2001).
- John Zukowski's Magic with Merlin series is all about the changes Merlin brings to the Java platform.
- The JavaWorld article "Master Merlin's new I/O classes " tells you how to get maximum performance out of nonblocking I/O and memory-mapped buffers .
- You'll find hundreds of articles about every aspect of Java programming in the developerWorks Java technology zone.
Download
|
| Name |
| |
| Size |
| |
| Download method |
| | |
| j-javaio.zip |
| |
| |
| |
| FTP |
| | | | | | | | | | | | | |
About the authors
Aruna Kalagnanam is a software engineer with e-Business Integration Technologies, IBM India Labs. You can contact Aruna at kaaruna@in.ibm.com. | |
Balu G is a software engineer with e-Business Integration Technologies, IBM India Labs. Balu may be reached at gbalu@in.ibm.com.
|
| 
2306
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
