全方位解析操作系统的线程与进程

楔子

本文来自于公众号《小林coding》。

我们在编写代码的时候经常会用到多线程或者多进程，但是你对进程和线程本身的了解有多深呢？这次让我们来仔细地梳理一下关于进程和线程方面的知识吧。

进程

比如我们写了一份代码，无论是 Go 代码也好，Python 代码也罢，它们本质上都只是一个静态文件。当我们将其编译成二进制文件（Go 语言）然后执行，或者解释器直接解释执行这个文件（Python语言），那么它们就会对应一个运行中的程序，我们将这个运行中的程序称之为 "进程"。

再比如 QQ、微信、音乐播放器、浏览器、或者游戏等等，它们本质上也是一个文件（这里说的是启动文件 exe，当然还有很多依赖的动态库等等），只不过是二进制文件，不是进程。然而一旦我们双击运行的时候，操作系统就会为它们创建一个进程，并将程序内部的所有指令加载到内存中，然后 CPU 一条一条执行。

但是 CPU 在同一时刻只会专注于一个进程、并且不会一直专注于某一个进程，比如早期的 CPU 只有一个核，可我们即可以听歌、也可以浏览网页，说明 CPU 是为所有的进程服务的。但是明明只有一个核，为什么却能同时听歌和浏览网页呢？这就涉及到了时间片原理，因为 CPU 会切换的，CPU 执行某个进程一段时间后，便会切换到其它的进程上，保证每个进程都能得到执行。只不过它切换的速度非常快，导致我们产生了并行执行的错觉。

或者我们有一个需要从硬盘上读取文件的程序，当程序执行到读取文件的指令之后就会从硬盘上读取，但是我们知道硬盘的读取是非常慢的（相较于 CPU 的执行速度而言），难道 CPU 要一直傻等着程序将文件读取完毕吗？显然不会，因为这样的话 CPU 的利用率也太低了，更何况 CPU 是非常宝贵的资源。所以当进程需要从硬盘中读取数据的时候，CPU 不需要阻塞然后等待数据的返回，而是去执行另外的进程。当硬盘数据读取成功之后，CPU 会收到一个 "中断"，于是 CPU 再继续运行这个进程。

这种多个程序交替执行的思想，就是 CPU 管理多个进程的初步想法。对于一个支持多进程的系统，CPU 会从一个进程迅速切换至另一个进程，其中每个进程各运行几十或者几百毫秒，就这样不停地切换，保证每个进程都能有机会得到执行。虽然单核的 CPU 在某一个瞬间只能运行一个进程，但是在一秒钟内，它可能会切换好几个进程，这样就产生了 "并行" 的错觉，但实际上这是 "并发"。

并行和并发有什么区别？

一张图说明一切：

进程和程序之间的关系？

估计有人会问：我们平时说的程序和这里的进程是一回事吗？答案不是一回事，进程和程序之间的区别如下：

• 1. 程序只是一组指令的有序集合，它本身没有任何运行的含义，只是一个静态的实体；而进程是一个动态的实体，它有自己的声明周期，因创建而产生、因调度而运行、因等待某个资源或者某个事件触发而处于阻塞状态、因完成任务之后而被销毁，所以进程反映了一个程序在一定的数据集上运行的全部动态过程。估计到这里有人已经猜到了，说人话就是假设我们编写一个正确的 C 源文件，那么这个 C 源文件我们就可以称之为源代码，对源代码进行编译得到的二进制可执行文件就是程序，双击执行这个可执行程序就会创建一个进程。
• 2. 进程和程序不是一一对应的，比如 Chrome 浏览器。一个 chrome.exe 就可以看成是一个程序(当然它也是一个文件，只不过是二进制可执行文件)，然后当我们双击的时候就产生了一个进程。但是我们只能打开一个 Chrome 吗，显然是可以打开多个的，因此此时就会有多个进程，但是这些进程都是由一个程序启动时创建的，并且每一个进程都会有一个唯一的 ID，所以一个程序可以对应多个进程。但是一个进程会不会也对应多个程序呢？关于这一点说法不一，我个人认为从可执行文件的角度考虑的话，一个进程只会对应一个程序。

比如到了晚饭时间，一对小情侣肚子饿了，于是男生见机行事，就想给女生做饭。他在网上找了辣子鸡的菜谱，接着买了一些鸡肉、辣椒、香料等材料，然后边看边学着做。那么这一过程和我们这里的主题就可以用如下关系对应：

突然，女生说她想喝可乐，那么男生只好把做菜的事情暂时搁置一下，并记录自己当前做菜做到哪一步了，比如正在切黄瓜。然后听从女生的指令，去给女生买可乐，完事之后继续回到厨房做菜，并且不是从头做，而是从刚才中断的位置开始做，也就是继续切黄瓜。

这里变体现了CPU可以从一个进程(做菜)切换到另一个进程(买可乐)，并且在切换之前会记录自己在当前进程中运行的状态信息，然后切换回来之后可以从中断的地方继续执行。因此进程有着 "运行--暂停--运行" 的活动规律。

进程的状态

我们说进程有着 "运行--暂停--运行" 的活动规律，而一般说来，一个进程并不是自始至终都连续不断地运行，它与并发过程中的其它进程都是相互制约的。它有时处于运行状态，有时又因为某种原因处于阻塞状态（比如执行读取大文件的指令，在文件读取完毕之前 CPU 没办法继续往下执行内部的指令集），当使它阻塞的原因消失之后又进入准备运行状态、或者说就绪状态。

所以在一个进程活动期间，至少具备三种状态：运行状态、阻塞状态、就绪状态。

• 运行状态(Running)：进程占用 CPU，开开心心地让 CPU 执行自己内部的一条一条指令。
• 阻塞状态(Blocked)：因为某种原因处于阻塞状态，比如当执行到从硬盘中加载大文件的指令时，在文件加载完毕之前是不会继续往下执行指令的。也就是说阻塞状态下，即使将 CPU 控制权交给该进程，它也没办法调度 CPU 执行(当然具体调度是由进程内部的线程做的，后面会说)，因为当前的指令还没结束，所以 CPU 就会去执行其它的进程。
• 就绪状态(Ready)：当进程阻塞的原因消失后，比如：上面的大文件已经加载完毕了，该进程就会给 CPU 发送一个"中断"，告诉 CPU 可以向下执行指令啦。但是 CPU 表示我不要你觉得可以，我要我觉得可以，老子还有其它进程要服务，不是你想让我执行我就执行的。因此此时进程就处于就绪状态了，所以我们看到就绪状态指的就是可以执行但是 CPU 在时间片轮转的时候还没转到自己这里来。

我们知道 IO 阻塞是不耗费 CPU 的，而纯计算则是需要耗费 CPU 的。如果一个进程内部指令全部都是计算相关，不涉及 IO，那么它也可以没有阻塞状态。但即便如此，操作系统也不会一直让该进程霸占着 CPU，当该进程执行一段时间之后，操作系统也会强制将 CPU 的控制权交给其它进程，此时进程就直接由运行状态变成了就绪状态。因此从这里我们可以看出 CPU 切换会有两种情况，一种是遇见不需要 CPU 的 IO 操作；另一种就是 CPU 的时间片轮转，时间到了也会强制从一个进程切换到另一个进程。

当然啦，除了上面三种状态之外，还要有两种状态。显然各位都猜到了，那就是 "创建状态" 和 "结束状态"，因为进程肯定是要被创建的，而且最终也是要被销毁的。

• 创建状态(new)：进程正在被创建时的状态。
• 结束状态(exit)：进程正在从系统中消失时的状态。

于是一个完整的进程状态的生命周期与变迁就可以用下面这张图表示：

再来详细说明一下进程的状态变迁：

• NULL -> 创建状态：一个新进程被创建时的状态，也是第一个状态
• 创建状态 -> 就绪状态：当进程被创建并完成初始化后，一切就准备就绪了，此时就变成了就绪状态，这个过程是很快的
• 就绪状态 -> 运行状态：处于就绪状态的进程被操作系统的进程调度器选中之后，就分配 CPU 来执行指令
• 运行状态 -> 结束状态：当进程运行完毕或者出错时，会被操作系统销毁，此时进入结束状态
• 运行状态 -> 就绪状态：处于运行状态的进程用完时间片之后，操作系统会将其变成就绪状态，然后选择另一个就绪状态的进程执行
• 运行状态 -> 阻塞状态：当进程因为某个事件阻塞、并且必须要等待该事件完成时，那么操作系统会将其设置为阻塞状态
• 阻塞状态 -> 就绪状态：导致某个进程处于阻塞状态的事件完成时，它会从阻塞状态变成就绪状态

如果有大量处于阻塞状态的进程，那么这是非常浪费物理内存的，显然这不是我们想要的。毕竟物理内存有限，让阻塞状态的进程一直占用着物理内存是一件非常奢侈的事情。所以，在虚拟内存管理的操作系统中，通常会把处于阻塞状态的进程占用的物理内存 "换出" 到硬盘，等需要再次运行的时候再从硬盘 "换入" 到物理内存。

因此，此时就需要一个新的状态，来表示进程没有占用实际的物理内存，该状态就是 "挂起状态"。注意：这跟阻塞状态不一样，阻塞状态是等待某个事件返回。并且挂起状态可以分为两种：

• 阻塞挂起状态：进程在外存(硬盘)并等待某个事件返回。
• 就绪挂起状态：进程在外存(硬盘)，但只要进入内存，便能立刻运行。

这两种挂起状态再加上之前的五种状态，就变成了七种状态变迁，如果所示：

导致进程挂起的原因不只是因为进程所使用的内存空间不在物理内存，还包括如下情况：

• 通过 sleep 让进程间歇性挂起，其工作原理是设置一个定时器，到期后唤醒进程；
• 用户希望挂起一个程序的执行，比如在 Linux 中用 Ctrl+Z 挂起进程；

进程的控制结构

在操作系统中，是用 "进程控制块（process control block，PCB）" 数据结构来描述进程的。

那 PCB 是什么呢？我们搜索一下吧。

抱歉，我失态了。

PCB 是进程存在的唯一标识，这意味着一个进程的存在必然会有一个 PCB，如果进程消失，那么对应的 PCB 也会随之消失。

PCB具体包含什么信息呢？

进程描述信息：

• 进程标识符：标识各个进程，每个进程都会有一个、并且唯一一个标识符；
• 用户标识符：进程归属的用户，用户标识符主要为共享和保护而服务；

进程控制和管理信息：

• 进程当前状态，如：new(创建)、ready(就绪)、running(运行)、blocked(阻塞)、waiting(等待,和阻塞类似)、suspend(挂起)、exit(退出)；
• 进程优先级：进程抢占 CPU 的优先级；

资源分配清单：

• 有关内存地址空间或者虚拟地址空间的信息，所打开文件的列表和所使用的 I/O 设备信息。

CPU 相关信息：

• CPU 中各个寄存器的值，当进程被切换时，CPU 的状态信息都会保存在相应的 PCB 中，以便进程重新执行时，能够从断点处继续执行。

由此可见 PCB 包含的信息还是很多的。

每个 PCB 是如何组织的呢？

通常是通过链表的方式进行组织，把具有相同状态的进程链在一起，组成各种队列，比如：

• 把所有处于就绪状态的进程链在一起，组成 "就绪队列"；
• 把所有因等待事件而处于阻塞状态的进程链在一起，组成 "阻塞队列"；
• 另外，对于运行队列来说，在单核 CPU 系统中只会有一个运行指针，因为单核 CPU 同一时刻只会执行一个程序。

就绪队列和阻塞队列的链表组织如图所示：

除了链接的组织方式，还有索引方式，它的工作原理：将同一状态的进程组织在一个索引表中，索引表项指向相应的 PCB，不同状态对应不同的索引表。

一般会选择链表，因为可能面临进程创建、销毁等调度，从而导致进程状态发生变化，所以链表能够更加灵活的插入和删除。

进程的控制

在我们了解了进程的状态变迁和数据结构 PCB 之后，再来看看进程的创建、终止、阻塞、唤醒的过程，这些过程便是进程的控制。

1. 创建进程

操作系统允许一个进程创建另一个进程，而且允许子进程继承父进程所拥有的资源，当子进程被终止时，其继承的父进程的资源也会归还给相应的父进程。同时，终止父进程的同时也会终止其所有的子进程。

创建进程的过程如下：

• 为新进程分配一个唯一的进程标识号，并申请一个空白的 PCB。另外，PCB 是有限的，所申请失败则进程也会创建失败。
• 为进程分配资源，此处如果资源不足，进程就会进入等待状态，以等待资源。
• 初始化 PCB。
• 如果进程的调度队列能够接纳新进程，那就将进程插入到就绪队列，等待被调度运行。

2. 终止进程

进程可以有三种终止方式：正常结束、异常结束、以及外界干预(信号kill掉)。

终止进程的过程如下：

• 查找需要终止的进程的 PCB；
• 如果处于执行状态，则立即终止该进程的执行，然后将 CPU 资源分配给其它进程；
• 如果还有子进程，则应将其所有子进程终止；
• 将该进程所拥有的全部资源都归还给父进程或操作系统；
• 将其 PCB 从所在队列中删除；

3. 阻塞进程

当进程需要等待某一事件完成时，它可以调用阻塞语句将自己变成阻塞等待状态。而一旦进入此状态，则必须由另一个进程唤醒。

阻塞进程的过程如下：

• 找到将要被阻塞的进程对应的 PCB；
• 如果该进程为运行状态，则保存当前进程的上下文，然后将其由运行状态变成阻塞状态，停止运行；
• 将其对应的 PCB 插入到阻塞队列当中去；

4. 唤醒进程

进程由运行变为阻塞是由于进程必须等待某一事件的完成，所以处于阻塞状态的进程是绝对不可能叫醒自己的。

如果某进程正在等待 I/O 事件，需要别的进程发消息给它，则只有当该进程所期待的事件出现时，才由发现者进程调用语句叫醒它。

唤醒进程的过程如下：

• 在阻塞队列中找到相应的进程对应的 PCB；
• 将其从阻塞队列中移除，并把状态从阻塞状态设变成就绪状态；
• 把该 PCB 插入到就绪队列中，等待调度。

进程的阻塞和唤醒是一对功能相反的语句，如果某个进程调用了阻塞语句，那么必有一个与之对应的唤醒语句(只不过调用的是其它进程)。

进程的上下文切换

各个进程之间是共享 CPU 资源的，在不同的时候进程之间需要切换，让不同的进程都有机会操作 CPU 执行指令。而一个进程切换到另一个进程运行，称为进程的上下文切换。

在介绍进程上下文切换之前，先来看看 CPU 的上下文切换

大多数操作系统都是多任务，通常支持大于 CPU 数量的任务同时运行。实际上，这些任务并不是同时运行的，只是因为系统在很短的时间内，就能让 CPU 在各个任务之间进行切换，因此造成了同时运行的错觉。

而任务是交给 CPU 运行的，那么在每个任务运行之前，CPU 需要知道任务从哪里加载，又从哪里开始运行。因此，操作系统需要事先将 "这些关键信息" 设置到 CPU 的 "寄存器" 和 "程序计数器" 中。

CPU 寄存器是 CPU 内部一个容量小，但是速度极快的存储介质，可以用来存储一些临时数据。举个栗子：寄存器就像是你的口袋，内存像你身上的书包，硬盘则是你家里面的柜子。你从口袋里面拿东西肯定比从书包和柜子里面快，不过显然速度越快容量就越小。

我们说 CPU 操作自身寄存器存储的数据的速度是极快的，因此在 C 中也允许你通过 register 来声明一个寄存器变量，不过还是那句话，速度越快容量就越有限。

而程序计数器则是用来存储 CPU 正在执行的指令位置，或者即将执行的下一条指令的位置。

所以说 CPU 寄存器和程序计数器保存了 CPU 在运行任何任务时都必须依赖的环境，这些环境就叫做 CPU 上下文。

既然理解了 CPU 上下文，那么 CPU 上下文切换就不难了。

CPU 上下文切换就是先把前一个任务的 CPU 上下文保存起来，然后加载新任务的上下文到寄存器和程序计数器，最后再跳转到程序计数器所指的位置，运行新任务。

这些上下文的保存会由系统内核负责，当此任务再次被分给 CPU 运行时，CPU 会重新加载这些上下文到 CPU 的寄存器和程序计数器中，然后跳转到程序计数器所指的位置，从中断的地方继续运行，这样就能保证原来任务的状态不受影响，看起来就像是连续运行。

上面说到的任务，主要包含进程、线程和中断。所以根据任务的不同，会把 CPU 上下文切换分为：进程上下文切换、线程上下文切换和中断上下文切换，所以进程上下文切换是 CPU 上下文切换的一种。

进程的上下文切换到底是切换什么呢？

进程是由内核管理和调度的，所以进程的切换只会发生在内核态。

所以，进程的上下文切换不仅包含了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的资源。

通常，会把交换的信息保存在进程的 PCB，当要运行另一个进程的时候，我们需要从这个进程的 PCB 中取出上下文，然后恢复到 CPU 中，使得该进程可以继续执行，如下图所示：

注意：进程的上下文开销是很关键的，我们希望它的开销越少越好，这样可以把更多的时间用在执行程序上，而不是耗费在上下文切换。

有哪些场景会发生进程的上下文切换呢？

• 为了保证所有进程都可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片被轮流分配给各个进程。这个当某个进程的时间片耗尽了，那么该进程就会从运行状态变为就绪状态，然后系统会从就绪队列中选择另外一个进程运行。
• 进程在系统资源不足(比如内存不足)时，要等到资源满足后才可以运行，这个时候进程也会被挂起，并由系统调度其它进程运行。
• 当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时，自然也会重新调度。
• 当有优先级更高的进程运行时，为了保证高优先级的进程运行，当前进程会被挂起，从而将资源留给高优先级的进程。
• 发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序。

以上就是发生进程上下文切换的常见场景了。

线程

说完进程之后，我们来说说线程。线程是操作系统调度的最小单元，它才是真正操作 CPU 执行指令的，而上面说的进程是操作系统进行资源分配的最小单元，它是为线程提供资源的。线程必须要在进程中，不可能独立存在，所以每一个线程都有对应的进程，每一个进程都至少会有一个线程。

然而在早期的操作系统中都是以进程作为独立运行的基本单元，但是随着发展，计算机科学家们又提出了更小的可以独立运行的基本单元，也就是线程。

为什么使用线程？

举个栗子，假设你要编写一个视频播放器软件，这个软件的核心模块有三个：

• 1. 从视频文件中读取数据；
• 2. 对读取的数据进行解压缩；
• 3. 把解压缩后的视频数据播放出来；

对于单进程的实现方式，我想最简单也是最直接的方式就是像下面这样：

但是这种单进程的模式，存在以下问题：

• 播放出来的画面和声音会不连贯，因为当 CPU 能力不够强的时候，read(读取文件数据) 可能会导致进程就卡在这了，这样就会导致等半天才会进程数据解压和播放；
• 各个函数之间不是并发执行，因此会影响资源的使用效率；

那如果改成多进程的方式：

但是对于这种多进程的方式，依然会存在问题：

• 1. 进程之间如何通信、如何共享数据呢?
• 2. 维护进程的系统开销很大，比如创建进程时需要分配资源、建立 PCB；终止进程时需要回收资源、撤销 PCB；进程切换时需要保存当前进程的上下文信息

那么问题来了，如何才能解决这一点呢？显然我们需要有一种新的实体，能满足以下特性：

• 实体之间可以并发地运行；
• 实体之间共享相同的地址空间；

这个新的实体就是线程，线程之间可以并发运行并且共享相同的地址空间。

什么是线程？

线程是进程当中的一条执行流程。

同一个进程内的多个线程之间可以共享代码段、数据段、打开的文件等资源，但每个线程都有一套独立的寄存器和栈，这样可以确保对线程的控制流是相对独立的。

线程都有哪些优缺点呢？

1. 线程的优点：

• 一个进程中可以同时存在多个线程；
• 各个线程之间可以并发的执行；
• 各个线程之间可以共享地址空间和文件等资源，多个线程之间的通信是方便的。

2. 线程的缺点：

• 1. 当进程中的一个线程崩溃时，会导致该进程内的所有其它线程都崩溃；
• 2. 我们说进程内的资源是线程共享的，那么多个线程来同时访问一块数据的时候该给哪个线程呢？所以线程存在着资源竞争；

线程和进程的比较

我们介绍了进程和线程，那么它们之间的区别以及联系是什么呢？

• 1. 进程是操作系统进行资源(包括内存、打开的文件等)分配的最小单元，线程是操作系统调度(去操作CPU)的最小单元；
• 2. 进程拥有一个完整的资源平台，而线程只具有一些必不可少的资源，比如寄存器和栈；
• 3. 线程同样具有就绪、阻塞、执行三种基本状态，同样具有状态之间的转换关系；
• 4. 线程能减少并发执行的时间开销和空间开销；
• 5. 每一个进程都至少有一个线程，这个线程叫做主线程，每个线程可以创建新的线程，主线程之外的线程叫做子线程。

对于第4个区别，线程相比进程能够减少开销，主要体现在：

• 1. 线程的创建比进程快很多，因为进程在创建的过程中还需要资源管理信息，比如：内存管理信息、文件管理信息，而线程在创建的过程中不会涉及这些资源管理信息，而是共享它们；总之我们说线程是用来操作 CPU 执行指令集的，而进程是给线程提供资源的，所以你把创建一个进程想象成盖一间房子，而创建一个线程就是让一个人进去办公，显然创建线程的速度要比创建进程的速度快很多。
• 2. 线程的终止比进程快，因为线程释放的资源要比进程少很多。
• 3. 同一个进程内的线程切换也比多个进程之间的切换快很多，因为线程具有相同的地址空间(虚拟内存共享)，这意味着同一个进程的线程都具有同一个页表，那么在切换的时候不需要切换页表。而对于进程之间的切换是需要把页表给切换掉的，而页表切换的过程开销恰恰又是比较大的。
• 4. 由于同一个进程内的所有线程都是共享资源，因此在线程之间进行数据传递都不需要经过内核了，这就使得线程之间的数据通信的成本大大降低，从而提高交互效率。

因此，在对比进程的时候，不管是时间效率还是空间效率，线程都要高上很多。

线程的上下文切换

我们已经知道，线程与进程之间的最大区别在于：线程是操作系统调度的最小单元，进程是操作系统资源分配的最小单元，线程不能独立于进程而存在，一个进程内部至少有一个线程，而且线程是真正用来 "干活" 的。

所以操作系统的任务调度，调度的实际上是线程，而进程只是给线程提供了虚拟内存、全局变量等资源。

对于线程和进程，我们可以这么理解：

• 1. 创建一个进程时，默认会有一个主线程；
• 2. 线程可以创建其它的线程，当进程内部有多个线程时，这些线程会共享相同的虚拟内存和全局变量资源，这些资源在上下文切换时是不需要修改的；

另外，线程也有自己的私有数据，比如栈和寄存器等等，这些在上下文切换的时候也是需要保存的。

所谓线程上下文切换，到底切换的是什么？

这还得看互相切换线程是不是属于同一个进程：

• 当两个切换的线程不属于同一个进程，那么线程的切换和进程的切换是一样的；
• 当两个线程属于同一个进程，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、以及寄存器内等不共享的数据；

所以相比进程，线程的切换要小很多。

线程的实现

线程的实现方式主要有三种：

• 用户线程(user thread)：在用户空间实现的线程，不是由内核管理的线程，是由用户态的线程库来完成线程的管理。
• 内核线程(kernel thread)：在内核中实现的线程，是由内核管理的线程。
• 轻量级进程(lightweight thread)：在内核中来支持用户线程。

线程的种类我们虽然知道了，但是它们之间的对应关系是什么呢？

1. 第一种关系是多对一的关系，即多个用户线程对应一个内核线程：

2. 第二种关系是一对一的关系，即一个用户线程对应一个内核线程：

3. 第三种关系是多对多的关系，即多个用户线程对应多个内核线程：

用户线程如何理解？存在什么优势和缺陷？

用户线程是基于用户态的线程管理库来实现的，那么线程控制块（Thread Control Block，TCB）也是在库里面实现的，而对于操作系统而言是看不到这个 TCB 的，操作系统只能看到进程对应的 PCB。

所以，用户线程的整个线程管理和调度，操作系统是不直接参与的，而是由用户级线程库函数来完成线程的管理，包括线程的创建、终止、同步和调度等等。

用户级线程的模型，也就类似前面提到了多对一的关系，即多个用户线程对应一个内核线程，如下图所示：

用户线程的优点：

• 每个线程都需要拥有它独有的线程控制块(TCB)列表，用来跟踪记录它内部的各个线程状态信息(PC、栈指针、寄存器)，TCB 由用户级线程库来维护，可用于不支持线程技术的操作系统。
• 用户线程的切换也是由线程库函数来完成的，无需用户态和内核态之间的切换，所以速度特别快。

用户线程的缺点：

• 由于操作系统不参与线程的调度，如果一个线程发起了系统调用而阻塞，那该进程包含的所有用户线程都无法执行了。
• 当一个线程开始运行后，除非它主动交出 CPU 的使用权，否则它所在进程中的其它线程都无法运行，因为用户态的线程没办法打断其它正在运行的线程，它们之间是平级的，没有谁具有特权，只有操作系统才具有，但是操作系统不参与用户态线程的管理。
• 由于 CPU 的时间片分给的是进程，然后进程内的线程去操作 CPU 执行，因此在多线程执行时，每个线程得到时间片较少，执行会比较慢。

以上便是用户线程的优缺点。

内核线程如何理解？存在什么优势和缺陷？

内核线程是由操作系统负责管理的，因此线程对应的 TCB 自然是放在操作系统里面的，这样线程的创建、终止和管理都是由操作系统负责。

内核线程的模型就类似于前面提到的一对一的关系，即一个用户线程对应一个内核线程，如下图所示：

内核线程的优点：

• 在一个进程中，某个内核线程发起系统调用而被阻塞，并不会影响其它内核线程的运行。
• 分配给多线程的进程更多的操作 CPU 的时间。

内核线程的缺点：

• 在支持内核线程的操作系统中，由内核来维护进程和线程的上下文信息，如 PCB 和 TCB。
• 线程的创建、终止和切换都是通过系统调用的方式来执行，因此对于系统来说，开销会比较大。

以上便是内核线程的优缺点。

最后的轻量级进程如何理解呢？

轻量级进程（lightweight process，LWP）是内核支持的用户线程，一个进程可以有一个或多个 LWP，每个 LWP 跟内核线程都是一对一映射的，也就是说 LWP 都是由一个内核线程支持。

另外，LWP 只能由内核管理并像普通的进程一样被调度，Linux 内核是支持 LWP 的典型例子。

在大多数系统中，LWP 与普通进程的区别在于它只有一个最小的执行上下文和调度程序所需要的统计信息。一般来说，一个进程代表一个程序的实例，而 LWP 代表程序的执行线程，因为一个执行线程不像进程一样需要那么多的状态信息，所以 LWP 也不带有这样的信息。

但在 LWP 之上也是可以使用用户线程的，所以 LWP 和用户线程之间的对应关系就有如下三种：

• 1:1，即一个 LWP 对应一个用户线程；
• 1:n，即一个 LWP 对应多个用户线程；
• m:n，即多个 LWP 对应多个用户线程；

先看LWP模型的一张图，然后分析其优缺点。

从图中我们可以看出，一个 LWP 对应一个内核线程，一个内核线程对应一个 CPU，但是用户线程和 LWP 之间的关系则可以有多种。

1:1 模式

一个用户线程对应一个 LWP 再对应一个内核线程，图中的进程 4 便属于此模型。

• 优点：实现并行，当一个 LWP 阻塞，不会影响其它 LWP。
• 缺点：每一个用户线程，就会对应一个内核线程，因此创建线程的的开销比较大。

n:1 模式

多个线程对应一个 LWP 再对应一个内核线程，图中的进程 2 便属于此模型，线程管理是在用户空间完成的，此模式中的用户线程对操作系统不可见。

• 优点：用户线程开几个都没关系，且上下文切换发生在用户空间，切换的效率较高。
• 缺点：一个用户线程如果阻塞了，则整个进程都将阻塞，另外在多核 CPU 中也是没有办法充分利用多核的。

m:n 模式

将上面两个模式混搭在一起，就形成 m:n 模型，该模型提供了两级控制，首先多个用户线程可以对应多个 LWP，LWP 再一一对应到内核线程，如图中的进程 3。

• 优点：综合了前面两种优点，大部分的线程上下文切换发生在用户空间，且多个线程又可以充分利用多核 CPU 资源。

组合模式

如图中的进程5，此进程结合1:1和m:n两种模型，开发人员可以针对不同的应用特点来调节内核线程的数目，以此达到物理并行性和逻辑并行性的最佳方案。

调度

进程都希望自己能尽可能多的占用 CPU 进行工作，但这显然是不现实的，操作系统不会允许的，因此就涉及到了上下文切换。

一旦操作系统把进程切换到运行状态，那么就意味着该进程要占有 CPU 了；但是当操作系统将进程从运行状态切换到其它状态时，那么它就无法占有 CPU 了，于是操作系统会从就绪队列中选择一个其它的线程。

而选择一个进程执行这一功能是在操作系统中完成的，通常被称为 "调度程序（scheduler）"。

那么到底什么时候、以什么原则来调度进程呢？

调度时机

在进程的生命周期中，当进程从一个状态变成另一状态的时候，就会触发一次调度。

比如，以下状态的变化都会触发操作系统的调度：

• 就绪态 -> 运行态：当进程被创建时，会进入到就绪队列，操作系统会从就绪队列中选择一个进程运行；
• 运行态 -> 阻塞态：当进程发生 I/O 事件而阻塞时，操作系统必须从就绪队列中选择另外一个进程运行；
• 运行态 -> 结束态：当进程退出结束后，操作系统同样要从就绪队列中选择另外一个进程运行；

因为在状态发生变化的时候，操作系统需要考虑是否将 CPU 的控制权交给新的进程，或者是否拿走 CPU 的控制权交给另一个进程。

另外，如果硬件时钟提供某个频率的周期性中断，那么可以根据如何处理时钟中断，而将调度算法分为两类：

• 非抢占式调度算法：挑选一个进程，然后让该进程运行，直到阻塞或者退出，才会处理调用另一个进程，也就是说这种算法不会理会时钟中断这件事情。
• 抢占式调度算法：挑选一个进程，然后让该进程只运行某段时间，如果时间结束时该进程仍在运行，那么操作系统会将其强制挂起，接着调度程序会从就绪队列中选择另外一个进程。这种抢占式调度处理，需要在时间间隔的末端发生时钟中断，以便把 CPU 控制权返还给调度程序进行调度，也就是常说的时间片机制。

调度原则

原则一：如果运行的程序，发生了 I/O 事件的请求，那 CPU 使用率必然会很低，因为此时进程在阻塞等待硬盘的数据返回。这样的过程，势必会造成 CPU 的空闲。所以，为了提高 CPU 利用率，在这种发送 I/O 事件致使 CPU 空闲的情况下，调度程序需要从就绪队列中选择一个进程来运行。

原则二：有的程序执行某个任务花费的时间会比较长，如果这个程序一直占用着 CPU，会造成系统吞吐量（CPU 在单位时间内操作的进程数量）的降低。所以，要提高系统的吞吐率，调度程序要权衡长任务进程和短任务进程的运行完成数量。

原则三：从进程开始到结束的过程中，实际上是包含两个时间，分别是进程运行时间和进程等待时间，这两个时间总和就称为周转时间。进程的周转时间越小越好，如果进程的等待时间很长而运行时间很短，那周转时间就很长，这不是我们所期望的，调度程序应该避免这种情况发生。

原则四：处于就绪队列的进程，也不能等太久，当然希望这个等待的时间越短越好，这样可以使得进程更快的在 CPU 中执行。所以，就绪队列中进程的等待时间也是调度程序所需要考虑的原则。

原则五：对于鼠标、键盘这种交互式比较强的应用，我们当然希望它的响应时间越快越好，否则就会影响用户体验了。所以，对于交互式比较强的应用，响应时间也是调度程序需要考虑的原则。

针对上面的五种调度原则，总结如下：

• CPU 利用率：调度程序应确保 CPU 是始终匆忙的状态，这可提高 CPU 的利用率；
• 系统吞吐量：吞吐量表示的是单位时间内 CPU 完成进程的数量，长作业的进程会占用较长的 CPU 资源，因此会降低吞吐量，相反，短作业的进程会提升系统吞吐量；
• 周转时间：周转时间是进程运行和阻塞时间总和，一个进程的周转时间越小越好；
• 等待时间：这个等待时间不是阻塞状态的时间，而是进程处于就绪队列的时间，等待的时间越长，用户越不满意；
• 响应时间：用户提交请求到系统第一次产生响应所花费的时间，在交互式系统中，响应时间是衡量调度算法好坏的主要标准。

说白了，这么多调度原则，目的就是使得进程要「快」。

调度算法

不同的调度算法适用的场景也是不同的，先来说说在单核CPU中常见的调度算法。

1. "先来先" 服务调度算法

最简单的一个调度算法，就是非抢占式的 "先来先服务（First Come First Serverd，FCFS）"算法。

顾名思义，就是先来后到，每次从就绪队列中选择最先进入队列的进程，然后一直运行，直到进程退出或阻塞，才会继续从队列中选择一个进程接着运行。

这似乎很公平，但是当一个长作业先运行了，那么后面的短作业等待的时间就会很长，不利于短作业。

FCFS 对长作业有利，适用于 CPU 密集型作业的系统，不适于 I/O 密集型。

2. "最短作业优先" 调度算法

最短作业优先（Short Job First，SJF）调度算法从名字上也能理解它的意思，会优先选择运行时间最短的进程来执行，这有助于系统的吞吐量。

这显然对长作业不利，很容易造成一种极端现象。

比如，一个长作业在就绪队列等待运行，而这个就绪队列有非常多的短作业，那么就会使得长作业不断的往后推，周转时间变长，致使长作业长期不会被运行。

3. "高响应比优先" 调度算法

前面的「先来先服务调度算法」和「最短作业优先调度算法」都没有很好的权衡短作业和长作业，而高响应比优先（Highest Response Ratio Next，HRRN）调度算法显然考虑到了这一问题。

每次进行进程调度时，先计算「响应比」优先级，然后把「响应比」优先级最高的进程投入运行，「响应比」优先级的计算公式：

「响应比」优先级 = (等待时间 + 要求服务时间) / 要求服务时间

从上面的公式，可以发现：

• 如果两个进程的「等待时间」相同时，「要求的服务时间」越短，「响应比」就越高，这样短作业的进程容易被选中运行；
• 如果两个进程「要求的服务时间」相同时，「等待时间」越长，「响应比」就越高，这就兼顾到了长作业进程，因为进程的响应比可以随时间等待的增加而提高，当其等待时间足够长时，其响应比便可以升到很高，从而获得运行的机会；

4. "时间片轮转" 调度算法

最古老、最简单、最公平且使用最广的算法就是时间片轮转（Round Robin，RR）调度算法。

每个进程会被分配一个时间段，称之为时间片（Quantum），即允许进程执行的时间。

• 如果时间片用完，进程还在运行，那么将会把此进程的 CPU 控制权 拿走，并把 CPU 分配另外一个进程；
• 如果该进程在时间片结束前阻塞或结束，则 CPU 立即切换到另一个进程；

另外，时间片的长度也是一个很关键的点：

• 如果时间片设得太短会导致过多的进程上下文切换，降低了 CPU 效率；
• 如果设得太长又可能引起对短作业进程的响应时间变长，通常将时间片设为 20ms~50ms 是一个比较合理的折中值。

5. "最高优先级" 调度算法

前面的「时间片轮转算法」做了个假设，即让所有的进程同等重要，也不偏袒谁，大家的运行时间都一样。

但是，对于多用户计算机系统就有不同的看法了，它们希望调度是有优先级的，即希望调度程序能 "从就绪队列中选择最高优先级的进程去运行，称为最高优先级（Highest Priority First，HPF）调度算法"。

进程的优先级可以分为，静态优先级或动态优先级：

• 静态优先级：创建进程时候，就已经确定了优先级了，然后整个运行时间优先级都不会变化；
• 动态优先级：根据进程的动态变化调整优先级，比如如果进程运行时间增加，则降低其优先级，如果进程等待时间（就绪队列的等待时间）增加，则升高其优先级，也就是随着时间的推移增加等待进程的优先级。

该算法也有两种处理优先级高的方法，非抢占式和抢占式：

• 非抢占式：当就绪队列中出现优先级高的进程，运行完当前进程，再选择优先级高的进程。
• 抢占式：当就绪队列中出现优先级高的进程，当前进程挂起，调度优先级高的进程运行。

但是依然有缺点，可能会导致低优先级的进程永远不会运行。

6. "多级反馈队列" 调度算法

多级反馈队列（MultiLevel Feedback Queue）调度算法是「时间片轮转算法」和「最高优先级算法」的综合和发展。

顾名思义：

• 「多级」表示有多个队列，每个队列优先级从高到低，并且优先级越高时间片越短。
• 「反馈」表示如果有新的进程加入优先级高的队列时，立刻停止当前正在运行的进程，转而去运行优先级高的队列。

来看看，它是如何工作的：

• 设置了多个队列，赋予每个队列不同的优先级，每个队列的优先级从高到低，同时优先级越高时间片越短；
• 新的进程会被放入到第一级队列的末尾，按先来先服务的原则排队等待被调度，如果在第一级队列规定的时间片没运行完成，则将其转入到第二级队列的末尾，以此类推，直至完成；
• 当较高优先级的队列为空，才调度较低优先级的队列中的进程去运行。如果进程运行时，有新进程进入较高优先级的队列，则停止当前运行的进程并将其移入到原队列末尾，接着让较高优先级的进程运行；

可以发现，对于短作业可能可以在第一级队列很快被处理完。对于长作业，如果在第一级队列处理不完，可以移入下次队列等待被执行，虽然等待的时间变长了，但是运行时间也会更长了，所以该算法很好的 "兼顾了长短作业，同时还有较好的响应时间"。

举个生活中的栗子

如果看的有些迷迷糊糊的话，那我们举个银行办业务的例子，将上面的调度算法串起来，相信你一定会明白的。

办理业务的客户相当于进程，银行窗口工作人员相当于 CPU。

现在，假设这个银行只有一个窗口（单核 CPU ），那么工作人员一次只能处理一个业务。

那么最简单的处理方式，就是先来的先处理，后面来的就乖乖排队，这就是先来先服务（FCFS）调度算法。但是万一先来的这位老哥是来贷款的，这一谈就好几个小时，一直占用着窗口，这样后面的人只能干等，或许后面的人只是想简单的取个钱，几分钟就能搞定，却因为前面老哥办长业务而要等几个小时，你说气不气人？

有客户抱怨了，那我们就要改进，我们干脆优先给那些几分钟就能搞定的人办理业务，这就是短作业优先（SJF）调度算法。听起来不错，但是依然还是有个极端情况，万一办理短业务的人非常的多，这会导致长业务的人一直得不到服务，万一这个长业务是个大客户，那不就捡了芝麻丢了西瓜。

那就公平起见，现在窗口工作人员规定，每个人我只处理 10 分钟。如果 10 分钟之内处理完，就马上换下一个人。如果没处理完，依然换下一个人，但是客户自己得记住办理到哪个步骤了。这个也就是时间片轮转（RR）调度算法。但是如果时间片设置过短，那么就会造成大量的上下文切换，增大了系统开销。如果时间片过长，相当于退化成退化成 FCFS 算法了。

既然公平也可能存在问题，那银行就对客户分等级，分为普通客户、VIP 客户、SVIP 客户。只要高优先级的客户一来，就第一时间处理这个客户，这就是最高优先级（HPF）调度算法。但依然也会有极端的问题，万一当天来的全是高级客户，那普通客户不是没有被服务的机会，不把普通客户当人是吗？那我们把优先级改成动态的，如果客户办理业务时间增加，则降低其优先级，如果客户等待时间增加，则升高其优先级。

那有没有兼顾到公平和效率的方式呢？这里介绍一种算法，考虑的还算充分的，多级反馈队列（MFQ）调度算法，它是时间片轮转算法和优先级算法的综合和发展。它的工作方式：

• 银行设置了多个排队（就绪）队列，每个队列都有不同的优先级，各个队列优先级从高到低，同时每个队列执行时间片的长度也不同，优先级越高的时间片越短。
• 新客户（进程）来了，先进入第一级队列的末尾，按先来先服务原则排队等待被叫号（运行）。如果时间片用完客户的业务还没办理完成，则让客户进入到下一级队列的末尾，以此类推，直至客户业务办理完成。
• 当第一级队列没人排队时，就会叫号二级队列的客户。如果客户办理业务过程中，有新的客户加入到较高优先级的队列，那么此时办理中的客户需要停止办理，回到原队列的末尾等待再次叫号，因为要把窗口让给刚进入较高优先级队列的客户。

可以发现，对于要办理短业务的客户来说，可以很快的轮到并解决。对于要办理长业务的客户，一下子解决不了，就可以放到下一个队列，虽然等待的时间稍微变长了，但是轮到自己的办理时间也变长了，也可以接受，不会造成极端的现象，可以说是综合上面几种算法的优点。

小结

线程和进程虽然是一门很复杂的学问，但是理解它们的意义、工作方式、主要作用是什么等等还是很轻松的。有兴趣的话，可以用代码写一下多线程、多进程之类的，或者也可以更深入的研究一下，看一下编程语言的底层实现，它们的线程如何和操作系统的线程进行对应的。