# 前言
本文主要是个人在学习中，对 JVM 结构组织的梳理。通过梳理各个部分的由来，逐步描绘出 JVM 整体的框架，并串联相关的知识点，让对 JVM 的理解整体更加有条理、丰满。



# 跨平台特性，JVM 运行时数据区的由来
Java 作为一个具有跨平台特性的语言，JVM 运行时数据区自然就要处理不同平台间程序的内存结构的不同问题。

### 不同OS中程序的内存结构
JVM 运行时数据区就是 Java 程序的内存结构，而当我们讨论其对 OS 原生程序的内存抽象封装，对 Java 程序管理和操作内存提供统一的接口，OS 原生程序的内存结构是怎么样的自然是绕不开的话题。

Java 程序是通过编译为 `.class` 字节码文件在 JVM 中执行，而在我们的原生计算机系统中，这个过程就是 C 语言被编译为机器码（0101的那个机器码，汇编语言只是类似机器码另一只符号表达方式）然后在 CPU 中执行指令。所以 C 语言程序的内存结构自然就是 OS 原生程序内存结构展现了。

对于不同 OS 我们用下面两个表格来对比展现差异：

- **基本结构相似，但实现细节不同**
C 程序的内存布局在概念上是通用的，通常包括以下几个区域：
![file-20250820115901059.png](https://www.blog.aeside.top/static/img/7cc650cb7a5794f0f890a24270081f3c.file-20250820115901059.webp)

| 区域        | 作用               |
| --------- | ---------------- |
| 代码段（Text） | 存放机器指令           |
| 数据段（Data） | 存放已初始化的全局/静态变量   |
| BSS 段     | 存放未初始化的全局/静态变量   |
| 堆（Heap）   | 动态分配内存（`malloc`） |
| 栈（Stack）  | 函数调用、局部变量        |

这个结构在 **Windows、Linux、macOS 等系统中基本一致**，因为它们都遵循冯·诺伊曼模型。

-  **底层实现存在差异**
尽管结构相似，但在具体实现上存在关键差异：

| 差异点          | Linux                               | Windows                 |
| ------------ | ----------------------------------- | ----------------------- |
| **内存分配系统调用** | `brk()` / `sbrk()` / `mmap()`       | `VirtualAlloc()`        |
| **可执行文件格式**  | ELF（Executable and Linkable Format） | PE（Portable Executable） |
| **栈的默认大小**   | 通常 8MB                              | 通常 1MB                  |
| **地址空间布局**   | ASLR（地址空间布局随机化）实现方式不同               |                         |
| **共享库机制**    | `.so` 文件                            | `.dll` 文件               |

### JVM 实现跨平台特性
从刚才的表格中，我们可以知道**C 程序的内存“逻辑结构”相似，但“物理实现”依赖操作系统**。而这也正是 JVM 的一个重要使命——**“Write Once, Run Anywhere”***~~（一次编写，到处报错）~~*

为了实现这个使命，JVM 就对操作系统**内存**进行抽象，为提供开发者提供统一的内存接口调用（准确来说是统一的内存组织方式，Java中默认不允许直接操作内存）， 也就是 JVM 运行时数据区。

而 JVM 运行时数据区作为对原生计算机程序内存结构的抽象，自然其内存区域划分也是类似的，**堆、栈和静态代码段（方法区）**。

> 有趣的是，我们原生计算机程序的内存结构来源于 **“操作系统 + 可执行文件格式 + 编译器/链接器”** 共同决定。JVM 本质上是一个用C/C++编写的程序，所以 JVM 内部也是遵循原生计算机程序的内存结构，`.text`段存放其实现代码，堆、栈中存储变量实现虚拟机功能

## JVM 运行时数据区结构
在有了前面那么多的铺垫后，JVM 运行时数据区终于是千呼万唤始出来了。作为 Java 程序的内存结构，并不完全与计算机原生程序相同，但是在堆、栈和静态代码段这三个概念上是相似的。这里我们就从这三个概念上，对 JVM 运行时数据区域结构进行梳理
![[assets/JVM/file-20250721162725868.png]]
### 栈
栈内存的由来是计算机运行程序过程中经常进入一个函数后，然后返回一个结果跳回原来的函数中，这样层层嵌套的访问特点自然地出现了栈内存，同时也是数据结构中栈的由来

#### 虚拟机栈
在 Java 中栈内存是通过**虚拟机栈**来实现的，虚拟机栈里面的每个数据叫做**栈帧**，而一个栈帧由多个部分组成，内容和功能如下：
- 局部变量表
	- **局部变量表**主要存放了编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。
- 操作数栈
	- **操作数栈**主要作为方法调用的中转站使用，用于存放方法执行过程中产生的中间计算结果。另外，计算过程中产生的临时变量也会放在操作数栈中。
- 动态链接
	- **动态链接**主要服务一个方法需要调用其他方法的场景。Class 文件的常量池里保存有大量的符号引用比如方法引用的符号引用。当一个方法要调用其他方法，需要将常量池中指向方法的符号引用转化为其在内存地址中的直接引用。动态链接的作用就是为了将符号引用转换为调用方法的直接引用，这个过程也被称为 **动态链接** 
- 方法返回地址
	- **方法返回地址**存储了当当前方法执行完毕后，需要返回到**调用者方法**的哪个位置继续执行的指令地址

![file-20250820172902514.png](https://www.blog.aeside.top/static/img/4f220266058fb1db419f625bbfe9d511.file-20250820172902514.webp)

> 栈空间虽然不是无限的，但一般正常调用的情况下是不会出现问题的。不过，如果函数调用陷入无限循环的话，就会导致栈中被压入太多栈帧而占用太多空间，导致栈空间过深。那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度的时候，就抛出 `StackOverFlowError` 错误。
> 
> Java 方法有两种返回方式，一种是 return 语句正常返回，一种是抛出异常。不管哪种返回方式，都会导致栈帧被弹出。也就是说， **栈帧随着方法调用而创建，随着方法结束而销毁。无论方法正常完成还是异常完成都算作方法结束。**
> 
> 除了 `StackOverFlowError` 错误之外，栈还可能会出现`OutOfMemoryError`错误，这是因为如果栈的内存大小可以动态扩展， 那么当虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出`OutOfMemoryError`异常。

#### 本地方法栈
和虚拟机栈所发挥的作用非常相似，区别是：**虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。** 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。

本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。

方法执行完毕后相应的栈帧也会出栈并释放内存空间，也会出现 `StackOverFlowError` 和 `OutOfMemoryError` 两种错误。

#### PC 程序计数器
PC 程序计数器是 JVM 实现其**多线程执行模型**和**字节码指令流控制**所必需的基础设施。它让 JVM 能够知道“这个线程现在执行到哪了”，从而实现线程的暂停、恢复和正确执行。

⚠️ 注意：程序计数器是唯一一个不会出现 `OutOfMemoryError` 的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。
### 堆
在计算机程序的内存中，除了具有栈特点的函数进出所出现的栈内存数据，在程序中还经常会出现**生命周期不确定、大小动态变化**的数据，这部分数据较为复杂需要人为操控，我们就将这部分内存分配模式叫做**堆（Heap）内存**。

堆内存的分配方式并不是类似数据结构中的最大/小堆一样，它名字的由来是英文中的Heap，具有无序混乱的意思。堆内存中的内存块大小不一致比较混乱，因此得名**堆内存**。

堆内存个人认为也是 JVM 内存中的核心，因为 Java 中采用了完全的面向对象设计——**一切皆对象**。因此几乎所有的类都是继承于`Object`类，也就是说我们绝大多数使用的变量都是一种引用对象，操作时大多数都是操作其指向的内存地址，作为一个指针使用，而不同于`int`等类型存储于栈中。

#### 字符串常量池
**字符串常量池** 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。

HotSpot 虚拟机中字符串常量池的实现是`StringTable`可以简单理解为一个固定大小的`HashTable` ，容量为 `StringTableSize`（可以通过 `-XX:StringTableSize` 参数来设置），保存的是字符串（key）和 字符串对象的引用（value）的映射关系，字符串对象的引用指向堆中的字符串对象。

> JDK1.7 之前，字符串常量池存放在方法区。JDK1.7 字符串常量池和静态变量从方法区移动到了 Java 堆中。主要是因为方法区GC回收效率太低，字符串增多容易导致OOM

#### GC
堆内存作为 JVM 运行时内存区的主要部分，承担了 Java 对象的管理责任。自然而然，GC 便是不可避免的话题。对于这部分内容篇幅较大，就不在这里进行过多的探讨了，主要讨论根据 GC 所对对内存空间的划分说一下。

##### 堆空间划分
Java 虚拟机所管理的内存中最大的一块，Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。**此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。**

Java 世界中“几乎”所有的对象都在堆中分配，但是，随着 JIT 编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。从 JDK 1.7 开始已经默认开启逃逸分析，如果某些方法中的对象引用没有被返回或者未被外面使用（也就是未逃逸出去），那么对象可以直接在栈上分配内存。

Java 堆是垃圾收集器管理的主要区域，因此也被称作 **GC 堆（Garbage Collected Heap）**。从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代；再细致一点有：Eden、Survivor、Old 等空间。进一步划分的目的是更好地回收内存，或者更快地分配内存。

![file-20250821181643417.png](https://www.blog.aeside.top/static/img/ec07f2627bef02a08887e823f7e067a4.file-20250821181643417.webp)

关于这部分推荐的阅读资料：

[JavaGuide_Java内存区域详解（重点）](https://javaguide.cn/java/jvm/memory-area.html)

[深入理解 JVM 的垃圾回收机制](https://javabetter.cn/jvm/gc.html)
- ##### 回收对象判断
- ##### 垃圾回收算法

### 方法区
#### 原生程序中的代码段 & 数据段
方法去我们可以借助原生计算机程序中**静态数据的代码段和数据段**来理解。在原生计算机程序中，我们运行的程序代码是先要被从磁盘中读取到内存中，然后 CPU 再用程序计数器从对应的**内存地址**中读取要指向的机器指令后，交由给 CPU 执行。

**数据段**

#### 动态的代码，方法区与类加载

JVM运行时数据区知识梳理串联

首先，HashMap的主要结构是由 Node 数组（哈希桶）+ 链表/红黑树（哈希冲突）所实现的

这里我们通过对 HashMap 的`put`方法来缕清 HashMap 的主要结构。HashMap的put方法主要逻辑可以分成三个大部分：
- 初始化检测
- Key-Value 节点插入
	- 索引计算
	- 哈希冲突处理
	- 链表 / 红黑树转换
	- 相同Key-Value更新
- 扩容检测



首先是边界检测部分，HashMap 在进行插入节点之前要通过比对Node数组`length == 0`和`isNull`情况来判断是否需要初始化，如果需要初始化就调用resize()函数进行初始化容量

检测完毕后就进入插入环节，计算插入对象的哈希索引，通过对象的hashCode()方法计算出hashCode（大部分类继承用Object类的hashCode方法用对象地址计算，String是用字符串内容计算，数字类有不同的实现）

然后将 hashCode 二进制展开，将其右移16位与再与本身进行与运算，从而将高16的信息融入到低16位中

最后再用HashMap的容量 - 1与前面异或运算结果进行与运算。这是因为HashMap的容量是2的幂次方，将其减去一进行二进制展开就可以得到幂次方减去一位的全1二进制数，这样进行与运算我们就相当于每一次扩容就多读取一位与运算结果的信息，并且我们可以根据新增读取的位是1或0来决定是否要迁移对应位置的数据。

但是通过按哈希表大小来读取hashcode信息这样会容易遗漏高16位的信息，而前面`(h = key.hashCode()) ^ (h >>> 16)`操作能尽量让高16位的信息也被读取，从而让哈希函数更均匀分布

然后在上面一系列的操作后，我们找到对应的Node数组位置，进行节点插入，如果当前槽位是空就new Node放入对应Key-Value

如果哈希冲突就通过拉链法用尾插法插入新节点，1.8之前用的是头插法，多线程环境下HashMap多个线程扩容可能会导致链表成环。而且尾插法能保证扩容前后元素位置一致，且尾插法的顺序更符合红黑树结构。

当链表长度大于8时，且HashMap容量大于64时，链表就会被转换为红黑树，而红黑线小于6时就回转换回链表。这是由于链表只需要一个指针指向下一个节点就好了，而红黑树是一种二叉搜索树，相同的数据需要两个指针指向左右子树，占用更大的内存

如果插入发现是相同的Key则回替换原有的Value，其他不变

最后`put`会进行HashMap的容量检测，如果数组的使用率大于装填因子0.75就会进行一次扩容操作。0.75是通过泊松分布用概率学计算出来的最佳装填因子大小，如果过小会导致数组使用率过低浪费内存，过大则会导致哈希冲突频繁

HashMap梳理

# 引言
我们要如何做到使用非自增主键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