A preliminary study of Java AIO (asynchronous network IO)

According to UNIX network programming, IO models can be divided into: blocking io, non-blocking io, io multiplexing, signal-driven IO, and asynchronous Io, divided into two classes according to POSIX standards: synchronous IO and asynchronous IO. How do you differentiate? First, an IO operation is actually divided into two steps: initiating IO requests and actual IO operations, the difference between synchronous IO and asynchronous IO is whether the second step is blocked, and if the actual IO read-write blocking request process is synchronous io, blocking io, non-blocking io, io taking, Signal-driven IO is synchronous io, if not blocked, but the operating system to help you finish IO operations and then return the results to you, then asynchronous IO. The difference between blocking IO and non-blocking io is that the first step is whether the IO request is blocked and, if blocked up to completion, the traditional blocking IO, or non-blocking io if it is not blocked.

The main improvement of Java NIO 2.0 is the introduction of asynchronous IO (including files and networks), which mainly introduces the use of the asynchronous network IO API and the design of the framework, taking the TCP server as an example. First look at the new classes and interfaces to support AIO introduction:

Java.nio.channels.AsynchronousChannel

Marking a channel supports asynchronous IO operations.

Java.nio.channels.AsynchronousServerSocketChannel

ServerSocket's AIO version, creating a TCP server, binding addresses, listening ports, and so on.

Java.nio.channels.AsynchronousSocketChannel

A stream-oriented asynchronous socket channel that represents a connection.

Java.nio.channels.AsynchronousChannelGroup

The group management of asynchronous channel is to share resources. A asynchronouschannelgroup binds a thread pool, which performs two tasks: processing IO events and distributing Completionhandler. Asynchronousserversocketchannel can be created by passing in a asynchronouschannelgroup, then created by Asynchronousserversocketchannel Asynchronoussocketchannel will belong to a group that shares resources.

Java.nio.channels.CompletionHandler

The callback interface for the result of an asynchronous IO operation that defines the callback work done after the IO operation is completed. The AIO API allows you to handle the results of an asynchronous operation in two ways: The returned future pattern or the registered Completionhandler, which I recommend in Completionhandler Way, these handler calls are made by the Asynchronouschannelgroup's line Cheng hair. Obviously, the size of the thread pool is a key factor in performance. Asynchronouschannelgroup allows different thread pools to be bound, created by three static methods:

public　static　AsynchronousChannelGroup　withFixedThreadPool(int　nThreads,
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ThreadFactory　threadFactory)
　　　　　　　　 throws　IOException
　 public　static　AsynchronousChannelGroup　withCachedThreadPool(ExecutorService　executor,
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 int　initialSize)
　 public　static　AsynchronousChannelGroup　withThreadPool(ExecutorService　executor)
　　　　　　　　 throws　IOException

Needs to be adjusted according to the specific application, from the frame point of view, need to expose such configuration options to the user.

After introducing the main TCP interfaces and classes introduced by AIO, let's imagine how the next AIO framework should be designed. The design of a non-blocking NIO framework is generally based on the reactor mode, where Reacot is responsible for registering, select, and distributing events; Accordingly, asynchronous IO has a proactor mode, proactor responsible for the distribution of Completionhandler, Look at the process of a typical IO write operation to see the difference between the two:

Reactor:send (msg)-> Message Queuing is empty, if the op_write is registered for NULL-> to reactor, and then returns-> reactor select-> Trigger writable to notify the user that the thread is to handle-&G t; Log off first writable (many people encounter CPU 100% problem is not logoff), processing writeable, if not fully written, continue to register Op_write. Note that the write work is still handled by the user thread.

Proactor:send (msg)-> Message Queuing is NULL, if NULL, initiates a read asynchronous call, registers the Completionhandler, and returns. The-> operating system is responsible for writing your messages and returning the results (the number of bytes written) to Proactor-> proactor for distribution Completionhandler. As you can see, the writing work is done by the operating system without user thread involvement. In fact, in the AIO API, Asynchronouschannelgroup played the role of Proactor.

Completionhandler has three methods that correspond to callback processing in the case of success, failure, cancellation (via returned future):

public　interface　CompletionHandler<V,A>　{
　　　　　 void　completed(V　result,　A　attachment);
　　　　 void　failed(Throwable　exc,　A　attachment);

　　　　 void　cancelled(A　attachment);
}