参考 《Netty 权威指南》，整理 I/O 方面的基础知识，包含 Linux 网络 I/O 模型简介、I/O 多路复用技术介绍、Java I/O 演进。

后续如果有好的资料，我也会整理进来。

Java1.4 之前的早期版本，Java 对 I/O 的支持并不完善，开发人员在开发高性能 I/O 程序的时候，会面临一些巨大的挑战和困难，主要问题如下。

  • 没有数据缓冲区，I/O性能存在问题；
  • 没有 C 或者 C++ 中的 Channel 概念，只有输入和输出流；
  • 同步阻塞式 I/O 通信（BIO），通常会导致通信线程被长时间阻塞；
  • 支持的字符集有限，硬件可移植性不好。

在 Java 支持异步 I/O 之前的很长一段时间里，高性能服务端开发领域一直被 C++ 和 C 长期占据，Java 的同步阻塞 I/O 被大家所诟病。

Linux 网络 I/O 模型简介

Linux 的内核将所有外部设备都看做一个文件来操作，对一个文件的读写操作会调用内核提供的系统命令，返回一个 file descriptor（fd，文件描述符）。而对一个 socket 的读写也会有相应的描述符，称为 socketfd（socket 描述符），描述符就是一个数字，它指向内核中的一个结构体（文件路径，数据区等一些属性）。

根据 UNIX 网络编程对 I/O 模型的分类，UNIX 提供了 5 种 I/O 模型，分别如下。

1. 阻塞 I/O 模型

最常用的 I/O 模型就是阻塞 I/O 模型，缺省情形下，所有文件操作都是阻塞的。我们以套接字接口为例来讲解此模型：在进程空间中调用 recvfrom，其系统调用直到数据包到达且被复制到应用进程的缓冲区中或者发生错误时才返回，在此期间一直会等待，进程在从调用 recvfrom 开始到它返回的整段时间内都是被阻塞的，因此被称为阻塞 I/O 模型，如下图所示。

image.png

2. 非阻塞 I/O 模型

recvfrom 从应用层到内核的时候，如果该缓冲区没有数据的话，就直接返回一个 EWOULDBLOCK 错误，一般都对非阻塞 I/O 模型进行轮询检查这个状态，看内核是不是有数据来，如下图所示。

image.png

3. I/O复用模型

Linux 提供 select/poll，进程通过将一个或多个 fd 传递给 select 或 poll 系统调用，阻塞在 select 操作上，这样 select/poll 可以帮我们侦测多个 fd 是否处于就绪状态。select/poll 是顺序扫描 fd 是否就绪，而且支持的 fd 数量有限，因此它的使用受到了一些制约。Linux 还提供了一个 epoll 系统调用，epoll 使用基于事件驱动方式代替顺序扫描，因此性能更高。当有 fd 就绪时，立即回调函数 rollback，如下图所示。

image.png

4. 信号驱动 I/O 模型

首先开启套接口信号驱动 I/O 功能，并通过系统调用 sigaction 执行一个信号处理函数（此系统调用立即返回，进程继续工作，它是非阻塞的）。当数据准备就绪时，就为该进程生成一个 SIGIO 信号，通过信号回调通知应用程序调用 recvfrom 来读取数据，并通知主循环函数处理数据，如下图所示。

image.png

5. 异步 I/O 模型

告知内核启动某个操作，并让内核在整个操作完成后（包括将数据从内核复制到用户自己的缓冲区）通知我们。这种模型与信号驱动模型的主要区别是：信号驱动 I/O 由内核通知我们何时可以开始一个 I/O 操作；异步 I/O 模型由内核通知我们 I/O 操作何时已经完成，如下图所示。

image.png

I/O 多路复用技术介绍

从上述我们可以知道，其实操作系统对于异步IO是支持的，只不过 Java 在很长的一段时间并没有提供异步 IO 通信的类库。由于 Java NIO 的核心类库多路复用器 Selector 就是基于 epoll 的多路复用技术实现，下面会重点分析 IO 多路复用技术。

在 I/O 编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者 I/O 多路复用技术进行处理。I/O 多路复用技术通过把多个 I/O 的阻塞复用到同一个 select 的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比，I/O 多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降底了系统的维护工作量，节省了系统资源，I/O 多路复用的主要应用场景如下。

  • 服务器需要同时处理多个处于监听状态或者多个连接状态的套接字。
  • 服务器需要同时处理多种网络协议的套接字。

目前支持 I/O 多路复用的系统调用有 select、pselect、poll、epoll，在 Linux 网络编程过程中，很长一段时间都使用 select 做轮询和网络事件通知，然而 select 的一些固有缺陷导致了它的应用受到了很大的限制，最终 Linux 不得不在新的内核版本中寻找 select 的替代方案，最终选择了 epoll。epoll 与 select 的原理比较类似，为了克服 select 的缺点，epoll 作了很多重大改进，现总结如下。

1.支持一个进程打开的 socket 描述符（FD）不受限制（仅受限于操作系统的最大文件句柄数）

select 最大的缺陷就是单个进程所打开的 FD 是有一定限制的，它由 FD_SETSIZE 设置，默认值是 1024。对于那些需要支持上万个 TCP 连接的大型服务器来说显然太少了。

可以选择修改这个宏，然后重新编译内核，不过这会带来网络效率的下降。我们也可以通过选择多进程的方案（传统的 Apache 方案）解决这个问题，不过虽然在 Linux 上创建进程的代价比较小，但仍旧是不可忽视的，另外，进程间的数据交换非常麻烦，对于 Java 来说，由于没有共享内存，需要通过 Socket 通信或者其他方式进行数据同步，这带来了额外的性能损耗，增加了程序复杂度，所以也不是一种完美的解决方案。

值得庆幸的是，epoll 并没有这个限制，它所支持的 FD 上限是操作系统的最大文件句柄数，这个数字远远大于 1024。例如，在 1GB 内存的机器上大约是 10 万个句柄左右，具体的值可以通过 cat /proc/sys/fs/file-max 察看，通常情况下这个值跟系统的内存关系比较大。

2.I/O 效率不会随着 FD 数目的增加而线性下降。

传统的 select/poll 另一个致命弱点就是当你拥有一个很大的 socket 集合，由于网络延时或者链路空闲，任一时刻只有少部分的 socket 是“活跃”的，但是 select/poll 每次调用都会线性扫描全部集合，导致效率呈现线性下降。

epoll 不存在这个问题，它只会对“活跃”的 socket 进行操作，这是因为在内核实现中，epoll 是根据每个 fd 上面的 callback 函数实现的。那么，只有“活跃”的 socket 才会主动的去调用 callback 函数，其他 idle 状态的 socket 则不会。在这点上，epoll 实现了一个伪 AIO。

针对 epoll 和 select 性能对比的 benchmark 测试表明：如果所有的 socket 都处于活跃态。例如一个高速 LAN 环境，epoll 并不比 select/poll 效率高太多；相反，如果过多使用 epoll_ctl，效率相比还有稍微的下降。但是一旦使用 idle connections 模拟 WAN 环境，epoll 的效率就远在 select/poll 之上了。

3.使用 mmap 加速内核与用户空间的消息传递。

无论是 select，poll 还是 epoll 都需要内核把 FD 消息通知给用户空间，如何避免不必要的内存复制就显得非常重要，epoll 是通过内核和用户空间 mmap 使用同一块内存实现。

4.epoll 的 API 更加简单。

用来克服 select/poll 缺点的方法不只有 epoll，epoll 只是一种 Linux 的实现方案。在 freeBSD 下有 kqueue，而 dev/poll 是最古老的 Solaris 的方案，使用难度依次递增。相比 epoll 的 API 更加简单。

Java I/O 演进

Java I/O 的演进主要经历了如下三个阶段：

第一阶段

从 JDK1.0 到 JDK1.3，Java 的 I/O 类库都非常原始，很多 UNIX 网络编程中的概念或者接口在 I/O 类库中都没有体现，例如 Pipe、Channel、Buffer 和 Selector 等。

第二阶段

2002 年发布 JDK1.4 时，NIO 以 JSR-51 的身份正式随 JDK 发布。它新增了个 java.nio 包，提供了很多进行异步 I/O 开发的 API 和类库，主要的类和接口如下。

  • 进行异步 I/O 操作的缓冲区 ByteBuffer 等。
  • 进行异步 I/O 操作的管道 Pipe。
  • 进行各种 I/O 操作（异步或者同步）的 Channel，包括 ServerSocketChannel 和 SocketChannel。
  • 多种字符集的编码能力和解码能力。
  • 实现非阻塞 I/O 操作的多路复用器 selector。
  • 基于流行的 Perl 实现的正则表达式类库。
  • 文件通道 FileChannel。

新的 NIO 类库的提供，极大地促进了基于 Java 的异步非阻塞编程的发展和应用，但是，它依然有不完善的地方，特别是对文件系统的处理能力仍显不足，主要问题如下。

  • 没有统一的文件属性（例如读写权限）。
  • API 能力比较弱，例如目录的级联创建和递归遍历，往往需要自己实现。
  • 底层存储系统的一些高级 API 无法使用。
  • 所有的文件操作都是同步阻塞调用，不支持异步文件读写操作。

第三阶段

2011 年 7 月 28 日，JDK1.7 正式发布。它的一个比较大的亮点就是将原来的 NIO 类库进行了升级，被称为 NIO2.0。NIO2.0 由 JSR-203 演进而来，主要提供了如下三个方面的改进。

  • 提供能够批量获取文件属性的 API，这些 API 具有平台无关性，不与特性的文件系统相耦合。另外它还提供了标准文件系统的 SPI，供各个服务提供商扩展实现。
  • 提供 AIO 功能，支持基于文件的异步 I/O 操作和针对网络套接字的异步操作。
  • 完成 JSR-51 定义的通道功能，包括对配置和多播数据报的支持等。

摘录：《Netty 权威指南》

作者：殷建卫 链接：https://www.yuque.com/yinjianwei/vyrvkf/wvqofs 来源：殷建卫 - 架构笔记 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。