Does java nio read/write file actually non-blocking io?

Question

I'm learning about non-blocking i/o terms. Mainly, I'm learning java Nio. I'm trying to understand non-blocking i/o better and observe how it works in the implementation with Java Nio.

I read a dozen questions and answers related to the non-blocking i/o term and the non-blocking i/o by using java Nio.

I see a following similar statement everywhere.

Non-blocking IO does not wait for the data to be read or written before returning. Java NIO non-blocking mode allows the thread to request writing data to a channel, but Non-blocking IO does not wait for the data to be read or written before returning.

I tried to illustrate the statement with an example java code that reads a file's content using Nio. However, the thread is still blocked at the channel's read() method.

System.out.println("Thread-" + Thread.currentThread().getName() 
+ "-" + Thread.currentThread().getId());// Thread-main-1

String filePath = "./resources/nio-demo.txt";
FileInputStream fis = new FileInputStream(new File(filePath));
FileChannel fileChannel = fis.getChannel();

ByteBuffer buf = ByteBuffer.allocate(102400);

int bytesRead = fileChannel.read(buf);
System.out.println(buf.position()); //check how many bytes are written to the buf, always 102400

while (bytesRead != -1)
{

    buf.flip();

    while (buf.hasRemaining())
    {
        System.out.print((char) buf.get());
    }

    buf.clear();
    bytesRead = fileChannel.read(buf);
}
fis.close();

As I understand, after triggering the read() method, the thread will execute the following line of code. It doesn't matter if the buf is full of data or not. But here, the thread is blocked until the buf is complete and continues the process sequence.

The above example reads a file about 300M with buf is 102400.

The situation confused me much; perhaps I misunderstood non-blocking i/o with java Nio.

Could you please help me explain this situation?

How does java Nio achieve purely non-blocking i/o with only one thread?

Answer 1

[…] perhaps I misunderstood non-blocking i/o with java Nio.

Yes; it sounds like you've misunderstood what's meant by "blocking" and "non-blocking". These terms are not synonymous with "synchronous" and "asynchronous".

The distinction between "blocking" and "non-blocking" isn't so meaningful when reading from a regular file — and indeed, java.nio.channels.FileChannel doesn't have blocking and non-blocking modes — so please put files out of your mind, and instead, imagine a situation where two processes are communicating via a channel. For example, consider a shell pipeline, where the output of one process is piped to the input of another:

./writer | ./reader

Let's imagine that the writer doesn't write continuously to the pipe, but rather, just prints every so often; maybe its output is computationally expensive to generate, or maybe its output isn't its primary work but is just a rare secondary effect (e.g., printing out a message every time it's completed a chunk of work), or . . . well, you get the idea.

Now, consider this from the perspective of the reader process, when it performs an operation like this:

numBytesRead = inputChannel.read(dst);

There are (at least) two different ways we could imagine this working:

• It might read until dst is full or it reaches the end of the input. This involves potentially waiting a long time for the writer process to generate enough blocks of output to fill dst.
  • We call this a "blocking" operation.
• It might read until dst is full, or it reaches the end of the input, or it runs out of already-available input. This doesn't involve waiting for the writer process, but it means that it might not fill dst — in fact, it might not read even a single byte into dst — even if there may be more input to read later.
  • We call this a "non-blocking" operation.

Does that make sense?

Another situation where "blocking" and "non-blocking" operations come up a lot is with locks. For example, FileChannel has both lock (blocking) and tryLock (non-blocking) methods to obtain a filesystem lock; if it's not possible to take a lock immediately, lock waits until it can, whereas tryLock just immediately returns null.

---

A few other things worth noting:

• Even if a channel supports non-blocking operations, it will still default to blocking ones. To get non-blocking behavior, you need to put it in "non-blocking mode", e.g. by calling its configureBlocking method if it has one.
• Even a "non-blocking" operation can take a long time, if the buffer is large and there's a lot of input available. It's just that it never actually blocks: it runs only as long as there's input available, and if at any point it catches up to the writer, it immediately returns what it's read so far.
• The NIO APIs include a class called java.nio.channels.AsynchronousFileChannel, which behaves how you expected FileChannel to behave. It's analogous to FileChannel, except that its methods are asynchronous: instead of waiting for the actual read or write to complete, they just cause it to start (in a separate thread). You'll notice that its method signatures are better designed for this call pattern; instead of returning an integer, they accept a callback or return a future.