# 引言
我们要如何做到使用非自增主键ID，但是又保证一定的查询性能呢？一般来说，我们可以通过引入索引来优化SQL查询性能，但是具体要如何优化呢？从什么方向上优化呢？

本文通过如何设计订单表ID为起点，引出关于如何设计主键保证数据库查询性能所引起的血案，~~来逐步发掘 “MySQL 数据库索引设计中“ 的真相~~，一步步解析 MySQL 的索引相关知识点



#### 思路
主键设计 => 数据库查询性能 => 索引性能 => 如何充分利用索引 => MySQL索引架构 => 主键索引 => 二级索引 => 联合索引 => 覆盖索引

# DBMS 二级索引结构
>数据库中，**二级索引**（Secondary Index）是除了主键索引之外的索引

MySQL中主键索引是属于聚簇索引，由于聚簇索引中索引和数据物理上粘连存储，所以索引是**逻辑并物理有序的**，也就是说主键索引不仅在B+树上是有序的，而且在磁盘中的存储位置也是有序排列的。

由于磁盘读取是每次按块读取的，**物理有序的主键索引**也都会**连续地**存储在**同一磁盘块上**，磁盘读取**命中率就会大大提高**，减少磁盘IO次数提高读写性能

而二级索引就只是**逻辑上有序**，通过磁盘中存储的一个数据结构组织数据的具体地址，而不是物理数据，是一种**非聚簇索引**。二级索引在这里作为补充方案，对部分常用的字段查找性能进行有取舍的优化

# MySQL实现
在MySQL中的二级索引实现，是通过B+树存储二级索引结，在叶节点存储对应数据的主键ID。当使用二级索引进行查找对应数据时，会进入到对应的索引B+树中进行查找，然后从对应叶节点获取主键ID进行**回表查询**

#### 回表查询
**MySQL的二级索引的叶节点，存储的并不是数据的磁盘物理地址，而是主键的值，通过主键值再从主键索引中查询数据。**

因此对于这个特性可以针对性地优化SQL语句：减少查询字段，
```sql
SELECT * FROM users WHERE name = 'Alice';
```

```sql
SELECT id, name FROM users WHERE name = 'Alice';
```
第一条SQL中select所有列，就需要回表查询所有数据。而第二条SQL中，首先是通过 name = ‘Alice’ 获取到了name，然后在name字段的二级索引中，获取到了id。由于到这里已经获取到所有需要的数据了，因此直接返回而没有进行回表查询。

# 联合索引
相较于前面提到的索引，都是**单个字段**组成的索引，而我们可以还可以将多个字段组合在一起变成一个**二级索引**，也就是我们常说的**联合索引**。

这里我们通过一个图表来解释联合索引的构成：
假设我们有一个表 `orders`，有三个字段：`user_id`, `status`, `created_at`。

我们创建了一个联合索引：`INDEX idx_order (user_id, status)`。从而我们就可以得到如下的一个索引B+树：
![output.png](https://www.blog.aeside.top/static/img/91f166817a97b7355bd5d1cd8e5d47e2.output.webp)通过这张图，我们可以发现联合索引中，按照**联合索引的排列顺序**，整个B+树按照**这个排列顺序**有序。换句话说，在这个B+索引树中，`user_id`全局上有序；但`status`只在`user_id`其中内部有序，而整个B+索引树中全局上无序

而这一个特性，也就引出联合索引中的一个关键使用原则：**最左匹配原则**

### 最左匹配原则 & 失效
>最左匹配原则是指在使用联合索引时，MySQL 会从联合索引的最左边的列开始，依次向右匹配查询条件，直到遇到范围查询（如 `>`、`<`、`BETWEEN` 等）或不满足条件的列为止。

从刚才的B+联合索引树中，我们可以很容易就理解最左匹配原则的原理：
*在这个B+索引树中，`user_id`全局上有序；但`status`只在`user_id`其中内部有序，而整个B+索引树中全局上无序*

通过遵守最左匹配原则，我们能大大提高SQL的查询性能，但是为什么有时候我们的最左匹配原则会失效呢？首先是比较常见的失效常见：
1. 查询条件跳过最左列
2. 查询条件包含范围查询 & 使用非等值操作符
3. 查询条件
4. 索引列参与表达式或函数
5. 隐式类型转换
6. 数据分布极端

而这里由于**包含范围查询 & 使用非等值操作符**导致的失效比较难理解外，其他的都一看就懂，因此不做分析
#### 范围查询 & 非等值操作符导致的联合索引失效
##### B+树与链表
为什么在B+树中**包含范围查询 & 使用非等值操作符**会导致联合索引失效？对于这样一个问题，我们要层层刨析、分而治之。

首先，B+树的结构不仅适合精确查询，也十分适合范围查询。因为在B+树中，所有的数据都存储在叶节点中，而且所有的叶节点都必须在同一层上，且B+树的叶节点之间还会有指针相连接前后节点。
因此，根据B+树的特性，我们不妨可以**将这个树作为一个链表来看**：B+树的叶节点是一条长长的链表，而在链表之上，有一个索引树指向链表分为一条条的段。**似乎可以将B+树作为一种另类的跳表来看**

通过上面B+树特性的分析，我们就可以简而明了地理解B+树对范围查询的支持：**B+树的叶节点作为链表来看，是全局有序的**。只需要通过索引找出对应的开头和结尾，就可以确定范围。
##### “链表”中的有序性
似乎我们看见了一个故人——**全局有序性**，而与之对应的就是局部有序性。回看我们前面的内容：
*在这个B+索引树中，`user_id`全局上有序；但`status`只在`user_id`其中内部有序，而整个B+索引树中全局上无序*

我们在对次级索引进行更详细的归纳：**次级索引的有序性，是基于==单个==主要索引的有序性之上的。**

是的，单个主要索引之上。到了这里问题的答案也就自然引出：
**在`user_id > 100`中存在多个主要索引，而在这些不同的主要索引之中的次级索引，只在单个主要索引中具有有序性，而在多个索引中、全局上是不具有有序性的。**
因此我们就无法用联合索引进行SQL查询`WHERE user_id > 100 AND status = 0`！

举一反三，通过上面的原理`WHERE user_id = 100 AND status > 1`就可以使用联合索引，首先找到user_id = 100的节点区域，在这个主要索引内部中，status就具有局部的有效性。

最后留个思考题，like的模糊查询呢？

### 覆盖索引
基于MySQL中回表查询的特性，我们就可以针对特定的SQL语句，创建**具有所有需要查找字段的索引**——**覆盖索引**

结合前面二级索引，当我们使用覆盖索引进行SQL查询，就可以之间通过B+索引树之间获取到我们全部所需要字段内容，而无需进行回表查询，实现和主键索引一样的性能
## 总结
至此，通过我们对 MySQL 索引结构、回表查询、联合索引、覆盖索引的学习，我们可以针对特定业务所需要执行的SQL语句，建立对应字段的**覆盖索引**，就可以同时实现安全性和查询性能的保障了。

MySQL索引结构 & 回表查询

*~~个人觉得自己这部分内容写得太牛逼了，所以单独抽出成一篇Blog~~*
# B+树与链表
为什么在B+树中**包含范围查询 & 使用非等值操作符**会导致联合索引失效？对于这样一个问题，我们要层层刨析、分而治之。



首先，B+树的结构不仅适合精确查询，也十分适合范围查询。因为在B+树中，所有的数据都存储在叶节点中，而且所有的叶节点都必须在同一层上，且B+树的叶节点之间还会有指针相连接前后节点。

因此，根据B+树的特性，我们不妨可以**将这个树作为一个链表来看**：B+树的叶节点是一条长长的链表，而在链表之上，有一个索引树指向链表分为一条条的段，**而我们似乎可以将B+树作为一种另类的跳表来看待**。

通过上面B+树特性的分析，我们就可以简而明了地理解B+树对范围查询的支持：**B+树的叶节点作为链表来看，是全局有序的**。只需要通过索引找出对应的开头和结尾，就可以确定范围。
# “链表”中的有序性
似乎我们看见了一个故人——**全局有序性**，而与之对应的就是局部有序性。回看我们前面的内容：
>*在这个B+索引树中，`user_id`全局上有序；但`status`只在`user_id`其中内部有序，而整个B+索引树中全局上无序*

我们在对次级索引进行更详细的归纳：**次级索引的有序性，是基于==单个==主要索引的有序性之上的。**

是的，单个主要索引之上。到了这里问题的答案也就自然引出：
**在`user_id > 100`中存在多个主要索引，而在这些不同的主要索引之中的次级索引，只在单个主要索引中具有有序性，而在多个索引中、全局上是不具有有序性的。**
因此我们就无法用联合索引进行SQL查询`WHERE user_id > 100 AND status = 0`！

举一反三，通过上面的原理`WHERE user_id = 100 AND status > 1`就可以使用联合索引，首先找到user_id = 100的节点区域，在这个主要索引内部中，status就具有局部的有效性。

>最后留个思考题，like的模糊查询呢？

MySQL中范围查询 & 非等值操作符导致的联合索引失效

Redis 是多线程还是单线程？这是一个经典的面试题目，个人认为也是对Redis架构设计的一个简单概要。
本文主要是对 Redis 架构进行一个简要的梳理分析和概要，而不在细节上进行深入的探讨




# 总览
首先，Redis 并不是简单的多线程或是单线程，他既是一个单线程程序，又是一个多线程程序，两者的关系并非非此即彼，而且在其中还穿插着异步线程。我们可以通过一张简单的模型图来大致概括一下 Redis 的线程结构：

![Redis多线程架构图.drawio.png](https://www.blog.aeside.top/static/img/126ea7c9d8325eecc2bd1cca4cf3f403.Redis%C3%A5%C2%A4%C2%9A%C3%A7%C2%BA%C2%BF%C3%A7%C2%A8%C2%8B%C3%A6%C2%9E%C2%B6%C3%A6%C2%9E%C2%84%C3%A5%C2%9B%C2%BE.drawio.webp)


# Redis 的单线程
Redis的“单线程”主要是指Redis的**网络IO**和**键值对读写**是由**一个线程**来完成的，Redis在处理客户端的请求时包括获取（socket读）、解析、执行、内容返回（socket写）等都由一个**顺序串行的主线程处理**（第一篇介绍过的那些原子的命令），这也是Redis对外提供键值存储服务的主要流程。

Redis采用**Reactor模式**的网络模型，对于一个客户端请求，主线程负责一个完整的处理过程，如下图：

![file-20250726090401203.png](https://www.blog.aeside.top/static/img/faa3320e65c53adb5007b67e576269bd.file-20250726090401203.webp)
> 补充：
> 
> Reactor 模式是一种**并发模型**，在这种模型中，**主线程（Reactor）**避免了由于等待一或多个并发事件（比如 I/O 操作）的完成而无法继续工作的阻塞。通过使用非阻塞 I/O 操作和事件通知，主线程在并发操作完成时得到通知。
> 
> 一般来说，Reactor 模式的工作流程如下：
> 
> 1. 应用程序将需要**监听的 I/O 事件（比如 socket 的可读、可写事件）注册到 Reactor 中，并且关联对应的处理事件。
> 2. Reactor 不断地**轮询**这些事件，当某个事件到达的时候（比如 socket 中有数据可读），Reactor 将这个事件对应的处理事件唤醒，交由一个工作线程（或者称之为 EventHandler）去处理。
> 3. 工作线程处理完相应的事件后，通知 Reactor **继续监听**这个事件。
> 
> 这种模型非常适合于**大并发，少逻辑**的网络程序中，比如 Nginx 中就用到了这种设计模式。通过这种方式，一个线程可以处理很多连接的事件，而不需要为每个连接都创建一个线程，这样就可以避免线程切换的开销，并且可以更有效地使用系统资源。

# Redis 的异步
Redis 作为一款内存型数据库，大多数读写操作的执行速度都非常快。然而，仍有一些操作相对耗时，例如持久化、空间清理、删除大对象（Big Key）等。这类操作如果在主线程中同步执行，可能会显著阻塞 Redis 对后续请求的响应，从而影响整体性能。

通过分析可以发现，这些操作往往对实时性要求并不高。因此，我们可以将它们**异步化处理**，即通过后台线程或子进程的方式执行这些耗时任务，从而避免阻塞主线程，提升 Redis 的响应能力和吞吐量。

- **持久化操作**：如 RDB 快照生成、AOF 重写，通过 fork 子进程完成，主线程不被阻塞。
- **惰性删除（Lazy Free）**：使用 `UNLINK` 命令删除大对象时，实际内存释放由后台线程异步完成。
- **过期键清理**：Redis 采用惰性删除与定期删除相结合的方式，部分清理任务异步执行。
- **主从复制**：写命令的同步是异步进行的，提升主节点的响应效率。

# Redis 的多线程
Redis 的多线程架构在使用方面上，主要还是在IO处理上面。首先，在 Redis 早期完全单线程的结构中，面对IO瓶颈是通过多路复用的方式解决的。

> IO多路复用
> 一种同步的IO模型，实现一个线程监视多个文件句柄，一旦某个文件句柄就绪，就能通知到对应程序进行相应的读写操作，没有文件句柄就绪时，就会阻塞应用程序，从而释放CPU资源。
> 
> 我们来介绍几个概念：
> - I/O
> 	- 网络I/O，尤其在操作系统层面指数据在内核态和用户态之间的读写操作
> - 多路
> 	- 多个客户端连接（连接就是套接字描述符，即socket或者channel）
> - 复用
> 	- 复用一个或者几个线程连接
> - IO多路复用
> - 也就是说一个或者一组线程处理多个TCP，使用单进程就能实现同时处理多个客户端的连接，无需创建或者维护过多的进程/线程
> 
> 总结
> - 一个服务端进程可以同时处理多个套接字描述符
> - 实现多路复用的模型有3种：可以分select->poll->epoll3个阶段来描述

但是随着 Redis QPS增多，一个线程同时处理的IO请求变得越来越多。举个极端的例子，当一个线程通过IO多路复用，同时监控1k个socket接口，这时候瓶颈反而到了CPU上面。因此，我们就需要映入多个线程来进行负载均衡，但是依然是一个线程通过IO多路复用对多个socket。

# 总结

![](https://www.blog.aeside.top/static/img/126ea7c9d8325eecc2bd1cca4cf3f403.Rediså¤çº¿ç¨æ¶æå¾.drawio.webp)

Redis 的多线程设计主要致力于解决**网络 I/O 在高并发下的性能瓶颈**，而非为了并行执行 Redis 命令。它采用了**主线程 + 多个 I/O 子线程**的混合模型，既保留了 Redis 的一致性优势，又显著提升了整体吞吐能力。

- **主线程**负责接收客户端连接、解析命令以及执行核心逻辑操作，确保数据的一致性和命令执行的原子性。
- **I/O 子线程**用于加速网络请求的读取和响应写回过程，特别是在高并发场景下，通过多个I/O子线程来均衡负载，提高处理效率。

与此同时，Redis 还引入了**异步处理机制**以应对那些相对耗时但对实时性要求不高的任务，例如持久化、空间清理和删除大对象（Big Key）。这些操作如果同步执行会阻塞主线程，影响系统性能。因此，Redis 采用以下策略进行优化：

- **持久化操作**：如 RDB 快照生成和 AOF 文件重写，通过 fork 子进程完成，避免阻塞主线程。
- **惰性删除（Lazy Free）**：使用 `UNLINK` 命令删除大对象时，实际内存释放由后台线程异步完成。
- **过期键清理**：Redis 结合惰性删除与定期删除的方式，部分清理任务异步执行，减少对主线程的影响。

综上所述，Redis 不仅通过多线程架构提升网络 I/O 性能，还利用异步处理机制优化了耗时任务的管理。这种综合设计使得 Redis 能够在保持高性能的同时，提供稳定可靠的服务。

# 参考资料
【Redis】高级篇： 一篇文章讲清楚Redis的单线程和多线程 - 秦她的菜的文章 - 知乎
https://zhuanlan.zhihu.com/p/646111642

Redis 线程模型

 
- 虚拟化
	- ==进程，操作系统为程序提供了一个虚拟环境，让程序 **“好像”** 独占了CPU==



# 进程
- 除了程序状态，还会保存一些额外的(只读)状态

进程中的程序
- 程序是状态机的**静态描述**
	- 描述了在程序运行时，所有可能的程序状态
	- **程序运行，就变成了进程**
# 进程管理API  
- 创建状态机
	- Windows系统
		- 创建状态机spawn(path, argv)
		- 销毁状态机_exit()
	- UNIX
		- 复制状态机fork()
			- 会 ==**完整地拷贝状态**==（寄存器&每一个字节的内存）
			- 包括这个进程在操作系统中的状态(ppid,文件,信号)
			- 区分
				- 新创建进程返回 0
				- 执行 fork 的进程返回子进程的进程号——“父子关系”
		- ==**复位状态机execve()**==
			 UNIX 选择只给一个复位状态机的 API
			- 将当前进程**重置**成一个可执行文件描述状态机的初始状态
			- **操作系统维护的状态不变**：进程号、目录、打开的文件……
			    - (程序员总犯错，因此打开文件有了 O_CLOEXEC)
		- 销毁状态机
			- 立即摧毁状态机，允许有一个返回值
		    - 返回值可以被父进程获取
# 进程的地址空间
- 程序的初始状态
- Memory Map 系统调用，分配内存给予程序
	- mmap() 
		- 在状态机状态上增加一段可访问的内存
		- 把物理磁盘地址，映射到虚拟地址空间。让进程通过虚拟地址，间接操作磁盘文件
	- munmap()
		- 释放
	- mprotect()
		- 修改  
- 入侵进程的地址空间 

****
# 文件
# 访问操作系统中的对象
**==In UNIX, everything is a file==**
**文件——有"名字"的数据对象**
- 字节流
- 字节序列

- **File Descriptor** **文件描述符**
	- FD是操作系统为进程维护的**一个int索引值**。
	- 一个进程的所有FD，被**私有**地存放在进程的 **文件描述符表**。在这里，**文件描述表**相当于一个==`struct file`的数组==，而`fd`则是这里的**idx**。而`struct file`则是存储文件信息的结构体
	- 但是FD的所有操作都是借助OS API进行的
	- 操作
		- open()
			- 在FD表中，找一个最小IDX的空闲位置，分配一个新的FD
		- write() & read()
			- 通过FD找到对应`struct file`中的f_pos（文件偏移量），读取偏移count个字节
		- dup()
			- 先和open()一样分配一个FD，然后复制指定FD的内容
- **offset** **文件偏移量**
	- f_pos，Linux下的offset
		- 无论是在dup()中，还是在fork()中，offset都是**继承**的。
		- 为了便利开发者选择继承机制，后来引入了fcntl() 
		- 共用一个文件的同一个offset
		- 
- Handle，Windows下的FD
		- 在Windows中，handle默认是不继承的（面向工程的设计，=="最小权限原则"==）
- pipe() 管道
	- 返回两个FD
		- write port
		- read port
	- 父子进程实现同步
- Unix中的管道符" | "实现
- FD适合什么
	- 字节流，顺序读写，无数据等待
	- 而对于字节序列

- In UNIX, everything is a file
	- 优点
	- 一套API访问所有对象
		-  一切都可以 | grep
	- 缺点
		- 耦合

# Shell
## 什么是终端
- 终端原理
	- 作为输出设备
		- 接受 UART 信号并显示 (Escape Sequence 就非常自然了)
	- 作为输入设备
		- 把按键的 ASCII 码输出到 UART (所以有很多控制字符)

- 历史上的终端——电子打字机VT100
	- 同时作为输入和输出设备，打字到上面，从上面看见
- 今天的伪终端
	- 通过一个pipe实现双向通信
		- 主设备 PTY Master
			- 连接到终端模拟器（就是现在的终端）
		- 从设备 PTY Slave
			- 连接到shell应用（zsh、fish、bash）或者其他程序（vim）

> [!NOTE] 终端模拟器 & Shell应用
> 两者的关系类似硬件和软件，终端模拟器负责键盘输入和屏幕显示。而Shell应用负责指令处理。
> 在对终端输入指令的时候，终端会把收到的信息传到Shell中，Shell处理后的信息会发送到终端上（也就是Pipe在此处的作用，对接两者的FD stdin和stdout）

- 终端与应用的**配对**
	终端与应用并不是天然固定连接的（比如终端就是Bash这样），而是负责一个屏幕和键盘的IO功能（输入/输出），也就是可以像一个屏幕连个键盘一样，在上面打开各种应用程序（Bash，Vim），并进行输入
	- 配对原理：[[用户登录的起点涉及系统启动和远程登录的底层机制，主要通过进程间通信和终端管理实现。以下是详细解释]]

- 常用的伪终端
	- shh，tmux.......
	- 创建 openpty()
		- 通过/dev/ptmx 申请一个新终端
				- 返回两个FD%% 文件描述符 %%（master/slave）
# 启动
- 用户登录的起点
	- 系统启动
		- frame加载内核，创建第一个进程，调用init程序agetty，并且调用login接口执行登录程序
	- 远程登录
		- sshd收到请求，fork一个子进程，打开一个新的终端，修改stdin/stdout/stderror的FD指向新的终端
	- VSCode终端
## Session和Process Group——如何优雅地终止当前进程
在我们对当前终端上的前台应用使用Ctrl + C强制关闭时，我们需要关闭**前台应用的所有进程**，但是又不能影响后台的进程。也就是说，我们需要一个区分应用进程的方法——==**Session和Process Group**==
- Session ID，大分组
	- 子进程会继承父进程的 Session ID
    - 一个 Session 关联一个控制终端 (controlling terminal)
    - Leader 退出时，全体进程收到 Hang Up (SIGHUP)
- Process Group，小分组
	- 只能有一个前台进程组
	- 操作系统收到 Ctrl-C，向前台进程组**所有进程**发送 SIGINT
# Unix Shell
![[Pasted image 20250401093521.png]]
- [ ] man sh
- [ ] wget -r -np -nH --cut-dirs=2 -R "index.html*" "https://jyywiki.cn/os-demos/virtualization/sh/"

# Libc——C语言标准库和实现
“非必要不实现”（“机制与策略分离”、最小完备性原则）
**第一级抽象**
- 包装
	- OS->syscall->libc->sh/cat/gcc/python3

# 动态内存管理
- malloc基于系统API mmap()
	- mmap一次只能分配一大段内存，对于小内存分配， 只能由程序自己通过实现一个数据结构来实现
---
# 可执行文件


## ELF 
对于**ELF**，本质上是**可执行文件**的一个==**数据载体**==，通过在系统内核中的**加载器执行**
>[!quote] 
>ELF 是 Executable and Linkable Format 的缩写，是 Linux 系统上的一种可执行文件格式。

- ELF文件中主要包含的**信息**
	- 基本信息（版本、体系结构）
	- 内存布局
	- 其他（调试信息、符号表）
- ELF内容的**数据结构**
	- 由二进制字符构成
	- 主要通过offset来组成数据结构，机器友好，人类不友好(人类更适合平坦的信息)

- **Core Dump（核心转储）**
	- 程序崩溃时，操作系统自动生成的一个文件，记录了程序崩溃瞬间的内存状态、寄存器信息、调用栈等关键数据。它类似于程序崩溃时的“内存快照”，帮助开发者定位和调试问题。
	- 通过Core Dump，可以在gdb中复现程序奔溃



# 静态链接和加载

学前读物，宝宝读了都说好（迫真）结合CSAPP的内容——[[静态链接与加载]]

> [!tip] #### More than “可执行文件”
> - E = Excutable
> - L = **Linkable** ->
> - F = File

- 链接到加载的三要素
	- 代码
	- 符号
	- **重定位**

- 需要的工具
	- objdump/readfle/nm (显示)
	- cc/as (编译)
	- ld (链接)
## 操作系统和加载器 

>[!tip] 小彩蛋
> UNIX系统中通过注释`#!`加载和执行脚本语言

---
# 动态链接和加载
- #### 对比动态链接与静态链接

| **对比维度**   | **静态链接**                             | **动态链接**                                       |
| ---------- | ------------------------------------ | ---------------------------------------------- |
| **链接时间**   | 编译时完成（编译阶段一次性链接所有依赖库）                | 运行时完成（程序启动时或函数调用时动态加载库）                        |
| **文件大小**   | 可执行文件较大（包含所有库代码）                     | 可执行文件较小（仅包含库引用，依赖外部库）                          |
| **内存占用**   | 高（每个进程独立加载库代码，无法共享）                  | 低（多个进程共享同一份库代码，仅数据段独立）                         |
| **启动时间**   | 快（无需运行时解析和加载库）                       | 较慢（需加载和解析库，但可通过延迟绑定优化）                         |
| **符号解析**   | 编译时完成符号解析和重定位                        | 运行时动态解析符号（如Linux的PLT/GOT机制，Windows的延迟绑定）       |
| **依赖管理**   | 无外部依赖（自包含，无需额外库文件）                   | 依赖外部库文件（需确保库版本兼容性和存在性）                         |
| **程序更新维护** | 需重新编译整个程序才能更新库代码（维护成本高）              | 可独立更新库文件，无需重新编译程序（维护灵活，但需处理版本兼容性）              |
| **安全性**    | 更安全（无外部依赖，避免库劫持风险）                   | 存在风险（如DLL劫持、路径劫持、版本冲突等）                        |
| **适用场景**   | 嵌入式系统、资源受限环境、需要独立部署的程序（如关键基础设施、恢复工具） | 通用应用程序、服务器环境、需要频繁更新的程序（如Web服务、容器化应用）           |
| **代码共享性**  | 代码不共享（每个程序独立携带库代码）                   | 代码共享（所有进程共享库代码段，节省内存）                          |
| **版本兼容性**  | 无版本冲突（库代码固定在可执行文件中）                  | 可能引发版本冲突（需依赖系统库的兼容性管理，如Windows的Side-by-Side机制） |
| **性能优化**   | 无运行时开销（符号解析已完成）                      | 存在轻微运行时开销（动态加载和解析，但可通过缓存优化）                    |

- **拆解应用程序——应用之间的库共享**
	- 可以实现运行库与应用分开独立升级
- **大型项目的拆解**
	- 改一部分代码不用重新链接2GB的文件
- "Dependence Hell"

## 实现动态链接
[[动态链接]]
 - [ ] 读jyy的ld代码  
- 共享库的加载
	- **动态链接器**
		- 所有动态链接库，都由lib64/ld-linux-x86-64.so.2这个**程序**加载
  >[!tip] 
	>-  一个动态链接的程序，不能直接从他的a.out开始执行，因为如果从a.out开始执行就需要执行库函数了
	>- a.out执行的时候，libc还没有加载

	- libc 是用 mmap 系统调用加载的
	- `libc`的加载步骤
		1. **内存映射 (mmap)**
			- **多进程共享 `libc` 的机制**
		2. 符号解析
		3. 重定位
>[!important] **多进程共享 `libc` 的机制**
>在`libc`加载到内存后，多线程共享使用`libc`的两种数据，**只读数据**和**可读写数据**
> - 只读数据 -> 只读共享
> - 可读写数据 -> 写时复制（Copy-On-Write）
> 两者原理详见[[虚拟化#操作系统的Tricks]]

### 操作系统的Tricks
- Virtual Memory，动态链接中的内存分配
	- #### 延迟加载
		- 先通过**页表**逻辑上虚拟分配进程内存空间，但是物理上的内存分配，需要在使用时才实际分配到手
		- **按需加载策略**：程序在启动或运行时，**仅加载必要的数据到物理内存**，其他数据在真正需要时才动态加载
		  ~~先画大饼，需要吃的时候再分~~
		- **“用时再取，不用不取”**，避免一次性加载所有数据，减少内存占用和启动时间
		- 实现步骤
			1. 初始加载**绝对必要**的代码和数据到**物理内存**
			2. 访问未加载的页面，触发**缺页中断（Page Fault）**
			3. **缺页中断**处理，加载物理内存
	- #### 写时复制 Copy-on-Write
		1. **父进程与子进程的虚拟地址空间共享**
			- 当父进程fork()时，系统为子进程分配新的页表（虚拟内存）
			- 父子进程共享物理内存，但**子进程页表**中页面的权限被设置为只读
		2. **触发写操作时的复制**
			- **写保护异常（Write Protection Fault）**，当父进程或子进程尝试修改共享页面时，CPU 检测到页面是只读的，触发**缺页异常（Page Fault）**
			- **复制物理页面**

>[!example] 
>- 对于一个100GB的==**可读写**数组==，在fork时，子进程很难快速复制一个
>- 因此，对于这个==可读写的数组==，子进程中对应的fd，会指向父进程的==这个数组==，但只设置为**只读**
>- 当子进程中需要对==这个数组==进行写时，这个数组才会在子进程的空间中被==拷贝==一份
>- 而在拷贝后，这个进程之后的==这个数组==读写操作，都在这个==新的拷贝==上进行

>[!hint] **共享内存回收**
>- **页表项**中有一个**标志位**，存储着一些页表信息
>	- **只读位（Read-Only）**：标记页面是否可写。
>	- **COW 标志位**：标识该页面是否参与 COW 机制（部分系统实现）。
>	- **引用计数（Reference Count）**：记录共享页面的引用次数，用于释放物理页。
>对于上文中fork()时，父子进程共同指向的物理内存
>当这个块内存没有被任何进程使用时才会释放，而不是在父进程关闭后释放
>#### **引用计数机制**：
>- **初始共享**：父进程和子进程的共享页引用计数设为 2。
> - **写操作触发复制后**：新页的引用计数为 1，原页的计数减 1（变为 1）。
>- **释放物理页**：当引用计数为 0 时，回收物理页。

- #### Memory Deduplication 数据去重 —— 压缩&交换
	- 反正都是虚拟内存了，悄悄扫描内存
		- 如果有重复的 read-only pages，合并
		- 发现 cold pages，可以压缩/swap 到硬盘
	啊我草，操作系统咋这么坏啊，偷我的拼好存

# 构建应用生态
- Linux内核initramfs
	- 基本的命令工具，系统内核

	- 先启动内核初始化到初始状态
	- 创建设备文件
	- 加载磁盘
- ### 操作系统 = 对象的集合
	- 本质上除了系统开机初始化后，一切都是其他程序执行

虚拟化

# 什么是操作系统
**==管理资源，提供服务==**

对什么东西做抽象，然后提供服务？（后端接口，对整个后端服务器程序做抽象，抽象成为几个对前端开放的接口地址，为前端提供服务）

计算机操作系统，狭义上的操作系统——管理硬件资源，为软件运行提供服务
# 应用视角的操作系统
计算机是==状态机==，**程序的执行就是状态的变化**

**系统调用**
程序 = 状态机
操作系统 = 状态机的管理者
# 硬件视角的操作系统
- **计算机中的抽象**
	下层不需要知道上层怎么用，只需要向上层提供服务
- 状态机
	- 状态
	- **初始状态**
	- 状态迁移
- 计算机系统
	对于硬件来说，操作系统就是一个普通的（二进制）程序
	- 执行指令
		- 并发
	- **响应中断**
	- 输入输出
# 数学视角的操作系统
- [ ] 用严格的数学语言描述程序——离散数学
**程序都是严格的数学对象**
证明一个程序的正确性？？？
- 暴力枚举
- 写出证明（逻辑公式）

用逻辑语言编写程序
- 命题就是类型
- 证明就是程序
![[Pasted image 20250314202938.png]]
- UNIX基本模型
	- 进程
	- 系统调用
	- 上下文切换
	-  调度 