Java BIO 和 NIO 有什么区别？

简化版

BIO 通常指使用阻塞读写的编程模式，调用在数据未就绪时会等待，代码直观；NIO 是 Java 的 New I/O API，提供 Channel、Buffer，以及可选择网络通道的非阻塞模式和 Selector 多路复用。NIO 不等于所有操作都非阻塞，它的优势主要体现在大量网络连接的就绪事件管理上。

详细版

面试语境中的 BIO 与 NIO，实际上同时比较了 API 风格和网络并发模型：

对比项	BIO 常见用法	NIO Selector 常见用法
数据抽象	InputStream / OutputStream	Channel + Buffer
网络读写	通常使用阻塞调用	SelectableChannel 可切换为非阻塞
连接管理	常见是每个活动连接由一个线程处理	一个事件循环监听多个通道
代码形态	顺序流程，较容易编写	事件驱动，需维护连接状态
适用场景	连接较少，或配合虚拟线程的简洁阻塞代码	大量长连接、活跃比例较低的事件驱动服务

传统平台线程比较昂贵，如果为每个长时间等待数据的连接都保留一个平台线程，内存、调度和上下文切换成本会随连接数增长。Selector 让少量线程等待多个通道的就绪事件，但应用仍要主动执行读写、处理半包和部分写。

完整版教学

一、BIO 不是一个独立类库名称

JDK 里没有一个叫“BIO”的包。工程上通常用 BIO 表示阻塞 I/O 编程风格，典型例子是使用 ServerSocket、Socket、InputStream 和 OutputStream。read() 在没有数据且未到达流末尾时会阻塞当前线程。

最直观的服务器会在 accept() 得到连接后，交给一个线程顺序读取、处理和写回。“一连接一线程”是 BIO 的常见并发组织方式，但不是 java.io API 强制的语法规则。线程池可以限制平台线程数，代价是超出容量的连接或任务需要排队或被拒绝。

二、NIO 的“N”是 New，不是所有 API 都 Non-blocking

NIO 引入了 Buffer、Channel、Charset 和 Selector 等抽象。其中可选择网络通道可以在阻塞与非阻塞模式间切换；新建的 SelectableChannel 默认仍是阻塞模式，注册到 Selector 之前才必须调用 configureBlocking(false)。

FileChannel 不是 SelectableChannel，普通文件读写也不会因为使用了 NIO 包就自动变成非阻塞。因此更准确的说法是：NIO 提供了多种新 I/O 能力，其中 SelectableChannel + Selector 组成了多路复用的非阻塞网络 I/O 模型。

三、Selector 解决的是“等待谁就绪”

一个 Selector 可以管理多个已注册的 SelectableChannel。每个注册由 SelectionKey 表示，应用可关心接收连接、建立连接、可读和可写事件。select() 可以阻塞等待至少一个事件就绪，而通道的具体 read() / write() 仍以非阻塞方式由应用调用。

Selector 使用当前平台的 SelectorProvider 实现。Linux 上的 JDK 实现可以使用 epoll，其他系统可使用不同机制，也允许插入自定义 provider。所以代码应依赖 Selector 的就绪语义，而不是把 selector.select() 写死理解为某一个操作系统调用。

四、AIO 与 NIO Selector 的区别

NIO.2 的 AsynchronousSocketChannel、AsynchronousFileChannel 等类提供异步操作，可返回 Future，或在操作完成时调用 CompletionHandler。这与 Selector “通知就绪，应用再主动读写”的模型不同。

异步通道的底层如何完成操作由 AsynchronousChannelProvider 和平台实现决定，可能使用操作系统异步能力，也可能由线程池配合完成。应用层应依赖“提交操作并在完成后取得结果”的 API 语义，不应假设所有平台都使用同一种内核异步机制。

五、BIO 和 NIO 怎么选

• 连接数少、流程简单：阻塞模型代码易写、易调试。
• 大量长连接且同时活跃比例较低：Selector 事件循环可用少量线程管理就绪事件。
• 已有 Netty 等成熟框架：优先使用框架封装的事件循环、协议解码和缓冲区管理，避免重复实现细节。
• Java 21+ 阻塞风格网络代码：可评估虚拟线程。它降低了“一任务一线程”的线程成本，但不会增加下游容量，也不会让单次 I/O 更快。

选型应综合连接数、活跃比例、业务是否阻塞、延迟目标、团队经验和框架生态。“NIO 一定比 BIO 快”没有脱离场景的意义。

六、用数字比较线程占用与事件循环

假设有 10,000 个长连接，每个连接平均每 10 秒才收到一次请求，而且每次业务处理只需 2 ms。若使用“一连接一平台线程”，即使绝大多数线程都在等网络，也要维护约 10,000 个线程栈和调度状态；若每个线程预留 1 MiB 栈空间，仅地址空间预算就约为 10 GiB，实际提交量取决于 JVM 与操作系统配置。

Selector 模型可以让少量事件线程等待这 10,000 个通道，只在连接就绪时处理。它节省的是等待资源，不会把 2 ms 的业务计算消掉：若一秒内同时到达 1,000 个请求，单个事件线程仍要承担约 2 秒 CPU 工作，必须把耗时业务移交到有界工作池或拆分事件循环。

负载特征	阻塞平台线程	Selector	阻塞虚拟线程
少量连接、顺序流程	简单	状态机成本偏高	通常也简单
大量低活跃连接	线程成本高	擅长	适合评估
大量 CPU 计算	仍受 CPU 限制	事件线程易被拖住	仍受 CPU 限制
下游连接池仅 100	最多有效并发仍受 100 限制	同样受限	同样受限

记忆钩子：BIO、Selector 和虚拟线程改变的是“等待方式与代码组织”，不改变磁盘、网络、数据库和 CPU 的真实容量。

七、从 accept 到回写的执行链

BIO：accept → 阻塞 read → 业务处理 → 阻塞 write
NIO：select → 就绪 key → 非阻塞 read → 解码 → 业务调度 → 非阻塞 write

NIO 的每一步都可能只完成一部分。accept() 可能暂时返回 null，read() 可能返回 0 或只得到半条消息，write() 也可能只消耗 Buffer 的一部分。应用因此要为每个连接保存解码状态和待发送数据，并动态管理 OP_READ、OP_WRITE 兴趣集。

复杂度正来自这种显式状态管理。成熟框架的价值不只是封装 Selector，还包括连接生命周期、背压、缓冲区池、协议编解码和异常传播；面试中若只说“一个线程管很多连接”，还没有回答如何正确地管。

NIO 还要求公平处理多个连接。若一个热点连接每次可读都无限循环处理，其他 key 可能长期得不到机会；事件循环通常会限制单轮读取字节数或任务数量，并把连接关闭、异常和 EOF 纳入同一状态机。

当 read() 返回 -1 时表示对端已到达流末尾，应用应按协议完成清理；返回 0 在非阻塞模式下只表示本次没有读到数据。把 0 当 EOF 会误关连接，把 -1 忽略则可能留下无效 key 和资源泄漏。

虚拟线程虽然降低等待连接的平台线程成本，仍需用信号量、连接池或队列约束下游并发。若数据库池只有 100 个连接，让 10,000 个虚拟线程同时查询只会把等待位置从 Socket 转移到连接池。

选型还应以端到端指标验证：连接建立速率、活跃连接数、P99 延迟、CPU、内存和错误恢复缺一不可。只用单连接吞吐量比较 BIO 与 NIO，会漏掉两种模型真正不同的并发管理成本。

八、常见误区与追问

• 误区：Channel 一定是双向通道。 读写能力由通道类型和打开方式决定，ServerSocketChannel 的核心职责是接收连接。
• 误区：NIO 中的所有 I/O 都是非阻塞的。 非阻塞模式主要属于 SelectableChannel，FileChannel 不能注册到普通 Selector。
• 误区：读就绪代表一条完整消息已经到达。 TCP 是字节流，应用协议仍需用长度字段、分隔符或固定长度处理消息边界。
• 追问：为什么事件线程不能执行慢业务？ 一个事件线程服务多个连接，长时间阻塞会让同一循环上的其他连接也得不到处理。
• 误区：NIO 在任何场景都比 BIO 快。 连接规模较小或业务流程简单时，状态机成本可能超过它节省的线程成本。
• 追问：虚拟线程出现后 Selector 是否没用了？ 没有；虚拟线程适合简化阻塞式代码，事件循环仍适合既有框架、精细背压和高性能网络栈，选型取决于整体架构。
• 追问：Selector 报可写后是否一定能写完？ 不一定，非阻塞 write() 允许部分写甚至返回 0，必须保留 Buffer 进度并在后续可写时继续。

九、加强记忆

BIO 是阻塞编程风格，代码顺序直观；NIO 是 New I/O API，其中 SelectableChannel + Selector 用非阻塞多路复用让少量线程管理多个网络连接。NIO 不代表所有通道都非阻塞，Selector 也只报告就绪，真正读写、消息分帧和业务调度仍由应用负责。