Java IO 深入理解

最新推荐文章于 2022-02-17 21:21:31 发布

置顶 minGW_Lee

最新推荐文章于 2022-02-17 21:21:31 发布

阅读量585

点赞数 1

分类专栏：网络编程 socket IO

网络编程同时被 3 个专栏收录

2 篇文章 0 订阅

订阅专栏

socket

2 篇文章 0 订阅

订阅专栏

1 篇文章 0 订阅

订阅专栏

看了一段时间NIO之后，发现自己混淆了非阻塞和异步的概念。为了理清这些关系，这里就来详细了解下同步(Synchronous)、异步(ASynchronous)、阻塞(blocking)和非阻塞(non-blocking)这些概念。

这些概念的由来与操作系统的发展是分不开的，为什么这么说呢?这要从操作系统的内核态和用户态说起：

内核态：
CPU可以访问内存所有数据, 包括外围设备, 例如硬盘, 网卡. CPU也可以将自己从一个程序切换到另一个程序。（进城调度、文件读取、TCP/IP协议栈等都是工作在内核态）
用户态：
只能受限的访问内存, 且不允许访问外围设备. 占用CPU的能力被剥夺, CPU资源可以被其他程序获取（程序员开发的程序就是工作再这一层）

为什么要有用户态和内核态

由于需要限制不同的程序之间的访问能力，防止他们获取别的程序的内存数据，或者获取外围设备的数据, 并发送到网络, CPU划分出两个权限等级 – 用户态和内核态

用户态与内核态的切换

所有用户程序都是运行在用户态的, 但是有时候程序确实需要做一些内核态的事情, 例如从硬盘读取数据, 或者从键盘获取输入等. 而唯一可以做这些事情的就是操作系统, 所以此时程序就需要先请求操作系统以程序的名义来执行这些操作.

这时需要一个这样的机制: 用户态程序切换到内核态, 但是不能控制在内核态中执行的指令，这种机制叫系统调用, 在CPU中的实现称之为陷阱指令(Trap Instruction)。

系统调用工作流程如:

用户态程序执行系统调用.
CPU切换到内核态, 并跳到位于内存指定位置的指令, 这些指令是操作系统的一部分, 他们具有内存保护, 不可被用户态程序访问
这些指令称之为陷阱(trap)或者系统调用处理器(system call handler). 他们会读取程序放入内存的数据参数, 并执行程序请求的服务
系统调用完成后, 操作系统会重置CPU为用户态并返回系统调用的结果

应用程序

举例来说：你要转给张三1万元，肯定不能直接跑到银行里面，在银行内网的电脑上噼里啪啦转给张三的账户一万，你可以试试，估计会悲剧了。。。

你能做的就是先排个号，然后乖乖的在柜台上填单子写明张三的账户和转款的金额，填完了交给柜台的服务人员，让服务人员帮你你转账。在这个过程中银行就是内核，拍号就是系统调用，填写的单子就是系统调用的参数，柜台服务人员就是内核线程，所有的工作都是内核线程完成的。

同理网络编程(Socket是一个内核对象)也需要内核协助才能完成，如图：
Socket调用

通过socket对象的read方法发起系统调用
操作系统切换到内核态，同时将用户线程挂起
如果内核空间中有数据，就直接返回。如果没有数据就阻塞等待网卡缓冲区满了，将数据发送到内存
将内核空间的数据复制到用户空间

linux下有五种常见的IO模型。如图：

再说一下IO发生时涉及的对象和步骤。
对于一个network IO (这里我们以read举例)，它会涉及到两个系统对象，一个是调用这个IO的process (or thread)，另一个就是系统内核(kernel)。
当一个read操作发生时，它会经历两个阶段：

等待数据准备 (Waiting for the data to be ready)
将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)

记住这两点很重要，因为这些IO Model的区别就是在两个阶段上各有不同的情况。而同步与异步的主要区别就在于：当第一步调用完成之后用户线程是否等待内核线程完成数据准备工作。

blocking IO

在linux中，默认情况下所有的socket都是blocking，一个典型的读操作流程大概是这样：
BIO

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。
所以，blocking IO的特点就是在IO执行的两个阶段都被block了，如果TCP RecvBuffer里没有数据，函数会一直阻塞，直到收到数据，返回读到的数据。

non-blocking IO

linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时，流程是这个样子：

NIO

从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。
所以，用户进程其实是需要不断的主动询问kernel数据好了没有，当然用宝贵的CPU时间做轮询太不靠谱了！
所以，non blocking IO的特点就是在IO执行的第二个阶段被block了，但是第一阶段需要不断轮询。即如果TCP RecvBuffer有数据，就把数据从网卡读到内存，并且返回给用户；反之则直接返回0，永远不会阻塞。。

多路复用IO模型

多路复用是让阻塞发生在我们的多路复用IO操作的系统调用上面，而不是我们真正去执行IO的系统调用。使用这个方式的好处就是可以同时监控多个用于IO的文件描述符。通过用户进程来询问太浪费cpu了，于是就将询问的活交给内核来干，内核可以通过一个进程监控多个调用，省时又省力。
多路复用

当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。
这个图和blocking IO的图其实并没有太大的不同，事实上，还更差一些。因为这里需要使用两个system call (select 和 recvfrom)，而blocking IO只调用了一个system call (recvfrom)。但是，用select的优势在于它可以同时处理多个connection。（多说一句。所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）
在IO multiplexing Model中，实际中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。而通常我们都是讲select交由一个线程来负责，这样其他线程就不会阻塞

信号驱动IO模型

所谓信号驱动，就是利用信号机制，安装信号SIGIO的处理函数（进行IO相关操作），通过监控文件描述符，当其就绪时，通知目标进程进行IO操作（signal handler）。这种方式更近了一步，当你需要数据的时候，只是发送一个信号量就行，当内核的数据就绪之后，就会通知用户进程去复制数据。
信号驱动

异步IO模型

异步就是当你只需要发起一个一步的系统调用，操作系统内核不但把数据从网卡的缓冲区复制到内核空间，还讲内核空间的数据复制到用户空间。用户进程需要做的就是使用数据。
AIO

总结

现在回过头来回答最初的那几个问题：blocking和non-blocking的区别在哪，synchronous IO和asynchronous IO的区别在哪。
先回答最简单的这个：blocking vs non-blocking。
前面的介绍中其实已经很明确的说明了这两者的区别。调用blocking IO会一直block住对应的进程直到操作完成，而non-blocking IO在kernel还准备数据的情况下会立刻返回。

在说明synchronous IO和asynchronous IO的区别之前，需要先给出两者的定义。Stevens给出的定义（其实是POSIX的定义）是这样子的：

A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
两者的区别就在于synchronous IO做”IO operation”的时候会将process阻塞。按照这个定义，之前所述的blocking IO，non-blocking IO，IO multiplexing都属于synchronous IO。有人可能会说，non-blocking IO并没有被block啊。这里有个非常“狡猾”的地方，定义中所指的”IO operation”是指真实的IO操作，就是例子中的recvfrom这个system call。non-blocking IO在执行recvfrom这个system call的时候，如果kernel的数据没有准备好，这时候不会block进程。但是，当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了，在这段时间内，进程是被block的。而asynchronous IO则不一样，当进程发起IO 操作之后，就直接返回再也不理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block。

下图是这几种常见I/O模型的对比：
常见I/O模型对比

经过上面的介绍，会发现non-blocking IO和asynchronous IO的区别还是很明显的。在non-blocking IO中，虽然进程大部分时间都不会被block，但是它仍然要求进程去主动的check，并且当数据准备完成以后，也需要进程主动的再次调用recvfrom来将数据拷贝到用户内存。而asynchronous IO则完全不同。它就像是用户进程将整个IO操作交给了他人（kernel）完成，然后他人做完后发信号通知。在此期间，用户进程不需要去检查IO操作的状态，也不需要主动的去拷贝数据。

最后，再举几个不是很恰当的例子来说明这四个IO Model:

有A，B，C，D四个人在钓鱼：

A用的是最老式的鱼竿，所以呢，得一直守着，等到鱼上钩了再拉杆；

B的鱼竿有个功能，能够显示是否有鱼上钩，所以呢，B就和旁边的MM聊天，隔会再看看有没有鱼上钩，有的话就迅速拉杆；

C用的鱼竿和B差不多，但他想了一个好办法，就是同时放好几根鱼竿，然后守在旁边，一旦有显示说鱼上钩了，它就将对应的鱼竿拉起来；

D是个有钱人，干脆雇了一个人帮他钓鱼，一旦那个人把鱼钓上来了，就给D发个短信。

附加几个参考地址：
https://zhuanlan.zhihu.com/p/23488863
http://blog.csdn.net/historyasamirror/article/details/5778378
https://my.oschina.net/u/2485707/blog/796411