1、Netty权威指南—《Java的I/O演进之路》

第一章

Java的 I/O 演进之路

 

 

1.1  I/O 基础入门

 

 

1.1.1 Linux网络 I/O 模型简介

 

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

 

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

 

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

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

 

 

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

 

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

 

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

 

 

    如果想要了解更多的UNIX系统网络编程知识，可以阅读《UNIX网络编程》，里面有非常详细的原理和 API介绍。对于大多数Java程序员来说，不需要了解网络编程的底层细节，大家只需要有个概念，知道对于操作系统而言，底层是支持异步IO通信的。只不过在很长一段时间Java并没有提供异步I/O通信的类库，导致很多原生的Java程序员对这块儿比较陌生。当你了解了网络编程的基础知识后，理解Java的 NIO类库就会更加容易一些。

 

 

1.1.2  I/O 多路复用技术

 

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

 

    [x]服务器需要同时处理多个处于监听状态或者多个连接状态的套接字;

    [x]服务器需要同时处理多种网络协议的套接字。

 

 

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

 

    epoll相对于select的改进点：

 

    [x]1．支持一个进程打开的 socket描述符（FD)不受限制(仅受限于操作系统的最大文件句柄数)。

    

    select最大的缺陷就是单个进程所打开的FD是有一定限制的，它由FD_SETSIZE 设置，默认值是1024。对于那些需要支持上万个TCP连接的大型服务器来说显然太少了。可以选择修改这个宏然后重新编译内核，不过这会带来网络效率的下降。我们也可以通过选择多进程的方案（传统的Apache方案）解决这个问题，不过虽然在Linux 上创建进程的代价比较小，但仍旧是不可忽视的。另外，进程间的数据交换非常麻烦，对于Java来说，由于没有共享内存，需要通过Socket通信或者其他方式进行数据同步，这带来了额外的性能损耗，增加了程序复杂度，所以也不是一种完美的解决方案。值得庆幸的是，epoll并没有这个限制，它所支持的FD上限是操作系统的最大文件句柄数，这个数字远远大于1024。例如，在 1GB内存的机器上大约是 10 万个句柄左右，具体的值可以通过 cat/proc/sys/fs/file- max察看，通常情况下这个值跟系统的内存关系比较大。

 

   [x]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 之上了。

 

 

    [x]3．使用mmap加速内核与用户空间的消息传递。

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

 

    [x]4. epoll 的 API更加简单。

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

 

 

    值得说明的是，用来克服select/poll 缺点的方法不只有epoll，epoll 只是一种 Linux的实现方案。在 freeBSD下有kqueue，而 dev/poll是最古老的Solaris 的方案，使用难度依次递增。kqueue是freebsd 的宠儿，它实际上是一个功能相当丰富的 kernel事件队列，它不仅仅是select/poll的升级，而且可以处理signal、目录结构变化、进程等多种事件。kqueue是边缘触发的。ldev/poll 是 Solaris的产物，是这一系列高性能API中最早出现的。Kernel提供了一个特殊的设备文件/dev/poll，应用程序打开这个文件得到操作fd_set的句柄，通过写入pollfd来修改它，一个特殊的ioctl调用用来替换select。不过由于出现的年代比较早，所以/dev/poll的接口实现比较原始。

到这里，I/O的基础知识已经介绍完毕。从1.2节开始介绍Java的 I/O演进历史，从 BIO到NIO是Java通信类库迈出的一小步，但却对Java在高性能通信领域的发展起到了关键性的推动作用。随着基于NIO 的各类NIO框架的发展，以及基于NIO 的Web服务器的发展，Java在很多领域取代了C和C++，成为企业服务端应用开发的首选语言。

 

 

 

1.2  Java的 I/O 演进

 

    在JDK 1.4推出Java NIO之前，基于Java的所有Socket通信都采用了同步阻塞模式(BIO)，这种一请求一应答的通信模型简化了上层的应用开发，但是在性能和可靠性方面却存在着巨大的瓶颈。因此，在很长一段时间里，大型的应用服务器都采用C或者C++语言开发，因为它们可以直接使用操作系统提供的异步I/O或者AIO能力。当并发访问量增大、响应时间延迟增大之后，采用Java BIO开发的服务端软件只有通过硬件的不断扩容来满足高并发和低时延，它极大地增加了企业的成本，并且随着集群规模的不断膨胀，系统的可维护性也面临巨大的挑战，只能通过采购性能更高的硬件服务器来解决问题，这会导致恶性循环。

 

    正是由于Java传统BIO的拙劣表现，才使得Java支持非阻塞I/O的呼声日渐高涨，最终，JDK1.4版本提供了新的NIO类库，Java终于也可以支持非阻塞I/O了。

 

 

 

1.3  总结

 

 

    通过本章的学习，我们了解了UNIX网络编程的5种IO模型，学习了IO多路复用技术的基础知识。通过对Java lO演进历史的总结和介绍，相信大家对Java的I/O演进有了一个更加直观的认识。后面的第2章节会对阻塞I/O和非阻塞IO进行详细讲解，同时给出代码示例。相信学完第2章之后，大家就能够对传统的阻塞I/O 的弊端和非阻塞IO的优点有更加深刻的体会。好，稍微休息片刻，我们继续畅游在NIO编程的快乐海洋中!