When would you reach for java.io decorator streams with buffering versus NIO channels and ByteBuffers? What does each model optimize?

## Two families, two philosophies Java has two I/O toolkits: 1. **`java.io` (classic, 'stream I/O'):** the decorator family from this topic — `InputStream`/`OutputStream`, `Reader`/`Writer`, with wrappers like `BufferedInputStream`, `DataInputStream`, `GZIPInputStream`. It is **stream-oriented** (you think in a flowing sequence of bytes/chars) and **blocking** (a `read()` call parks the thread until data is available or EOF). 2. **`java.nio` ("new I/O", since Java 1.4):** `Channel`s (e.g. `FileChannel`, `SocketChannel`) that move data through **`ByteBuffer`** objects. It is **buffer-oriented** (you think in terms of filling/draining a fixed buffer) and supports **non-blocking** mode plus **multiplexing** via `Selector`. ## Key terms - **Blocking I/O:** the calling thread waits (does nothing else) until the operation can proceed. One thread per connection. - **Non-blocking I/O:** a read returns immediately with whatever is available (possibly nothing); you poll or get notified later. Lets one thread service many connections. - **Selector:** an NIO object that watches many channels and tells you which are ready to read/write — the basis of scalable event-loop servers. - **ByteBuffer:** a fixed-capacity wrapper around a byte array (or off-heap memory) with `position`/`limit`/`capacity` cursors you flip between filling and draining. - **MappedByteBuffer / memory-mapped file:** maps a file region directly into the process address space so reads/writes go through the OS page cache without explicit read/write syscalls. - **Zero-copy (`FileChannel.transferTo`):** moves bytes from a file to a socket inside the kernel without copying them into user space — big win for serving files. ## What each model optimizes **java.io + buffering optimizes simplicity and sequential throughput.** `BufferedReader.readLine()` for text, `BufferedInputStream` over a file for binary — the code is short, obviously correct, and fast enough because buffering already kills the per-byte syscall cost. The blocking model means one thread per stream, which is perfectly fine when you have a handful of streams. **NIO optimizes scalability and control.** Its decisive advantage is **non-blocking, selector-based multiplexing**: a server can handle tens of thousands of concurrent sockets on a small thread pool instead of one thread per connection (which would exhaust memory/scheduler). It also enables memory-mapping for random access over huge files and zero-copy file serving. The cost is complexity: you manage `ByteBuffer` flipping, handle partial reads/writes, and deal with a much lower-level API. ## Decision guide - **Reading/writing a file sequentially, or line-by-line text:** classic buffered streams. Don't reach for NIO. - **High-concurrency network server (chat, proxy, gateway):** NIO non-blocking + Selector, or — in practice — a framework like Netty built on NIO. One thread per blocking socket does not scale to 50k connections. - **Random access into a very large file / serving static files at high rate:** NIO `FileChannel` (memory-mapping, `transferTo` zero-copy). - **Simple bulk file copy:** `Files.copy` (java.nio.file) is concise; under the hood it may use channels. For modest sizes buffered streams are equally fine. - **You need primitive-typed reads (readInt/readUTF):** `DataInputStream` over a buffered stream is the easy path. ## They interoperate They are not an either/or wall. `Channels.newInputStream(channel)` and `Channels.newChannel(stream)` bridge the two, so you can use the convenient stream API on top of a channel or vice versa. Modern code often uses `java.nio.file` (Paths/Files) for file operations while still wrapping the result in a `BufferedReader`. ## Also note: virtual threads change the calculus Since Project Loom (virtual threads, Java 21), the historical 'one blocking thread per connection doesn't scale' argument is weakened: blocking java.io on virtual threads can now scale to many connections cheaply, because a blocked virtual thread does not pin an OS thread. This is a principal-level nuance: for new server code on modern JVMs, simple blocking I/O on virtual threads is often preferable to hand-rolled NIO selectors for both clarity and scale. ## Summary Buffered java.io decorators = simple, blocking, stream-shaped, great for files/text and moderate scale. NIO channels/buffers = lower-level, non-blocking, multiplex-capable, memory-mappable, zero-copy, built for high-concurrency networking and large-file random access. Choose by concurrency level, access pattern, and (now) whether you are on virtual threads.