从传统的阻塞I/O和线程池模型面临的问题讲起，然后对比几种常见I/O模型，一步步分析NIO怎么利用事件模型处理I/O，解决线程池瓶颈处理海量连接，包括利用面向事件的方式编写服务端/客户端程序。再延展到一些高级主题，如Reactor与Proactor模型的对比、Buffer的选择等。最后还会参考一下Linux的IO多路复用，映照着理解。

一、传统BIO、NIO对比

1.1 传统BIO模型分析

让我们先回忆一下传统的服务器端同步阻塞I/O处理（也就是BIO，Blocking I/O）的经典编程模型，服务器为每个客户端启动一个线程，这个线程会全心全意为这个客户端服务，但这个模式有一个重大弱点，它倾向于让CPU进行IO等待：

ExecutorService executor = Excutors.newFixedThreadPollExecutor(100);//线程池
ServerSocket serverSocket = new ServerSocket();
serverSocket.bind(8088);
while(!Thread.currentThread.isInturrupted()){    //主线程死循环等待新连接到来
    Socket socket = serverSocket.accept();       // 等待连接建立
    executor.submit(new ConnectIOnHandler(socket));   //为新的连接创建新的线程

class ConnectIOnHandler extends Thread{
    private Socket socket;
    public ConnectIOnHandler(Socket socket){
        this.socket = socket;
    }
    public void run(){
        while(!Thread.currentThread.isInturrupted()&&!socket.isClosed()){// 死循环处理读写事件
            String someThing = socket.read()....//读取数据
                if(someThing!=null){
                    ......//处理数据
                        socket.write()....//写数据
                    }
        }
    }
}

这是一个经典的一个Socket连接对应一个线程的IO模型。这里以多线程为例，主要是因为socket.accept()、socket.read()、socket.write()三个主要函数都是同步阻塞的，当一个Socket在处理IO时，系统是阻塞的。这时候可以利用多线程的本质:

• 利用多核
• 当I/O阻塞系统，但CPU空闲的时候，可以利用多线程使用CPU资源

并且现在的多线程一般使用线程池，可以让线程的创建回收成本相对较低。线程池本身就是一个天然的漏斗，可以缓冲一些系统处理不了的连接或请求。

不过，这个模型最本质的问题在于，严重依赖于线程。但线程是很”贵”的资源，主要表现在：

• 线程的创建和销毁成本很高：在Linux这样的操作系统中，线程本质上就是一个轻量级的进程，创建和销毁都是重量级的系统函数
• 线程本身占用较大内存：像Java的线程栈，一般至少分配512K～1M的空间，如果系统中的线程数过千，恐怕整个JVM的内存都会被吃掉一半
• 线程的切换成本是很高的：操作系统发生线程切换的时候，需要保留线程的上下文，然后执行系统调用。如果线程数过高，可能执行线程切换的时间甚至会大于线程执行的时间，这时候带来的表现往往是系统load偏高、CPU sy使用率特别高（超过20%以上)，导致系统几乎陷入不可用的状态
• 容易造成锯齿状的系统负载：系统负载是用活动线程数或CPU核心数，一旦线程数量高但外部网络环境不是很稳定，就很容易造成大量请求的结果同时返回，激活大量阻塞线程从而使系统负载压力过大

所以，当面对十万甚至百万级连接的时候，传统的BIO模型是无能为力的。随着移动端应用的兴起和各种网络游戏的盛行，百万级长连接日趋普遍，此时，必然需要一种更高效的I/O处理模型。

1.2 NIO是怎么工作的

所有的系统I/O都分为两个阶段：等待就绪和操作。举例来说：读函数，分为等待系统可读和真正读；同理，写函数分为等待网卡可写和真正写。

需要说明的是等待就绪的阻塞是不使用CPU的，线程处于空转状态。而真正的读写操作的阻塞是使用CPU的，真正在干活。而且这个过程非常快，属于memory copy，带宽通常在1GB/s级别以上，可以理解为基本不耗时。

以socket.read()为例子：

传统的BIO里面socket.read()，如果TCP RecvBuffer里没有数据，函数会一直阻塞，直到收到数据，返回读到的数据。对于NIO，如果TCP RecvBuffer有数据，就把数据从网卡读到内存，并且返回给用户；反之则直接返回0，永远不会阻塞。

最新的AIO(Async I/O)里面会更进一步：不但等待就绪是非阻塞的，就连数据从网卡到内存的过程也是异步的。

换句话说，BIO里用户最关心“我要读”，NIO里用户最关心”我可以读了”，在AIO模型里用户更需要关注的是“读完了”。BIO和NIO中数据的IO仍然需要用户自行完成，AIO中数据的IO是由内核完成的。

NIO一个重要的特点是：socket主要的读、写、注册和接收函数，在等待就绪阶段都是非阻塞的，真正的I/O操作是同步阻塞的（消耗CPU但性能非常高）。

1.2.1 结合事件模型使用NIO同步非阻塞特性

回忆BIO模型，之所以需要多线程，是因为在进行I/O操作的时候，一是没有办法知道到底能不能写、能不能读，只能”傻等”。即使通过各种估算，算出来操作系统没有能力进行读写，也没法在socket.read()和socket.write()函数中返回，这两个函数无法进行有效的中断。所以除了多开线程另起炉灶，没有好的办法利用CPU。

NIO的读写函数可以立刻返回，这就给了我们不开线程利用CPU的最好机会：如果一个连接不能读写（socket.read()返回0或者socket.write()返回0），我们可以 把这件事记下来，记录的方式通常是在Selector上注册标记位，然后切换到其它就绪的连接（channel）继续进行读写。

下面具体看下如何利用事件模型单线程处理所有I/O请求：NIO的主要事件有几个：读就绪（read）、写就绪（write）、有新连接到来（connect）。

首先需要注册当这几个事件到来的时候所对应的处理器，然后在合适的时机告诉事件选择器：我对这个事件感兴趣。对于写操作，就是写不出去的时候对写事件感兴趣；对于读操作，就是完成连接和系统没有办法承载新读入的数据的时；对于accept，一般是服务器刚启动的时候；而对于connect，一般是connect失败需要重连或者直接异步调用connect的时候。

其次，用一个死循环选择就绪的事件执行系统调用（Linux 2.6之前是select、poll，2.6之后是epoll（这几个概念后文专门解释），Windows是IOCP），还会阻塞的等待新事件的到来。新事件到来的时候，会在selector上注册标记位，标示可读、可写或者有连接到来。

select是阻塞的，无论是通过操作系统的通知（epoll）还是不停的轮询(select，poll)，这个函数是阻塞的。所以你可以放心大胆地在一个while(true)里面调用这个函数而不用担心CPU空转。

程序大概的模样是：

interface ChannelHandler{
    void channelReadable(Channel channel);
    void channelWritable(Channel channel);
}
class Channel{
    Socket socket;  // 关联Socket连接
    Event event;    // 注册关心的事件：读、写或者连接
}
//IO线程主循环
class IoThread extends Thread{
    public void run(){
        Channel channel;
        while(channel=Selector.select()){//选择就绪的事件和对应的连接
            if(channel.event==accept){
                registerNewChannelHandler(channel);//如果是新连接，则注册一个新的读写处理器
            }
            if(channel.event==write){
                getChannelHandler(channel).channelWritable(channel);//如果可以写，则执行写事件
            }
            if(channel.event==read){
                getChannelHandler(channel).channelReadable(channel);//如果可以读，则执行读事件
            }
        }
    }
    Map<Channel，ChannelHandler> handlerMap;//所有channel的对应事件处理器
}

这个程序很简短，也是最简单的Reactor模式：注册所有感兴趣的事件处理器，单线程轮询选择就绪事件，执行事件处理器。

1.3. 小结：两者的主要区别

1.3.1 面向流与面向缓冲

Java BIO面向流意味着每次从流中读一个或多个字节，直至读取所有字节，它们没有被缓存在任何地方。此外，它不能前后移动流中的数据。如果需要前后移动从流中读取的数据，需要先将它缓存到一个缓冲区。

Java NIO的缓冲导向方法略有不同。数据读取到一个它稍后处理的缓冲区，需要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性。但是，还需要检查是否该缓冲区中包含所有您需要处理的数据。而且，需确保当更多的数据读入缓冲区时，不要覆盖缓冲区里尚未处理的数据。

1.3.2 阻塞与非阻塞IO

Java BIO的各种流是阻塞的。这意味着，当一个线程调用read() 或 write()时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了。

Java NIO的非阻塞模式，使一个线程从某通道发送请求读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取。而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。 非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。 线程通常将非阻塞IO的空闲时间用于在其它通道上执行IO操作，所以一个单独的线程现在可以管理多个输入和输出通道（channel）**。**

二、NIO的核心部分

NIO主要有三大核心部分：Channel(通道)、Buffer(缓冲区)、 Selector（选择器）。传统IO基于字节流和字符流进行操作，而NIO基于Channel和Buffer(缓冲区)进行操作，数据总是从通道读取到缓冲区中，或者从缓冲区写入到通道中。Selector用于监听多个通道的事件，单个线程可以监听多个数据通道Channel。

2.1 Channel

Channel和IO中的Stream(流)是差不多一个等级的。只不过Stream是单向的，譬如：InputStream, OutputStream。而Channel是双向的，既可以用来进行读操作，又可以用来进行写操作。NIO中的Channel的主要实现有：

• FileChannel
• DatagramChannel
• SocketChannel
• ServerSocketChannel
  

这里看名字就可以猜出个所以然来：分别可以对应文件IO、UDP和TCP（Server和Client）。

2.2 Buffer

通常情况下，操作系统的一次写操作分为两步：

• 将数据从用户空间拷贝到系统空间
• 从系统空间往网卡写

同理，读操作也分为两步：

• 将数据从网卡拷贝到系统空间
• 将数据从系统空间拷贝到用户空间

对于NIO来说，缓存的使用可以使用DirectByteBuffer和HeapByteBuffer。如果使用了DirectByteBuffer，一般来说可以减少一次系统空间到用户空间的拷贝。但Buffer创建和销毁的成本更高，更不宜维护，通常会用内存池来提高性能。如果数据量比较小的中小应用情况下，可以考虑使用heapBuffer；反之可以用directBuffer。

2.3 Selectors

Java NIO的选择器允许一个单独的线程同时监视多个通道，可以注册多个通道到同一个选择器上，然后使用一个单独的线程来选择已经就绪的通道。这种选择机制为一个单独线程管理多个通道提供了可能。

Selector运行单线程处理多个Channel，如果应用打开了多个通道，但每个连接的流量都很低，使用Selector就会很方便。例如在一个聊天服务器中。要使用Selector, 得向Selector注册Channel，然后调用它的select方法。方法会一直阻塞到某个注册的通道有事件就绪。一旦这个方法返回，线程就可以处理这些事件，如新的连接进来、数据接收等。

2.4 Proactor与Reactor

I/O 复用机制需要事件分发器（event dispatcher），用于将那些读写事件源分发给各读写事件对应的事件处理器。开发人员在开始的时候需要在分发器那里注册感兴趣的事件，并提供相应的处理者（event handler)，或者是回调函数；事件分发器在适当的时候，会将请求的事件分发给这些handler或者回调函数。

• 在Reactor模式中，事件分发器等待某个事件可应用或某个操作的状态发生（比如文件描述符可读写，或者是socket可读写）变化，事件分发器就把这个事件传给事先注册的事件处理函数或者回调函数，由后者来做实际的读写操作
• 在Proactor模式中，事件处理者（或者代由事件分发器发起）直接发起一个异步读写操作（相当于请求），而实际的工作是由操作系统来完成的。发起时，需要提供的参数包括用于存放读到数据的缓存区、读的数据大小或用于存放外发数据的缓存区，以及这个请求完后的回调函数等信息。事件分发器得知了这个请求，它默默等待这个请求的完成，然后转发完成事件给相应的事件处理者或者回调。举例来说，在Windows上事件处理者投递了一个异步IO操作（称为overlapped技术），事件分发器等IO Complete事件完成。这种异步模式的典型实现是基于操作系统底层异步API的，所以我们可称之为“系统级别”的或者“真正意义上”的异步，因为具体的读写是由操作系统代劳的。

2.5 NIO存在的问题

• 使用NIO并不等于高性能，当连接数小于1000，并发程度不高或者局域网环境下NIO并没有显著的性能优势
• NIO并没有完全屏蔽平台差异，它仍然是基于各个操作系统的I/O系统实现的，差异仍然存在。使用NIO做网络编程构建事件驱动模型并不容易
• 推荐大家使用成熟的NIO框架，如Netty，MINA等。解决了很多NIO的陷阱，并屏蔽了操作系统的差异，有较好的性能和编程模型

2.6 适用范围

• BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序直观简单易理解
• NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持

三、Linux系统IO多路复用 select、poll与epoll

select，poll，epoll都是IO多路复用的机制。I/O多路复用可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。

3.1 前言：系统层面概念说明

在进行解释之前，首先要说明几个概念：

• 用户空间和内核空间
• 进程切换
• 进程的阻塞
• 文件描述符
• 缓存 I/O

3.1.1 用户空间与内核空间

现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操心系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。针对linux操作系统而言，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF），供内核使用，称为内核空间，而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。

3.1.2 进程切换

为了控制进程的执行，内核必须有能力挂起正在CPU上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。因此可以说，任何进程都是在操作系统内核的支持下运行的，是与内核紧密相关的。

从一个进程的运行转到另一个进程上运行，这个过程中经过下面这些变化：

• 保存处理器上下文，包括程序计数器和其他寄存器
• 更新PCB信息
• 把进程的PCB移入相应的队列，如就绪、在某事件阻塞等队列
• 选择另一个进程执行，并更新其PCB
• 更新内存管理的数据结构
• 恢复处理器上下文

总而言之就是很耗资源。

3.1.3 进程的阻塞

正在执行的进程，由于期待的某些事件未发生，如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等，则由系统自动执行阻塞原语(Block)，使自己由运行状态变为阻塞状态。可见，进程的阻塞是进程自身的一种主动行为，也因此只有处于运行态的进程（获得CPU），才可能将其转为阻塞状态。

当进程进入阻塞状态，是不占用CPU资源的。

3.1.4 文件描述符

文件描述符（fd，File descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

3.1.5 缓存 I/O

缓存 I/O 又被称作标准 I/O，大多数文件系统的默认 I/O 操作都是缓存 I/O。在 Linux 的缓存 I/O 机制中，操作系统会将 I/O 的数据缓存在文件系统的页缓存（ page cache ）中。数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到进程的缓冲区中。

缓存 I/O 的缺点在于：数据在传输过程中需要在应用程序地址空间和内核进行多次数据拷贝操作，这些数据拷贝操作所带来的 CPU 以及内存开销是非常大的。

3.2 I/O 多路复用

I/O 多路复用(IO multiplexing)就是我们说的select，poll，epoll，有些地方也称这种IO方式为事件驱动(event driven IO)。select/epoll的好处就在于单个进程就可以同时处理多个网络连接的IO。select，poll，epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。

所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符，而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select函数就可以返回。

所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用多线程multi-threading + 阻塞blocking IO的web server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。

在IO多路复用中，实际中，对于每一个socket，一般都设置成为非阻塞non-blocking，但整个用户进程其实是一直被阻塞的。只不过进程是被select这个函数阻塞，而不是被socket IO给阻塞。

3.3 select、poll、epoll详解

3.3.1 select

select的工作流程：单个进程就可以同时处理多个网络连接的io请求（同时阻塞多个io操作）。基本原理就是程序调用select，然后整个程序就阻塞了。这时候，select会将需要监控的readfds集合拷贝到内核空间（假设监控的仅仅是socket可读），kernel就会轮询检查所有select负责的fd，当找到一个client中的数据准备好了，select就会返回，这个时候程序就会系统调用，将数据从kernel复制到进程缓冲区。

通过上面的select逻辑过程分析，相信大家都意识到，select存在两个问题：

• 被监控的fds需要从用户空间拷贝到内核空间。为了减少数据拷贝带来的性能损坏，内核对被监控的fds集合大小做了限制，并且这个是通过宏控制的，大小不可改变(限制为1024)
• 被监控的fds集合中，只要有一个有数据可读，整个socket集合就会被遍历一次调用sk的poll函数收集可读事件。

由于当初的需求是朴素，仅仅关心是否有数据可读这样一个事件，当事件通知来的时候，由于数据的到来是异步的，我们不知道事件来的时候，有多少个被监控的socket有数据可读了，于是，只能挨个遍历每个socket来收集可读事件。

3.3.2 Poll

poll的原理与select非常相似，差别如下：

• 描述fd集合的方式不同：poll使用 pollfd 结构而不是select结构fd_set结构，所以poll是链式的，没有最大连接数的限制
• poll有一个特点是水平触发，也就是通知程序fd就绪后，这次没有被处理，那么下次poll的时候会再次通知同个fd已经就绪

poll机制虽然改进了select的监控大小1024的限制，但以下两个性能问题还没有解决：

• fds集合需要从用户空间拷贝到内核空间的问题
• 当被监控的fds中某些有数据可读的时候，希望通知更加精细一点，就是我们希望能够从通知中得到有可读事件的fds列表，而不是需要遍历整个fds来收集

3.3.3 epoll 解决问题

假设现实中，有1百万个客户端同时与一个服务器保持着tcp连接，而每一个时刻，通常只有几百上千个tcp连接是活跃的，这时候我们仍然使用select/poll机制，kernel必须在搜寻完100万个fd之后，才能找到其中状态是active的，这样资源消耗大而且效率低下。

(a) fds集合拷贝问题的解决

对于IO多路复用，有两件事是必须要做的(对于监控可读事件而言)：

• 准备好需要监控的fds集合
• 探测并返回fds集合中哪些fd可读了

细看select或poll的函数原型，我们会发现，每次调用select或poll都在重复地准备(集中处理)整个需要监控的fds集合。然而对于频繁调用的select或poll而言，fds集合的变化频率要低得多，我们没必要每次都重新准备(集中处理)整个fds集合。

于是，epoll引入了epoll_ctl系统调用，将高频调用的epoll_wait和低频的epoll_ctl隔离开。同时，epoll_ctl通过(EPOLL_CTL_ADD、EPOLL_CTL_MOD、EPOLL_CTL_DEL)三个操作来分散对需要监控的fds集合的修改，做到了有变化才变更，将select/poll高频、大块内存拷贝(集中处理)变成epoll_ctl的低频、小块内存的拷贝(分散处理)，避免了大量的内存拷贝。

(b) 按需遍历就绪的fds集合

为了做到只遍历就绪的fd，我们需要有个地方来组织那些已经就绪的fd。为此，epoll引入了一个中间层，一个双向链表(ready_list)，一个单独的睡眠队列(single_epoll_wait_list)。并且与select或poll不同的是，epoll的进程不需要同时插入到多路复用的socket集合的所有睡眠队列中，相反进程只是插入到中间层的epoll的单独睡眠队列中，进程睡眠在epoll的单独队列上，等待事件的发生。

3.3.4 小结

• select, poll是为了解決同时大量IO的情況（尤其网络服务器），但是随着连接数越多，性能越差
• epoll是select和poll的改进方案，在 linux 上可以取代 select 和 poll，可以处理大量连接的性能问题

参考链接

• Java NIO浅析
• 《实战Java高并发程序设计》
• Java NIO系列教程（十二） Java NIO与IO
• 攻破JAVA NIO技术壁垒
• Linux IO模式及 select、poll、epoll详解
• 细谈Select,Poll,Epoll
• 大话 Select、Poll、Epoll