「图文结合」Linux 进程、线程、文件描述符的底层原理

开发十年经验总结，阿里架构师的手写Spring boot原理实践文档

阿里架构师的这份：Redis核心原理与应用实践，带你手撕Redis

Tomcat结构原理详解

说到进程，恐怕面试中最常见的问题就是线程和进程的关系了，那么先说一下答案： 在 Linux 系统中，进程和线程几乎没有区别 。

Linux 中的进程其实就是一个数据结构，顺带可以理解文件描述符、重定向、管道命令的底层工作原理，最后我们从 *** 作系统的角度看看为什么说线程和进程基本没有区别。

首先，抽象地来说，我们的计算机就是这个东西：

这个大的矩形表示计算机的 内存空间 ，其中的小矩形代表 进程 ，左下角的圆形表示 磁盘 ，右下角的图形表示一些 输入输出设备 ，比如鼠标键盘显示器等等。另外，注意到内存空间被划分为了两块，上半部分表示 用户空间 ，下半部分表示 内核空间 。

用户空间装着用户进程需要使用的资源，比如你在程序代码里开一个数组，这个数组肯定存在用户空间；内核空间存放内核进程需要加载的系统资源，这一些资源一般是不允许用户访问的。但是注意有的用户进程会共享一些内核空间的资源，比如一些动态链接库等等。

我们用 C 语言写一个 hello 程序，编译后得到一个可执行文件，在命令行运行就可以打印出一句 hello world，然后程序退出。在 *** 作系统层面，就是新建了一个进程，这个进程将我们编译出来的可执行文件读入内存空间，然后执行，最后退出。

你编译好的那个可执行程序只是一个文件，不是进程，可执行文件必须要载入内存，包装成一个进程才能真正跑起来。进程是要依靠 *** 作系统创建的，每个进程都有它的固有属性，比如进程号（PID）、进程状态、打开的文件等等，进程创建好之后，读入你的程序，你的程序才被系统执行。

那么， *** 作系统是如何创建进程的呢？ 对于 *** 作系统，进程就是一个数据结构 ，我们直接来看 Linux 的源码：

task_struct 就是 Linux 内核对于一个进程的描述，也可以称为「进程描述符」。源码比较复杂，我这里就截取了一小部分比较常见的。

我们主要聊聊 mm 指针和 files 指针。 mm 指向的是进程的虚拟内存，也就是载入资源和可执行文件的地方； files 指针指向一个数组，这个数组里装着所有该进程打开的文件的指针。

先说 files ，它是一个文件指针数组。一般来说，一个进程会从 files[0] 读取输入，将输出写入 files[1] ，将错误信息写入 files[2] 。

举个例子，以我们的角度 C 语言的 printf 函数是向命令行打印字符，但是从进程的角度来看，就是向 files[1] 写入数据；同理， scanf 函数就是进程试图从 files[0] 这个文件中读取数据。

每个进程被创建时， files 的前三位被填入默认值，分别指向标准输入流、标准输出流、标准错误流。我们常说的「文件描述符」就是指这个文件指针数组的索引 ，所以程序的文件描述符默认情况下 0 是输入，1 是输出，2 是错误。

我们可以重新画一幅图：

对于一般的计算机，输入流是键盘，输出流是显示器，错误流也是显示器，所以现在这个进程和内核连了三根线。因为硬件都是由内核管理的，我们的进程需要通过「系统调用」让内核进程访问硬件资源。

PS：不要忘了，Linux 中一切都被抽象成文件，设备也是文件，可以进行读和写。

如果我们写的程序需要其他资源，比如打开一个文件进行读写，这也很简单，进行系统调用，让内核把文件打开，这个文件就会被放到 files 的第 4 个位置，对应文件描述符 3：

明白了这个原理， 输入重定向 就很好理解了，程序想读取数据的时候就会去 files[0] 读取，所以我们只要把 files[0] 指向一个文件，那么程序就会从这个文件中读取数据，而不是从键盘：

同理， 输出重定向 就是把 files[1] 指向一个文件，那么程序的输出就不会写入到显示器，而是写入到这个文件中：

错误重定向也是一样的，就不再赘述。

管道符其实也是异曲同工，把一个进程的输出流和另一个进程的输入流接起一条「管道」，数据就在其中传递，不得不说这种设计思想真的很巧妙：

到这里，你可能也看出「Linux 中一切皆文件」设计思路的高明了，不管是设备、另一个进程、socket 套接字还是真正的文件，全部都可以读写，统一装进一个简单的 files 数组，进程通过简单的文件描述符访问相应资源，具体细节交于 *** 作系统，有效解耦，优美高效。

首先要明确的是，多进程和多线程都是并发，都可以提高处理器的利用效率，所以现在的关键是，多线程和多进程有啥区别。

为什么说 Linux 中线程和进程基本没有区别呢，因为从 Linux 内核的角度来看，并没有把线程和进程区别对待。

我们知道系统调用 fork() 可以新建一个子进程，函数 pthread() 可以新建一个线程。 但无论线程还是进程，都是用 task_struct 结构表示的，唯一的区别就是共享的数据区域不同 。

换句话说，线程看起来跟进程没有区别，只是线程的某些数据区域和其父进程是共享的，而子进程是拷贝副本，而不是共享。就比如说， mm 结构和 files 结构在线程中都是共享的，我画两张图你就明白了：

所以说，我们的多线程程序要利用锁机制，避免多个线程同时往同一区域写入数据，否则可能造成数据错乱。

那么你可能问， 既然进程和线程差不多，而且多进程数据不共享，即不存在数据错乱的问题，为什么多线程的使用比多进程普遍得多呢 ？

因为现实中数据共享的并发更普遍呀，比如十个人同时从一个账户取十元，我们希望的是这个共享账户的余额正确减少一百元，而不是希望每人获得一个账户的拷贝，每个拷贝账户减少十元。

当然，必须要说明的是， 只有 Linux 系统将线程看做共享数据的进程 ，不对其做特殊看待 ，其他的很多 *** 作系统是对线程和进程区别对待的，线程有其特有的数据结构，我个人认为不如 Linux 的这种设计简洁，增加了系统的复杂度。

在 Linux 中新建线程和进程的效率都是很高的，对于新建进程时内存区域拷贝的问题，Linux 采用了 copy-on-write 的策略优化，也就是并不真正复制父进程的内存空间，而是等到需要写 *** 作时才去复制。 所以 Linux 中新建进程和新建线程都是很迅速的 。

1 管道（Pipe）及有名管道（namedpipe）：

管道可用于具有亲缘关系进程间的通信，有名管道克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信；

2 信号（Signal）：

信号是比较复杂的通信方式，用于通知接受进程有某种事件发生，除了用于进程间通信外，进程还可以发送信号给进程本身；linux除了支持Unix早期信号语义函数sigal外，还支持语义符合Posix.1标准的信号函数sigaction（实际上，该函数是基于BSD的，BSD为了实现可靠信号机制，又能够统一对外接口，用sigaction函数重新实现了signal函数）；

3 报文（Message）队列（消息队列）：

消息队列是消息的链接表，包括Posix消息队列systemV消息队列。有足够权限的进程可以向队列中添加消息，被赋予读权限的进程则可以读走队列中的消息。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。

4 共享内存：

使得多个进程可以访问同一块内存空间，是最快的可用IPC形式。是针对其他通信机制运行效率较低而设计的。往往与其它通信机制，如信号量结合使用，来达到进程间的同步及互斥。

5 信号量（semaphore）：

主要作为进程间以及同一进程不同线程之间的同步手段。

6 套接口（Socket）：

更为一般的进程间通信机制，可用于不同机器之间的进程间通信。起初是由Unix系统的BSD分支开发出来的，但现在一般可以移植到其它类Unix系统上：Linux和SystemV的变种都支持套接字。

上回书说到 Linux进程的由来 和 Linux进程的创建 ，其实在同一时刻只能支持有限个进程或线程同时运行(这取决于CPU核数量，基本上一个进程对应一个CPU)，在一个运行的 *** 作系统上可能运行着很多进程，如果运行的进程占据CPU的时间很长，就有可能导致其他进程饿死。为了解决这种问题， *** 作系统引入了 进程调度器 来进行进程的切换，轮流让各个进程使用CPU资源。

1）rq： 进程的运行队列( runqueue)， 每个CPU对应一个 ，包含自旋锁(spinlock)、进程数量、用于公平调度的CFS信息结构、当前运行的进程描述符等。实际的进程队列用红黑树来维护(通过CFS信息结构来访问)。

2）cfs_rq： cfs调度的进程运行队列信息 ，包含红黑树的根结点、正在运行的进程指针、用于负载均衡的叶子队列等。

3）sched_entity： 把需要调度的东西抽象成调度实体 ，调度实体可以是进程、进程组、用户等。这里包含负载权重值、对应红黑树结点、 虚拟运行时vruntime 等。

4）sched_class：把 调度策略(算法)抽象成调度类 ，包含一组通用的调度 *** 作接口。接口和实现是分离，可以根据调度接口去实现不同的调度算法，使一个Linux调度程序可以有多个不同的调度策略。

1） 关闭内核抢占 ，初始化部分变量。获取当前CPU的ID号，并赋值给局部变量CPU， 使rq指向CPU对应的运行队列 。 标识当前CPU发生任务切换 ，通知RCU更新状态，如果当前CPU处于rcu_read_lock状态，当前进程将会放入rnp->blkd_tasks阻塞队列，并呈现在rnp->gp_tasks链表中。 关闭本地中断 ，获取所要保护的运行队列的自旋锁， 为查找可运行进程做准备 。

2） 检查prev的状态，更新运行队列 。如果不是可运行状态，而且在内核态没被抢占，应该从运行队列中 删除prev进程 。如果是非阻塞挂起信号，而且状态为TASK_INTER-RUPTIBLE，就把该进程的状态设置为TASK_RUNNING，并将它 插入到运行队列 。

3）task_on_rq_queued(prev) 将pre进程插入到运行队列的队尾。

4）pick_next_task 选取将要执行的next进程。

5）context_switch(rq, prev, next)进行 进程上下文切换 。

1) 该进程分配的CPU时间片用完。

2) 该进程主动放弃CPU(例如IO *** 作)。

3) 某一进程抢占CPU获得执行机会。

Linux并没有使用x86 CPU自带的任务切换机制，需要通过手工的方式实现了切换。

进程创建后在内核的数据结构为task_struct ， 该结构中有掩码属性cpus_allowed，4个核的CPU可以有4位掩码，如果CPU开启超线程，有一个8位掩码，进程可以运行在掩码位设置为1的CPU上。

Linux内核API提供了两个系统调用 ，让用户可以修改和查看当前的掩码：

1) sched_setaffinity()：用来修改位掩码。

2) sched_getaffinity()：用来查看当前的位掩码。

在下次task被唤醒时，select_task_rq_fair根据cpu_allowed里的掩码来确定将其置于哪个CPU的运行队列，一个进程在某一时刻只能存在于一个CPU的运行队列里。

在Nginx中，使用了CPU亲和度来完成某些场景的工作：

worker_processes      4

worker_cpu_affinity 0001001001001000

上面这个配置说明了4个工作进程中的每一个和一个CPU核挂钩。如果这个内容写入Nginx的配置文件中，然后Nginx启动或者重新加载配置的时候，若worker_process是4，就会启用4个worker，然后把worker_cpu_affinity后面的4个值当作4个cpu affinity mask，分别调用ngx_setaffinity，然后就把4个worker进程分别绑定到CPU0～3上。

worker_processes      2

worker_cpu_affinity 01011010

上面这个配置则说明了两个工作进程中的每一个和2个核挂钩。

---