如何评价「线程的本质就是一个正在运行的函数」? 第1页

这属于话糙理不糙系列。

从说话人的口吻来看，貌似是在给某人传授关于编程的知识和经验。

诚然，这段话本身是不严谨的，但对初学者来说，有益于入门多线程编程。

毕竟，你要把本质讲清楚了，一半的人吓跑了，剩下一半听睡着了，结果一个学会的都没有。

这就跟我们小学一开始只学自然数，老师会说1 - 3减不了、2 ÷ 3除不开一样，具有更多知识的人一看就知道不严谨，但对小学一年级入门数学殿堂是有帮助的。

这个人说这话的本意，我觉得是希望打消听话人对线程的恐惧，就把它当做一个可以同时执行的函数，赶紧动手试一试。一跑程序结果对了，自然会带来更多的自信，会让人继续深入学习下去，随着学习的深入，自然会知道线程的本质到底是什么。我见过太多一提到线程、进程、并行、C语言，还没说要干啥呢，就吓得扭头就跑的汉子了……对于这些人，有一个可以降低恐惧感的老师，还是很有帮助的，哪怕说得话不严谨。

所以，要问这种说法对不对，其实说话人本身估计也知道漏洞很多。然而，他的目的是让别人赶紧钻进线程学习里，而不是一定要保证自己每句话都是无懈可击的。所以，感觉倒也无伤大雅，没必要非要去杠。

我给别人培训的时候，就说过这样的话：我给你们讲东西，从来都不怕讲错了。因为，我讲错了，你以后用到了，只要认真做测试，就会发现错了，反而印象更深刻；我讲错了，你以后用不到，既然用不到，对错又有何妨呢？这就是我为什么讲计算机知识，不讲医学知识的缘故。

说这种话的才是外行吧，

因为函数这玩意儿，本来就是C语言带坏的。这货应该说是带参数的子过程，C语言不管子过程带不带参数都叫做函数，这本来就很离谱。

至于什么正在运行的函数这更离谱，搞得函数好像有个状态叫做运行一样……

与其说什么多线程和线程是用来迷惑外行的，倒不如说是用来筛选从业者的。毕竟这玩意儿都要什么理解本质，什么直观形象，你压根儿就不适合干这行才对……

我看了一下现在的回答，似乎大都围绕着实现细节说了，少数在概念层面解释的，却都被绕进了“调度/时间片/并发”这个圈子里绕不出来了。然而，我必须指出，线程/进程在概念上，并不和这些概念捆绑——虽然大多数情况下，确实如此。

其实，线程/进程并不是一个真实存在的实体，是一个凭空抽象出来的逻辑概念。和所有凭空抽象出来的概念一样，它必然是为了某个目的而出现的，那这个目的，不是“并发/并行”，而是一个已经“濒临失传”的概念：状态机。

回到一个最简单最基础的计算机环境，一个单核单U的平台，加电后就从0地址加载第一条指令开始执行一个程序。这时候，整个程序的指令和流程必然就实现了一部状态机，而这部状态机的核心，就是一张状态转移表。这个程序所执行的各种操作，实际上都是围绕着这张状态转移表来执行的。

然而，随着软件规模的逐步扩大，各种功能逐步加强，状态的数量会越来越多，这张状态转移表也就会越来越大，越来越复杂，以至于难以维护，各种逻辑bug频出。而这个时候，再仔细看那张非常复杂的状态转移表，往往会发现，对于某个特定状态而言，它所能转移的状态一般是有限的，也就是说大多数其它状态是和它无关的。那么，为了降低编程的复杂度，为了屏蔽某些处理中不相关细节，就需要利用这点，把这张庞大的状态转移表拆分（高相关性的状态单独成表）。而这些拆分出去的子表，实际上就构成了子状态机，执行它的程序，也就成了子程序，这就是：child process。至于线程……一回事。

所以，进程/线程概念的出现，本质上是一种屏蔽无关细节，降低程序设计复杂度和难度而出现的编程概念——至于怎么实现它，那是后话（事实上在上古年代，实现方式还真的是百花齐放奇葩迭出的）。

于是有了那句著名但比较偏激的话：

A Computer is a state machine. Threads are for people who can't program state machines.
---- Alan Cox
计算机就是状态机。线程是为不懂状态机的程序员准备的。

进程线程的概念说清楚了，那稍微扩展一点，说一下它为什么现在基本上和“并发”概念给绑定了吧：

在最早期的时候，计算机还普遍处在单核单U的年代，就算拆了多个子状态机，实际上也是无法并行的。那么怎么在不同的子状态机之间进行切换呢？一种传统的办法是在子状态机内部主动设定某些条件进行主动切换，这就是所谓的用户态线程。另外一种就是大家所熟知的：统一由os接管，为每个状态机执行调度——当然，os本身也是一个状态机，无非是调度状态机的状态机而已。

早年在单核单U的年代，用户态线程，也就是所谓的“伪并发”是编程的主流。因为这种切换有明确的目的和时机，所以成本开销最小（例如说不需要加锁），因此最适合当年硬件水平还不高的环境。实际上这种架构在现今一些硬件性能不高（非常低端的嵌入式）、延迟极度敏感（游戏引擎）、极度追求性能（用户态协议栈）的项目中还能看到。

后来，随着cpu硬件的发展，尤其是多U多核的出现，并行并发任务的需求开始井喷。这时候，再让每个应用程序都继续实现用户态切换就不现实了。所以，由os统一切换和管理的“内核态线程”开始流行，于是线程/进程的概念就和“os/并发/时间片/上下文”等相关概念给深度捆绑了。

到现在，毕竟内核没有办法深度了解子程序内部逻辑，所以它的调度必然是无序而且粗暴的——所以它必须设定“时间片/优先级”之类的概念，而且每次切换都必须完整保留上下文（因为它不知道那些有用哪些没用）。同时，为了对付无序的切换，各种额外的开销（并发编程/锁）也必然很大。所以，为了降低这些开销，上古年代的用户态伪并发玩法被重新拿出来，封装了一下之后，没再用线程/进程这个名字，而是给了一个新鲜的名字：协程。

如果我的学生问我线程是什么,我的回答基本也会和「线程的本质就是一个正在运行的函数」差不多

因为这是最容易让初学者理解并能够帮助他们应用到实践中的方式。对于我来说，我施教的目的达到了。

但如果在知乎上这么说，就经常就会有一些写了几年代码的“大神”们跳出来，指正我的不对，然后举出一堆专业术语来告诉我线程不是那么一回事。同时给我扣个误人子弟，不懂装懂之类的帽子。这让我很难受。

所以回答这种问题，我还是真的挺纠结的，一来我实在不想一上来就直接就扯什么调度器，时间切片，上下文切换，信号量之类的玩意，二来我又想把这个知识点科普出去，还得让“大神”们不至于太鄙视我，思来想去干脆完成实现一个“多线程”程序。来演示“线程”这一个概念是如何运作的----准确来说，我的意思是实现一个编译器，将代码中的函数编译为特定指令流，然后在此基础上实现一个虚拟机执行环境，执行该指令流并设计一个基于指令计数切片的调度器，完成这个线程的调度工作。然后我们进一步科普线程间的协同关系并引入更多的装逼术语。当然我们的多线程的实现机制是纯算法实现且平台无关的，你不用纠结一些平台相关的额外的设计模式把你绕的云里雾里最后问一句：“听上去感觉听屌的，但线程到底是个啥”这种疑问，同时这种设计思想也许因为平台或硬件支持关系有所不同，但核心思想在多数的平台上大同小异，所以你也不用纠结我这个是不是实现的不够高大上。如果你听不明白上面说的是什么东西没关系，下面的内容，通俗易懂，老少咸宜。

我们先来写一段代码

       #name "main" #include "stdlib.h" #runtime thread 8  //线程1的函数 export void thread1() {   while(1)   {     print("I'm thread 1");      sleep(1000);   } }  //线程2的函数 export void thread2() {    while(1)   {     print("I'm thread 2");      sleep(1000);   } }  //线程3的函数 export void thread3() {    while(1)   {     print("I'm thread 3");      sleep(1000);   } }  //主线程 export int main() {   CreateThread("thread1");//开始线程1   CreateThread("thread2");//开始线程2   CreateThread("thread3");//开始线程3   while(1) sleep(1000);   return 0; }     

上面的代码,应该只要稍微懂一点C语言(虽然它不是),都很容易看懂,首先我们实现了3个线程函数,作用非常简单,就是每隔1秒print一段文本,然后一直循环下去.

因此,我们直观的理解就是,这三个函数是同时运行的,那么在屏幕上,我们大致会看到下面这种结果

那么这个是怎么实现的呢,首先,我们的函数代码会被编译为中间指令,一种类似于汇编语言的结构,可以这么说,函数里的代码,最终会编译为这种汇编指令结构,至于为什么呢,我们可以这么想,如果让CPU直接理解代码里的表达式,可能会让电路设计变得非常非常的复杂,所以呢,我们把表达式的内容这个大问题拆分成小问题,把小问题一步一步解决了,大问题就解决了,就像你计算1+2x3,我们先计算2x3=6,然后1+6=7,一步一步走,也就是这个意思

如果能理解到这一步,事情就变得很简单了,多线程怎么实现的呢,非常非常的简单,就拿我们上面这个例子来说,我们先执行线程1函数的第一条指令,比如上面的第9条指令,然后我们跳到线程2的第一条指令,也就是第33条指令..然后我们又回到线程1函数执行它的第二条指令,就是第10行指令,再到线程2函数执行它的第二条指令,就是第34条指令......一直执行下去,直到执行到这个函数的ret,也就是函数结束的返回,因为计算机的执行速度很快,所以最终看起来,这些函数就像同时运行的一样

实际上简单来说就是函数1的工作先做一点,然后跑去函数2的做一点,再去函数3的做一点....通通都只做一点点,直到事情做完为止,让人感觉我们同时在做很多事情一样.

如果我们只讨论算法方面的实现而不考虑例如一些硬件辅助,好了,这就是线程的本质,剩下的,就是纠结一些细节问题,然后发明出一堆听上去高大上的术语让别人觉得我们很牛逼了.

什么是上下文切换

我们先来直面第一个问题,要完成这种切换工作,我们需要什么?

最简单的,既然我们每个函数都做了一点工作,那么我们是不是应该拿个小本本记录一下,不同的线程分别执行到哪了,比如线程1,我们执行了2条指令,这个时候,我们就要记录:恩,线程1已经做完2条指令了,下一次要从第三条指令开始执行.这样我们下一次回到线程1时,我们就知道我们之前已经做完哪些工作了,下一次应该从哪里继续开始

那么,这个记录这个信息的东西,就叫做线程的上下文,我不知道为什么会翻译为上下文这种那么拗口的中文名,如果叫"运行状态",绝对比上下文好理解,而传说中的那个上下文切换,实际上就是当你运行了线程1的指令--->保存状态-->读取线程2上一次的运行状态--->运行线程2这一个简单的过程.

为什么要栈帧

好了,现在让我们来思考另一个问题,你想啊,既然线程1和线程2外面看起来就是两个相互独立同时运行的函数,那么是不是说,它们应该有各自独立的内存来保存自己计算过程的中间结果,这块内存区域一般放在栈中,这也就是为什么常常每个线程有自己独立的一个栈帧,当然,这块内存到底在哪了,长度有多大,一般也是在上下文中保存的

什么是时间片

这个时候,你发现了一个问题,如果线程1每次只执行1条指令,然后就跑去下一个线程执行下一个指令,显然是非常不经济实惠的,因为这种切换也会带来性能开销,你不能说为了看起来像做多件事,结果大部分时候不是在做事情,而是在各个线程中来回跑,这就非常划不来了,所以你这样这么来,定一个时间,比如线程1执行个10毫秒,然后线程2执行个10毫秒,这样就不会显得疲于奔命,这个就叫时间片,但时间片一定是按时间来的么,不一定,你也可以按指令数来,比如线程1执行个100条指令,线程2执行100条...以此类推也一样,当然两种做法各有优劣,总之时间片一个简单的概述就是在某个线程做多少/多久的事情这一个简单的概念

什么是信号量/锁

比如一个工作,要等线程1和线程2都做完了才能接着往下做,或者说线程1要等线程2做完了才能继续往下做,怎么办呢,简单啊,我们定义一个变量,初始值为0来说,线程2做完了,就把它的值设置为1(或者通知其它线程检查这个变量),而线程1呢,它会检查这个变量,如果说如果它看到这个值是0,它就跑去睡大觉了(线程挂起)直到有人通知他它才醒来再检查一次,那么这个过程就叫信号量,如果它不断检查这个变量而不去睡大觉直到它变为1,那么这个过程叫锁(自旋锁),当然基于这点还可以拓展实现出一些临界区,互斥量之类的叫法,然而换汤不换药,本质上这个打tag然后检查的这个过程实现并没有太多变动.

什么是原子操作

这堆代码没有执行完之前,不!准!进!行!上!下!文!切!换!,哪怕已经没有时间片了

碰到阻塞函数怎么办

比如上面的sleep函数,比如你想从硬盘读数据这种可能花的时间比较久的函数,或者说你在等待网络有一个数据包过来,常常是一些IO类的函数,执行到这个函数,即使时间片还没有用完也不要瞎等了,直接上下文切换该干什么干什么不要浪费CPU的人生.

那什么是调度器

好了,实现可能包括但不限于这些功能,然后把它们拼在一块的玩意,就叫调度器.

现在我们基本讲完一个线程的大部分内容了

文章的最后,如果你真对这个线程实现感兴趣

这里有编译器到带有线程调度功能的虚拟机的完整C语言实现

最后,学习过程中真的应该珍惜有这种愿意用最好懂的方式或语言给你讲解知识点的朋友或老师,如果一个人明知道他说的这些你听不懂,而仍然坚持要跟你这么说,那只能说明他的目的并不是想教会你,而是想告诉你我有多凡尔赛多牛逼.当然我也没有贬低谁的意思,毕竟这种事情你知我知,大家都爱干.

       # centos yum install criu # ubuntu apt-get install criu     

       #define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <sys/mount.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/wait.h> #include <sys/param.h> #include <sys/mman.h> #include <fcntl.h> #include <signal.h> #include <sched.h>  #define STACK_SIZE (8 * 4096)  static int ac; static char **av; static int ns_exec(void *_arg) {         close(0);  setsid();  execvp(av[1], av + 1);  return 1; }  int main(int argc, char **argv) {  void *stack;  pid_t pid;   ac = argc;  av = argv;   stack = mmap(NULL, STACK_SIZE, PROT_WRITE | PROT_READ,     MAP_PRIVATE | MAP_GROWSDOWN | MAP_ANONYMOUS, -1, 0);  clone(ns_exec, stack + STACK_SIZE,    CLONE_NEWPID | CLONE_NEWIPC | SIGCHLD, NULL);  return 0; }     

       gcc -o newns newns.c     

       #!/bin/sh while :; do     sleep 1     date done     

       [root@VM-8-5-centos thread]# ./newns bash test.sh [root@VM-8-5-centos thread]# 2021年 07月 06日 星期二 19:55:53 CST 2021年 07月 06日 星期二 19:55:54 CST 2021年 07月 06日 星期二 19:55:55 CST 2021年 07月 06日 星期二 19:55:56 CST 2021年 07月 06日 星期二 19:55:57 CST     

       ps -ef| grep 'bash test.sh'  | head -1 | awk '{print $2}' | xargs -I PID criu dump -t PID --shell-job  --images-dir /home/thread/checkpoint     

       [root@VM-8-5-centos thread]# cd checkpoint/ [root@VM-8-5-centos checkpoint]# ls core-14.img   fdinfo-3.img  fs-24.img   inventory.img    mm-24.img       pages-1.img  stats-dump core-1.img    files.img     ids-14.img  ipcns-var-9.img  pagemap-14.img  pages-2.img  tty-info.img core-24.img   fs-14.img     ids-1.img   mm-14.img        pagemap-1.img   pstree.img fdinfo-2.img  fs-1.img      ids-24.img  mm-1.img         pagemap-24.img  seccomp.img [root@VM-8-5-centos checkpoint]# criu restore --images-dir /home/thread/checkpoint --shell-job & [1] 17235 [root@VM-8-5-centos checkpoint]#  2021年 07月 06日 星期二 19:56:26 CST 2021年 07月 06日 星期二 19:56:27 CST 2021年 07月 06日 星期二 19:56:28 CST 2021年 07月 06日 星期二 19:56:29 CST 2021年 07月 06日 星期二 19:56:30 CST     

       [root@VM-8-5-centos thread]# crit decode -i /home/thread/checkpoint/core-1.img --pretty >> /home/thread/checkpoint/core-1.json