Java NIO的三个核心组件是Buffer、Channel和Selector，分别作为状态化中转站、双向数据管道和事件中枢协同工作：Buffer控制读写状态，Channel需配合Buffer实现非阻塞I/O，Selector通过事件驱动实现单线程管理多连接。
Java NIO 的三个核心组件不是并列关系，而是各司其职、紧密协作的有机整体：Buffer 是数据容器，Channel 是传输管道，Selector 是事件调度员。理解它们的关键，不在于背定义，而在于看清“谁在什么时候做什么、为什么非它不可”。
Buffer 是数据的“状态化中转站”
它不只是一个字节数组，而是一个带读写状态的内存块。传统 IO 中你面对的是流（Stream），数据边读边处理；NIO 中你必须先把数据“搬进” Buffer，再从 Buffer “搬出”，中间所有操作都受 position、limit 和 capacity 控制。
常见误区是把 Buffer 当作普通数组直接读写。实际上：
- 写入后必须调用 flip() 才能开始读——否则 position 在末尾，limit 还是 capacity，读不到任何有效数据；
- 读完若要复用，用 clear()（全清空重来）或 compact()（保留未读部分，把已读数据挤到开头）；
- ByteBuffer 最常用，但 CharBuffer 处理文本更安全（避免字节与字符边界错位）；
- DirectBuffer 可绕过 JVM 堆，直接与操作系统交互，在大文件或网络高频传输时减少拷贝开销。
Channel 是双向“数据管道”
它抽象了数据源/目标（文件、TCP 连接、UDP 包等），和传统流的最大区别是：可读可写、非阻塞就绪、必须配合 Buffer 使用。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
不同场景对应不同 Channel：
-
FileChannel：用于高效文件读写，支持内存映射（
map()）和零拷贝（transferTo/transferFrom）； - SocketChannel：客户端发起 TCP 连接，可配置为非阻塞模式；
- ServerSocketChannel：服务端监听连接请求，accept() 返回新的 SocketChannel；
- DatagramChannel：处理 UDP 数据包，同样支持非阻塞。
注意：Channel 本身不存数据，所有读写都依赖 Buffer；它也不负责线程调度，只响应“现在能不能读/写”这个事实。
Selector 是单线程管理多连接的“事件中枢”
它是 NIO 实现高并发的关键。没有 Selector，每个 Channel 都得配一个线程轮询或阻塞等待，连接数一多就崩；有了 Selector，一个线程就能监听成百上千个 Channel 的就绪事件（如 OP_CONNECT、OP_ACCEPT、OP_READ、OP_WRITE）。
使用 Selector 的几个硬性前提：
- Channel 必须是 SelectableChannel 子类（如 SocketChannel、ServerSocketChannel）；
- 必须调用 configureBlocking(false) 切换为非阻塞模式；
- 必须通过 register(Selector, int ops) 注册，并指定关注的事件类型；
- 每次调用 select() 后，需遍历 selectedKeys() 处理就绪事件，且处理完要手动 remove() 键，否则下次 select 会重复返回。
Selector 不是万能加速器——它适合连接多、单次流量小的场景（如 IM 心跳、HTTP 短连接）。如果某 Channel 持续大量数据传输，反而可能因频繁触发 OP_READ 影响其他通道响应。
