【Linux】多线程详解（上）

电玩女神 2024-04-20 06:41 3阅读 0赞

> **🎇Linux：**
> 
> --------------------
> 
>  *  **博客主页：**[一起去看日落吗][Link 1]
>  *  **分享博主的在Linux中学习到的知识和遇到的问题**
>  *  **`博主的能力有限，出现错误希望大家不吝赐教`**
>  *  **分享给大家一句我很喜欢的话：** 看似不起波澜的日复一日，一定会在某一天让你看见坚持的意义，祝我们都能在鸡零狗碎里找到闪闪的快乐🌿🌞🐾。
> 
> --------------------
> 
> ![在这里插入图片描述][0c3f31bc6bb5460689d5e339f5299830.jpeg_pic_center]

🍁 🍃 🍂 🌿

--------------------

#### 目录 ####

*  🍁 1. Linux线程概念
 *   *  🍂 1.1 什么是线程
     *  🍂 1.2 二级页表
     *  🍂 1.3 线程的优点
     *  🍂 1.4 线程的缺点
     *  🍂 1.5 线程异常
     *  🍂 1.6 线程用途
 *  🍁 2. Linux进程VS线程
 *   *  🍂 2.1 进程和线程
     *  🍂 2.2 进程的多个线程共享
     *  🍂 2.3 进程和线程的关系

## 🍁 1. Linux线程概念 ##

### 🍂 1.1 什么是线程 ###

*  在一个程序里的一个执行路线就叫做线程（thread）。更准确的定义是：线程是“一个进程内部的控制序列”
 *  一切进程至少都有一个执行线程
 *  线程在进程内部运行，本质是在进程地址空间内运行
 *  在Linux系统中，在CPU眼中，看到的PCB都要比传统的进程更加轻量化
 *  透过进程虚拟地址空间，可以看到进程的大部分资源，将进程资源合理分配给每个执行流，就形成了线程执行流

需要明确的是，一个进程的创建实际上伴随着其进程控制块（task\_struct）、进程地址空间（mm\_struct）以及页表的创建，虚拟地址和物理地址就是通过页表建立映射的。

每个进程都有自己独立的进程地址空间和独立的页表，也就意味着所有进程在运行时本身就具有独立性。

其中每一个线程都是当前进程里面的一个执行流，也就是我们常说的“线程是进程内部的一个执行分支”。

同时我们也可以看出，线程在进程内部运行，本质就是线程在进程地址空间内运行，也就是说曾经这个进程申请的所有资源，几乎都是被所有线程共享的。

当我们创建进程时是创建一个task\_struct、创建地址空间、维护页表，然后在物理内存当中开辟空间、构建映射，打开进程默认打开的相关文件、注册信号对应的处理方案等等。

而我们之前接触到的进程都只有一个task\_struct，也就是该进程内部只有一个执行流，即单执行流进程，反之，内部有多个执行流的进程叫做多执行流进程。  
![在这里插入图片描述][03ad00fde7f84aacbdf862bdefcdb5ca.png]

*  **在Linux中，站在CPU的角度，能否识别当前调度的task\_struct是进程还是线程？**

答案是不能，也不需要了，因为CPU只关心一个一个的独立执行流。无论进程内部只有一个执行流还是有多个执行流，CPU都是以task\_struct为单位进行调度的。

CPU看到的虽说还是task\_struct，但已经比传统的进程要更轻量化了。

*  **Linux下并不存在真正的多线程！而是用进程模拟的！**

操作系统中存在大量的进程，一个进程内又存在一个或多个线程，因此线程的数量一定比进程的数量多，当线程的数量足够多的时候，很明显线程的执行粒度要比进程更细。

如果一款操作系统要支持真的线程，那么就需要对这些线程进行管理。比如说创建线程、终止线程、调度线程、切换线程、给线程分配资源、释放资源以及回收资源等等，所有的这一套相比较进程都需要另起炉灶，搭建一套与进程平行的线程管理模块。

因此，如果要支持真的线程一定会提高设计操作系统的复杂程度。在Linux看来，描述线程的控制块和描述进程的控制块是类似的，因此Linux并没有重新为线程设计数据结构，而是直接复用了进程控制块，所以我们说Linux中的所有执行流都叫做轻量级进程。

但也有支持真的线程的操作系统，比如Windows操作系统，因此Windows操作系统系统的实现逻辑一定比Linux操作系统的实现逻辑要复杂得多。

*  **既然在Linux没有真正意义的线程，那么也就绝对没有真正意义上的线程相关的系统调用！**

这很好理解，既然在Linux中都没有真正意义上的线程了，那么自然也没有真正意义上的线程相关的系统调用了。但是Linux可以提供创建轻量级进程的接口，也就是创建进程，共享空间，其中最典型的代表就是vfork函数。

vfork函数的功能就是创建子进程，但是父子共享空间

pid_t vfork(void);

vfork函数的返回值与fork函数的返回值相同：

*  给父进程返回子进程的PID。
 *  给子进程返回0。

只不过vfork函数创建出来的子进程与其父进程共享地址空间，例如在下面的代码中，父进程使用vfork函数创建子进程，子进程将全局变量g\_val由100改为了200，父进程休眠3秒后再读取到全局变量g\_val的值。

#include <stdio.h>
    #include <stdlib.h>
    #include <sys/types.h>
    #include <unistd.h>
    int g_val = 100;
    int main()
    {
        
    	pid_t id = vfork();
    	if (id == 0){
        
    		//child
    		g_val = 200;
    		printf("child:PID:%d, PPID:%d, g_val:%d\n", getpid(), getppid(), g_val);
    		exit(0);
    	}
    	//father
    	sleep(3);
    	printf("father:PID:%d, PPID:%d, g_val:%d\n", getpid(), getppid(), g_val);
    	return 0;
    }

可以看到，父进程读取到g\_val的值是子进程修改后的值，也就证明了vfork创建的子进程与其父进程是共享地址空间的。

![在这里插入图片描述][f552b097ac2848e7a2e07ed14323ed78.png]

*  **原生线程库pthread**

在Linux中，站在内核角度没有真正意义上线程相关的接口，但是站在用户角度，当用户想创建一个线程时更期望使用thread\_create这样类似的接口，而不是vfork函数，因此系统为用户层提供了原生线程库pthread。

原生线程库实际就是对轻量级进程的系统调用进行了封装，在用户层模拟实现了一套线程相关的接口。

因此对于我们来讲，在Linux下学习线程实际上就是学习在用户层模拟实现的这一套接口，而并非操作系统的接口。

--------------------

### 🍂 1.2 二级页表 ###

**以32位平台为例，在32位平台下一共有232个地址，也就意味着有232个地址需要被映射。**

如果我们所谓的页表就只是单纯的一张表，那么这张表就需要建立232个虚拟地址和物理地址之间的映射关系，即这张表一共有232个映射表项。

![在这里插入图片描述][7599a8f6d6194091ac6fd1f55e5f8a9c.png]  
![在这里插入图片描述][836e6577c6c44ba98f13db72522bee17.png]  
每个应表项中存储一个物理地址和一个虚拟地址就需要8个字节，考虑到还需要包含权限相关的各种信息，这里每一个表项就按10个字节计算。

这里一共有232个表项，也就意味着存储这张页表我们需要用232 \* 10个字节，也就是40GB。而在32位平台下我们的内存可能一共就只有4GB，也就是说我们根本无法存储这样的一张页表。

**因此所谓的页表并不是单纯的一张表。**

还是以32位平台为例，其页表的映射过程如下：

*  选择虚拟地址的前10个比特位在页目录当中进行查找，找到对应的页表。
 *  再选择虚拟地址的10个比特位在对应的页表当中进行查找，找到物理内存中对应页框的起始地址。
 *  最后将虚拟地址中剩下的12个比特位作为偏移量从对应页框的起始地址处向后进行偏移，找到物理内存中某一个对应的字节数据。

相关说明：

*  物理内存实际是被划分成一个个4KB大小的页框的，而磁盘上的程序也是被划分成一个个4KB大小的页帧的，当内存和磁盘进行数据交换时也就是以4KB大小为单位进行加载和保存的。
 *  4KB实际上就是212个字节，也就是说一个页框中有212个字节，而访问内存的基本大小是1字节，因此一个页框中就有212个地址，于是我们就可以将剩下的12个比特位作为偏移量，从页框的起始地址处开始向后进行偏移，从而找到物理内存中某一个对应字节数据。

![在这里插入图片描述][650e7b5e53f947428289de020ea11db4.png]  
这实际上就是我们所谓的二级页表，其中页目录项是一级页表，页表项是二级页表。

每一个表项还是按10字节计算，页目录和页表的表项都是210个，因此一个表的大小就是210 \* 10个字节，也就是10KB。而页目录有210个表项也就意味着页表有210个，也就是说一级页表有1张，二级页表有210张，总共算下来大概就是10MB，内存消耗并不高，因此Linux中实际就是这样映射的。

上面所说的所有映射过程，都是由MMU（MemoryManagementUnit）这个硬件完成的，该硬件是集成在CPU内的。页表是一种软件映射，MMU是一种硬件映射，所以计算机进行虚拟地址到物理地址的转化采用的是软硬件结合的方式。

**注意： 在Linux中，32位平台下用的是二级页表，而64位平台下用的是多级页表。**

**修改常量字符串为什么会触发段错误？**

当我们要修改一个字符串常量时，虚拟地址必须经过页表映射找到对应的物理内存，而在查表过程中发现其权限是只读的，此时你要对其进行修改就会在MMU内部触发硬件错误，操作系统在识别到是哪一个进程导致的之后，就会给该进程发送信号对其进行终止。

--------------------

### 🍂 1.3 线程的优点 ###

*  创建一个新线程的代价要比创建一个新进程小得多。
 *  与进程之间的切换相比，线程之间的切换需要操作系统做的工作要少很多。
 *  线程占用的资源要比进程少很多。
 *  能充分利用多处理器的可并行数量。
 *  在等待慢速IO操作结束的同时，程序可执行其他的计算任务。
 *  计算密集型应用，为了能在多处理器系统上运行，将计算分解到多个线程中实现。
 *  IO密集型应用，为了提高性能，将IO操作重叠，线程可以同时等待不同的IO操作。

计算密集型：执行流的大部分任务，主要以计算为主。比如加密解密、大数据查找等。

IO密集型：执行流的大部分任务，主要以IO为主。比如刷磁盘、访问数据库、访问网络等。

--------------------

### 🍂 1.4 线程的缺点 ###

*  **性能损失**： 一个很少被外部事件阻塞的计算密集型线程往往无法与其他线程共享同一个处理器。如果计算密集型线程的数量比可用的处理器多，那么可能会有较大的性能损失，这里的性能损失指的是增加了额外的同步和调度开销，而可用的资源不变。
 *  **健壮性降低**： 编写多线程需要更全面更深入的考虑，在一个多线程程序里，因时间分配上的细微偏差或者因共享了不该共享的变量而造成不良影响的可能性是很大的，换句话说，线程之间是缺乏保护的。
 *  **缺乏访问控制**： 进程是访问控制的基本粒度，在一个线程中调用某些OS函数会对整个进程造成影响。
 *  **编程难度提高**： 编写与调试一个多线程程序比单线程程序困难得多。

--------------------

### 🍂 1.5 线程异常 ###

*  单个线程如果出现除零、野指针等问题导致线程崩溃，进程也会随着崩溃。
 *  线程是进程的执行分支，线程出异常，就类似进程出异常，进而触发信号机制，终止进程，进程终止，该进程内的所有线程也就随即退出。

### 🍂 1.6 线程用途 ###

*  合理的使用多线程，能提高CPU密集型程序的执行效率。
 *  合理的使用多线程，能提高IO密集型程序的用户体验（如生活中我们一边写代码一边下载开发工具，就是多线程运行的一种表现）。

--------------------

## 🍁 2. Linux进程VS线程 ##

### 🍂 2.1 进程和线程 ###

**进程是承担分配系统资源的基本实体，线程是调度的基本单位。**

线程共享进程数据，但也拥有自己的一部分数据：

*  线程ID。
 *  一组寄存器。（存储每个线程的上下文信息）
 *  栈。（每个线程都有临时的数据，需要压栈出栈）
 *  errno。（C语言提供的全局变量，每个线程都有自己的）
 *  信号屏蔽字。
 *  调度优先级。

--------------------

### 🍂 2.2 进程的多个线程共享 ###

因为是在同一个地址空间，因此所谓的代码段（Text Segment）、数据段（Data Segment）都是共享的：

*  如果定义一个函数，在各线程中都可以调用。
 *  如果定义一个全局变量，在各线程中都可以访问到。

除此之外，各线程还共享以下进程资源和环境：

*  文件描述符表。（进程打开一个文件后，其他线程也能够看到）
 *  每种信号的处理方式。（SIG\_IGN、SIG\_DFL或者自定义的信号处理函数）
 *  当前工作目录。（cwd）
 *  用户ID和组ID。

--------------------

### 🍂 2.3 进程和线程的关系 ###

进程和线程的关系如下图：

![在这里插入图片描述][78c5025c39b14f7ea014aa395a2e9984.png]

在此之前我们接触到的都是具有一个线程执行流的进程，即单线程进程。

--------------------

[Link 1]: https://blog.csdn.net/m0_60338933?type=blog
[0c3f31bc6bb5460689d5e339f5299830.jpeg_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/20/44d06b57f5924e9c8bfe85d0a872ead1.jpeg
[03ad00fde7f84aacbdf862bdefcdb5ca.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/20/1367f970d0554630abdf0fed973f2d20.png
[f552b097ac2848e7a2e07ed14323ed78.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/20/01a99eeb6807400d8a57c6b1c103078f.png
[7599a8f6d6194091ac6fd1f55e5f8a9c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/20/3bbbc194b3054742a2fa8956e0c27024.png
[836e6577c6c44ba98f13db72522bee17.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/20/097a80da67bf40d494388d37040bb86f.png
[650e7b5e53f947428289de020ea11db4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/20/8ac047926473416da91075f4ca7a845b.png
[78c5025c39b14f7ea014aa395a2e9984.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/20/4977343d6b1f4bf08357d5c9178a55a0.png