vlambda博客
学习文章列表

来源 | 码农的荒岛求生

作者 | 码农的荒岛求生

你可能会有疑问，讲多线程为什么要从 CPU 说起呢？原因很简单，在这里没有那些时髦的概念，你可以更加清晰地看清问题的本质。

CPU 并不知道线程、进程之类的概念。

CPU 只知道两件事：

1. 从内存中取出指令；

2. 执行指令，然后回到 1。

你看，在这里 CPU 确实是不知道什么进程、线程之类的概念。

接下来的问题就是 CPU 从哪里取出指令呢？答案是来自一个被称为 Program Counter（简称 PC）的寄存器，也就是我们熟知的程序计数器，在这里大家不要把寄存器想得太神秘，你可以简单地把寄存器理解为内存，只不过存取速度更快而已。

聪明的你一定会问，那么 PC 中的初始值是怎么被设置的呢？

在回答这个问题之前我们需要知道 CPU 执行的指令来自哪里？是来自内存，废话，内存中的指令是从磁盘中保存的可执行程序加载过来的，磁盘中可执行程序是编译器生成的，编译器又是从哪里生成的机器指令呢？答案就是我们定义的函数。

注意是函数，函数被编译后才会形成 CPU 执行的指令，那么很自然的，我们该如何让 CPU 执行一个函数呢？显然我们只需要找到函数被编译后形成的第一条指令就可以了，第一条指令就是函数入口。

你可能会有疑问，这和线程有什么关系呢？

上一小节中我们明白了 CPU 的工作原理，我们想让 CPU 执行某个函数，那么只需要把函数对应的第一条机器执行装入 PC 寄存器就可以了，这样即使没有操作系统我们也可以让 CPU 执行程序，虽然可行但这是一个非常繁琐的过程，我们需要：

• 在内存中找到一块大小合适的区域装入程序；

• 找到函数入口，设置好 PC 寄存器让 CPU 开始执行程序。

这两个步骤绝不是那么容易的事情，如果每次在执行程序时程序员自己手动实现上述两个过程会疯掉的，因此聪明的程序员就会想干脆直接写个程序来自动完成上面两个步骤吧。

struct *** { void* start_addr; int len;  void* start_point;   ...};

接下来就是起名字时刻。

这个数据结构总要有个名字吧，这个结构体用来记录什么信息呢？记录的是程序在被加载到内存中的运行状态，程序从磁盘加载到内存跑起来叫什么好呢？干脆就叫进程（Process）好了，我们的指导原则就是一定要听上去比较神秘，总之大家都不容易弄懂就对了，我将其称为“弄不懂原则”。

就这样进程诞生了。

CPU 执行的第一个函数也起个名字，第一个要被执行的函数听起来比较重要，干脆就叫 main 函数吧。

完成上述两个步骤的程序也要起个名字，根据“弄不懂原则”这个“简单”的程序就叫操作系统（Operating System）好啦。

就这样操作系统诞生了，程序员要想运行程序再也不用自己手动加载一遍了。

现在进程和操作系统都有了，一切看上去都很完美。

人类的一大特点就是生命不息折腾不止，从单核折腾到了多核。

这时，假设我们想写一个程序并且要充分利用多核该怎么办呢？

有的同学可能会说不是有进程吗，多开几个进程不就可以了？听上去似乎很有道理，但是主要存在这样几个问题：

• 进程是需要占用内存空间的（从上一节能看到这一点），如果多个进程基于同一个可执行程序，那么这些进程其内存区域中的内容几乎完全相同，这显然会造成内存的浪费。

该怎么办呢？

进程的缺点在于只有一个入口函数，也就是 main 函数，因此进程中的机器指令只能被一个 CPU 执行，那么有没有办法让多个 CPU 来执行同一个进程中的机器指令呢？

答案是没什么区别，main 函数的特殊之处无非就在于是 CPU 执行的第一个函数，除此之外再无特别之处，我们可以把 PC 寄存器指向 main 函数，就可以把 PC 寄存器指向任何一个函数。

当我们把 PC 寄存器指向非 main 函数时，线程就诞生了。

至此我们解放了思想，一个进程内可以有多个入口函数，也就是说属于同一个进程中的机器指令可以被多个 CPU 同时执行。

注意，这是一个和进程不同的概念，创建进程时我们需要在内存中找到一块合适的区域以装入进程，然后把 CPU 的 PC 寄存器指向 main 函数，也就是说进程中只有一个执行流。

但是现在不一样了，多个 CPU 可以在同一个屋檐下（进程占用的内存区域）同时执行属于该进程的多个入口函数，也就是说现在一个进程内可以有多个执行流了。

总是叫执行流好像有点太容易理解了，再次祭出”弄不懂原则“，起个不容易懂的名字，就叫线程吧。

这就是线程的由来。

操作系统为每个进程维护了一堆信息，用来记录进程所处的内存空间等，这堆信息记为数据集 A。

同样的，操作系统也需要为线程维护一堆信息，用来记录线程的入口函数或者栈信息等，这堆数据记为数据集 B。

值得注意的是，有了线程这个概念后，我们只需要进程开启后创建多个线程就可以让所有 CPU 都忙起来，这就是所谓高性能、高并发的根本所在。

很简单，只需要创建出数量合适的线程就可以了。

需要提醒的是，虽然前面关于线程讲解使用的图中用了多个 CPU，但不是说一定要有多核才能使用多线程，在单核的情况下一样可以创建出多个线程，原因在于线程是操作系统层面的实现，和有多少个核心是没有关系的，CPU 在执行机器指令时也意识不到执行的机器指令属于哪个线程。即使在只有一个 CPU 的情况下，操作系统也可以通过线程调度让各个线程“同时”向前推进，方法就是将 CPU 的时间片在各个线程之间来回分配，这样多个线程看起来就是“同时”运行了，但实际上任意时刻还是只有一个线程在运行。

在前面的讨论中我们知道了线程和 CPU 的关系，也就是把 CPU 的 PC 寄存器指向线程的入口函数，这样线程就可以运行起来了，这就是为什么我们创建线程时必须指定一个入口函数的原因。无论使用哪种编程语言，创建一个线程大体相同：

// 设置线程入口函数DoSomethingthread = CreateThread(DoSomething);
// 让线程运行起来thread.Run();

那么线程和内存又有什么关联呢？

那么有了线程以后呢？

同时我们也可以看到，创建线程是要消耗进程内存空间的，这一点也值得注意。

现在有了线程的概念，那么接下来作为程序员的我们该如何使用线程呢？

从生命周期的角度讲，线程要处理的任务有两类：长任务和短任务。

1. 长任务，long-lived tasks

顾名思义，就是任务存活的时间很长，比如以我们常用的 word 为例，我们在 word 中编辑的文字需要保存在磁盘上，往磁盘上写数据就是一个任务，那么这时一个比较好的方法就是专门创建一个写磁盘的线程，该写线程的生命周期和 word 进程是一样的，只要打开 word 就要创建出该写线程，当用户关闭 word 时该线程才会被销毁，这就是长任务。

这种场景非常适合创建专用的线程来处理某些特定任务，这种情况比较简单。

有长任务，相应的就有短任务。

2. 短任务，short-lived tasks

这个概念也很简单，那就是任务的处理时间很短，比如一次网络请求、一次数据库查询等，这种任务可以在短时间内快速处理完成。因此短任务多见于各种 Server，像 web server、database server、file server、mail server 等，这也是互联网行业的同学最常见的场景，这种场景是我们要重点讨论的。

这种场景有两个特点：一个是任务处理所需时间短；另一个是任务数量巨大。

如果让你来处理这种类型的任务该怎么办呢？

你可能会想，这很简单啊，当 server 接收到一个请求后就创建一个线程来处理任务，处理完成后销毁该线程即可，So easy。

这种方法通常被称为 thread-per-request，也就是说来一个请求就创建一个线程：

如果是长任务，那么这种方法可以工作得很好，但是对于大量的短任务，这种方法虽然实现简单但是有这样几个缺点：

1. 从前几节我们能看到，线程是操作系统中的概念（这里不讨论用户态线程实现、协程之类），因此创建线程天然需要借助操作系统来完成，操作系统创建和销毁线程是需要消耗时间的。

2. 每个线程需要有自己独立的栈，因此当创建大量线程时会消耗过多的内存等系统资源。

这就好比你是一个工厂老板（想想都很开心有没有），手里有很多订单，每来一批订单就要招一批工人，生产的产品非常简单，工人们很快就能处理完，处理完这批订单后就把这些千辛万苦招过来的工人辞退掉，当有新的订单时你再千辛万苦地招一遍工人，干活儿 5 分钟招人 10 小时，如果你不是立志要让企业倒闭的话大概是不会这么做的，因此一个更好的策略就是招一批人后就地养着，有订单时处理订单，没有订单时大家可以闲呆着。

这就是线程池的由来。

线程池的概念是非常简单的，无非就是创建一批线程，之后就不再释放了，有任务就提交给这些线程处理，因此无需频繁地创建、销毁线程，同时由于线程池中的线程个数通常是固定的，也不会消耗过多的内存，因此这里的思想就是复用、可控。

可能有的同学会问，该怎么给线程池提交任务呢？这些任务又是怎么给到线程池中线程呢？

很显然，数据结构中的队列天然适合这种场景，提交任务的就是生产者，消费任务的线程就是消费者，实际上这就是经典的生产者-消费者问题。

现在你应该知道为什么操作系统课程要讲、面试要问这个问题了吧，因为如果你对生产者-消费者问题不理解的话，本质上你是无法正确地写出线程池的。

限于篇幅在这里不详细地讲解生产者消费者问题，参考操作系统相关资料就能获取答案。这里讲一讲一般提交给线程池的任务是什么样子的。

一般来说提交给线程池的任务包含两部分：

1) 需要被处理的数据；

2) 处理数据的函数。

struct task { void* data; // 任务所携带的数据 handler handle; // 处理数据的方法}

（注意，你也可以把代码中的 struct 理解成 class，也就是对象。）

线程池中的线程会阻塞在队列上，当生产者向队列中写入数据后，线程池中的某个线程会被唤醒，该线程从队列中取出上述结构体（或者对象），以结构体（或者对象）中的数据为参数并调用处理函数：

while(true) { struct task = GetFromQueue(); // 从队列中取出数据 task->handle(task->data); // 处理数据}

以上就是线程池最核心的部分。理解这些你就能明白线程池是如何工作的了。

现在线程池有了，那么线程池中线程的数量该是多少呢？

在接着往下看前先自己想一想这个问题。

如果你能看到这里说明还没有睡着。

要知道线程池的线程过少就不能充分利用 CPU，线程创建得过多反而会造成系统性能下降，内存占用过多，线程切换造成的消耗等等。因此线程的数量既不能太多也不能太少，那到底该是多少呢？

回答这个问题，你需要知道线程池处理的任务有哪几类，有的同学可能会说你不是说有两类吗？长任务和短任务，这个是从生命周期的角度来看的，那么从处理任务所需要的资源角度看也有两种类型，这就是没事儿找抽型和。。啊不，是 CPU 密集型和 I/O 密集型。

1. CPU 密集型

所谓 CPU 密集型就是说处理任务不需要依赖外部 I/O，比如科学计算、矩阵运算等等。在这种情况下只要线程的数量和核数基本相同就可以充分利用 CPU 资源。

2. I/O 密集型

这一类任务可能计算部分所占用时间不多，大部分时间都用在了比如磁盘 I/O、网络 I/O 等。

这种情况下就稍微复杂一些了，你需要利用性能测试工具评估出用在 I/O 等待上的时间，这里记为 WT（wait time），以及 CPU 计算所需要的时间，这里记为 CT（computing time），那么对于一个 N 核的系统，合适的线程数大概是 N * (1 + WT/CT)，假设 I/O 等待时间和计算时间相同，那么你大概需要 2N 个线程才能充分利用 CPU 资源，注意这只是一个理论值，具体设置多少需要根据真实的业务场景进行测试。

当然充分利用 CPU 不是唯一需要考虑的点，随着线程数量的增多，内存占用、系统调度、打开的文件数量、打开的 socker 数量以及打开的数据库链接等等都是需要考虑的。

因此这里没有万能公式，要具体情况具体分析。

线程池仅仅是多线程的一种使用形式，因此多线程面临的问题线程池同样不能避免，像死锁问题、race condition 问题等等，关于这一部分同样可以参考操作系统相关资料就能得到答案，所以基础很重要呀老铁们。

线程池是程序员手中强大的武器，互联网公司的各个 server 上几乎都能见到线程池的身影，使用线程池前你需要考虑：

• 充分理解你的任务，是长任务还是短任务、是 CPU 密集型还是 I/O 密集型，如果两种都有，那么一种可能更好的办法是把这两类任务放到不同的线程池中，这样也许可以更好地确定线程数量。

• 如果线程池中的任务有 I/O 操作，那么务必对此任务设置超时，否则处理该任务的线程可能会一直阻塞下去。

• 线程池中的任务最好不要同步等待其它任务的结果。

本文我们从 CPU 开始一路来到常用的线程池，从底层到上层、从硬件到软件。注意，这里通篇没有出现任何特定的编程语言，线程不是语言层面的概念（依然不考虑用户态线程），但是当你真正理解了线程后，相信你可以在任何一门语言下用好多线程，你需要理解的是道，此后才是术。

- END -