IO模型

知识点

内核缓冲区与进程缓冲区

在用户进行IO读写操作时并不是直接从物理设备把数据读取到内存或者直接把数据写入到物理设备。在物理设备和用户直接存在着内核缓冲区和进程缓冲区（用户进程自己的缓冲区）这两个区域，比如用户在进行read操作时，是把数据从内核缓冲区复制到进程缓冲区，同理，在进行write操作时是把数据从进程缓冲区复制到内核缓冲区。
也就是说上层程序的IO操作实际上不是物理设备级别的读写操作，而是对缓存的读写操作。而IO设备的中断处理（读中断、写中断），集中执行物理设备的实际IO操作（将数据从物理设备读取到内核缓冲区、将内核缓冲区数据更新到物理设备），由操作系统的内核来决定，用户程序无需关心。

IO中的同步与异步的概念

同步IO是指用户所在的线程是主动发起IO请求的一方，内核空间是被动接受方。异步IO则相反，系统内核是主动发起IO请求的一方，用户空间的线程是被动接受方，类型于回调这么的一个机制。

IO模型

同步阻塞IO（Blocking IO）

在阻塞式IO模型中，Java应用程序从IO系统调用开始，直到系统调用返回，在这段时间内，Java进程是阻塞的。返回成功后，应用进程开始处理用户空间的缓存区数据。

优点：应用的程序开发非常简单；在阻塞等待数据期间，用户线程挂起。在阻塞期间，用户线程基本不会占用CPU资源。
缺点：一般情况下，会为每个连接配备一个独立的线程；反过来说，就是一个线程维护一个连接的IO操作。在并发量小的情况下，这样做没有什么问题。但是，当在高并发的应用场景下，需要大量的线程来维护大量的网络连接，内存、线程切换开销会非常巨大。

同步非阻塞IO（None Blocking IO）

在内核缓冲区中没有数据的情况下，系统调用会立即返回，返回一个调用失败的信息。在内核缓冲区中有数据的情况下，是阻塞的，直到数据从内核缓冲复制到用户进程缓冲。复制完成后，系统调用返回成功，应用进程开始处理用户空间的缓存数据。

优点：每次发起的IO系统调用，在内核等待数据过程中可以立即返回。用户线程不会阻塞，实时性较好。
缺点：不断地轮询内核，这将占用大量的CPU时间，效率低下。

IO多路复用模型（IO Multiplexing）

在IO多路复用模型中，引入了一种新的系统调用，查询IO的就绪状态。在Linux系统中，对应的系统调用为select/epoll系统调用。通过该系统调用，一个进程可以监视多个文件描述符，一旦某个描述符就绪（一般是内核缓冲区可读/可写），内核能够将就绪的状态返回给应用程序。随后，应用程序根据就绪的状态，进行相应的IO系统调用。
目前支持IO多路复用的系统调用，有select、epoll等等。select系统调用，几乎在所有的操作系统上都有支持，具有良好的跨平台特性。epoll是在Linux2.6内核中提出的，是select系统调用的Linux增强版本。
在IO多路复用模型中通过select/epoll系统调用，单个应用程序的线程，可以不断地轮询成百上千的socket连接，当某个或者某些socket网络连接有IO就绪的状态，就返回对应的可以执行的读写操作。

优点：与一个线程维护一个连接的阻塞IO模式相比，使用select/epoll的最大优势在于，一个选择器查询线程可以同时处理成千上万个连接。系统不必创建大量的线程，也不必维护这些线程，从而大大减小了系统的开销。
缺点：本质上，select/epoll系统调用是阻塞式的，属于同步IO。都需要在读写事件就绪后，由系统调用本身负责进行读写，也就是说这个读写过程是阻塞的。

异步IO模型（Asynchronous IO）

用户线程通过系统调用，向内核注册某个IO操作。内核在整个IO操作（包括数据准备、数据复制）完成后，通知用户程序，用户执行后续的业务操作。

特点：在内核等待数据和复制数据的两个阶段，用户线程都不是阻塞的。用户线程需要接收内核的IO操作完成的事件，或者用户线程需要注册一个IO操作完成的回调函数。正因为如此，异步IO有的时候也被称为信号驱动IO。
缺点：应用程序仅需要进行事件的注册与接收，其余的工作都留给了操作系统，也就是说，需要底层内核提供支持。目前而言，Windows系统下通过IOCP实现了真正的异步IO。而在Linux系统下，异步IO模型在2.6版本才引入，目前并不完善，其底层实现仍使用epoll与IO多路复用相同，因此在性能上没有明显的优势。大多数的高并发服务器端的程序，一般都是基于Linux系统的。因而，目前这类高并发网络应用程序的开发，大多采用IO多路复用模型。