Java NIO Overview

The fifteen chapters before this one were java.io — streams, Reader/Writer, File, Serializable. That API was Java's original I/O, and it's still in heavy use. NIO is the family of APIs Java added later to cover what java.io couldn't. It comes in two parts that share a package prefix and not much else:

NIO (Java 1.4, 2002) — java.nio.* — channels, buffers, selectors. A different shape for I/O: byte-buffer based, optionally non-blocking, designed for high-throughput servers.
NIO.2 (Java 7, 2011) — java.nio.file.* — the Path, Files, FileSystem, and WatchService classes. A friendlier replacement for java.io.File and a place for filesystem features java.io never had (symbolic links, extended attributes, asynchronous file I/O, directory watching).

You've been using bits of NIO.2 since the start of this part: Path, Files.newBufferedReader, Files.newInputStream are all java.nio.file. This chapter zooms out and shows where those pieces fit, and what the rest of the package is for.

Stream vs channel: two different shapes

InputStream.read() returns one byte. OutputStream.write(int) writes one byte. The mental model is a one-byte-at-a-time pipe. Buffered decorators make it fast, but the abstraction is sequential and one-directional.

A channel (java.nio.channels.Channel) is bidirectional, byte-buffer-oriented, and supports operations that InputStream can't express:

Read into and write from a ByteBuffer — not a byte[].
Memory-map a file region into RAM and read/write it as a buffer.
Scatter a read into multiple buffers (header → one, payload → another).
Gather a write from multiple buffers (single write() produces a contiguous output).
Mark a channel non-blocking and let a Selector multiplex thousands of them on one thread.

The trade is verbosity. Channel code reads and writes through a ByteBuffer with explicit flip() and position() calls; java.io hides all of that behind read(byte[]). For typical file reading, prefer the java.io/Files APIs. Drop to channels when you need one of the channel-only features.

// channel-shaped read into a 1 KB buffer
try (FileChannel ch = FileChannel.open(path, StandardOpenOption.READ)) {
  ByteBuffer buf = ByteBuffer.allocate(1024);
  int n = ch.read(buf);                              // fills the buffer; updates position
  buf.flip();                                        // switch to "read what was just written"
  while (buf.hasRemaining()) {
    process(buf.get());
  }
}

The flip() step is the moment people learn that ByteBuffer has its own little state machine.

`ByteBuffer`: position, limit, capacity

A ByteBuffer is a fixed-size byte[] (or a chunk of off-heap memory) plus three indices:

position — the next byte to be read or written.
limit — the index past the last byte you're allowed to touch.
capacity — the buffer's fixed size; can't change.

0 ─────── position ─────── limit ─────── capacity
   (consumed)   (active region)   (untouchable / empty)

The buffer is in one of two modes by convention:

Write mode (default): you put(byte)s into it. position advances; limit == capacity.
Read mode: you get() bytes out. position advances; limit is wherever you stopped writing.

flip() switches from write to read: it sets limit = position (mark where the data ends) and resets position = 0 (start reading from the beginning). clear() switches back to write (position = 0, limit = capacity). Mistakes here are the most common source of "I read zero bytes; why?" frustration.

Off-heap buffers (ByteBuffer.allocateDirect(n)) bypass the JVM heap and let the OS read/write them directly without an extra copy. They're slower to allocate, faster to do I/O with, and the right choice for hot-path I/O code only.

Selectors: one thread, many channels

Before virtual threads (Java 21), serving thousands of concurrent network connections in Java meant either thousands of OS threads (one per connection — expensive) or a single thread multiplexing with a Selector:

Selector sel = Selector.open();
serverChannel.register(sel, SelectionKey.OP_ACCEPT);
while (true) {
  sel.select();                                       // blocks until any channel is ready
  for (SelectionKey k : sel.selectedKeys()) {
    if (k.isAcceptable()) accept(k);
    if (k.isReadable())   read(k);
  }
}

The OS notifies the JVM when any registered channel can make progress; the JVM hands you the ready set; you do a non-blocking read or write and go back to select(). The framework code under Netty, gRPC, and Spring WebFlux is shaped like this.

With virtual threads (Thread.startVirtualThread(...)), the simpler "one thread per request" pattern scales to the same connection counts without the Selector choreography — virtual threads park on blocking I/O essentially for free. For new application code on Java 21+, the selector loop is increasingly a library concern; you usually don't write it by hand. For library code and pre-Loom JVMs, it's the standard pattern.

`java.nio.file`: the modern file API

This is the half of NIO you'll touch in everyday code. It replaces java.io.File and most of the file-related parts of java.io:

`java.io`	`java.nio.file`	Why the replacement
`File`	`Path`	Immutable, OS-agnostic, no built-in I/O methods
`File.list()`	`Files.list(Path)`, `Files.walk(Path)`	`Stream<Path>`; closeable; respects symbolic links
`new FileInputStream(...)`	`Files.newInputStream(path)`	Charset-aware variants for text; one consistent open API
`file.delete()` returning `false` on failure	`Files.delete(path)` throwing `IOException`	Failures are visible, not silent
no equivalent	`Files.walkFileTree`, `WatchService`, symbolic-link API, file attribute views	Capabilities `java.io` never had

The two upcoming chapters cover Path and Files in depth. The rule of thumb: for file work in 2024+ Java, reach for java.nio.file. java.io.File is still around because old code uses it, but new code should default to Path.

A worked example: round-trip a file via a channel and a buffer

The program below copies a small text file the channel-and-buffer way to make position/limit/flip concrete. It opens the source as a FileChannel, reads into a ByteBuffer, flips, writes to a destination FileChannel, and prints the buffer state at each step so you can see how the indices move.

java— editable, runs on the server

import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;

public class NioOverviewDemo {
  public static void main(String[] args) throws IOException {
    // --- 1. Write a small source file (using the java.io-style Files helper) ---
    Path src = Files.createTempFile("nio-src-", ".txt");
    src.toFile().deleteOnExit();
    Files.writeString(src, "the quick brown fox jumps over the lazy dog\n", StandardCharsets.UTF_8);
    System.out.println("source size: " + Files.size(src) + " bytes");

Path dst = Files.createTempFile("nio-dst-", ".txt");
    dst.toFile().deleteOnExit();

// --- 2. Channel-and-buffer copy with running state prints ---
    try (FileChannel in  = FileChannel.open(src, StandardOpenOption.READ);
         FileChannel out = FileChannel.open(dst, StandardOpenOption.WRITE)) {
      ByteBuffer buf = ByteBuffer.allocate(16);              // intentionally smaller than the file
      int totalCopied = 0;
      int iteration = 1;
      while (true) {
        int n = in.read(buf);                                // fill buf; advances position
        if (n == -1) break;
        System.out.printf("iter %d: read %d bytes  -- %s%n", iteration, n, describe(buf));
        buf.flip();                                          // switch to read-from-buf mode
        System.out.printf("         after flip()       -- %s%n", describe(buf));
        int written = out.write(buf);                        // drain buf; advances position
        totalCopied += written;
        System.out.printf("         wrote %d bytes      -- %s%n", written, describe(buf));
        buf.clear();                                         // back to write-into-buf mode
        System.out.printf("         after clear()      -- %s%n%n", describe(buf));
        iteration++;
      }
      System.out.println("total copied: " + totalCopied + " bytes");
    }

// --- 3. Verify the destination matches ---
    String dstContent = Files.readString(dst, StandardCharsets.UTF_8);
    System.out.println("\ndst contents: " + dstContent.replace("\n", "\\n"));

// --- 4. transferTo for comparison — the one-line channel copy ---
    Path dst2 = Files.createTempFile("nio-dst2-", ".txt");
    dst2.toFile().deleteOnExit();
    try (FileChannel in  = FileChannel.open(src, StandardOpenOption.READ);
         FileChannel out = FileChannel.open(dst2, StandardOpenOption.WRITE)) {
      long n = in.transferTo(0, in.size(), out);             // OS-level copy; no buffer in user space
      System.out.println("\ntransferTo copied " + n + " bytes (no manual buffer juggling)");
    }
    System.out.println("dst2 contents matches? " + Files.readString(dst2, StandardCharsets.UTF_8).equals(dstContent));
  }

static String describe(ByteBuffer b) {
    return "pos=" + b.position() + " lim=" + b.limit() + " cap=" + b.capacity();
  }
}

What to take from the run:

The loop printed the buffer state on every step. After a read(), position was the number of bytes read and limit was still capacity — that's "write mode": room left at the end. After flip(), position = 0 and limit = the number-just-read — that's "read mode": the bytes lie between 0 and limit. The two indices encode "where the data lives" without copying it.
The buffer was 16 bytes; the file was 44. The loop ran three iterations: 16, 16, 12. Once the buffer was empty (after write had drained it), clear() reset it back to "write mode" so the next read() could refill it. This is the channel pattern in miniature: refill, flip, drain, clear, repeat.
transferTo did the same copy in one line with no ByteBuffer involved at all. On Linux, that maps to a single sendfile() syscall — the bytes travel kernel-to-kernel without crossing the JVM. When you're moving data between two channels and don't need to look at it, this is the right tool.
Notice that the source file was created with Files.writeString and the destination read back with Files.readString — both are java.nio.file one-liners that hide channels and buffers entirely. The detailed channel loop in the middle is what you'd write only when you need direct buffer access (custom binary parsing, memory mapping, scatter/gather). For "copy a file," transferTo or Files.copy is shorter and at least as fast.
The FileChannel.open(path, OPTION) constructor is the parallel to Files.newInputStream(path). The StandardOpenOption enum (READ, WRITE, CREATE, APPEND, TRUNCATE_EXISTING, ...) is what controls open behaviour — there's only one place to look. That open-options enum keeps recurring through the next chapter.

What's next

This chapter named the pieces — channels, buffers, selectors, java.nio.file. The next chapter, Java Path Class, goes into the friendliest of those pieces — Path — and the methods (resolve, relativize, normalize) you'll use every time you touch a filesystem path.

Practice

You read 10 bytes from a channel into a `ByteBuffer` of capacity 1024. You want to write those 10 bytes to another channel. What do you have to do between the `read()` and the `write()`?

Call `buf.flip()` — it sets `limit = position` (so the writer stops at byte 10) and `position = 0` (so it starts at the beginning). Without `flip()`, the writer sees an empty 'remaining' region and writes nothing
Nothing — `read()` automatically rewinds the buffer for the next `write()`
Call `buf.clear()` — that's the standard 'switch direction' operation
Wrap the buffer in `Buffer.asReadOnlyBuffer()` so the writer can access it