Java NIO 入门：掌握缓冲区、通道与选择器

Java NIO（New I/O）提供了面向缓冲区的 I/O API。它常用于文件读写、网络通信，以及需要同时管理大量连接的服务器程序。理解 NIO 的关键不是记住几个类名，而是掌握三件事如何配合：缓冲区保存数据，通道负责传输数据，选择器帮助线程发现哪些通道已经就绪。

NIO 并不意味着所有 I/O 都天然更快，也不等于“零拷贝”。它提供了更灵活的 I/O 模型；是否适合某个应用，取决于数据量、连接数、操作系统、JDK 实现和程序结构。本文示例使用 JDK 8 及以上版本，不依赖第三方库。

一、NIO 适合什么场景

• 文件读写：使用 FileChannel 进行定位读写，或在适用时尝试 transferTo、transferFrom。
• 高并发网络服务：使用非阻塞通道与 Selector，让一个或少数线程处理多个连接，避免每个连接都占用一个阻塞线程。
• 需要精细控制数据传输：例如处理部分读写、协议分帧、限流和背压。

如果程序只是读取一个小文件，使用 Files.readAllBytes 或传统流通常更简单。NIO 的非阻塞模型也会带来额外状态管理：应用必须处理半包、部分写入、连接关闭和缓冲区生命周期。并发连接很多，并不自动意味着应当使用单线程 Selector；业务处理耗时较长时，通常还要将计算任务交给工作线程池。

二、Buffer：理解位置、上限与容量

ByteBuffer 是最常见的缓冲区类型。它有四个重要属性：

• capacity：缓冲区容量，创建后固定。
• position：下一次读或写的位置。
• limit：当前允许读写的边界。
• mark：可选的位置标记，可由 reset() 返回。

缓冲区的基本不变量是：0 <= mark <= position <= limit <= capacity（mark 未设置时除外）。新建缓冲区用于写入时，position 为 0、limit 等于 capacity。写完后调用 flip()，把当前位置设为读取上限，并将位置重置为 0。读完后可以调用 clear() 重新用于写入；它只重置状态，不会清除底层数据。若还没读完就要继续接收数据，应使用 compact()：它会把未读数据移到缓冲区开头，并为后续写入腾出空间。

import java.nio.ByteBuffer;
import java.nio.charset.StandardCharsets;

public class BufferDemo {
    public static void main(String[] args) {
        ByteBuffer buffer = ByteBuffer.allocate(16);

        buffer.put("hello".getBytes(StandardCharsets.UTF_8));
        System.out.println("写入后 position=" + buffer.position());

        buffer.flip();
        byte[] bytes = new byte[buffer.remaining()];
        buffer.get(bytes);
        System.out.println(new String(bytes, StandardCharsets.UTF_8));

        buffer.clear(); // 只重置 position、limit、mark，不擦除内容
    }
}

allocate(n) 创建堆缓冲区，数据由 Java 堆管理；allocateDirect(n) 创建直接缓冲区，通常由堆外内存支持，可能减少某些 I/O 路径上的复制，但分配和释放成本更高，也会占用堆外内存。直接缓冲区不是“必然更快”，更不应不加测量地为每次小操作创建。可以复用缓冲区，并结合实际负载进行基准测试。

容量参数必须大于等于 0；负数会导致 IllegalArgumentException。容量过大则可能造成内存压力。直接缓冲区还受到进程可用堆外内存等因素影响，不能把它当成无限资源。Java 也不保证使用者能精确控制直接缓冲区的物理释放时机。

缓冲区不是线程安全的。多个线程同时改变同一个缓冲区的 position 或 limit，容易破坏状态。需要并发访问时，应通过明确的所有权约定、同步或独立缓冲区来管理。

三、Channel：数据通过通道传输

通道与流的一个重要区别是：流通常是单向的，而通道可能支持读、写或两者兼有。常见类型包括 FileChannel、SocketChannel、ServerSocketChannel 和 DatagramChannel。通道读写的数据通常通过 ByteBuffer 传递。

通道的读写不一定一次完成。非阻塞 SocketChannel 的 read 可能读取 0 个字节；write 也可能只写出一部分数据。即使是文件通道，也不应在程序逻辑中假设一次调用总能处理完所有数据。检查返回值，并根据剩余字节继续操作。

文件通道示例：复制文件

下面的程序使用固定大小的缓冲区复制文件，适合展示通道读写流程。保存为 FileCopyDemo.java，编译后运行时传入源路径和目标路径。

import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.nio.file.StandardOpenOption;

public class FileCopyDemo {
    public static void main(String[] args) throws IOException {
        if (args.length != 2) {
            System.err.println("用法: java FileCopyDemo <源文件> <目标文件>");
            System.exit(2);
        }

        Path source = Paths.get(args[0]);
        Path target = Paths.get(args[1]);
        ByteBuffer buffer = ByteBuffer.allocate(16 * 1024);

        try (FileChannel in = FileChannel.open(source, StandardOpenOption.READ);
             FileChannel out = FileChannel.open(
                     target,
                     StandardOpenOption.CREATE,
                     StandardOpenOption.TRUNCATE_EXISTING,
                     StandardOpenOption.WRITE)) {

            while (in.read(buffer) != -1) {
                buffer.flip();
                while (buffer.hasRemaining()) {
                    out.write(buffer);
                }
                buffer.clear();
            }
        }
    }
}

文件通道的读取到文件末尾时返回 -1；如果仍有数据，读取结果可能小于缓冲区容量。缓冲区写满后要先 flip()，让通道从已写入区域读取；写完后再 clear()。遗漏这两个状态转换，是常见的“程序不报错但复制结果为空或不完整”的原因。

FileChannel.open 的打开选项决定文件如何处理。示例使用 CREATE、TRUNCATE_EXISTING 和 WRITE：若目标已存在，会先截断内容。实际使用时不要把不可信输入直接作为目标路径，也要确认覆盖行为符合预期。示例未保留文件权限、时间戳等元数据；生产级复制可能需要额外处理属性、符号链接和失败后的清理。

FileChannel.transferTo 和 transferFrom 可用于在通道间传输数据，有些平台或路径可能利用更高效的系统调用，但不能据此保证一定零拷贝或一次传输完毕。调用者仍应根据返回值处理部分传输；不同文件系统、通道类型和运行环境也会影响结果。

四、Selector：一个线程管理多个连接

Selector 用来检查注册到它的可选择通道是否就绪。常见兴趣事件有：

• OP_ACCEPT：服务器通道可以接受新连接。
• OP_CONNECT：客户端连接操作已完成或可继续处理。
• OP_READ：通道当前可读。
• OP_WRITE：通道当前可写。

“就绪”不代表一次操作必定处理完所有数据，也不代表读操作一定会得到正数字节。非阻塞网络编程通常按以下步骤组织：创建 Selector；将通道设为非阻塞；注册感兴趣事件；调用 select()；处理就绪事件；按实际读写结果更新兴趣事件。

可运行示例：非阻塞 Echo 服务器

下面是一个简单的 TCP 回显服务器。客户端发送的字节会原样返回；服务端不做字符集解码，也不按行切分。代码将每个连接的待发送数据保存在 SelectionKey 的附件中，未写完时保留 OP_WRITE，写完后移除它，避免通道一直可写导致 Selector 忙循环。

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.util.Iterator;
import java.util.Set;

public class NioEchoServer {
    private static final int PORT = 9000;
    private static final int BUFFER_SIZE = 8192;

    public static void main(String[] args) throws IOException {
        try (Selector selector = Selector.open();
             ServerSocketChannel server = ServerSocketChannel.open()) {

            server.configureBlocking(false);
            server.bind(new InetSocketAddress(PORT));
            server.register(selector, SelectionKey.OP_ACCEPT);

            System.out.println("Echo server listening on port " + PORT);

            while (true) {
                selector.select();

                Set<SelectionKey> selected = selector.selectedKeys();
                Iterator<SelectionKey> iterator = selected.iterator();

                while (iterator.hasNext()) {
                    SelectionKey key = iterator.next();
                    iterator.remove();

                    if (!key.isValid()) {
                        continue;
                    }

                    try {
                        if (key.isAcceptable()) {
                            acceptConnections(server, selector);
                        } else if (key.isReadable()) {
                            readFromClient(key);
                        } else if (key.isWritable()) {
                            writeToClient(key);
                        }
                    } catch (IOException e) {
                        closeKey(key);
                    }
                }
            }
        }
    }

    private static void acceptConnections(
            ServerSocketChannel server, Selector selector) throws IOException {
        SocketChannel client;
        while ((client = server.accept()) != null) {
            client.configureBlocking(false);
            client.register(selector, SelectionKey.OP_READ, ByteBuffer.allocate(BUFFER_SIZE));
            System.out.println("Accepted " + client.getRemoteAddress());
        }
    }

    private static void readFromClient(SelectionKey key) throws IOException {
        SocketChannel client = (SocketChannel) key.channel();
        ByteBuffer buffer = (ByteBuffer) key.attachment();

        int count = client.read(buffer);
        if (count == -1) {
            closeKey(key);
            return;
        }
        if (count == 0) {
            return;
        }

        buffer.flip();
        key.interestOps(key.interestOps() & ~SelectionKey.OP_READ
                | SelectionKey.OP_WRITE);
    }

    private static void writeToClient(SelectionKey key) throws IOException {
        SocketChannel client = (SocketChannel) key.channel();
        ByteBuffer buffer = (ByteBuffer) key.attachment();

        client.write(buffer);
        if (buffer.hasRemaining()) {
            return;
        }

        buffer.clear();
        key.interestOps(key.interestOps() & ~SelectionKey.OP_WRITE
                | SelectionKey.OP_READ);
    }

    private static void closeKey(SelectionKey key) {
        key.cancel();
        try {
            key.channel().close();
        } catch (IOException ignored) {
            // 关闭失败时仍继续清理循环
        }
    }
}

编译并启动：

javac NioEchoServer.java
java NioEchoServer

另开一个终端，用系统自带的 nc 连接测试（具体参数可能因系统版本不同而异）：

nc 127.0.0.1 9000

输入内容后，服务器会把收到的字节回送。可以用 Ctrl+C 结束客户端。该示例仅用于展示 NIO 的事件处理，并非完整生产服务器：它没有连接数上限、空闲超时、认证、协议长度限制、日志与优雅停机，也没有把业务计算分发到工作线程。

示例中的状态与事件处理

• 服务器通道和客户端通道都设置为非阻塞模式。可注册到 Selector 的通道必须支持非阻塞 I/O。
• 新连接到达时，accept() 在非阻塞模式下可能返回 null，因此循环接受直到没有待处理连接。
• 读入数据后调用 flip()，再切换到写事件。若只写出一部分，缓冲区 position 会前移，剩余数据继续保留。
• 写完后调用 clear()，并切回读事件。不能长期监听 OP_WRITE：套接字大多数时候都可写，会导致循环频繁唤醒。
• 对端关闭连接时，read() 返回 -1，示例取消注册并关闭通道。

示例每次读之前都确保缓冲区处于写入模式，且上一次数据已全部回送，因此一个缓冲区足以演示简单回显。但 TCP 是字节流，不保留客户端每次 write 的消息边界。真实协议必须自己定义分帧方式，例如固定长度、长度前缀或分隔符，并处理一条消息被拆成多次读取、一次读取包含多条消息等情况。还应给单条消息设置合理的最大长度。

五、Selector 的边界与常见误区

select() 返回就绪键的数量。一次返回后，应遍历 selectedKeys()，并移除已经处理的键；若不移除，旧键会留在集合中，导致后续重复处理。不要将就绪事件理解为“数据完整到达”，也不要假设 read() 必然返回正数。

注册和兴趣事件更新应当有清晰的线程归属。通常由事件循环线程执行通道注册及相关状态修改。若另一个线程需要唤醒阻塞在 select() 的线程，可以调用 selector.wakeup()，并通过线程安全的队列传递待处理任务。wakeup() 用于唤醒选择操作，不会替代队列同步或任务状态管理。

选择器和非阻塞 I/O 降低了“一个连接占用一个阻塞线程”的需求，但没有消除资源上限。文件描述符、内存、连接数、CPU 和系统配置都可能成为限制。具体上限由操作系统和进程配置决定，不能把它们视为固定的 Java 常量。对外服务应限制并发连接、缓冲区总量和待发送数据，避免慢客户端长期占用资源。

Selector 的底层实现与平台有关。应用应依赖 Java API 的语义，而不是假定某一种内核通知机制或固定的性能表现。大型服务还需考虑事件循环的公平性：如果单个连接一次处理过多数据，可能挤占其他连接的处理时间；可以设置每轮读写预算，再留待后续事件循环继续处理。

六、字符编码、参数和安全注意事项

ByteBuffer 保存的是字节，不是 Java 字符串。文本协议应明确字符集，通常可显式使用 StandardCharsets.UTF_8，避免依赖平台默认字符集。若一个 UTF-8 字符跨越两次读取，不能把每次读到的字节片段分别独立解码；应使用 CharsetDecoder，保留未完成的字节，或在协议层先完成消息拼接再解码。

不要直接信任网络输入中的长度字段。读取长度后先检查是否为非负数、是否小于应用允许的上限，再分配缓冲区或累计数据。否则攻击者可能通过伪造超大长度造成内存耗尽。即便使用固定大小的 ByteBuffer，也要为协议累积区、发送队列和每个连接的其他状态设定总量预算。

NIO 本身不是安全机制，也不会自动提供加密、身份验证、访问控制或输入校验。需要传输机密数据或验证对端身份时，应使用经过正确配置的 TLS，例如基于 SSLEngine 的非阻塞 TLS，或根据应用架构选择其他安全传输方案。使用 TLS 时还必须正确处理握手、加密记录、缓冲区溢出与下溢、关闭流程和证书验证；不能只把 SocketChannel 切换为非阻塞就认为连接安全。

路径处理也要谨慎。文件路径可能包含符号链接，权限检查与实际打开之间还可能出现竞争条件。处理不可信路径时，应结合应用的目录边界、文件系统语义和权限策略设计，避免仅靠字符串前缀判断路径是否“位于某个目录内”。

七、排查常见错误

1. 忘记 flip：写入缓冲区后直接交给通道读取，limit 仍在容量位置，可能读到未写入区域。写模式转读模式时调用 flip()。
2. 误把 clear 当成清零：clear() 只改变状态，不擦除数据。若读取逻辑只看 limit 和 position，旧字节不会自动被当作有效数据，但也不应把它当作安全擦除。
3. 忽略部分写入：只调用一次 write() 就清空缓冲区，会丢失未写出的数据。根据 hasRemaining() 保留数据并等待后续可写事件。
4. 一直监听 OP_WRITE：通道通常可写，可能造成 Selector 高频返回。仅在确有待发送数据时注册，发送队列清空后及时移除。
5. 把 TCP 当成消息队列：一次读取不等于一条消息。为协议实现明确的消息边界、长度校验和超时策略。
6. 直接缓冲区用量失控：大量分配大容量直接缓冲区会消耗堆外资源。优先复用，监控进程资源，并用真实负载验证收益。
7. 事件循环执行慢任务：数据库调用、阻塞文件操作或长时间计算会拖延所有连接。应把耗时业务交给有界工作线程池，并设计好结果如何返回事件循环。

八、选择合适的起点

入门时可以按这个顺序练习：先用 ByteBuffer 熟悉 position、limit、flip 和 compact；再用 FileChannel 完成文件复制并处理部分读写；最后实现一个非阻塞服务器，加入协议分帧、待发送队列、连接上限和超时处理。每一步都应检查返回值，并观察缓冲区状态，而不是依赖“通常一次就能完成”。

当连接数量有限、代码简洁性更重要时，阻塞 I/O 可能更合适；当需要管理大量并发连接，并愿意承担事件循环与状态机的复杂度时，Selector 才更有价值。选型应通过可复现的负载测试和资源监控验证，而不是仅凭“非阻塞”或“新 I/O”判断性能。