读取文件时，程序经历了什么？

拼搏现实的明天。 2022-12-10 08:38 202阅读 0赞

承接上文《[一文彻底理解高性能高并发中的线程与线程池][Link 1]》，这是高性能、高并发系列的第二篇文章，在这里我们来到了I/O这一话题。

你有没有想过当我们执行I/O操作时计算机底层都发生了些什么？

在回答这个问题之前，我们先来看下为什么对于计算机来说I/O是极其重要的。

### **不能执行I/O的计算机是什么？** ###

相信对于程序员来说I/O操作是最为熟悉不过的了：

当我们使用C语言中的printf、C++中的"<<"，Python中的print，Java中的System.out.println等时，这是I/O；当我们使用各种语言读写文件时，这也是I/O；当我们通过TCP/IP进行网络通信时，这同样是I/O;当我们使用鼠标龙飞凤舞时，当我们扛起键盘在评论区里指点江山亦或是埋头苦干努力制造bug时、当我们能看到屏幕上的漂亮的图形界面时等等，这一切都是I/O。

想一想，如果没有I/O计算机该是一种多么枯燥的设备，不能看电影、不能玩游戏，也不能上网，这样的计算机最多就是一个大号的计算器。

既然I/O这么重要，那么到底什么才是I/O呢？

### **什么是I/O** ###

I/O就是简单的**数据Copy**，仅此而已。

这一点很重要，为了加深大家的印象，来，Everybody，Follow me，那边树上的朋友，还有那边墙上的朋友们，举起你们的双手，跟我唱，苍茫的天涯是。。。Sorry，I/O仅仅就是数据copy、I/O仅仅就是数据copy。

让我们先把演唱会的事情放在一边，既然是copy数据，又是从哪里copy到哪里呢？

如果数据是从外部设备copy到内存中，这就是Input。

如果数据是从内存copy到外部设备，这就是Output。

**内存与外部设备之间不嫌麻烦的来回copy数据就是Input and Output，简称I/O**（Input/Output），仅此而已。

![bbeec7a9682a7291e5805cb822da9f82.png][]

### **I/O与CPU** ###

现在我们知道了什么是I/O，接下来就是重点部分了，大家注意，坐稳了。

我们知道现在的CPU其主频都是数GHz起步，这是什么意思呢？简单说就是CPU执行机器指令的速度是纳秒级别的，而通常的I/O比如磁盘操作，一次磁盘seek大概在毫秒级别，**因此如果我们把CPU的速度比作战斗机的话，那么I/O操作的速度就是肯德鸡**。

![c8aadcf039dbe0c5aecf3efefe975e90.png][]

也就是说当我们的程序跑起来时(CPU执行机器指令)，其速度是要远远快于I/O速度的，那么接下来的问题就是二者速度相差这么大，那么我们该如何设计、该如何更加合理的高效利用系统资源呢？

既然有速度差异，而且进程在执行完I/O操作前不能继续向前推进，那么显然只有一个办法，那就是**等待，wait**。

同样是等待，有聪明的等待，也有傻傻的等待，简称傻等，那么是选择聪明的等待呢还是选择傻等呢？

假设你是一个急性子(CPU)，需要等待一个重要的文件，不巧的是这个文件只能快递过来(I/O)，那么这时你是选择什么事情都不干了，深情的注视着门口就像盼望着你的哈尼一样专心等待这个快递呢？还是暂时先不要管快递了，玩个游戏看个电影刷会儿短视频等快递来了再说呢？

很显然，更好的方法就是先去干其它事情，快递来了再说。

**因此这里的关键点就是快递没到前手头上的事情可以先暂停，切换到其它任务，等快递过来了再切换回来**。

理解了这一点你就能明白执行I/O操作时底层都发生了什么。

接下来让我们以读取磁盘文件为例来讲解这一过程。

### **执行I/O时底层都发生了什么** ###

在上一篇《[一文彻底理解高并发高性能中的线程与线程池][Link 1]》中，我们引入了进程和线程的概念，在支持线程的操作系统中，实际上被调度的是线程而不是进程，为了更加清晰的理解I/O过程，我们暂时假设操作系统只有进程这样的概念，先不去考虑线程，这并不会影响我们的讨论。

现在内存中有两个进程，进程A和进程B，当前进程A正在运行，如图所示：

![8205c37d03bbc98655e33fce8eefdf0b.png][]

进程A中有一段读取文件的代码，不管在什么语言中通常我们定义一个用来装数据的buff，然后调用read之类的函数，像这样：

read(buff);

这就是一种典型的I/O操作，当CPU执行到这段代码的时候会向磁盘发送读取请求，注意与CPU执行指令的速度相比，I/O操作操作是非常慢的，因此操作系统是不可能把宝贵的CPU计算资源浪费在无谓的等待上的，这时重点来了，注意接下来是重点哦。

由于外部设备执行I/O操作是相当慢的，因此在I/O操作完成之前进程是无法继续向前推进的，这就是所谓的**阻塞**，即通常所说的block。操作系统检测到进程向I/O设备发起请求后就暂停进程的运行，怎么暂停运行呢？很简单，只需要记录下当前进程的运行状态并把CPU的PC寄存器指向其它进程的指令就可以了。

进程有暂停就会有继续执行，因此操作系统必须保存被暂停的进程以备后续继续执行，显然我们可以用队列来保存被暂停执行的进程，如图所示，进程A被暂停执行并被放到阻塞队列中(注意，不同的操作系统会有不同的实现，可能每个I/O设备都有一个对应的阻塞队列，但这种实现细节上的差异不影响我们的讨论)。

![d09c84613c00d778110d2456aeb4012a.png][]

这时操作系统已经向磁盘发送了I/O请求，因此磁盘driver开始将磁盘中的数据copy到进程A的buff中，虽然这时进程A已经被暂停执行了，但这并不妨碍磁盘向内存中copy数据。注意，现代磁盘向内存copy数据时无需借助CPU的帮助，这就是所谓的DMA(Direct Memory Access)，这个过程如图所示：

![b5a4525012504ae2f35310a5b9d2e0d8.png][]

让磁盘先copy着数据，我们接着聊。

实际上操作系统中除了有阻塞队列之外也有**就绪**队列，所谓就绪队列是指队列里的进程准备就绪可以被CPU执行了，你可能会问为什么不直接执行非要有个就绪队列呢？答案很简单，那就是**僧多粥少**，在即使只有1个核的机器上也可以创建出成千上万个进程，CPU不可能同时执行这么多的进程，因此必然存在这样的进程，**即使其一切准备就绪也不能被分配到计算资源**，这样的进程就被放到了就绪队列。

现在进程B就位于就绪队列，万事俱备只欠CPU，如图所示：

![e10a5acb49b19f6ac686c027e8ad9666.png][]

当进程A被暂停执行后CPU是不可以闲下来的，因为就绪队列中还有嗷嗷待哺的进程B，这时操作系统开始在就绪队列中找下一个可以执行的进程，也就是这里的进程B。

此时操作系统将进程B从就绪队列中取出，找出进程B被暂停时执行到的机器指令的位置，然后将CPU的PC寄存器指向该位置，这样进程B就开始运行啦，如图所示：

![17a79900beca87943359eab08b8fb899.png][]

注意，注意，接下来的这段是重点中的重点。

注意观察上图，你能看出这种设计的精妙之处吗，这对于理解操作系统至关重要，关注公众号“码农的荒岛求生”回复“过程”二字你就能得到答案以及该过程的最后两个步骤啦。

### **零拷贝，Zero-copy** ###

最后需要注意的一点就是上面的讲解中我们直接把磁盘数据copy到了进程空间中，**但实际上一般情况下I/O数据是要首先copy到操作系统内部，然后操作系统再copy到进程空间中**。因此我们可以看到这里其实还有一层经过操作系统的copy，对于性能要求很高的场景其实也是可以绕过操作系统直接进行数据copy的，这也是本文描述的场景，这种绕过操作系统直接进行数据copy的技术被称为**Zero-copy**，也就零拷贝，高并发、高性能场景下常用的一种技术，原理上很简单吧。

### **总结** ###

本文讲解的是程序员常用的I/O，一般来说作为程序员我们无需关心，但是理解I/O背后的底层原理对于设计高性能、高并发系统是极为有益的，希望这篇能对大家加深对I/O的认识有所帮助。

![9af0baaf980bfed66f7894e662f1d274.png][]

[Link 1]: https://blog.csdn.net/github_37382319/article/details/108478589
[bbeec7a9682a7291e5805cb822da9f82.png]: /images/20221123/c493573a75374efeb6e5151084d54c45.png
[c8aadcf039dbe0c5aecf3efefe975e90.png]: /images/20221123/e9a0f3cbef484d08b6b9ea0d2e6bbffa.png
[8205c37d03bbc98655e33fce8eefdf0b.png]: /images/20221123/50c7cded55464aab81d412f638d9059a.png
[d09c84613c00d778110d2456aeb4012a.png]: /images/20221123/0478514439fa476d99cbaa08c404ec12.png
[b5a4525012504ae2f35310a5b9d2e0d8.png]: /images/20221123/3bffd169f01d4fcca16f53d9fb3577f6.png
[e10a5acb49b19f6ac686c027e8ad9666.png]: /images/20221123/f5e53a0f2bdb461db98002b2da1d4101.png
[17a79900beca87943359eab08b8fb899.png]: /images/20221123/69e6d889ae9949d799e03355639273e1.png
[9af0baaf980bfed66f7894e662f1d274.png]: /images/20221123/972267a0ee364dfaa46b6ef5e5b1a919.png