Introducción a Java NIO | W3Docs Learn Java

Los quince capítulos anteriores a este trataron sobre java.io — streams, Reader/Writer, File, Serializable. Esa API fue la I/O original de Java y todavía se usa ampliamente. NIO es la familia de APIs que Java añadió posteriormente para cubrir lo que java.io no podía. Viene en dos partes que comparten un prefijo de paquete y poco más:

NIO (Java 1.4, 2002) — java.nio.* — canales, buffers, selectores. Una forma distinta de I/O: basada en byte-buffer, opcionalmente sin bloqueo, diseñada para servidores de alto rendimiento.
NIO.2 (Java 7, 2011) — java.nio.file.* — las clases Path, Files, FileSystem y WatchService. Un reemplazo más amigable para java.io.File y un lugar para características del sistema de archivos que java.io nunca tuvo (enlaces simbólicos, atributos extendidos, I/O de archivos asíncrona, observación de directorios).

Has estado usando partes de NIO.2 desde el inicio de esta sección: Path, Files.newBufferedReader, Files.newInputStream son todos java.nio.file. Este capítulo amplía la perspectiva y muestra dónde encajan esas piezas y para qué sirve el resto del paquete.

Stream vs canal: dos formas diferentes

InputStream.read() devuelve un byte. OutputStream.write(int) escribe un byte. El modelo mental es una tubería de un byte a la vez. Los decoradores con buffer lo hacen rápido, pero la abstracción es secuencial y unidireccional.

Un canal (java.nio.channels.Channel) es bidireccional, orientado a byte-buffer y admite operaciones que InputStream no puede expresar:

Leer hacia y escribir desde un ByteBuffer — no un byte[].
Mapear en memoria una región de un archivo en RAM y leerla/escribirla como un buffer.
Dispersar una lectura en múltiples buffers (cabecera → uno, carga útil → otro).
Concentrar una escritura desde múltiples buffers (un solo write() produce una salida contigua).
Marcar un canal como sin bloqueo y dejar que un Selector multipleque miles de ellos en un solo hilo.

El precio es la verbosidad. El código de canal lee y escribe a través de un ByteBuffer con llamadas explícitas a flip() y position(); java.io oculta todo eso detrás de read(byte[]). Para la lectura típica de archivos, prefiere las APIs de java.io/Files. Recurre a los canales cuando necesites una de las características exclusivas de los canales.

// 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());
  }
}

El paso flip() es el momento en que la gente aprende que ByteBuffer tiene su propia pequeña máquina de estados.

`ByteBuffer`: position, limit, capacity

Un ByteBuffer es un byte[] de tamaño fijo (o un trozo de memoria fuera del heap) más tres índices:

position — el siguiente byte que se va a leer o escribir.
limit — el índice posterior al último byte que puedes tocar.
capacity — el tamaño fijo del buffer; no puede cambiar.

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

El buffer está en uno de dos modos por convención:

Modo escritura (predeterminado): metes bytes con put(byte). position avanza; limit == capacity.
Modo lectura: sacas bytes con get(). position avanza; limit está donde dejaste de escribir.

flip() cambia de escritura a lectura: establece limit = position (marca dónde terminan los datos) y restablece position = 0 (empieza a leer desde el principio). clear() vuelve al modo escritura (position = 0, limit = capacity). Los errores aquí son la fuente más común de la frustración de "leí cero bytes; ¿por qué?".

Los buffers fuera del heap (ByteBuffer.allocateDirect(n)) evitan el heap de la JVM y permiten que el sistema operativo los lea/escriba directamente sin una copia adicional. Son más lentos de asignar, más rápidos para hacer I/O y son la elección correcta solo para código de I/O en la ruta crítica.

Selectores: un hilo, muchos canales

Antes de los hilos virtuales (Java 21), atender miles de conexiones de red concurrentes en Java implicaba miles de hilos del sistema operativo (uno por conexión — costoso) o un único hilo multiplexando con un 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);
  }
}

El sistema operativo notifica a la JVM cuando cualquier canal registrado puede progresar; la JVM te entrega el conjunto listo; haces una lectura o escritura sin bloqueo y vuelves a select(). El código de framework bajo Netty, gRPC y Spring WebFlux tiene esta forma.

Con los hilos virtuales (Thread.startVirtualThread(...)), el patrón más sencillo de "un hilo por solicitud" escala al mismo número de conexiones sin la coreografía del Selector — los hilos virtuales se estacionan en I/O bloqueante esencialmente sin costo. Para código de aplicación nuevo en Java 21+, el bucle de selector es cada vez más una preocupación de las bibliotecas; normalmente no lo escribes a mano. Para código de biblioteca y JVM anteriores a Loom, es el patrón estándar.

`java.nio.file`: la API moderna de archivos

Esta es la mitad de NIO que usarás en el código cotidiano. Reemplaza java.io.File y la mayoría de las partes relacionadas con archivos de java.io:

`java.io`	`java.nio.file`	Por qué el reemplazo
`File`	`Path`	Inmutable, independiente del SO, sin métodos de I/O integrados
`File.list()`	`Files.list(Path)`, `Files.walk(Path)`	`Stream<Path>`; cerrable; respeta los enlaces simbólicos
`new FileInputStream(...)`	`Files.newInputStream(path)`	Variantes con soporte de juego de caracteres para texto; una API de apertura consistente
`file.delete()` devolviendo `false` al fallar	`Files.delete(path)` lanzando `IOException`	Los fallos son visibles, no silenciosos
sin equivalente	`Files.walkFileTree`, `WatchService`, API de enlace simbólico, vistas de atributos de archivo	Capacidades que `java.io` nunca tuvo

Los dos próximos capítulos cubren Path y Files en profundidad. La regla general: para trabajo con archivos en Java 2024+, recurre a java.nio.file. java.io.File sigue existiendo porque el código antiguo lo usa, pero el código nuevo debería usar Path por defecto.

Un ejemplo práctico: ida y vuelta de un archivo mediante un canal y un buffer

El programa a continuación copia un pequeño archivo de texto de la manera canal-y-buffer para hacer concretos position/limit/flip. Abre el origen como un FileChannel, lee en un ByteBuffer, hace flip, escribe en un FileChannel de destino e imprime el estado del buffer en cada paso para que puedas ver cómo se mueven los índices.

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();
  }
}

Lo que hay que extraer de la ejecución:

El bucle imprimió el estado del buffer en cada paso. Después de un read(), position era el número de bytes leídos y limit seguía siendo capacity — eso es "modo escritura": hay espacio al final. Después de flip(), position = 0 y limit = el número recién leído — eso es "modo lectura": los bytes se encuentran entre 0 y limit. Los dos índices codifican "dónde viven los datos" sin copiarlos.
El buffer tenía 16 bytes; el archivo tenía 44. El bucle se ejecutó tres iteraciones: 16, 16, 12. Una vez que el buffer estaba vacío (después de que write lo había drenado), clear() lo restableció al "modo escritura" para que el siguiente read() pudiera rellenarlo. Este es el patrón de canal en miniatura: rellenar, flip, drenar, clear, repetir.
transferTo hizo la misma copia en una línea sin ningún ByteBuffer implicado. En Linux, eso se mapea a una única llamada al sistema sendfile() — los bytes viajan de kernel a kernel sin cruzar la JVM. Cuando mueves datos entre dos canales y no necesitas examinarlos, esta es la herramienta correcta.
Observa que el archivo fuente fue creado con Files.writeString y el destino se leyó de nuevo con Files.readString — ambos son instrucciones de una línea de java.nio.file que ocultan completamente los canales y buffers. El bucle detallado de canal en el medio es lo que escribirías solo cuando necesitas acceso directo al buffer (análisis binario personalizado, mapeo de memoria, scatter/gather). Para "copiar un archivo", transferTo o Files.copy es más corto y al menos igual de rápido.
El constructor FileChannel.open(path, OPTION) es el paralelo a Files.newInputStream(path). El enum StandardOpenOption (READ, WRITE, CREATE, APPEND, TRUNCATE_EXISTING, ...) es lo que controla el comportamiento de apertura — hay un solo lugar donde mirar. Ese enum de opciones de apertura sigue reapareciendo en el próximo capítulo.

Qué sigue

Este capítulo nombró las piezas — canales, buffers, selectores, java.nio.file. El próximo capítulo, Clase Path de Java, profundiza en la más amigable de esas piezas — Path — y los métodos (resolve, relativize, normalize) que usarás cada vez que trabajes con una ruta del sistema de archivos.

Práctica

Lees 10 bytes de un canal en un `ByteBuffer` de capacidad 1024. Quieres escribir esos 10 bytes en otro canal. ¿Qué tienes que hacer entre el `read()` y el `write()`?

Llamar a `buf.flip()` — establece `limit = position` (para que el escritor se detenga en el byte 10) y `position = 0` (para que empiece desde el principio). Sin `flip()`, el escritor ve una región 'remaining' vacía y no escribe nadaNada — `read()` rebobina automáticamente el buffer para el siguiente `write()`Llamar a `buf.clear()` — esa es la operación estándar de 'cambiar dirección'Envolver el buffer en `Buffer.asReadOnlyBuffer()` para que el escritor pueda acceder a él