What’s Behind Java’s I/O: From BIO to Epoll and Beyond

1. Unix I/O Models

Unix defines five I/O models: Blocking I/O (BIO), Non‑Blocking I/O (NIO), I/O multiplexing (select and poll), Signal‑Driven I/O (SIGIO), and Asynchronous I/O (AIO). BIO blocks the application thread until data is copied into the user buffer. NIO returns an error code immediately and requires the application to poll for completion.

In NIO, the recvfrom system call receives data from a socket and copies it into the application's buffer:

ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen);

Java’s FileInputStream, FileOutputStream, and socket read/write streams are examples of BIO.

Non‑Blocking I/O (NIO)

The application repeatedly issues system calls to check if I/O is complete, a process known as polling, which consumes CPU resources and leads to the need for I/O multiplexing.

I/O Multiplexing

Multiplexing allows a single thread to monitor multiple sockets. The select call blocks until any monitored descriptor becomes readable, then returns the ready set. However, select has drawbacks: copying the fd set between user and kernel space, linear scanning of all fds, a low descriptor limit (1024), and low efficiency.

Copying fd set incurs overhead.

Scanning all fds is costly for large numbers.

Descriptor limit of 1024.

Active polling is inefficient. poll solves the descriptor‑limit issue but retains similar performance characteristics. epoll (Linux) creates an epoll instance with epoll_create or epoll_create1, registers interest via epoll_ctl, and waits for events with epoll_wait. It uses a red‑black tree for ready events, offering higher efficiency. Epoll supports level‑triggered (LT) and edge‑triggered (ET) modes; ET only reports a descriptor when its state changes. kqueue provides similar functionality on BSD/macOS.

2. I/O Multiplexing in Practice

Java’s NIO framework builds on the I/O multiplexing model, using Channel, Selector, and Buffer abstractions. Netty’s EpollSocketChannel defaults to edge‑triggered mode, while JDK NIO defaults to level‑triggered.

3. Network Models

From a kernel‑space perspective we examined I/O models; now we view them from user space. Traditional models include blocking and non‑blocking I/O. Blocking I/O assigns a thread per connection, suitable only for low‑concurrency scenarios.

Non‑blocking I/O reduces thread count by polling sockets, but still incurs frequent user‑kernel transitions.

Reactor Model

The Reactor pattern, introduced in JDK 1.4, is event‑driven. An Acceptor accepts connections, a Reactor dispatches events, and Handlers process them. This separates connection handling, network I/O, and business logic, improving throughput.

Single‑threaded Reactor can handle many connections without spawning many threads.

It is an asynchronous non‑blocking model where idle threads can perform other work.

Variants include:

Single Reactor + thread pool for business logic.

Master‑Slave Reactor: a master Reactor handles connections, while slave Reactors (with thread pools) handle I/O and business processing, scaling to millions of connections (used by Tomcat, Netty).

Proactor Model: based on true asynchronous I/O (AIO). The kernel handles event notification, I/O execution, and result dispatch. Windows provides IOCP for full async I/O; Linux relies mainly on Reactor‑style mechanisms.

All these models share an event‑dispatch architecture; the key difference is whether they wait for I/O completion (Reactor) or are notified after completion (Proactor).

In summary, understanding the evolution from simple blocking I/O to sophisticated multiplexing and event‑driven models is essential for building scalable Java network applications.