案例代码:https://github.com/anxpp/Java-IO

概念剖析

相信很多从事linux后台开发工作的都接触过同步&异步、阻塞&非阻塞这样的概念，也相信都曾经产生过误解，比如认为同步就是阻塞、异步就是非阻塞，下面我们先剖析下这几个概念分别是什么含义。

同步

所谓同步，就是在发出一个功能调用时，在没有得到结果之前，该调用就不返回。也就是必须一件一件事做,等前一件做完了才能做下一件事。
例如普通B/S模式（同步）：提交请求->等待服务器处理->处理完毕返回 这个期间客户端浏览器不能干任何事

异步：

异步的概念和同步相对。当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者。
例如 ajax请求（异步）: 请求通过事件触发->服务器处理（这是浏览器仍然可以作其他事情）->处理完毕

阻塞：

阻塞调用是指调用结果返回之前，当前线程会被挂起（线程进入非可执行状态，在这个状态下，cpu不会给线程分配时间片，即线程暂停运行）。函数只有在得到结果之后才会返回。
有人也许会把阻塞调用和同步调用等同起来，实际上他是不同的。对于同步调用来说，很多时候当前线程还是激活的，只是从逻辑上当前函数没有返回,它还会抢占cpu去执行其他逻辑，也会主动检测io是否准备好。

非阻塞

非阻塞和阻塞的概念相对应，指在不能立刻得到结果之前，该函数不会阻塞当前线程，而会立刻返回。
再简单点理解就是：

  1. 同步，就是我调用一个功能，该功能没有结束前，我死等结果。
  2. 异步，就是我调用一个功能，不需要知道该功能结果，该功能有结果后通知我（回调通知）
  3. 阻塞，就是调用我（函数），我（函数）没有接收完数据或者没有得到结果之前，我不会返回。
  4. 非阻塞，就是调用我（函数），我（函数）立即返回，通过select通知调用者

同步IO和异步IO的区别就在于：数据拷贝的时候进程是否阻塞
阻塞IO和非阻塞IO的区别就在于：应用程序的调用是否立即返回
综上可知，同步和异步,阻塞和非阻塞,有些混用,其实它们完全不是一回事,而且它们修饰的对象也不相同。

五种IO模型

在了解了同步与异步、阻塞与非阻塞概念后，我们来讲讲linux的五种IO模型：
同步模型（synchronous IO）

  1. 阻塞IO（bloking IO）
  2. 非阻塞IO（non-blocking IO）
  3. 多路复用IO（multiplexing IO）
  4. 信号驱动式IO（signal-driven IO）

异步IO（asynchronous IO）

同步阻塞

它是最简单也最常用的网络IO模型。linux下默认的socket都是blocking的。

从图中可以看到，用户进程调用recvfrom这个系统调用后，就处于阻塞状态。然后kernel就开始了IO的第一个阶段：数据准备。等第一个阶段准备完成之后，kernel开始第二阶段，将数据从内核缓冲区拷贝到用户程序缓冲区（需要花费一定时间）。然后kernel返回结果（确切的说是recvfrom这个系统调用函数返回结果），用户进程才结束blocking，重新运行起来。 总结：同步阻塞模型下，用户程序在kernel执行io的两个阶段都被blocking住了。但是优点也是因为这个，无延迟能及时返回数据，且程序模型简单。

同步非阻塞

同步非阻塞就是隔一会瞄一下的轮询方式。同步非阻塞模式其实是可以看做一小段一小段的同步阻塞模式。

如图所示，用户进程在read过程中，同样也是先发起recvfrom这个系统调用，不同的是，如果io第一阶段还没准备好，也即内核缓冲区中的数据还没到位的话，recvfrom不会等待数据到位，而是直接给用户程序返回一个error，用户程序收到error后就知道kernel的数据没到位，用户程序可以先去干点别的事，等过了一会再发起recvfrom调用来看看kernel的数据有没有到位。经过一次次的轮询。。。终于当内核中的数据准备就绪且又收到了用户程序发起的recvfrom调用后，kernel会将kernel缓冲区中的数据拷贝到用户程序地址空间。但是请注意：在第二阶段将数据从kernel缓冲区拷贝到用户程序空间的这段时间内，用户程序是阻塞的。
总结：
优点：能够在等待任务完成的时间里干其他活了（包括提交其他任务，也就是 “后台” 可以有多个任务在同时执行）。
缺点：任务完成的响应延迟增大了，因为每过一段时间才去轮询一次read操作，而任务可能在两次轮询之间的任意时间完成。这会导致整体数据吞吐量的降低。

信号驱动式IO（signal-driven IO）

信号驱动式I/O：首先我们允许Socket进行信号驱动IO,并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。过程如下图所示：
Netty教程(一) - 图1

IO多路复用

Netty教程(一) - 图2

由于同步非阻塞方式需要不断的轮询，光轮询就占据了很大一部分过程，且消耗cpu资源。而这个用户进程可能不止对这个socket的read，可能还有对其他socket的read或者write操作，那人们就想到了一次轮询的时候，不光只查询询一个socket fd，而是在一次轮询下，查询多个任务的socket fd的完成状态，只要有任何一个任务完成，就去处理它。而且，轮询人不是进程的用户态，而是有人帮忙就好了。那么这就是所谓的IO多路复用。总所周知的linux下的select，poll和epoll就是这么干的。。。

selelct调用是内核级别的，selelct轮询相比较同步非阻塞模式下的轮询的区别为：前者可以等待多个socket，能实现同时对多个IO端口的监听，当其中任何一个socket数据准备好了，就返回可读。select或poll调用之后，会阻塞进程，与blocking IO 阻塞不用在于，此时的select不是等到所有socket数据达到再处理，而是某个socket数据就会返回给用户进程来处理。
其实select这种相比较同步non-blocking的效果在单个任务的情况下可能还更差一些，因为这里调用了select和recvfrom两个system call，而non-blocking只调用了一个recvfrom，但是用select的优势在于它可以同时处理多个socket fd。

在io复用模型下，对于每一个socket，一般都设置成non-blocking，但是其实整个用户进程是一直被block的，只不过用户process不是被socket IO给block住，而是被select这个函数block住的。
与多进程多线程技术相比，IO多路复用的最大优势是系统开销小

select

select函数监视多个socket fs，直到有描述符就绪或者超时，函数返回。当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。select的基本流程为：
select的特点：
1：最大缺陷是单个进程锁打开的fd是有限制的，32位机器上是1024个，64位机器上是2048个，虽然可以改这个数值，但是会造成性能下降。
2：对socket进行扫描时是线性扫描，当套接字比较多时，不管哪个socket是活跃的，都要遍历一遍fdset，很耗时耗cpu（
如果能给套接字注册某个回调函数，当本套接字活跃时，自动完成相关操作，就不用轮询，实际上epoll就是改了这儿
）
3：需要维护一个用来存放大量fd的数据结构，且在kernel缓冲区和用户缓冲区之间拷贝这个结构的开销很大。

poll

poll本质上跟select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd的状态，如果某个fd的状态为就绪，则将此fd加入到等待队列中并继续遍历。如果遍历完所有的fd后发现没有就绪的，则挂起当前进程，直到设备就绪或者主动超时。被唤醒后它又要再次遍历fd。
特点：
1：poll没有最大连接数限制，因为它是用基于链表来存储的，跟selelct直接监听fd不一样。
2：同样的大量的fd的数组被整体复制与用户态和内核地址空间之间。
3：poll还有一个特点是水平触发：如果报告了fd后没有被处理，则下次poll时还会再次报告该fd。
4：跟select一样，在poll返回后，还是需要通过遍历fdset来获取已经就绪的socket。当fd很多时，效率会线性下降。

epoll

epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）。

效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数；即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。

内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。

异步IO

Netty教程(一) - 图3

用户进程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。
然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了

五中模式对比图

Netty教程(一) - 图4

JAVA NIO

Java NIO 由以下几个核心部分组成：
Channels Buffers Selectors

Channel 和 Buffer

所有的 IO 在NIO 中都从一个Channel 开始。Channel 有点像流。 数据可以从Channel读到Buffer中，也可以从Buffer 写到Channel中。这里有个图示：
Netty教程(一) - 图5

Channel和Buffer有好几种类型。下面是JAVA NIO中的一些主要Channel的实现：
FileChannel DatagramChannel SocketChannel ServerSocketChanne

正如你所看到的，这些通道涵盖了UDP 和 TCP 网络IO，以及文件IO。 与这些类一起的有一些有趣的接口，但为简单起见，我尽量在概述中不提到它们。本教程其它章节与它们相关的地方我会进行解释。
以下是Java NIO里关键的Buffer实现：

  • ByteBuffer
  • CharBuffer
  • DoubleBuffer
  • FloatBuffer
  • IntBuffer
  • LongBuffer
  • ShortBuffer

这些Buffer覆盖了你能通过IO发送的基本数据类型：byte, short, int, long, float, double 和 char。

Java NIO 还有个 MappedByteBuffer，用于表示内存映射文件， 我也不打算在概述中说明。

Selector

Selector允许单线程处理多个 Channel。如果你的应用打开了多个连接（通道），但每个连接的流量都很低，使用Selector就会很方便。例如，在一个聊天服务器中。
这是在一个单线程中使用一个Selector处理3个Channel的图示：
Netty教程(一) - 图6

要使用Selector，得向Selector注册Channel，然后调用它的select()方法。这个方法会一直阻塞到某个注册的通道有事件就绪。一旦这个方法返回，线程就可以处理这些事件，事件的例子有如新连接进来，数据接收等。