Java NIO

一、IO 的第一性原理（本质层）

1. IO 的根本问题是什么？

IO 的本质不是读写数据，而是：

如何在“外部事件完成时间不可预测”的前提下， 高效使用有限的计算资源（CPU / 线程 / 内存）。

换句话说：

👉 所有 IO 模型、NIO、Reactor 的存在，都是为了解决这一不对称性。

2. IO 系统中的三大核心矛盾

矛盾 说明
等待 vs 计算 IO 等待期间 CPU 是否被浪费
连接数 vs 线程数 外部连接规模远大于可用线程
同步语义 vs 系统吞吐 易理解的同步模型限制并发

所有 IO 架构，本质上都是在这三者之间做权衡。

二、资源模型：为什么 BIO 天生不可扩展

1. BIO 的隐含假设

BIO（Blocking IO）并不是“设计得差”，而是基于以下假设：

其真实模型是：

一个 IO 会话 = 一个线程的生命周期

2. BIO 的根本问题（不是“线程多”）

BIO 的问题不在于“线程数量”，而在于：

即：

计算资源被无意义地占用

这就是 BIO 在高并发、长连接场景下必然崩溃的原因。

三、IO 模型的演进（操作系统层）

OS 层 IO 模型解决的是： “进程如何感知 IO 何时就绪”

1. IO 的两个阶段（统一抽象）

所有 IO 都可拆为两个阶段：

  1. 等待数据就绪（数据到达内核）
  2. 数据拷贝（内核 → 用户态）

2. 五种经典 IO 模型（OS 视角）

模型 第一阶段 第二阶段 本质
阻塞 IO 阻塞 阻塞 线程绑定 IO
非阻塞 IO 轮询 阻塞 CPU 换延迟
IO 多路复用 阻塞在选择器 阻塞 事件集中管理
信号驱动 IO 信号通知 阻塞 回调感知
异步 IO 非阻塞 非阻塞 内核完成一切

关键结论：

前四种仍是“同步 IO”，只有异步 IO 在两个阶段都解耦了线程。

四、架构模式层：从 IO 模型到系统设计

架构模式解决的是： “应用如何组织代码来消费 IO 能力”

1. Thread-Per-Request 模式（BIO 架构）

适用场景：

2. Reactor 模式（事件驱动）

Reactor 要解决的核心问题

如何让少量线程同时管理大量连接？

核心思想

角色拆分

角色 职责
Reactor 事件监听与分发
Demultiplexer 事件检测（select/epoll）
Handler 业务处理

Reactor 的本质：

用事件循环 + 状态机，替代线程阻塞。

3. Proactor 模式（完成驱动）

Proactor 的前提条件

核心思想

Proactor = 把 IO 生命周期完全下沉到内核

五、Java NIO 的定位（JVM 层）

1. Java NIO 是什么？

Java NIO 是 Reactor 模式在 JVM 上的标准实现。

它并不是 OS 级异步 IO，而是：

2. 抽象层级映射关系

抽象层 对应概念
OS IO 模型 IO 多路复用
架构模式 Reactor
JVM 抽象 Selector / Channel
OS 实现 epoll / poll / select

六、Java NIO 核心组件的“设计动机”

1. Channel：连接的抽象

2. Selector：事件多路分发器

本质：

将“等待 IO”这一行为集中化、共享化。

3. Buffer：数据与状态的统一体

Buffer 的价值不在于“数组”，而在于：

Heap vs Direct

类型 设计取舍
HeapBuffer GC 友好，IO 性能一般
DirectBuffer 减少拷贝，管理复杂

DirectBuffer 的本质：

用内存管理复杂度，换取 IO 路径性能。

七、零拷贝的本质（性能哲学）

零拷贝不是“不拷贝”，而是：

避免无意义的用户态 / 内核态来回搬运。

技术 本质
mmap 共享内存视图
sendfile 内核态直传
transferTo JVM 对 sendfile 的封装

八、工程实践的正确打开方式

1. 网络 IO 的正确理解

2. 何时不该使用 NIO

九、IO 架构选型方法论（稳定知识）

场景 推荐模型
管理后台 BIO
高并发长连接 Reactor + NIO
文件分发 零拷贝
Windows 高性能 IO Proactor / IOCP

关联内容（自动生成）