Netty权威指南 第2版学习笔记1——Java的I/O演进之路

本系列学习笔记是中国工信出版集团、电子工业出版社《Netty权威指南(第2版)》学习笔记。原书内容详尽，学习笔记只是一个概况，无法尽述原书内容，建议有需求者直接读原书。

I/O基础入门

Java1.4之前对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提供了5种I/O模型，分别如下：

• 阻塞I/O模型：最常用的I/O模型，缺省情形下，所有文件操作都是阻塞的。
  

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

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

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

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

《UNIX网络编程》对Unix系统网络编程知识有非常详细的原理和API介绍。
Java 在很长一段时间没有提供异步I/O通信的类库，而操作系统底层是支持异步I/O通信的。Java NIO的核心类库多路利用器Selector就是基于epoll的多路复用技术实现。

I/O多路复用技术

在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：

1.支持一个进程打开的socket描述特不受限制（仅受限于操作系统的最大文件句柄数）
select单个进程所打开的FD是有一定限制的，由FDSETSIZE设置，默认1024。对于需要支持上万个TCP连接的大型服务器来说太少了，可以选择修改这个宏然后重新编译内核，不过会带来网络效率的下降。也可以通过选择多进程的方案（传统的Apache方案）解决这个问题，不过虽然在Linux上创建进程的代码比较小，但仍旧是不可忽视的。另外，进程间的数据交换非常麻烦，对Java来说，没有共享内存，需要通过Socket通信或者其它方式进行数据同步，这带来了额外的性能损耗，增加了程序复杂度，所以也不是一种完美的解决方案。epoll没有这个限制，上限是操作系统的最大文件句柄数，在1G内存的机器上大约是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效率高太多；但是一旦使用idle connections模拟WAN环境，epoll的效率就远在select/poll之上了。

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

4.epoll的API更加简单
包括创建一个epoll描述符、添加监听事件、阻塞等等待所监听的事件发生、关闭epoll描述符等。

epoll是Linux的实现方案。在freeBSD下有kqueue，而dev/poll是最古老的Solaris的方案。

从BIO到NIO是Java通信类库迈出的一小步，但对Java的高性能通信领域的发展起到了关键性的推动作用。

Java的I/O演进

在Jdk1.4推出Java NIO之前，基于Java的Socket都采用了同步阻塞模式（BIO）。
NIO在JDK1.4时，以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无法使用
• 所有的文件操作都是同步阻塞调用，不支持异步文件读写操作

JDK1.7对NIO升级为2.0，由JSR-203演化而来，提供了以下改进：

• 提供能够指获取文件属性的API
• 提供AIO功能，支持基于文件的异步I/O操作和针对网络套接字的异步操作
• 完成JSR-51定义的通道功能，包括对配置和多播数据报的支持等。