Java NIO - non-blocking channels vs AsynchronousChannels

Question

Java NIO offers SocketChannel and ServerSocketChannel which can be set to non-blocking mode (asynchronous). Most of the operations return a value that corresponds to success or that the operation is not yet done. What is the purpose of AynchronousSocketChannel and AsynchronousServerSocketChannel then, apart from the callback functionalities?

Answer 1

which can be set to non-blocking mode (asynchronous)

There's your misapprehension, right there. Non-blocking mode is different from asynchronous mode.

A non-blocking operation either transfers data or it doesn't. In either case there is no blocking, and the operation is complete once it returns. This mode is supported by SocketChannel, DatagramSocketChannel, and Selector.

An asynchronous operation starts when you call the method and continues in the background, with the result becoming available at a later time via a callback or a Future. This mode is supported by the AsynchronousSocketChannel etc classes you mention in your question.

Answer 2

The AynchronousSocketChannel and AsynchronousServerSocketChannel come into their own when using the methods that take a CompletionHandler.

For example the code in a server might look like this:

asynchronousServerSocketChannel.accept(Void, new ConnectionHander()); 

Where ConnectionHander is an implementation of CompletionHandler that deals with client connections.

The thread that makes the accept call can then continue doing other work and the NIO API will deal with scheduling the callback to the CompletionHandler when a client connection is made (I believe this is an OS level interupt).

The alternative code might look like this:

SocketChannel socketChannel = serverSocketChannel.accept();

Depending on the mode, the calling thread is now blocked until a client connection is made or null is returned leaving you to poll. In both cases, it's you that has to deal with the threads, which generally means more work.

At the end of the day, you take your pick based on your particular use-case, though I've generally the former produces clearer more reliable code.