计算机内功心法03】三：一文彻底理解IO多路复用计算机内功心法04】四：进程切换与线程切换的区别

 

 

计算机内功心法03】三：一文彻底理解IO多路复用

计算机内功心法04】四：进程切换与线程切换的区别

 

【计算机内功心法】三：一文彻底理解IO多路复用

 

在讲解IO多路复用之前，我们需要预习一下文件以及文件描述符。

什么是文件

程序员使用I/O最终都逃不过文件。

因为这篇同属于高性能、高并发系列，讲到高性能、高并发就离不开Linux/Unix，因此这里就来讨论一下Linux世界中的文件。

实际上对于程序员来说文件是一个很简单的概念，我们只需要将其理解为一个N byte的序列就可以了：

 

b1, b2, b3, b4, ……. bN

 

实际上所有的I/O设备都被抽象为了文件这个概念，一切皆文件，Everything isFile，磁盘、网络数据、终端，甚至进程间通信工具管道pipe等都被当做文件对待。

linuxfile

所有的I/O操作也都是通过文件读写来实现的，这一非常优雅的抽象可以让程序员使用一套接口就能实现所有I/O操作。

常用的I/O操作接口一般有以下几类：

• 打开文件，open
• 改变读写位置，seek
• 文件读写，read、write
• 关闭文件，close

程序员通过这几个接口几乎可以实现所有I/O操作，这就是文件这个概念的强大之处。

文件描述符

在本篇第二节I/O过程中我们讲到，要想读取比如磁盘数据我们需要指定一个buff用来装入数据，是这样用的：

read(buff);

但是这里我们忽略了一个问题，那就是虽然我们执行了往哪里写数据，但是我们该从哪里读数据呢？从上一节中我们知道，通过文件这个概念我们能实现几乎所有I/O操作，因此这里少的一个主角就是文件。

那么我们一般都这么使用文件呢？

pexels-pixabay-261866

如果你周末去比较火的餐厅吃饭应该会有体会，一般周末这样的餐厅都会排队，然后服务员会给你一个排队序号，通过这个序号服务员就能找到你，这里的好处就是服务员无需记住你是谁、你的名字是什么、是不是保护环境爱好小动物等等，这里的关键点就是服务员对你一无所知，但是依然可以通过一个号码就能找到你。

同样的，在Linux世界使用文件，我们也需要借助一个号码，根据“弄不懂原则”，这个号码就被称为了文件描述符filedescriptors，在Linux世界中鼎鼎大名，其道理和上面那个排队号码一样。

因此，文件描述仅仅就是一个数字而已，但是通过这个数字我们可以操作一个打开的文件，这一点要记住。

1600146248647

有了文件描述符，进程对文件一无所知，比如文件在磁盘的什么位置上、内存是如何管理文件的等等，这些信息属于操作系统，进程无需关心，操作系统只需要给进程一个文件描述符就足够了。

因此我们来完善上述程序：

int fd = open(file_name);
read(fd, buff);

怎么样，是不是非常简单。

文件描述符太多了怎么办

经过了这么多的铺垫，终于到高性能、高并发这一主题了。

从前几节我们知道，所有I/O操作都可以通过文件样的概念来进行，这当然包括网络通信。

如果你是一个web服务器，当三次握手成功以后，我们通过调用accept同样会得到一个文件描述符，只不过这个文件描述符是用来进行网络通信的，通过读写该文件描述符你就可以同客户端通信。在这里为了概念上好理解，我们称之为链接描述符，通过这个描述符我们就可以读写客户端的数据了。

int conn_fd = accept(...); 

server的处理逻辑通常是读取客户端请求数据，然后执行某些特定逻辑：

if(read(conn_fd, request_buff) > 0) {
    do_something(request_buff);
}

是不是非常简单，然而世界终归是复杂的，也不是这么简单的。

接下来就是比较复杂的了。

giphy

既然我们的主题是高并发，那么server端就不可能只和一个客户端通信，而是成千上万个客户端。这时你需要处理不再是一个描述符这么简单，而是有可能要处理成千上万个描述符。

为了不让问题一上来就过于复杂，我们先简单化，假设只同时处理两个客户端的请求。

有的同学可能会说，这还不简单，这样写不就行了：

if(read(socket_fd1, buff) > 0) { // 处理第一个
    do_something();
}
if(read(socket_fd2, buff) > 0) {
    do_something();

在本篇第二节中我们讨论过这是非常典型的阻塞式I/O，如果读取第一个请求进程被阻塞而暂停运行，那么这时我们就无法处理第二个请求了，即使第二个请求的数据已经就位，这也就意味着所有其它客户端必须等待，而且通常情况下也不会只有两个客户端而是成千上万个，上万个连接也要这样串行处理吗。

聪明的你一定会想到使用多线程，为每个请求开启一个线程，这样一个线程被阻塞不会影响到其它线程了，注意，既然是高并发，那么我们要为成千上万个请求开启成千上万个线程吗，大量创建销毁线程会严重影响系统性能。

那么这个问题该怎么解决呢？

这里的关键点在于在进行I/O时，我们并不是到该文件描述对于的I/O设备是否是可读的、是否是可写的，在外设的不可读或不可写的状态下进行I/O只会导致进程阻塞被暂停运行。

因此要优雅的解决这个问题，就要从其它角度来思考这个问题了。

think2

不要打电话给我，有需要我会打给你

大家生活中肯定会接到过推销电话，而且不止一个，一天下来接上十个八个推销电话你的身体会被掏空的。

这个场景的关键点在于打电话的人并不知道你是不是要买东西，只能来一遍遍问你，因此一种更好的策略是不要让他们打电话给你，记下他们的电话，有需要的话打给他们。

也就是不要打电话给我，有需要我会打给你。

在这个例子中，你，就好比内核，推销者就好比应用程序，电话号码就好比文件描述符，和你用电话沟通就好比I/O。

现在你应该明白了吧，处理多个文件描述符的更好方法其实就存在于推销电话中。

因此相比上一节中我们主动通过I/O接口主动问内核这些文件描述符对应的外设是不是已经就绪了，一种更好的方法是，我们把这些内核一股脑扔给内核，并霸气的告诉内核：“我这里有1万个文件描述符，你替我监视着它们，有可以读写的文件描述符时你就告诉我，我好处理”。而不是弱弱的问内核：“第一个文件描述可以读写了吗？第二个文件描述符可以读写吗？第三个文件描述符可以读写了吗？”

这样应用程序就从“繁忙”的主动变为清闲的被动了，反正哪些设备ok了内核会通知我， 能偷懒我才不要那么勤奋。

dogcarry

这是一种不同的处理I/O的机制，同样需要起一个名字，再次祭出“弄不懂原则”，就叫I/O多路复用吧，这就是 I/O multiplexing。

I/O多路复用，I/O multiplexing

multiplexing一词其实多用于通信领域，为了充分利用通信线路，希望在一个信道中传输多路信号，要想在一个信道中传输多路信号就需要把这多路信号结合为一路，将多路信号组合成一个信号的设备被称为multiplexer，显然接收方接收到这一路组合后的信号后要恢复原先的多路信号，这个设备被称为demultiplexer，如图所示：

1598607337812

回到我们的主题。

所谓I/O多路复用指的是这样一个过程：

1. 我们拿到了一堆文件描述符(不管是网络相关的、还是磁盘文件相关等等，任何文件描述符都可以)
2. 通过调用某个函数告诉内核：“这个函数你先不要返回，你替我监视着这些描述符，当这堆文件描述符中有可以进行I/O读写操作的时候你再返回”
3. 当调用的这个函数返回后我们就能知道哪些文件描述符可以进行I/O操作了。

那么有哪些函数可以用来进行I/O多路复用呢？

在Linux世界中有这样三种机制可以用来进行I/O多路复用：

• select
• poll
• epoll

接下来我们就简单介绍一下牛掰的I/O多路复用三剑客。

swordman

I/O多路复用三剑客

本质上select、poll、epoll都是阻塞式I/O，也就是我们常说的同步I/O。

select：初出茅庐

在select这种I/O多路复用机制下，我们需要把想监控的文件描述集合通过函数参数的形式告诉select，然后select会将这些文件描述符集合拷贝到内核中，我们知道数据拷贝是有性能损耗的，因此为了减少这种数据拷贝带来的性能损耗，Linux内核对集合的大小做了限制，并规定用户监控的文件描述集合不能超过1024个，同时当select返回后我们仅仅能知道有些文件描述符可以读写了，但是我们不知道是哪一个，因此程序员必须再遍历一边找到具体是哪个文件描述符可以读写了。

因此，总结下来select有这样几个特点：

• 我能照看的文件描述符数量有限，不能超过1024个
• 用户给我的文件描述符需要拷贝的内核中
• 我只能告诉你有文件描述符满足要求了，但是我不知道是哪个，你自己一个一个去找吧(遍历)

因此我们可以看到，select机制的特性在高性能网络服务器动辄几万几十万并发链接的场景下无疑是低效的。

use

poll：小有所成

poll和select是非常相似的，poll相对于select的优化仅仅在于解决了文件描述符不能超过1024个的限制，select和poll都会随着监控的文件描述增加而出现性能下降，因此不适合高并发场景。

epoll：独步天下

在select面临的三个问题中，文件描述数量限制已经在poll中解决了，那么剩下的两个问题epoll是通过什么技术巧妙解决的呢？这个问题你可以关注公众号“码农的荒岛求生”并回复"epoll"就能得到答案啦。

总结

基于一切皆文件的设计哲学，I/O也可以通过文件的形式实现，显然高并发要与多个文件交互，这就离不开高效的I/O多路复用技术，本文我们详细讲解了什么是I/O多路复用以及使用方法，这其中以epoll为代表的I/O多路复用(基于事件驱动)技术使用非常广泛，实际上你会发现但凡涉及到高并发、高性能都能见到事件驱动的编程方法，这也是下一篇的主题，敬请期待。

 

 

计算机内功心法】四：进程切换与线程切换的区别

 

注意这个题目问的是进程切换与线程切换的区别，不是进程与线程的区别。当然这里的线程指的是同一个进程中的线程。

这个问题能很好的考察面试者对进程和线程的理解深度，有比较高的区分度。

要想正确回答这个问题，面试者需要理解虚拟内存。

虚拟内存解放生产力

对于程序员来说，我们在编程时实际上是不怎么操心内存问题的，对于使用Java、Python、JavaScript等类型语言的程序员来说更是如此，自动内存回收机制的引入使得使用这类语言的程序员几乎完全不用关心内存问题；即使对于编译型语言C/C++来说，程序员需要关心的也仅仅是内存的申请和释放。

总的来说，作为程序员(无论使用什么类型的语言)我们根本就不关心数据以及程序被放在了物理内存的哪个位置上(设计实现操作系统的程序员除外)，我们可以简单的认为我们的程序独占内存，比如在32位系统下我们的进程占用的内存空间为4G；并且我们可以申请超过物理内存大小的空间，比如在只有256MB的系统上程序员可以申请1G大小的内存空间，这种假设极大的解放了程序员的生产力。

而这种假设实现的背后功臣就是虚拟内存。

什么是虚拟内存

虚拟内存是操作系统为每个进程提供的一种抽象，每个进程都有属于自己的、私有的、地址连续的虚拟内存，当然我们知道最终进程的数据及代码必然要放到物理内存上，那么必须有某种机制能记住虚拟地址空间中的某个数据被放到了哪个物理内存地址上，这就是所谓的地址空间映射，也就是虚拟内存地址与物理内存地址的映射关系，那么操作系统是如何记住这种映射关系的呢，答案就是页表，页表中记录了虚拟内存地址到物理内存地址的映射关系。有了页表就可以将虚拟地址转换为物理内存地址了，这种机制就是虚拟内存。

每个进程都有自己的虚拟地址空间，进程内的所有线程共享进程的虚拟地址空间。

现在我们就可以来回答这个面试题了。

进程切换与线程切换的区别

进程切换与线程切换的一个最主要区别就在于进程切换涉及到虚拟地址空间的切换而线程切换则不会。因为每个进程都有自己的虚拟地址空间，而线程是共享所在进程的虚拟地址空间的，因此同一个进程中的线程进行线程切换时不涉及虚拟地址空间的转换。

举一个不太恰当的例子，线程切换就好比你从主卧走到次卧，反正主卧和次卧都在同一个房子中(虚拟地址空间)，因此你无需换鞋子、换衣服等等。但是进程切换就不一样了，进程切换就好比从你家到别人家，这是两个不同的房子(不同的虚拟地址空间)，出发时要换好衣服、鞋子等等，到别人家后还要再换鞋子等等。

因此我们可以形象的认为线程是处在同一个屋檐下的，这里的屋檐就是虚拟地址空间，因此线程间切换无需虚拟地址空间的切换；而进程则不同，两个不同进程位于不同的屋檐下，即进程位于不同的虚拟地址空间，因此进程切换涉及到虚拟地址空间的切换，这也是为什么进程切换要比线程切换慢的原因。

有的同学可能还是不太明白，为什么虚拟地址空间切换会比较耗时呢？
这也是面试官紧接会问的第二个问题。
关于这个问题的答案，关注公众号“码农的荒岛求生”并回复“地址切换”几个字你就能得到答案啦。

总结

虚拟内存是现代操作系统极其重要的一部分，当然在这里限于篇幅我们只能简单介绍，关于虚拟内存的详细讲解请参见这里《深入理解操作系统》