标签：而不是 中断处理 读取数据 reac input bsp 支持 关心 inux
本文的原则是：从基础讲起。IO的原理和模型是隐藏在编程知识底下的，是开发人员必须掌握的基础原理，是基础的基础，更是通关大公司面试的必备知识。本文从操作系统的底层原理入手，通过图文并茂的方式，为大家深入剖析高并发IO的底层原理，并介绍如何通过设置来让操作系统支持高并发。
大家知道，用户程序进行IO的读写，依赖于底层的IO读写，基本上会用到底层的read&write两大系统调用。在不同的操作系统中，IO读写的系统调用的名称可能不完全一样，但是基本功能是一样的。
这里涉及一个基础的知识：read系统调用，并不是直接从物理设备把数据读取到内存中；write系统调用，也不是直接把数据写入到物理设备。上层应用无论是调用操作系统的read，还是调用操作系统的write，都会涉及缓冲区。具体来说，调用操作系统的read，是把数据从内核缓冲区复制到进程缓冲区；而write系统调用，是把数据从进程缓冲区复制到内核缓冲区。
也就是说，上层程序的IO操作，实际上不是物理设备级别的读写，而是缓存的复制。read&write两大系统调用，都不负责数据在内核缓冲区和物理设备（如磁盘）之间的交换，这项底层的读写交换，是由操作系统内核（Kernel）来完成的。注：本文后文如果没有特别指明，内核即指操作系统内核。
在用户程序中，无论是Socket的IO、还是文件IO操作，都属于上层应用的开发，它们的输入（Input）和输出（Output）的处理，在编程的流程上，都是一致的。
为什么设置那么多的缓冲区，为什么要那么麻烦呢？缓冲区的目的，是为了减少频繁地与设备之间的物理交换。大家都知道，外部设备的直接读写，涉及操作系统的中断。发生系统中断时，需要保存之前的进程数据和状态等信息，而结束中断之后，还需要恢复之前的进程数据和状态等信息。为了减少这种底层系统的时间损耗、性能损耗，于是出现了内存缓冲区。
有了内存缓冲区，上层应用使用read系统调用时，仅仅把数据从内核缓冲区复制到上层应用的缓冲区（进程缓冲区）；上层应用使用write系统调用时，仅仅把数据从进程缓冲区复制到内核缓冲区中。底层操作会对内核缓冲区进行监控，等待缓冲区达到一定数量的时候，再进行IO设备的中断处理，集中执行物理设备的实际IO操作，这种机制提升了系统的性能。至于什么时候中断（读中断、写中断），由操作系统的内核来决定，用户程序则不需要关心。
从数量上来说，在Linux系统中，操作系统内核只有一个内核缓冲区。而每个用户程序（进程），有自己独立的缓冲区，叫作进程缓冲区。所以，用户程序的IO读写程序，在大多数情况下，并没有进行实际的IO操作，而是在进程缓冲区和内核缓冲区之间直接进行数据的交换。
前面讲到，用户程序所使用的系统调用read&write，它们不等价于数据在内核缓冲区和磁盘之间的交换。read把数据从内核缓冲区复制到进程缓冲区，write把数据从进程缓冲区复制到内核缓冲区，具体的流程，如图1-1所示。
图1-1 系统调用read&write的流程
这里以read系统调用为例，先看下一个完整输入流程的两个阶段：
等待数据准备好。
如果是read一个socket（套接字），那么以上两个阶段的具体处理流程如下：
再具体一点，如果是在Java服务器端，完成一次socket请求和响应，完整的流程如下：
服务器端编程，经常需要构造高性能的网络应用，需要选用高性能的IO模型。本文从最为基础的模型开始，为大家揭秘IO模型。常见的IO模型有四种：
首先，解释一下这里的阻塞与非阻塞：阻塞IO，指的是需要内核IO操作彻底完成后，才返回到用户空间执行用户的操作。阻塞指的是用户空间程序的执行状态。传统的IO模型都是同步阻塞IO。在Java中，默认创建的socket都是阻塞的。其次，解释一下同步与异步：同步IO，是一种用户空间与内核空间的IO发起方式。同步IO是指用户空间的线程是主动发起IO请求的一方，内核空间是被动接受方。异步IO则反过来，是指系统内核是主动发起IO请求的一方，用户空间的线程是被动接受方。
非阻塞IO，指的是用户空间的程序不需要等待内核IO操作彻底完成，可以立即返回用户空间执行用户的操作，即处于非阻塞的状态，与此同时内核会立即返回给用户一个状态值。简单来说：阻塞是指用户空间（调用线程）一直在等待，而不能干别的事情；非阻塞是指用户空间（调用线程）拿到内核返回的状态值就返回自己的空间，IO操作可以干就干，不可以干，就去干别的事情。非阻塞IO要求socket被设置为NONBLOCK。强调一下，这里所说的NIO（同步非阻塞IO）模型，并非Java的NIO（New IO）库。
异步IO，指的是用户空间与内核空间的调用方式反过来。用户空间的线程变成被动接受者，而内核空间成了主动调用者。这有点类似于Java中比较典型的回调模式，用户空间的线程向内核空间注册了各种IO事件的回调函数，由内核去主动调用。
在Java应用程序进程中，默认情况下，所有的socket连接的IO操作都是同步阻塞IO（Blocking IO）。在阻塞式IO模型中，Java应用程序从IO系统调用开始，直到系统调用返回，在这段时间内，Java进程是阻塞的。返回成功后，应用进程开始处理用户空间的缓存区数据。同步阻塞IO的具体流程，如图1-2所示。
图1-2 同步阻塞IO的流程
举个例子，在Java中发起一个socket的read读操作的系统调用，流程大致如下：
总之，阻塞IO的特点是：在内核进行IO执行的两个阶段，用户线程都被阻塞了。阻塞IO的优点是：应用的程序开发非常简单；在阻塞等待数据期间，用户线程挂起。在阻塞期间，用户线程基本不会占用CPU资源。阻塞IO的缺点是：一般情况下，会为每个连接配备一个独立的线程；反过来说，就是一个线程维护一个连接的IO操作。在并发量小的情况下，这样做没有什么问题。但是，当在高并发的应用场景下，需要大量的线程来维护大量的网络连接，内存、线程切换开销会非常巨大。因此，基本上阻塞IO模型在高并发应用场景下是不可用的。
socket连接默认是阻塞模式，在Linux系统下，可以通过设置将socket变成为非阻塞的模式（Non-Blocking）。使用非阻塞模式的IO读写，叫作同步非阻塞IO（None Blocking IO），简称为NIO模式。在NIO模型中，应用程序一旦开始IO系统调用，会出现以下两种情况：
同步非阻塞IO的流程，如图1-3所示。
图1-3 同步非阻塞IO的流程
举个例子。发起一个非阻塞socket的read读操作的系统调用，流程如下：
同步非阻塞IO的特点：应用程序的线程需要不断地进行IO系统调用，轮询数据是否已经准备好，如果没有准备好，就继续轮询，直到完成IO系统调用为止。
同步非阻塞IO的优点：每次发起的IO系统调用，在内核等待数据过程中可以立即返回。用户线程不会阻塞，实时性较好。同步非阻塞IO的缺点：不断地轮询内核，这将占用大量的CPU时间，效率低下。
总体来说，在高并发应用场景下，同步非阻塞IO也是不可用的。一般Web服务器不使用这种IO模型。这种IO模型一般很少直接使用，而是在其他IO模型中使用非阻塞IO这一特性。在Java的实际开发中，也不会涉及这种IO模型。
这里说明一下，同步非阻塞IO，可以简称为NIO，但是，它不是Java中的NIO，虽然它们的英文缩写一样，希望大家不要混淆。Java的NIO（New IO），对应的不是四种基础IO模型中的NIO（None Blocking IO）模型，而是另外的一种模型，叫作IO多路复用模型（IO Multiplexing）。
如何避免同步非阻塞IO模型中轮询等待的问题呢？这就是IO多路复用模型。在IO多路复用模型中，引入了一种新的系统调用，查询IO的就绪状态。在Linux系统中，对应的系统调用为select/epoll系统调用。通过该系统调用，一个进程可以监视多个文件描述符，一旦某个描述符就绪（一般是内核缓冲区可读/可写），内核能够将就绪的状态返回给应用程序。随后，应用程序根据就绪的状态，进行相应的IO系统调用。目前支持IO多路复用的系统调用，有select、epoll等等。select系统调用，几乎在所有的操作系统上都有支持，具有良好的跨平台特性。epoll是在Linux 2.6内核中提出的，是select系统调用的Linux增强版本。
在IO多路复用模型中通过select/epoll系统调用，单个应用程序的线程，可以不断地轮询成百上千的socket连接，当某个或者某些socket网络连接有IO就绪的状态，就返回对应的可以执行的读写操作。
举个例子来说明IO多路复用模型的流程。发起一个多路复用IO的read读操作的系统调用，流程如下：
IO多路复用模型的流程，如图1-4所示。
图1-4 IO多路复用模型的流程
IO多路复用模型的特点：IO多路复用模型的IO涉及两种系统调用（System Call），另一种是select/epoll（就绪查询），一种是IO操作。IO多路复用模型建立在操作系统的基础设施之上，即操作系统的内核必须能够提供多路分离的系统调用select/epoll。
和NIO模型相似，多路复用IO也需要轮询。负责select/epoll状态查询调用的线程，需要不断地进行select/epoll轮询，查找出达到IO操作就绪的socket连接。
IO多路复用模型与同步非阻塞IO模型是有密切关系的。对于注册在选择器上的每一个可以查询的socket连接，一般都设置成为同步非阻塞模型。仅是这一点，对于用户程序而言是无感知的。
IO多路复用模型的优点：与一个线程维护一个连接的阻塞IO模式相比，使用select/epoll的最大优势在于，一个选择器查询线程可以同时处理成千上万个连接（Connection）。系统不必创建大量的线程，也不必维护这些线程，从而大大减小了系统的开销。
Java语言的NIO（New IO）技术，使用的就是IO多路复用模型。在Linux系统上，使用的是epoll系统调用。
IO多路复用模型的缺点：本质上，select/epoll系统调用是阻塞式的，属于同步IO。都需要在读写事件就绪后，由系统调用本身负责进行读写，也就是说这个读写过程是阻塞的。
如何彻底地解除线程的阻塞，就必须使用异步IO模型。
异步IO模型（Asynchronous IO，简称为AIO）。AIO的基本流程是：用户线程通过系统调用，向内核注册某个IO操作。内核在整个IO操作（包括数据准备、数据复制）完成后，通知用户程序，用户执行后续的业务操作。
在异步IO模型中，在整个内核的数据处理过程中，包括内核将数据从网络物理设备（网卡）读取到内核缓冲区、将内核缓冲区的数据复制到用户缓冲区，用户程序都不需要阻塞。
异步IO模型的流程，如图1-5所示。
图1-5 异步IO模型的流程
举个例子。发起一个异步IO的read读操作的系统调用，流程如下：
异步IO模型的特点：在内核等待数据和复制数据的两个阶段，用户线程都不是阻塞的。用户线程需要接收内核的IO操作完成的事件，或者用户线程需要注册一个IO操作完成的回调函数。正因为如此，异步IO有的时候也被称为信号驱动IO。异步IO异步模型的缺点：应用程序仅需要进行事件的注册与接收，其余的工作都留给了操作系统，也就是说，需要底层内核提供支持。
理论上来说，异步IO是真正的异步输入输出，它的吞吐量高于IO多路复用模型的吞吐量。就目前而言，Windows系统下通过IOCP实现了真正的异步IO。而在Linux系统下，异步IO模型在2.6版本才引入，目前并不完善，其底层实现仍使用epoll，与IO多路复用相同，因此在性能上没有明显的优势。大多数的高并发服务器端的程序，一般都是基于Linux系统的。因而，目前这类高并发网络应用程序的开发，大多采用IO多路复用模型。大名鼎鼎的Netty框架，使用的就是IO多路复用模型，而不是异步IO模型。
本文的原则是：从基础讲起。本文彻底体现了这个原则。
本文聚焦的主题：一是底层IO操作的两个阶段，二是最为基础的四种IO模型，三是操作系统对高并发的底层的支持。
四种IO模型，基本上概况了当前主要的IO处理模型，理论上来说，从阻塞IO到异步IO，越往后，阻塞越少，效率也越优。在这四种IO模型中，前三种属于同步IO，因为真正的IO操作都将阻塞应用线程。
只有最后一种异步IO模型，才是真正的异步IO模型，可惜目前Linux操作系统尚欠完善。不过，通过应用层优秀框架如Netty，同样能在IO多路复用模型的基础上，开发出具备支撑高并发（如百万级以上的连接）的服务器端应用。
最后强调一下，本章是理论课，比较抽象，但是一定要懂。理解了这些理论之后，再学习后面的学习会事半功倍。
标签：而不是 中断处理 读取数据 reac input bsp 支持 关心 inux
原文地址：https://www.cnblogs.com/cnjf/p/14532263.html
