，JavaGuide 对其做了补充完善。
+
+
## 引言
所谓排序，就是使一串记录，按照其中的某个或某些关键字的大小，递增或递减的排列起来的操作。排序算法，就是如何使得记录按照要求排列的方法。排序算法在很多领域得到相当地重视，尤其是在大量数据的处理方面。一个优秀的算法可以节省大量的资源。在各个领域中考虑到数据的各种限制和规范，要得到一个符合实际的优秀算法，得经过大量的推理和分析。
-两年前，我曾在[博客园](https://www.cnblogs.com/guoyaohua/)发布过一篇[《十大经典排序算法最强总结（含 JAVA 代码实现）》](https://www.cnblogs.com/guoyaohua/p/8600214.html)博文，简要介绍了比较经典的十大排序算法，不过在之前的博文中，仅给出了 Java 版本的代码实现，并且有一些细节上的错误。所以，今天重新写一篇文章，深入了解下十大经典排序算法的原理及实现。
-
## 简介
-排序算法可以分为：
-
-- **内部排序**：数据记录在内存中进行排序。
-- **[外部排序](https://zh.wikipedia.org/wiki/外排序)**：因排序的数据很大，一次不能容纳全部的排序记录，在排序过程中需要访问外存。
-
-常见的内部排序算法有：**插入排序**、**希尔排序**、**选择排序**、**冒泡排序**、**归并排序**、**快速排序**、**堆排序**、**基数排序**等，本文只讲解内部排序算法。用一张图概括：
-
-
-
-上图存在错误：
-
-1. 插入排序的最好时间复杂度为 $O(n)$ 而不是 $O(n^2)$。
-2. 希尔排序的平均时间复杂度为 $O(nlogn)$。
-
-**图片名词解释：**
-
-- **n**：数据规模
-- **k**：“桶” 的个数
-- **In-place**：占用常数内存，不占用额外内存
-- **Out-place**：占用额外内存
-
-### 术语说明
-
+### 排序算法总结
+
+常见的内部排序算法有：**插入排序**、**希尔排序**、**选择排序**、**冒泡排序**、**归并排序**、**快速排序**、**堆排序**、**基数排序**等，本文只讲解内部排序算法。用一张表格概括：
+
+| 排序算法 | 时间复杂度（平均） | 时间复杂度（最差） | 时间复杂度（最好） | 空间复杂度 | 排序方式 | 稳定性 |
+| -------- | ------------------ | ------------------ | ------------------ | ---------- | -------- | ------ |
+| 冒泡排序 | O(n^2) | O(n^2) | O(n) | O(1) | 内部排序 | 稳定 |
+| 选择排序 | O(n^2) | O(n^2) | O(n^2) | O(1) | 内部排序 | 不稳定 |
+| 插入排序 | O(n^2) | O(n^2) | O(n) | O(1) | 内部排序 | 稳定 |
+| 希尔排序 | O(nlogn) | O(n^2) | O(nlogn) | O(1) | 内部排序 | 不稳定 |
+| 归并排序 | O(nlogn) | O(nlogn) | O(nlogn) | O(n) | 外部排序 | 稳定 |
+| 快速排序 | O(nlogn) | O(n^2) | O(nlogn) | O(logn) | 内部排序 | 不稳定 |
+| 堆排序 | O(nlogn) | O(nlogn) | O(nlogn) | O(1) | 内部排序 | 不稳定 |
+| 计数排序 | O(n+k) | O(n+k) | O(n+k) | O(k) | 外部排序 | 稳定 |
+| 桶排序 | O(n+k) | O(n^2) | O(n+k) | O(n+k) | 外部排序 | 稳定 |
+| 基数排序 | O(n×k) | O(n×k) | O(n×k) | O(n+k) | 外部排序 | 稳定 |
+
+**术语解释**：
+
+- **n**：数据规模，表示待排序的数据量大小。
+- **k**：“桶” 的个数，在某些特定的排序算法中（如基数排序、桶排序等），表示分割成的独立的排序区间或类别的数量。
+- **内部排序**：所有排序操作都在内存中完成，不需要额外的磁盘或其他存储设备的辅助。这适用于数据量小到足以完全加载到内存中的情况。
+- **外部排序**：当数据量过大，不可能全部加载到内存中时使用。外部排序通常涉及到数据的分区处理，部分数据被暂时存储在外部磁盘等存储设备上。
- **稳定**：如果 A 原本在 B 前面，而 $A=B$，排序之后 A 仍然在 B 的前面。
- **不稳定**：如果 A 原本在 B 的前面，而 $A=B$，排序之后 A 可能会出现在 B 的后面。
-- **内排序**：所有排序操作都在内存中完成。
-- **外排序**：由于数据太大，因此把数据放在磁盘中，而排序通过磁盘和内存的数据传输才能进行。
- **时间复杂度**：定性描述一个算法执行所耗费的时间。
- **空间复杂度**：定性描述一个算法执行所需内存的大小。
-### 算法分类
+### 排序算法分类
十种常见排序算法可以分类两大类别：**比较类排序**和**非比较类排序**。
@@ -369,31 +367,60 @@ public static int[] merge(int[] arr_1, int[] arr_2) {
### 代码实现
-> 来源：[使用 Java 实现快速排序（详解）](https://segmentfault.com/a/1190000040022056)
-
```java
-public static int partition(int[] array, int low, int high) {
- int pivot = array[high];
- int pointer = low;
- for (int i = low; i < high; i++) {
- if (array[i] <= pivot) {
- int temp = array[i];
- array[i] = array[pointer];
- array[pointer] = temp;
- pointer++;
+import java.util.concurrent.ThreadLocalRandom;
+
+class Solution {
+ public int[] sortArray(int[] a) {
+ quick(a, 0, a.length - 1);
+ return a;
+ }
+
+ // 快速排序的核心递归函数
+ void quick(int[] a, int left, int right) {
+ if (left >= right) { // 递归终止条件：区间只有一个或没有元素
+ return;
}
- System.out.println(Arrays.toString(array));
+ int p = partition(a, left, right); // 分区操作，返回分区点索引
+ quick(a, left, p - 1); // 对左侧子数组递归排序
+ quick(a, p + 1, right); // 对右侧子数组递归排序
}
- int temp = array[pointer];
- array[pointer] = array[high];
- array[high] = temp;
- return pointer;
-}
-public static void quickSort(int[] array, int low, int high) {
- if (low < high) {
- int position = partition(array, low, high);
- quickSort(array, low, position - 1);
- quickSort(array, position + 1, high);
+
+ // 分区函数：将数组分为两部分，小于基准值的在左，大于基准值的在右
+ int partition(int[] a, int left, int right) {
+ // 随机选择一个基准点，避免最坏情况（如数组接近有序）
+ int idx = ThreadLocalRandom.current().nextInt(right - left + 1) + left;
+ swap(a, left, idx); // 将基准点放在数组的最左端
+ int pv = a[left]; // 基准值
+ int i = left + 1; // 左指针，指向当前需要检查的元素
+ int j = right; // 右指针，从右往左寻找比基准值小的元素
+
+ while (i <= j) {
+ // 左指针向右移动，直到找到一个大于等于基准值的元素
+ while (i <= j && a[i] < pv) {
+ i++;
+ }
+ // 右指针向左移动，直到找到一个小于等于基准值的元素
+ while (i <= j && a[j] > pv) {
+ j--;
+ }
+ // 如果左指针尚未越过右指针，交换两个不符合位置的元素
+ if (i <= j) {
+ swap(a, i, j);
+ i++;
+ j--;
+ }
+ }
+ // 将基准值放到分区点位置，使得基准值左侧小于它，右侧大于它
+ swap(a, j, left);
+ return j;
+ }
+
+ // 交换数组中两个元素的位置
+ void swap(int[] a, int i, int j) {
+ int t = a[i];
+ a[i] = a[j];
+ a[j] = t;
}
}
```
@@ -401,7 +428,7 @@ public static void quickSort(int[] array, int low, int high) {
### 算法分析
- **稳定性**：不稳定
-- **时间复杂度**：最佳：$O(nlogn)$， 最差：$O(nlogn)$，平均：$O(nlogn)$
+- **时间复杂度**：最佳：$O(nlogn)$， 最差：$O(n^2)$，平均：$O(nlogn)$
- **空间复杂度**：$O(logn)$
## 堆排序 (Heap Sort)
@@ -565,13 +592,13 @@ public static int[] countingSort(int[] arr) {
}
```
-## 算法分析
+### 算法分析
当输入的元素是 `n` 个 `0` 到 `k` 之间的整数时，它的运行时间是 $O(n+k)$。计数排序不是比较排序，排序的速度快于任何比较排序算法。由于用来计数的数组 `C` 的长度取决于待排序数组中数据的范围（等于待排序数组的**最大值与最小值的差加上 1**），这使得计数排序对于数据范围很大的数组，需要大量额外内存空间。
- **稳定性**：稳定
- **时间复杂度**：最佳：$O(n+k)$ 最差：$O(n+k)$ 平均：$O(n+k)$
-- **空间复杂度**：`O(k)`
+- **空间复杂度**：$O(k)$
## 桶排序 (Bucket Sort)
diff --git a/docs/cs-basics/algorithms/linkedlist-algorithm-problems.md b/docs/cs-basics/algorithms/linkedlist-algorithm-problems.md
index b50b1b1b00f..1280445409e 100644
--- a/docs/cs-basics/algorithms/linkedlist-algorithm-problems.md
+++ b/docs/cs-basics/algorithms/linkedlist-algorithm-problems.md
@@ -5,6 +5,8 @@ tag:
- 算法
---
+
+
## 1. 两数相加
### 题目描述
diff --git a/docs/cs-basics/data-structure/bloom-filter.md b/docs/cs-basics/data-structure/bloom-filter.md
index 8d4130c6f04..be17c1a53aa 100644
--- a/docs/cs-basics/data-structure/bloom-filter.md
+++ b/docs/cs-basics/data-structure/bloom-filter.md
@@ -148,7 +148,7 @@ public class MyBloomFilter {
*/
public int hash(Object value) {
int h;
- return (value == null) ? 0 : Math.abs(seed * (cap - 1) & ((h = value.hashCode()) ^ (h >>> 16)));
+ return (value == null) ? 0 : Math.abs((cap - 1) & seed * ((h = value.hashCode()) ^ (h >>> 16)));
}
}
diff --git a/docs/cs-basics/data-structure/linear-data-structure.md b/docs/cs-basics/data-structure/linear-data-structure.md
index cc5cc6a5db2..e8ae63a19d5 100644
--- a/docs/cs-basics/data-structure/linear-data-structure.md
+++ b/docs/cs-basics/data-structure/linear-data-structure.md
@@ -326,9 +326,9 @@ myStack.pop();//报错：java.lang.IllegalArgumentException: Stack is empty.
当我们需要按照一定顺序来处理数据的时候可以考虑使用队列这个数据结构。
- **阻塞队列：** 阻塞队列可以看成在队列基础上加了阻塞操作的队列。当队列为空的时候，出队操作阻塞，当队列满的时候，入队操作阻塞。使用阻塞队列我们可以很容易实现“生产者 - 消费者“模型。
-- **线程池中的请求/任务队列：** 线程池中没有空闲线程时，新的任务请求线程资源时，线程池该如何处理呢？答案是将这些请求放在队列中，当有空闲线程的时候，会循环中反复从队列中获取任务来执行。队列分为无界队列(基于链表)和有界队列(基于数组)。无界队列的特点就是可以一直入列，除非系统资源耗尽，比如：`FixedThreadPool` 使用无界队列 `LinkedBlockingQueue`。但是有界队列就不一样了，当队列满的话后面再有任务/请求就会拒绝，在 Java 中的体现就是会抛出`java.util.concurrent.RejectedExecutionException` 异常。
-- 栈：双端队列天生便可以实现栈的全部功能（`push`、`pop` 和 `peek`），并且在 Deque 接口中已经实现了相关方法。Stack 类已经和 Vector 一样被遗弃，现在在 Java 中普遍使用双端队列（Deque）来实现栈。
-- 广度优先搜索（BFS），在图的广度优先搜索过程中，队列被用于存储待访问的节点，保证按照层次顺序遍历图的节点。
+- **线程池中的请求/任务队列：** 当线程池中没有空闲线程时，新的任务请求线程资源会被如何处理呢？答案是这些任务会被放入任务队列中，等待线程池中的线程空闲后再从队列中取出任务执行。任务队列分为无界队列（基于链表实现）和有界队列（基于数组实现）。无界队列的特点是队列容量理论上没有限制，任务可以持续入队，直到系统资源耗尽。例如：`FixedThreadPool` 使用的阻塞队列 `LinkedBlockingQueue`，其默认容量为 `Integer.MAX_VALUE`，因此可以被视为“无界队列”。而有界队列则不同，当队列已满时，如果再有新任务提交，由于队列无法继续容纳任务，线程池会拒绝这些任务，并抛出 `java.util.concurrent.RejectedExecutionException` 异常。
+- **栈**：双端队列天生便可以实现栈的全部功能（`push`、`pop` 和 `peek`），并且在 Deque 接口中已经实现了相关方法。Stack 类已经和 Vector 一样被遗弃，现在在 Java 中普遍使用双端队列（Deque）来实现栈。
+- **广度优先搜索（BFS）**：在图的广度优先搜索过程中，队列被用于存储待访问的节点，保证按照层次顺序遍历图的节点。
- Linux 内核进程队列（按优先级排队）
- 现实生活中的派对，播放器上的播放列表;
- 消息队列
diff --git a/docs/cs-basics/data-structure/red-black-tree.md b/docs/cs-basics/data-structure/red-black-tree.md
index c7040eb6ebc..462010e910e 100644
--- a/docs/cs-basics/data-structure/red-black-tree.md
+++ b/docs/cs-basics/data-structure/red-black-tree.md
@@ -26,7 +26,7 @@ tag:
1. 每个节点非红即黑。黑色决定平衡，红色不决定平衡。这对应了 2-3 树中一个节点内可以存放 1~2 个节点。
2. 根节点总是黑色的。
3. 每个叶子节点都是黑色的空节点（NIL 节点）。这里指的是红黑树都会有一个空的叶子节点，是红黑树自己的规则。
-4. 如果节点是红色的，则它的子节点必须是黑色的（反之不一定）。通常这条规则也叫不会有连续的红色节点。一个节点最多临时会有 3 个节点，中间是黑色节点，左右是红色节点。
+4. 如果节点是红色的，则它的子节点必须是黑色的（反之不一定）。通常这条规则也叫不会有连续的红色节点。一个节点最多临时会有 3 个子节点，中间是黑色节点，左右是红色节点。
5. 从任意节点到它的叶子节点或空子节点的每条路径，必须包含相同数目的黑色节点（即相同的黑色高度）。每一层都只是有一个节点贡献了树高决定平衡性，也就是对应红黑树中的黑色节点。
正是这些特点才保证了红黑树的平衡，让红黑树的高度不会超过 2log(n+1)。
diff --git a/docs/cs-basics/data-structure/tree.md b/docs/cs-basics/data-structure/tree.md
index 9727359c114..de9c6eb6a27 100644
--- a/docs/cs-basics/data-structure/tree.md
+++ b/docs/cs-basics/data-structure/tree.md
@@ -50,7 +50,7 @@ tag:
### 完全二叉树
-除最后一层外，若其余层都是满的，并且最后一层或者是满的，或者是在右边缺少连续若干节点，则这个二叉树就是 **完全二叉树** 。
+除最后一层外，若其余层都是满的，并且最后一层是满的或者是在右边缺少连续若干节点，则这个二叉树就是 **完全二叉树** 。
大家可以想象为一棵树从根结点开始扩展，扩展完左子节点才能开始扩展右子节点，每扩展完一层，才能继续扩展下一层。如下图所示：
diff --git a/docs/cs-basics/network/application-layer-protocol.md b/docs/cs-basics/network/application-layer-protocol.md
index d34e98bcdab..cb809b9157d 100644
--- a/docs/cs-basics/network/application-layer-protocol.md
+++ b/docs/cs-basics/network/application-layer-protocol.md
@@ -15,7 +15,7 @@ HTTP 使用客户端-服务器模型，客户端向服务器发送 HTTP Request
HTTP 协议基于 TCP 协议，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-Alive 的，这样的话建立的连接就可以在多次请求中被复用了。
-另外， HTTP 协议是”无状态”的协议，它无法记录客户端用户的状态，一般我们都是通过 Session 来记录客户端用户的状态。
+另外， HTTP 协议是“无状态”的协议，它无法记录客户端用户的状态，一般我们都是通过 Session 来记录客户端用户的状态。
## Websocket：全双工通信协议
@@ -102,7 +102,7 @@ FTP 是基于客户—服务器（C/S）模型而设计的，在客户端与 FTP
-注意 ⚠️：FTP 是一种不安全的协议，因为它在传输过程中不会对数据进行加密。因此，FTP 传输的文件可能会被窃听或篡改。建议在传输敏感数据时使用更安全的协议，如 SFTP（一种基于 SSH 协议的安全文件传输协议，用于在网络上安全地传输文件）。
+注意 ⚠️：FTP 是一种不安全的协议，因为它在传输过程中不会对数据进行加密。因此，FTP 传输的文件可能会被窃听或篡改。建议在传输敏感数据时使用更安全的协议，如 SFTP（SSH File Transfer Protocol，一种基于 SSH 协议的安全文件传输协议，用于在网络上安全地传输文件）。
## Telnet:远程登陆协议
@@ -114,10 +114,12 @@ FTP 是基于客户—服务器（C/S）模型而设计的，在客户端与 FTP
**SSH（Secure Shell）** 基于 TCP 协议，通过加密和认证机制实现安全的访问和文件传输等业务。
-SSH 的经典用途是登录到远程电脑中执行命令。除此之外，SSH 也支持隧道协议、端口映射和 X11 连接。借助 SFTP 或 SCP 协议，SSH 还可以传输文件。
+SSH 的经典用途是登录到远程电脑中执行命令。除此之外，SSH 也支持隧道协议、端口映射和 X11 连接（允许用户在本地运行远程服务器上的图形应用程序）。借助 SFTP（SSH File Transfer Protocol） 或 SCP（Secure Copy Protocol） 协议，SSH 还可以安全传输文件。
SSH 使用客户端-服务器模型，默认端口是 22。SSH 是一个守护进程，负责实时监听客户端请求，并进行处理。大多数现代操作系统都提供了 SSH。
+如下图所示，SSH Client（SSH 客户端）和 SSH Server（SSH 服务器）通过公钥交换生成共享的对称加密密钥，用于后续的加密通信。
+
## RTP:实时传输协议
diff --git a/docs/cs-basics/network/computer-network-xiexiren-summary.md b/docs/cs-basics/network/computer-network-xiexiren-summary.md
index ac7e5d18b97..fc9f60fd39a 100644
--- a/docs/cs-basics/network/computer-network-xiexiren-summary.md
+++ b/docs/cs-basics/network/computer-network-xiexiren-summary.md
@@ -20,36 +20,36 @@ tag:
3. **主机（host）**：连接在因特网上的计算机。
4. **ISP（Internet Service Provider）**：因特网服务提供者（提供商）。
-
+ 
5. **IXP（Internet eXchange Point）**：互联网交换点 IXP 的主要作用就是允许两个网络直接相连并交换分组，而不需要再通过第三个网络来转发分组。
-
+ 
-https://labs.ripe.net/Members/fergalc/ixp-traffic-during-stratos-skydive
+ https://labs.ripe.net/Members/fergalc/ixp-traffic-during-stratos-skydive
6. **RFC(Request For Comments)**：意思是“请求评议”，包含了关于 Internet 几乎所有的重要的文字资料。
7. **广域网 WAN（Wide Area Network）**：任务是通过长距离运送主机发送的数据。
8. **城域网 MAN（Metropolitan Area Network）**：用来将多个局域网进行互连。
9. **局域网 LAN（Local Area Network）**：学校或企业大多拥有多个互连的局域网。
-
+ 
-http://conexionesmanwman.blogspot.com/
+ http://conexionesmanwman.blogspot.com/
10. **个人区域网 PAN（Personal Area Network）**：在个人工作的地方把属于个人使用的电子设备用无线技术连接起来的网络 。
-
+ 
-https://www.itrelease.com/2018/07/advantages-and-disadvantages-of-personal-area-network-pan/
+ https://www.itrelease.com/2018/07/advantages-and-disadvantages-of-personal-area-network-pan/
-12. **分组（packet ）**：因特网中传送的数据单元。由首部 header 和数据段组成。分组又称为包，首部可称为包头。
-13. **存储转发（store and forward ）**：路由器收到一个分组，先检查分组是否正确，并过滤掉冲突包错误。确定包正确后，取出目的地址，通过查找表找到想要发送的输出端口地址，然后将该包发送出去。
+11. **分组（packet ）**：因特网中传送的数据单元。由首部 header 和数据段组成。分组又称为包，首部可称为包头。
+12. **存储转发（store and forward ）**：路由器收到一个分组，先检查分组是否正确，并过滤掉冲突包错误。确定包正确后，取出目的地址，通过查找表找到想要发送的输出端口地址，然后将该包发送出去。
-
+ 
-14. **带宽（bandwidth）**：在计算机网络中，表示在单位时间内从网络中的某一点到另一点所能通过的“最高数据率”。常用来表示网络的通信线路所能传送数据的能力。单位是“比特每秒”，记为 b/s。
-15. **吞吐量（throughput ）**：表示在单位时间内通过某个网络（或信道、接口）的数据量。吞吐量更经常地用于对现实世界中的网络的一种测量，以便知道实际上到底有多少数据量能够通过网络。吞吐量受网络的带宽或网络的额定速率的限制。
+13. **带宽（bandwidth）**：在计算机网络中，表示在单位时间内从网络中的某一点到另一点所能通过的“最高数据率”。常用来表示网络的通信线路所能传送数据的能力。单位是“比特每秒”，记为 b/s。
+14. **吞吐量（throughput ）**：表示在单位时间内通过某个网络（或信道、接口）的数据量。吞吐量更经常地用于对现实世界中的网络的一种测量，以便知道实际上到底有多少数据量能够通过网络。吞吐量受网络的带宽或网络的额定速率的限制。
### 1.2. 重要知识点总结
@@ -81,11 +81,11 @@ tag:
5. **半双工（half duplex ）**：通信的双方都可以发送信息，但不能双方同时发送(当然也就不能同时接收)。
6. **全双工（full duplex）**：通信的双方可以同时发送和接收信息。
-
+ 
7. **失真**：失去真实性，主要是指接受到的信号和发送的信号不同，有磨损和衰减。影响失真程度的因素：1.码元传输速率 2.信号传输距离 3.噪声干扰 4.传输媒体质量
-
+ 
8. **奈氏准则**：在任何信道中，码元的传输的效率是有上限的，传输速率超过此上限，就会出现严重的码间串扰问题，使接收端对码元的判决（即识别）成为不可能。
9. **香农定理**：在带宽受限且有噪声的信道中，为了不产生误差，信息的数据传输速率有上限值。
@@ -95,7 +95,7 @@ tag:
13. **信噪比（signal-to-noise ratio ）**：指信号的平均功率和噪声的平均功率之比，记为 S/N。信噪比（dB）=10\*log10（S/N）。
14. **信道复用（channel multiplexing ）**：指多个用户共享同一个信道。（并不一定是同时）。
-
+ 
15. **比特率（bit rate ）**：单位时间（每秒）内传送的比特数。
16. **波特率（baud rate）**：单位时间载波调制状态改变的次数。针对数据信号对载波的调制速率。
@@ -151,7 +151,7 @@ tag:
8. **MAC 地址（Media Access Control 或者 Medium Access Control）**：意译为媒体访问控制，或称为物理地址、硬件地址，用来定义网络设备的位置。在 OSI 模型中，第三层网络层负责 IP 地址，第二层数据链路层则负责 MAC 地址。因此一个主机会有一个 MAC 地址，而每个网络位置会有一个专属于它的 IP 地址 。地址是识别某个系统的重要标识符，“名字指出我们所要寻找的资源，地址指出资源所在的地方，路由告诉我们如何到达该处。”
-
+ 
9. **网桥（bridge）**：一种用于数据链路层实现中继，连接两个或多个局域网的网络互连设备。
10. **交换机（switch ）**：广义的来说，交换机指的是一种通信系统中完成信息交换的设备。这里工作在数据链路层的交换机指的是交换式集线器，其实质是一个多接口的网桥
@@ -218,7 +218,7 @@ tag:
4. **TCP（Transmission Control Protocol）**：传输控制协议。
5. **UDP（User Datagram Protocol）**：用户数据报协议。
-
+ 
6. **端口（port）**：端口的目的是为了确认对方机器的哪个进程在与自己进行交互，比如 MSN 和 QQ 的端口不同，如果没有端口就可能出现 QQ 进程和 MSN 交互错误。端口又称协议端口号。
7. **停止等待协议（stop-and-wait）**：指发送方每发送完一个分组就停止发送，等待对方确认，在收到确认之后在发送下一个分组。
@@ -267,34 +267,34 @@ tag:
1. **域名系统（DNS）**：域名系统（DNS，Domain Name System）将人类可读的域名 (例如，www.baidu.com) 转换为机器可读的 IP 地址 (例如，220.181.38.148)。我们可以将其理解为专为互联网设计的电话薄。
-
+ 
-https://www.seobility.net/en/wiki/HTTP_headers
+ https://www.seobility.net/en/wiki/HTTP_headers
2. **文件传输协议（FTP）**：FTP 是 File Transfer Protocol（文件传输协议）的英文简称，而中文简称为“文传协议”。用于 Internet 上的控制文件的双向传输。同时，它也是一个应用程序（Application）。基于不同的操作系统有不同的 FTP 应用程序，而所有这些应用程序都遵守同一种协议以传输文件。在 FTP 的使用当中，用户经常遇到两个概念："下载"（Download）和"上传"（Upload）。 "下载"文件就是从远程主机拷贝文件至自己的计算机上；"上传"文件就是将文件从自己的计算机中拷贝至远程主机上。用 Internet 语言来说，用户可通过客户机程序向（从）远程主机上传（下载）文件。
-
+ 
3. **简单文件传输协议（TFTP）**：TFTP（Trivial File Transfer Protocol,简单文件传输协议）是 TCP/IP 协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，提供不复杂、开销不大的文件传输服务。端口号为 69。
4. **远程终端协议（TELNET）**：Telnet 协议是 TCP/IP 协议族中的一员，是 Internet 远程登陆服务的标准协议和主要方式。它为用户提供了在本地计算机上完成远程主机工作的能力。在终端使用者的电脑上使用 telnet 程序，用它连接到服务器。终端使用者可以在 telnet 程序中输入命令，这些命令会在服务器上运行，就像直接在服务器的控制台上输入一样。可以在本地就能控制服务器。要开始一个 telnet 会话，必须输入用户名和密码来登录服务器。Telnet 是常用的远程控制 Web 服务器的方法。
5. **万维网（WWW）**：WWW 是环球信息网的缩写，（亦作“Web”、“WWW”、“'W3'”，英文全称为“World Wide Web”），中文名字为“万维网”，"环球网"等，常简称为 Web。分为 Web 客户端和 Web 服务器程序。WWW 可以让 Web 客户端（常用浏览器）访问浏览 Web 服务器上的页面。是一个由许多互相链接的超文本组成的系统，通过互联网访问。在这个系统中，每个有用的事物，称为一样“资源”；并且由一个全局“统一资源标识符”（URI）标识；这些资源通过超文本传输协议（Hypertext Transfer Protocol）传送给用户，而后者通过点击链接来获得资源。万维网联盟（英语：World Wide Web Consortium，简称 W3C），又称 W3C 理事会。1994 年 10 月在麻省理工学院（MIT）计算机科学实验室成立。万维网联盟的创建者是万维网的发明者蒂姆·伯纳斯-李。万维网并不等同互联网，万维网只是互联网所能提供的服务其中之一，是靠着互联网运行的一项服务。
6. **万维网的大致工作工程：**
-
+ 
7. **统一资源定位符（URL）**：统一资源定位符是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址。互联网上的每个文件都有一个唯一的 URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它。
8. **超文本传输协议（HTTP）**：超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的 WWW 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。1960 年美国人 Ted Nelson 构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了 HTTP 超文本传输协议标准架构的发展根基。
-HTTP 协议的本质就是一种浏览器与服务器之间约定好的通信格式。HTTP 的原理如下图所示：
+ HTTP 协议的本质就是一种浏览器与服务器之间约定好的通信格式。HTTP 的原理如下图所示：
-
+ 
-10. **代理服务器（Proxy Server）**：代理服务器（Proxy Server）是一种网络实体，它又称为万维网高速缓存。 代理服务器把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时，若代理服务器发现这个请求与暂时存放的的请求相同，就返回暂存的响应，而不需要按 URL 的地址再次去互联网访问该资源。代理服务器可在客户端或服务器工作，也可以在中间系统工作。
-11. **简单邮件传输协议(SMTP)** : SMTP（Simple Mail Transfer Protocol）即简单邮件传输协议,它是一组用于由源地址到目的地址传送邮件的规则，由它来控制信件的中转方式。 SMTP 协议属于 TCP/IP 协议簇，它帮助每台计算机在发送或中转信件时找到下一个目的地。 通过 SMTP 协议所指定的服务器,就可以把 E-mail 寄到收信人的服务器上了，整个过程只要几分钟。SMTP 服务器则是遵循 SMTP 协议的发送邮件服务器，用来发送或中转发出的电子邮件。
+9. **代理服务器（Proxy Server）**：代理服务器（Proxy Server）是一种网络实体，它又称为万维网高速缓存。 代理服务器把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时，若代理服务器发现这个请求与暂时存放的的请求相同，就返回暂存的响应，而不需要按 URL 的地址再次去互联网访问该资源。代理服务器可在客户端或服务器工作，也可以在中间系统工作。
+10. **简单邮件传输协议(SMTP)** : SMTP（Simple Mail Transfer Protocol）即简单邮件传输协议,它是一组用于由源地址到目的地址传送邮件的规则，由它来控制信件的中转方式。 SMTP 协议属于 TCP/IP 协议簇，它帮助每台计算机在发送或中转信件时找到下一个目的地。 通过 SMTP 协议所指定的服务器,就可以把 E-mail 寄到收信人的服务器上了，整个过程只要几分钟。SMTP 服务器则是遵循 SMTP 协议的发送邮件服务器，用来发送或中转发出的电子邮件。
-
+ 
-https://www.campaignmonitor.com/resources/knowledge-base/what-is-the-code-that-makes-bcc-or-cc-operate-in-an-email/
+ https://www.campaignmonitor.com/resources/knowledge-base/what-is-the-code-that-makes-bcc-or-cc-operate-in-an-email/
11. **搜索引擎** :搜索引擎（Search Engine）是指根据一定的策略、运用特定的计算机程序从互联网上搜集信息，在对信息进行组织和处理后，为用户提供检索服务，将用户检索相关的信息展示给用户的系统。搜索引擎包括全文索引、目录索引、元搜索引擎、垂直搜索引擎、集合式搜索引擎、门户搜索引擎与免费链接列表等。
diff --git a/docs/cs-basics/network/dns.md b/docs/cs-basics/network/dns.md
index 3c65653a41f..3d3ef0e2254 100644
--- a/docs/cs-basics/network/dns.md
+++ b/docs/cs-basics/network/dns.md
@@ -72,7 +72,7 @@ DNS 报文分为查询和回答报文，两种形式的报文结构相同。
## DNS 记录
-DNS 服务器在响应查询时，需要查询自己的数据库，数据库中的条目被称为**资源记录(Resource Record，RR)**。RR 提供了主机名到 IP 地址的映射。RR 是一个包含了`Name`, `Value`, `Type`, `TTL`四个字段的四元组。
+DNS 服务器在响应查询时，需要查询自己的数据库，数据库中的条目被称为 **资源记录(Resource Record，RR)** 。RR 提供了主机名到 IP 地址的映射。RR 是一个包含了`Name`, `Value`, `Type`, `TTL`四个字段的四元组。
diff --git a/docs/cs-basics/network/http-status-codes.md b/docs/cs-basics/network/http-status-codes.md
index e281f44ca19..5550e06d5b8 100644
--- a/docs/cs-basics/network/http-status-codes.md
+++ b/docs/cs-basics/network/http-status-codes.md
@@ -15,10 +15,14 @@ HTTP 状态码用于描述 HTTP 请求的结果，比如 2xx 就代表请求被
### 2xx Success（成功状态码）
-- **200 OK**：请求被成功处理。比如我们发送一个查询用户数据的 HTTP 请求到服务端，服务端正确返回了用户数据。这个是我们平时最常见的一个 HTTP 状态码。
-- **201 Created**：请求被成功处理并且在服务端创建了一个新的资源。比如我们通过 POST 请求创建一个新的用户。
-- **202 Accepted**：服务端已经接收到了请求，但是还未处理。
-- **204 No Content**：服务端已经成功处理了请求，但是没有返回任何内容。
+- **200 OK**：请求被成功处理。例如，发送一个查询用户数据的 HTTP 请求到服务端，服务端正确返回了用户数据。这个是我们平时最常见的一个 HTTP 状态码。
+- **201 Created**：请求被成功处理并且在服务端创建了~~一个新的资源~~。例如，通过 POST 请求创建一个新的用户。
+- **202 Accepted**：服务端已经接收到了请求，但是还未处理。例如，发送一个需要服务端花费较长时间处理的请求（如报告生成、Excel 导出），服务端接收了请求但尚未处理完毕。
+- **204 No Content**：服务端已经成功处理了请求，但是没有返回任何内容。例如，发送请求删除一个用户，服务器成功处理了删除操作但没有返回任何内容。
+
+🐛 修正（参见：[issue#2458](https://github.com/Snailclimb/JavaGuide/issues/2458)）：201 Created 状态码更准确点来说是创建一个或多个新的资源，可以参考：。
+
+
这里格外提一下 204 状态码，平时学习/工作中见到的次数并不多。
diff --git a/docs/cs-basics/network/http1.0-vs-http1.1.md b/docs/cs-basics/network/http1.0-vs-http1.1.md
index eab4c324a51..f0bb9850780 100644
--- a/docs/cs-basics/network/http1.0-vs-http1.1.md
+++ b/docs/cs-basics/network/http1.0-vs-http1.1.md
@@ -70,9 +70,70 @@ Host: example1.org
HTTP/1.1 引入了范围请求（range request）机制，以避免带宽的浪费。当客户端想请求一个文件的一部分，或者需要继续下载一个已经下载了部分但被终止的文件，HTTP/1.1 可以在请求中加入`Range`头部，以请求（并只能请求字节型数据）数据的一部分。服务器端可以忽略`Range`头部，也可以返回若干`Range`响应。
-如果一个响应包含部分数据的话，那么将带有`206 (Partial Content)`状态码。该状态码的意义在于避免了 HTTP/1.0 代理缓存错误地把该响应认为是一个完整的数据响应，从而把他当作为一个请求的响应缓存。
+`206 (Partial Content)` 状态码的主要作用是确保客户端和代理服务器能正确识别部分内容响应，避免将其误认为完整资源并错误地缓存。这对于正确处理范围请求和缓存管理非常重要。
-在范围响应中，`Content-Range`头部标志指示出了该数据块的偏移量和数据块的长度。
+一个典型的 HTTP/1.1 范围请求示例：
+
+```bash
+# 获取一个文件的前 1024 个字节
+GET /z4d4kWk.jpg HTTP/1.1
+Host: i.imgur.com
+Range: bytes=0-1023
+```
+
+`206 Partial Content` 响应：
+
+```bash
+
+HTTP/1.1 206 Partial Content
+Content-Range: bytes 0-1023/146515
+Content-Length: 1024
+…
+（二进制内容）
+```
+
+简单解释一下 HTTP 范围响应头部中的字段：
+
+- **`Content-Range` 头部**：指示返回数据在整个资源中的位置，包括起始和结束字节以及资源的总长度。例如，`Content-Range: bytes 0-1023/146515` 表示服务器端返回了第 0 到 1023 字节的数据（共 1024 字节），而整个资源的总长度是 146,515 字节。
+- **`Content-Length` 头部**：指示此次响应中实际传输的字节数。例如，`Content-Length: 1024` 表示服务器端传输了 1024 字节的数据。
+
+`Range` 请求头不仅可以请求单个字节范围，还可以一次性请求多个范围。这种方式被称为“多重范围请求”（multiple range requests）。
+
+客户端想要获取资源的第 0 到 499 字节以及第 1000 到 1499 字节：
+
+```bash
+GET /path/to/resource HTTP/1.1
+Host: example.com
+Range: bytes=0-499,1000-1499
+```
+
+服务器端返回多个字节范围，每个范围的内容以分隔符分开：
+
+```bash
+HTTP/1.1 206 Partial Content
+Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
+Content-Length: 376
+
+--3d6b6a416f9b5
+Content-Type: application/octet-stream
+Content-Range: bytes 0-99/2000
+
+(第 0 到 99 字节的数据块)
+
+--3d6b6a416f9b5
+Content-Type: application/octet-stream
+Content-Range: bytes 500-599/2000
+
+(第 500 到 599 字节的数据块)
+
+--3d6b6a416f9b5
+Content-Type: application/octet-stream
+Content-Range: bytes 1000-1099/2000
+
+(第 1000 到 1099 字节的数据块)
+
+--3d6b6a416f9b5--
+```
### 状态码 100
diff --git a/docs/cs-basics/network/nat.md b/docs/cs-basics/network/nat.md
index c9c879b4293..4567719b81e 100644
--- a/docs/cs-basics/network/nat.md
+++ b/docs/cs-basics/network/nat.md
@@ -45,7 +45,7 @@ SOHO 子网的“代理人”，也就是和外界的窗口，通常由路由器
针对以上过程，有以下几个重点需要强调：
1. 当请求报文到达路由器，并被指定了新端口号时，由于端口号有 16 位，因此，通常来说，一个路由器管理的 LAN 中的最大主机数 $≈65500$（$2^{16}$ 的地址空间），但通常 SOHO 子网内不会有如此多的主机数量。
-2. 对于目的服务器来说，从来不知道“到底是哪个主机给我发送的请求”，它只知道是来自`138.76.29.7:5001`的路由器转发的请求。因此，可以说，**路由器在 WAN 和 LAN 之间起到了屏蔽作用，**所有内部主机发送到外部的报文，都具有同一个 IP 地址（不同的端口号），所有外部发送到内部的报文，也都只有一个目的地（不同端口号），是经过了 NAT 转换后，外部报文才得以正确地送达内部主机。
+2. 对于目的服务器来说，从来不知道“到底是哪个主机给我发送的请求”，它只知道是来自`138.76.29.7:5001`的路由器转发的请求。因此，可以说，**路由器在 WAN 和 LAN 之间起到了屏蔽作用**，所有内部主机发送到外部的报文，都具有同一个 IP 地址（不同的端口号），所有外部发送到内部的报文，也都只有一个目的地（不同端口号），是经过了 NAT 转换后，外部报文才得以正确地送达内部主机。
3. 在报文穿过路由器，发生 NAT 转换时，如果 LAN 主机 IP 已经在 NAT 转换表中注册过了，则不需要路由器新指派端口，而是直接按照转换记录穿过路由器。同理，外部报文发送至内部时也如此。
总结 NAT 协议的特点，有以下几点：
@@ -55,6 +55,6 @@ SOHO 子网的“代理人”，也就是和外界的窗口，通常由路由器
3. WAN 的 ISP 变更接口地址时，无需通告 LAN 内主机。
4. LAN 主机对 WAN 不可见，不可直接寻址，可以保证一定程度的安全性。
-然而，NAT 协议由于其独特性，存在着一些争议。比如，可能你已经注意到了，NAT 协议在 LAN 以外，标识一个内部主机时，使用的是端口号，因为 IP 地址都是相同的。 这种将端口号作为主机寻址的行为，可能会引发一些误会。此外，路由器作为网络层的设备，修改了传输层的分组内容（修改了源 IP 地址和端口号），同样是不规范的行为。但是，尽管如此，NAT 协议作为 IPv4 时代的产物，极大地方便了一些本来棘手的问题，一直被沿用至今。
+然而，NAT 协议由于其独特性，存在着一些争议。比如，可能你已经注意到了，**NAT 协议在 LAN 以外，标识一个内部主机时，使用的是端口号，因为 IP 地址都是相同的**。这种将端口号作为主机寻址的行为，可能会引发一些误会。此外，路由器作为网络层的设备，修改了传输层的分组内容（修改了源 IP 地址和端口号），同样是不规范的行为。但是，尽管如此，NAT 协议作为 IPv4 时代的产物，极大地方便了一些本来棘手的问题，一直被沿用至今。
diff --git a/docs/cs-basics/network/network-attack-means.md b/docs/cs-basics/network/network-attack-means.md
index 7f142af00c3..748999d6eba 100644
--- a/docs/cs-basics/network/network-attack-means.md
+++ b/docs/cs-basics/network/network-attack-means.md
@@ -357,17 +357,17 @@ DES 使用的密钥表面上是 64 位的，然而只有其中的 56 位被实
这个大家应该更加熟悉了，比如我们平常使用的 MD5 校验，在很多时候，我并不是拿来进行加密，而是用来获得唯一性 ID。在做系统的过程中，存储用户的各种密码信息，通常都会通过散列算法，最终存储其散列值。
-**MD5**
+**MD5**（不推荐）
MD5 可以用来生成一个 128 位的消息摘要，它是目前应用比较普遍的散列算法，具体的应用场景你可以自行 参阅。虽然，因为算法的缺陷，它的唯一性已经被破解了，但是大部分场景下，这并不会构成安全问题。但是，如果不是长度受限（32 个字符），我还是不推荐你继续使用 **MD5** 的。
**SHA**
-安全散列算法。**SHA** 分为 **SHA1** 和 **SH2** 两个版本。该算法的思想是接收一段明文，然后以一种不可逆的方式将它转换成一段（通常更小）密文，也可以简单的理解为取一串输入码（称为预映射或信息），并把它们转化为长度较短、位数固定的输出序列即散列值（也称为信息摘要或信息认证代码）的过程。
+安全散列算法。**SHA** 包括**SHA-1**、**SHA-2**和**SHA-3**三个版本。该算法的基本思想是：接收一段明文数据，通过不可逆的方式将其转换为固定长度的密文。简单来说，SHA 将输入数据（即预映射或消息）转化为固定长度、较短的输出值，称为散列值（或信息摘要、信息认证码）。SHA-1 已被证明不够安全，因此逐渐被 SHA-2 取代，而 SHA-3 则作为 SHA 系列的最新版本，采用不同的结构（Keccak 算法）提供更高的安全性和灵活性。
**SM3**
-国密算法**SM3**。加密强度和 SHA-256 想不多。主要是收到国家的支持。
+国密算法**SM3**。加密强度和 SHA-256 算法 相差不多。主要是受到了国家的支持。
**总结**：
diff --git a/docs/cs-basics/network/other-network-questions.md b/docs/cs-basics/network/other-network-questions.md
index f9f91f45e12..0b852b063ac 100644
--- a/docs/cs-basics/network/other-network-questions.md
+++ b/docs/cs-basics/network/other-network-questions.md
@@ -94,7 +94,7 @@ tag:
- **ARP（Address Resolution Protocol，地址解析协议）**：ARP 协议解决的是网络层地址和链路层地址之间的转换问题。因为一个 IP 数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。
- **ICMP（Internet Control Message Protocol，互联网控制报文协议）**：一种用于传输网络状态和错误消息的协议，常用于网络诊断和故障排除。例如，Ping 工具就使用了 ICMP 协议来测试网络连通性。
- **NAT（Network Address Translation，网络地址转换协议）**：NAT 协议的应用场景如同它的名称——网络地址转换，应用于内部网到外部网的地址转换过程中。具体地说，在一个小的子网（局域网，LAN）内，各主机使用的是同一个 LAN 下的 IP 地址，但在该 LAN 以外，在广域网（WAN）中，需要一个统一的 IP 地址来标识该 LAN 在整个 Internet 上的位置。
-- **OSPF（Open Shortest Path First，开放式最短路径优先）** ）：一种内部网关协议（Interior Gateway Protocol，IGP），也是广泛使用的一种动态路由协议，基于链路状态算法，考虑了链路的带宽、延迟等因素来选择最佳路径。
+- **OSPF（Open Shortest Path First，开放式最短路径优先）**：一种内部网关协议（Interior Gateway Protocol，IGP），也是广泛使用的一种动态路由协议，基于链路状态算法，考虑了链路的带宽、延迟等因素来选择最佳路径。
- **RIP(Routing Information Protocol，路由信息协议）**：一种内部网关协议（Interior Gateway Protocol，IGP），也是一种动态路由协议，基于距离向量算法，使用固定的跳数作为度量标准，选择跳数最少的路径作为最佳路径。
- **BGP（Border Gateway Protocol，边界网关协议）**：一种用来在路由选择域之间交换网络层可达性信息（Network Layer Reachability Information，NLRI）的路由选择协议，具有高度的灵活性和可扩展性。
@@ -132,40 +132,40 @@ HTTP 状态码用于描述 HTTP 请求的结果，比如 2xx 就代表请求被
### HTTP Header 中常见的字段有哪些？
-| 请求头字段名 | 说明 | 示例 |
-| :------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------- |
-| Accept | 能够接受的回应内容类型（Content-Types）。 | Accept: text/plain |
-| Accept-Charset | 能够接受的字符集 | Accept-Charset: utf-8 |
-| Accept-Datetime | 能够接受的按照时间来表示的版本 | Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT |
-| Accept-Encoding | 能够接受的编码方式列表。参考 HTTP 压缩。 | Accept-Encoding: gzip, deflate |
-| Accept-Language | 能够接受的回应内容的自然语言列表。 | Accept-Language: en-US |
-| Authorization | 用于超文本传输协议的认证的认证信息 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
-| Cache-Control | 用来指定在这次的请求/响应链中的所有缓存机制 都必须 遵守的指令 | Cache-Control: no-cache |
-| Connection | 该浏览器想要优先使用的连接类型 | Connection: keep-alive Connection: Upgrade |
-| Content-Length | 以 八位字节数组 （8 位的字节）表示的请求体的长度 | Content-Length: 348 |
-| Content-MD5 | 请求体的内容的二进制 MD5 散列值，以 Base64 编码的结果 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
-| Content-Type | 请求体的 多媒体类型 （用于 POST 和 PUT 请求中） | Content-Type: application/x-www-form-urlencoded |
-| Cookie | 之前由服务器通过 Set- Cookie （下文详述）发送的一个 超文本传输协议 Cookie | Cookie: \$Version=1; Skin=new; |
-| Date | 发送该消息的日期和时间(按照 RFC 7231 中定义的"超文本传输协议日期"格式来发送) | Date: Tue, 15 Nov 1994 08:12:31 GMT |
-| Expect | 表明客户端要求服务器做出特定的行为 | Expect: 100-continue |
-| From | 发起此请求的用户的邮件地址 | From: [user@example.com](mailto:user@example.com) |
-| Host | 服务器的域名(用于虚拟主机 )，以及服务器所监听的传输控制协议端口号。如果所请求的端口是对应的服务的标准端口，则端口号可被省略。 | Host: en.wikipedia.org:80 |
-| If-Match | 仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要作用时，用作像 PUT 这样的方法中，仅当从用户上次更新某个资源以来，该资源未被修改的情况下，才更新该资源。 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
-| If-Modified-Since | 允许在对应的内容未被修改的情况下返回 304 未修改（ 304 Not Modified ） | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
-| If-None-Match | 允许在对应的内容未被修改的情况下返回 304 未修改（ 304 Not Modified ） | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
-| If-Range | 如果该实体未被修改过，则向我发送我所缺少的那一个或多个部分；否则，发送整个新的实体 | If-Range: “737060cd8c284d8af7ad3082f209582d” |
-| If-Unmodified-Since | 仅当该实体自某个特定时间已来未被修改的情况下，才发送回应。 | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
-| Max-Forwards | 限制该消息可被代理及网关转发的次数。 | Max-Forwards: 10 |
-| Origin | 发起一个针对 跨来源资源共享 的请求。 | Origin: [http://www.example-social-network.com](http://www.example-social-network.com/) |
-| Pragma | 与具体的实现相关，这些字段可能在请求/回应链中的任何时候产生多种效果。 | Pragma: no-cache |
-| Proxy-Authorization | 用来向代理进行认证的认证信息。 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
-| Range | 仅请求某个实体的一部分。字节偏移以 0 开始。参见字节服务。 | Range: bytes=500-999 |
-| Referer | 表示浏览器所访问的前一个页面，正是那个页面上的某个链接将浏览器带到了当前所请求的这个页面。 | Referer: [http://en.wikipedia.org/wiki/Main_Page](https://en.wikipedia.org/wiki/Main_Page) |
-| TE | 浏览器预期接受的传输编码方式：可使用回应协议头 Transfer-Encoding 字段中的值； | TE: trailers, deflate |
-| Upgrade | 要求服务器升级到另一个协议。 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
-| User-Agent | 浏览器的浏览器身份标识字符串 | User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0 |
-| Via | 向服务器告知，这个请求是由哪些代理发出的。 | Via: 1.0 fred, 1.1 example.com (Apache/1.1) |
-| Warning | 一个一般性的警告，告知，在实体内容体中可能存在错误。 | Warning: 199 Miscellaneous warning |
+| 请求头字段名 | 说明 | 示例 |
+| :------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------- |
+| Accept | 能够接受的回应内容类型（Content-Types）。 | Accept: text/plain |
+| Accept-Charset | 能够接受的字符集 | Accept-Charset: utf-8 |
+| Accept-Datetime | 能够接受的按照时间来表示的版本 | Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT |
+| Accept-Encoding | 能够接受的编码方式列表。参考 HTTP 压缩。 | Accept-Encoding: gzip, deflate |
+| Accept-Language | 能够接受的回应内容的自然语言列表。 | Accept-Language: en-US |
+| Authorization | 用于超文本传输协议的认证的认证信息 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
+| Cache-Control | 用来指定在这次的请求/响应链中的所有缓存机制 都必须 遵守的指令 | Cache-Control: no-cache |
+| Connection | 该浏览器想要优先使用的连接类型 | Connection: keep-alive |
+| Content-Length | 以八位字节数组（8 位的字节）表示的请求体的长度 | Content-Length: 348 |
+| Content-MD5 | 请求体的内容的二进制 MD5 散列值，以 Base64 编码的结果 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
+| Content-Type | 请求体的多媒体类型（用于 POST 和 PUT 请求中） | Content-Type: application/x-www-form-urlencoded |
+| Cookie | 之前由服务器通过 Set-Cookie（下文详述）发送的一个超文本传输协议 Cookie | Cookie: $Version=1; Skin=new; |
+| Date | 发送该消息的日期和时间(按照 RFC 7231 中定义的"超文本传输协议日期"格式来发送) | Date: Tue, 15 Nov 1994 08:12:31 GMT |
+| Expect | 表明客户端要求服务器做出特定的行为 | Expect: 100-continue |
+| From | 发起此请求的用户的邮件地址 | From: `user@example.com` |
+| Host | 服务器的域名(用于虚拟主机)，以及服务器所监听的传输控制协议端口号。如果所请求的端口是对应的服务的标准端口，则端口号可被省略。 | Host: en.wikipedia.org |
+| If-Match | 仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要作用是用于像 PUT 这样的方法中，仅当从用户上次更新某个资源以来，该资源未被修改的情况下，才更新该资源。 | If-Match: "737060cd8c284d8af7ad3082f209582d" |
+| If-Modified-Since | 允许服务器在请求的资源自指定的日期以来未被修改的情况下返回 `304 Not Modified` 状态码 | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
+| If-None-Match | 允许服务器在请求的资源的 ETag 未发生变化的情况下返回 `304 Not Modified` 状态码 | If-None-Match: "737060cd8c284d8af7ad3082f209582d" |
+| If-Range | 如果该实体未被修改过，则向我发送我所缺少的那一个或多个部分；否则，发送整个新的实体 | If-Range: "737060cd8c284d8af7ad3082f209582d" |
+| If-Unmodified-Since | 仅当该实体自某个特定时间以来未被修改的情况下，才发送回应。 | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
+| Max-Forwards | 限制该消息可被代理及网关转发的次数。 | Max-Forwards: 10 |
+| Origin | 发起一个针对跨来源资源共享的请求。 | `Origin: http://www.example-social-network.com` |
+| Pragma | 与具体的实现相关，这些字段可能在请求/回应链中的任何时候产生多种效果。 | Pragma: no-cache |
+| Proxy-Authorization | 用来向代理进行认证的认证信息。 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
+| Range | 仅请求某个实体的一部分。字节偏移以 0 开始。参见字节服务。 | Range: bytes=500-999 |
+| Referer | 表示浏览器所访问的前一个页面，正是那个页面上的某个链接将浏览器带到了当前所请求的这个页面。 | `Referer: http://en.wikipedia.org/wiki/Main_Page` |
+| TE | 浏览器预期接受的传输编码方式：可使用回应协议头 Transfer-Encoding 字段中的值； | TE: trailers, deflate |
+| Upgrade | 要求服务器升级到另一个协议。 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
+| User-Agent | 浏览器的浏览器身份标识字符串 | User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0 |
+| Via | 向服务器告知，这个请求是由哪些代理发出的。 | Via: 1.0 fred, 1.1 example.com (Apache/1.1) |
+| Warning | 一个一般性的警告，告知，在实体内容体中可能存在错误。 | Warning: 199 Miscellaneous warning |
### HTTP 和 HTTPS 有什么区别？（重要）
@@ -194,8 +194,9 @@ HTTP 状态码用于描述 HTTP 请求的结果，比如 2xx 就代表请求被
-- **多路复用（Multiplexing）**：HTTP/2.0 在同一连接上可以同时传输多个请求和响应（可以看作是 HTTP/1.1 中长链接的升级版本），互不干扰。HTTP/1.1 则使用串行方式，每个请求和响应都需要独立的连接，而浏览器为了控制资源会有 6-8 个 TCP 连接都限制。。这使得 HTTP/2.0 在处理多个请求时更加高效，减少了网络延迟和提高了性能。
+- **多路复用（Multiplexing）**：HTTP/2.0 在同一连接上可以同时传输多个请求和响应（可以看作是 HTTP/1.1 中长链接的升级版本），互不干扰。HTTP/1.1 则使用串行方式，每个请求和响应都需要独立的连接，而浏览器为了控制资源会有 6-8 个 TCP 连接的限制。这使得 HTTP/2.0 在处理多个请求时更加高效，减少了网络延迟和提高了性能。
- **二进制帧（Binary Frames）**：HTTP/2.0 使用二进制帧进行数据传输，而 HTTP/1.1 则使用文本格式的报文。二进制帧更加紧凑和高效，减少了传输的数据量和带宽消耗。
+- **队头阻塞**：HTTP/2 引入了多路复用技术，允许多个请求和响应在单个 TCP 连接上并行交错传输，解决了 HTTP/1.1 应用层的队头阻塞问题，但 HTTP/2 依然受到 TCP 层队头阻塞 的影响。
- **头部压缩（Header Compression）**：HTTP/1.1 支持`Body`压缩，`Header`不支持压缩。HTTP/2.0 支持对`Header`压缩，使用了专门为`Header`压缩而设计的 HPACK 算法，减少了网络开销。
- **服务器推送（Server Push）**：HTTP/2.0 支持服务器推送，可以在客户端请求一个资源时，将其他相关资源一并推送给客户端，从而减少了客户端的请求次数和延迟。而 HTTP/1.1 需要客户端自己发送请求来获取相关资源。
@@ -203,7 +204,7 @@ HTTP/2.0 多路复用效果图（图源： [HTTP/2 For Web Developers](https://b
-可以看到，HTTP/2.0 的多路复用使得不同的请求可以共用一个 TCP 连接，避免建立多个连接带来不必要的额外开销，而 HTTP/1.1 中的每个请求都会建立一个单独的连接
+可以看到，HTTP/2 的多路复用机制允许多个请求和响应共享一个 TCP 连接，从而避免了 HTTP/1.1 在应对并发请求时需要建立多个并行连接的情况，减少了重复连接建立和维护的额外开销。而在 HTTP/1.1 中，尽管支持持久连接，但为了缓解队头阻塞问题，浏览器通常会为同一域名建立多个并行连接。
### HTTP/2.0 和 HTTP/3.0 有什么区别？
@@ -211,16 +212,50 @@ HTTP/2.0 多路复用效果图（图源： [HTTP/2 For Web Developers](https://b
- **传输协议**：HTTP/2.0 是基于 TCP 协议实现的，HTTP/3.0 新增了 QUIC（Quick UDP Internet Connections） 协议来实现可靠的传输，提供与 TLS/SSL 相当的安全性，具有较低的连接和传输延迟。你可以将 QUIC 看作是 UDP 的升级版本，在其基础上新增了很多功能比如加密、重传等等。HTTP/3.0 之前名为 HTTP-over-QUIC，从这个名字中我们也可以发现，HTTP/3 最大的改造就是使用了 QUIC。
- **连接建立**：HTTP/2.0 需要经过经典的 TCP 三次握手过程（由于安全的 HTTPS 连接建立还需要 TLS 握手，共需要大约 3 个 RTT）。由于 QUIC 协议的特性（TLS 1.3，TLS 1.3 除了支持 1 个 RTT 的握手，还支持 0 个 RTT 的握手）连接建立仅需 0-RTT 或者 1-RTT。这意味着 QUIC 在最佳情况下不需要任何的额外往返时间就可以建立新连接。
+- **头部压缩**：HTTP/2.0 使用 HPACK 算法进行头部压缩，而 HTTP/3.0 使用更高效的 QPACK 头压缩算法。
- **队头阻塞**：HTTP/2.0 多请求复用一个 TCP 连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。由于 QUIC 协议的特性，HTTP/3.0 在一定程度上解决了队头阻塞（Head-of-Line blocking, 简写：HOL blocking）问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。
+- **连接迁移**：HTTP/3.0 支持连接迁移，因为 QUIC 使用 64 位 ID 标识连接，只要 ID 不变就不会中断，网络环境改变时（如从 Wi-Fi 切换到移动数据）也能保持连接。而 TCP 连接是由（源 IP，源端口，目的 IP，目的端口）组成，这个四元组中一旦有一项值发生改变，这个连接也就不能用了。
- **错误恢复**：HTTP/3.0 具有更好的错误恢复机制，当出现丢包、延迟等网络问题时，可以更快地进行恢复和重传。而 HTTP/2.0 则需要依赖于 TCP 的错误恢复机制。
-- **安全性**：HTTP/2.0 和 HTTP/3.0 在安全性上都有较高的要求，支持加密通信，但在实现上有所不同。HTTP/2.0 使用 TLS 协议进行加密，而 HTTP/3.0 基于 QUIC 协议，包含了内置的加密和身份验证机制，可以提供更强的安全性。
+- **安全性**：在 HTTP/2.0 中，TLS 用于加密和认证整个 HTTP 会话，包括所有的 HTTP 头部和数据负载。TLS 的工作是在 TCP 层之上，它加密的是在 TCP 连接中传输的应用层的数据，并不会对 TCP 头部以及 TLS 记录层头部进行加密，所以在传输的过程中 TCP 头部可能会被攻击者篡改来干扰通信。而 HTTP/3.0 的 QUIC 对整个数据包（包括报文头和报文体）进行了加密与认证处理，保障安全性。
HTTP/1.0、HTTP/2.0 和 HTTP/3.0 的协议栈比较：
+下图是一个更详细的 HTTP/2.0 和 HTTP/3.0 对比图：
+
+
+
+从上图可以看出：
+
+- **HTTP/2.0**：使用 TCP 作为传输协议、使用 HPACK 进行头部压缩、依赖 TLS 进行加密。
+- **HTTP/3.0**：使用基于 UDP 的 QUIC 协议、使用更高效的 QPACK 进行头部压缩、在 QUIC 中直接集成了 TLS。QUIC 协议具备连接迁移、拥塞控制与避免、流量控制等特性。
+
关于 HTTP/1.0 -> HTTP/3.0 更详细的演进介绍，推荐阅读[HTTP1 到 HTTP3 的工程优化](https://dbwu.tech/posts/http_evolution/)。
+### HTTP/1.1 和 HTTP/2.0 的队头阻塞有什么不同？
+
+HTTP/1.1 队头阻塞的主要原因是无法多路复用：
+
+- 在一个 TCP 连接中，资源的请求和响应是按顺序处理的。如果一个大的资源（如一个大文件）正在传输，后续的小资源（如较小的 CSS 文件）需要等待前面的资源传输完成后才能被发送。
+- 如果浏览器需要同时加载多个资源（如多个 CSS、JS 文件等），它通常会开启多个并行的 TCP 连接（一般限制为 6 个）。但每个连接仍然受限于顺序的请求-响应机制，因此仍然会发生 **应用层的队头阻塞**。
+
+虽然 HTTP/2.0 引入了多路复用技术，允许多个请求和响应在单个 TCP 连接上并行交错传输，解决了 **HTTP/1.1 应用层的队头阻塞问题**，但 HTTP/2.0 依然受到 **TCP 层队头阻塞** 的影响：
+
+- HTTP/2.0 通过帧（frame）机制将每个资源分割成小块，并为每个资源分配唯一的流 ID，这样多个资源的数据可以在同一 TCP 连接中交错传输。
+- TCP 作为传输层协议，要求数据按顺序交付。如果某个数据包在传输过程中丢失，即使后续的数据包已经到达，也必须等待丢失的数据包重传后才能继续处理。这种传输层的顺序性导致了 **TCP 层的队头阻塞**。
+- 举例来说，如果 HTTP/2 的一个 TCP 数据包中携带了多个资源的数据（例如 JS 和 CSS），而该数据包丢失了，那么后续数据包中的所有资源数据都需要等待丢失的数据包重传回来，导致所有流（streams）都被阻塞。
+
+最后，来一张表格总结补充一下：
+
+| **方面** | **HTTP/1.1 的队头阻塞** | **HTTP/2.0 的队头阻塞** |
+| -------------- | ---------------------------------------- | ---------------------------------------------------------------- |
+| **层级** | 应用层（HTTP 协议本身的限制） | 传输层（TCP 协议的限制） |
+| **根本原因** | 无法多路复用，请求和响应必须按顺序传输 | TCP 要求数据包按顺序交付，丢包时阻塞整个连接 |
+| **受影响范围** | 单个 HTTP 请求/响应会阻塞后续请求/响应。 | 单个 TCP 包丢失会影响所有 HTTP/2.0 流(依赖于同一个底层 TCP 连接) |
+| **缓解方法** | 开启多个并行的 TCP 连接 | 减少网络掉包或者使用基于 UDP 的 QUIC 协议 |
+| **影响场景** | 每次都会发生，尤其是大文件阻塞小文件时。 | 丢包率较高的网络环境下更容易发生。 |
+
### HTTP 是不保存状态的协议, 如何保存用户状态?
HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们如何保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。
@@ -301,23 +336,70 @@ WebSocket 的工作过程可以分为以下几个步骤：
另外，建立 WebSocket 连接之后，通过心跳机制来保持 WebSocket 连接的稳定性和活跃性。
+### WebSocket 与短轮询、长轮询的区别
+
+这三种方式，都是为了解决“**客户端如何及时获取服务器最新数据，实现实时更新**”的问题。它们的实现方式和效率、实时性差异较大。
+
+**1.短轮询（Short Polling）**
+
+- **原理**：客户端每隔固定时间（如 5 秒）发起一次 HTTP 请求，询问服务器是否有新数据。服务器收到请求后立即响应。
+- **优点**：实现简单，兼容性好，直接用常规 HTTP 请求即可。
+- **缺点**：
+ - **实时性一般**：消息可能在两次轮询间到达，用户需等到下次请求才知晓。
+ - **资源浪费大**：反复建立/关闭连接，且大多数请求收到的都是“无新消息”，极大增加服务器和网络压力。
+
+**2.长轮询（Long Polling）**
+
+- **原理**：客户端发起请求后，若服务器暂时无新数据，则会保持连接，直到有新数据或超时才响应。客户端收到响应后立即发起下一次请求，实现“伪实时”。
+- **优点**：
+ - **实时性较好**：一旦有新数据可立即推送，无需等待下次定时请求。
+ - **空响应减少**：减少了无效的空响应，提升了效率。
+- **缺点**：
+ - **服务器资源占用高**：需长时间维护大量连接，消耗服务器线程/连接数。
+ - **资源浪费大**：每次响应后仍需重新建立连接，且依然基于 HTTP 单向请求-响应机制。
+
+**3. WebSocket**
+
+- **原理**：客户端与服务器通过一次 HTTP Upgrade 握手后，建立一条持久的 TCP 连接。之后，双方可以随时、主动地发送数据，实现真正的全双工、低延迟通信。
+- **优点**：
+ - **实时性强**：数据可即时双向收发，延迟极低。
+ - **资源效率高**：连接持续，无需反复建立/关闭，减少资源消耗。
+ - **功能强大**：支持服务端主动推送消息、客户端主动发起通信。
+- **缺点**：
+ - **使用限制**：需要服务器和客户端都支持 WebSocket 协议。对连接管理有一定要求（如心跳保活、断线重连等）。
+ - **实现麻烦**：实现起来比短轮询和长轮询要更麻烦一些。
+
+
+
### SSE 与 WebSocket 有什么区别？
-> 摘自[Web 实时消息推送详解](https://javaguide.cn/system-design/web-real-time-message-push.html)。
+SSE (Server-Sent Events) 和 WebSocket 都是用来实现服务器向浏览器实时推送消息的技术，让网页内容能自动更新，而不需要用户手动刷新。虽然目标相似，但它们在工作方式和适用场景上有几个关键区别：
+
+1. **通信方式:**
+ - **SSE:** **单向通信**。只有服务器能向客户端（浏览器）发送数据。客户端不能通过同一个连接向服务器发送数据（需要发起新的 HTTP 请求）。
+ - **WebSocket:** **双向通信 (全双工)**。客户端和服务器可以随时互相发送消息，实现真正的实时交互。
+2. **底层协议:**
+ - **SSE:** 基于**标准的 HTTP/HTTPS 协议**。它本质上是一个“长连接”的 HTTP 请求，服务器保持连接打开并持续发送事件流。不需要特殊的服务器或协议支持，现有的 HTTP 基础设施就能用。
+ - **WebSocket:** 使用**独立的 ws:// 或 wss:// 协议**。它需要通过一个特定的 HTTP "Upgrade" 请求来建立连接，并且服务器需要明确支持 WebSocket 协议来处理连接和消息帧。
+3. **实现复杂度和成本:**
+ - **SSE:** **实现相对简单**，主要在服务器端处理。浏览器端有标准的 EventSource API，使用方便。开发和维护成本较低。
+ - **WebSocket:** **稍微复杂一些**。需要服务器端专门处理 WebSocket 连接和协议，客户端也需要使用 WebSocket API。如果需要考虑兼容性、心跳、重连等，开发成本会更高。
+4. **断线重连:**
+ - **SSE:** **浏览器原生支持**。EventSource API 提供了自动断线重连的机制。
+ - **WebSocket:** **需要手动实现**。开发者需要自己编写逻辑来检测断线并进行重连尝试。
+5. **数据类型:**
+ - **SSE:** **主要设计用来传输文本** (UTF-8 编码)。如果需要传输二进制数据，需要先进行 Base64 等编码转换成文本。
+ - **WebSocket:** **原生支持传输文本和二进制数据**，无需额外编码。
-SSE 与 WebSocket 作用相似，都可以建立服务端与浏览器之间的通信，实现服务端向客户端推送消息，但还是有些许不同：
+为了提供更好的用户体验和利用其简单、高效、基于标准 HTTP 的特性，**Server-Sent Events (SSE) 是目前大型语言模型 API（如 OpenAI、DeepSeek 等）实现流式响应的常用甚至可以说是标准的技木选择**。
-- SSE 是基于 HTTP 协议的，它们不需要特殊的协议或服务器实现即可工作；WebSocket 需单独服务器来处理协议。
-- SSE 单向通信，只能由服务端向客户端单向通信；WebSocket 全双工通信，即通信的双方可以同时发送和接受信息。
-- SSE 实现简单开发成本低，无需引入其他组件；WebSocket 传输数据需做二次解析，开发门槛高一些。
-- SSE 默认支持断线重连；WebSocket 则需要自己实现。
-- SSE 只能传送文本消息，二进制数据需要经过编码后传送；WebSocket 默认支持传送二进制数据。
+这里以 DeepSeek 为例，我们发送一个请求并打开浏览器控制台验证一下：
-**SSE 与 WebSocket 该如何选择？**
+
-SSE 好像一直不被大家所熟知，一部分原因是出现了 WebSocket，这个提供了更丰富的协议来执行双向、全双工通信。对于游戏、即时通信以及需要双向近乎实时更新的场景，拥有双向通道更具吸引力。
+
-但是，在某些情况下，不需要从客户端发送数据。而你只需要一些服务器操作的更新。比如：站内信、未读消息数、状态更新、股票行情、监控数量等场景，SEE 不管是从实现的难易和成本上都更加有优势。此外，SSE 具有 WebSocket 在设计上缺乏的多种功能，例如：自动重新连接、事件 ID 和发送任意事件的能力。
+可以看到，响应头应里包含了 `text/event-stream`，说明使用的确实是SSE。并且，响应数据也确实是持续分块传输。
## PING
@@ -386,7 +468,7 @@ DNS 服务器自底向上可以依次分为以下几个层级(所有 DNS 服务
- 权威 DNS 服务器。在因特网上具有公共可访问主机的每个组织机构必须提供公共可访问的 DNS 记录，这些记录将这些主机的名字映射为 IP 地址。
- 本地 DNS 服务器。每个 ISP（互联网服务提供商）都有一个自己的本地 DNS 服务器。当主机发出 DNS 请求时，该请求被发往本地 DNS 服务器，它起着代理的作用，并将该请求转发到 DNS 层次结构中。严格说来，不属于 DNS 层级结构
-世界上并不是只有 13 台根服务器，这是很多人普遍的误解，网上很多文章也是这么写的。实际上，现在根服务器数量远远超过这个数量。最初确实是为 DNS 根服务器分配了 13 个 IP 地址，每个 IP 地址对应一个不同的根 DNS 服务器。然而，由于互联网的快速发展和增长，这个原始的架构变得不太适应当前的需求。为了提高 DNS 的可靠性、安全性和性能，目前这 13 个 IP 地址中的每一个都有多个服务器，截止到 2023 年底，所有根服务器之和达到了 600 多台，未来还会继续增加。
+世界上并不是只有 13 台根服务器，这是很多人普遍的误解，网上很多文章也是这么写的。实际上，现在根服务器数量远远超过这个数量。最初确实是为 DNS 根服务器分配了 13 个 IP 地址，每个 IP 地址对应一个不同的根 DNS 服务器。然而，由于互联网的快速发展和增长，这个原始的架构变得不太适应当前的需求。为了提高 DNS 的可靠性、安全性和性能，目前这 13 个 IP 地址中的每一个都有多个服务器，截止到 2023 年底，所有根服务器之和达到了 1700 多台，未来还会继续增加。
### DNS 解析的过程是什么样的？
@@ -394,7 +476,7 @@ DNS 服务器自底向上可以依次分为以下几个层级(所有 DNS 服务
### DNS 劫持了解吗？如何应对？
-DNS 劫持是一种网络攻击，它通过修改 DNS 服务器的解析结果，使用户访问的域名指向错误的 IP 地址，从而导致用户无法访问正常的网站，或者被引导到恶意的网站。DNS 劫持有时也被称为 DNS 重定向、DNS 欺骗或 DNS 污染。DNS 劫持详细介绍可以参考：[黑客技术？没你想象的那么难！——DNS 劫持篇](https://cloud.tencent.com/developer/article/1197474)。
+DNS 劫持是一种网络攻击，它通过修改 DNS 服务器的解析结果，使用户访问的域名指向错误的 IP 地址，从而导致用户无法访问正常的网站，或者被引导到恶意的网站。DNS 劫持有时也被称为 DNS 重定向、DNS 欺骗或 DNS 污染。
## 参考
diff --git a/docs/cs-basics/network/other-network-questions2.md b/docs/cs-basics/network/other-network-questions2.md
index d5054865497..67c731f44c0 100644
--- a/docs/cs-basics/network/other-network-questions2.md
+++ b/docs/cs-basics/network/other-network-questions2.md
@@ -11,31 +11,61 @@ tag:
### TCP 与 UDP 的区别（重要）
-1. **是否面向连接**：UDP 在传送数据之前不需要先建立连接。而 TCP 提供面向连接的服务，在传送数据之前必须先建立连接，数据传送结束后要释放连接。
-2. **是否是可靠传输**：远地主机在收到 UDP 报文后，不需要给出任何确认，并且不保证数据不丢失，不保证是否顺序到达。TCP 提供可靠的传输服务，TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制。通过 TCP 连接传输的数据，无差错、不丢失、不重复、并且按序到达。
-3. **是否有状态**：这个和上面的“是否可靠传输”相对应。TCP 传输是有状态的，这个有状态说的是 TCP 会去记录自己发送消息的状态比如消息是否发送了、是否被接收了等等。为此 ，TCP 需要维持复杂的连接状态表。而 UDP 是无状态服务，简单来说就是不管发出去之后的事情了（**这很渣男！**）。
-4. **传输效率**：由于使用 TCP 进行传输的时候多了连接、确认、重传等机制，所以 TCP 的传输效率要比 UDP 低很多。
-5. **传输形式**：TCP 是面向字节流的，UDP 是面向报文的。
-6. **首部开销**：TCP 首部开销（20 ～ 60 字节）比 UDP 首部开销（8 字节）要大。
-7. **是否提供广播或多播服务**：TCP 只支持点对点通信，UDP 支持一对一、一对多、多对一、多对多；
+1. **是否面向连接**：
+ - TCP 是面向连接的。在传输数据之前，必须先通过“三次握手”建立连接；数据传输完成后，还需要通过“四次挥手”来释放连接。这保证了双方都准备好通信。
+ - UDP 是无连接的。发送数据前不需要建立任何连接，直接把数据包（数据报）扔出去。
+2. **是否是可靠传输**：
+ - TCP 提供可靠的数据传输服务。它通过序列号、确认应答 (ACK)、超时重传、流量控制、拥塞控制等一系列机制，来确保数据能够无差错、不丢失、不重复且按顺序地到达目的地。
+ - UDP 提供不可靠的传输。它尽最大努力交付 (best-effort delivery)，但不保证数据一定能到达，也不保证到达的顺序，更不会自动重传。收到报文后，接收方也不会主动发确认。
+3. **是否有状态**：
+ - TCP 是有状态的。因为要保证可靠性，TCP 需要在连接的两端维护连接状态信息，比如序列号、窗口大小、哪些数据发出去了、哪些收到了确认等。
+ - UDP 是无状态的。它不维护连接状态，发送方发出数据后就不再关心它是否到达以及如何到达，因此开销更小（**这很“渣男”！**）。
+4. **传输效率**：
+ - TCP 因为需要建立连接、发送确认、处理重传等，其开销较大，传输效率相对较低。
+ - UDP 结构简单，没有复杂的控制机制，开销小，传输效率更高，速度更快。
+5. **传输形式**：
+ - TCP 是面向字节流 (Byte Stream) 的。它将应用程序交付的数据视为一连串无结构的字节流，可能会对数据进行拆分或合并。
+ - UDP 是面向报文 (Message Oriented) 的。应用程序交给 UDP 多大的数据块，UDP 就照样发送，既不拆分也不合并，保留了应用程序消息的边界。
+6. **首部开销**：
+ - TCP 的头部至少需要 20 字节，如果包含选项字段，最多可达 60 字节。
+ - UDP 的头部非常简单，固定只有 8 字节。
+7. **是否提供广播或多播服务**：
+ - TCP 只支持点对点 (Point-to-Point) 的单播通信。
+ - UDP 支持一对一 (单播)、一对多 (多播/Multicast) 和一对所有 (广播/Broadcast) 的通信方式。
8. ……
-我把上面总结的内容通过表格形式展示出来了！确定不点个赞嘛？
+为了更直观地对比，可以看下面这个表格：
-| | TCP | UDP |
-| ---------------------- | -------------- | ---------- |
-| 是否面向连接 | 是 | 否 |
-| 是否可靠 | 是 | 否 |
-| 是否有状态 | 是 | 否 |
-| 传输效率 | 较慢 | 较快 |
-| 传输形式 | 字节流 | 数据报文段 |
-| 首部开销 | 20 ～ 60 bytes | 8 bytes |
-| 是否提供广播或多播服务 | 否 | 是 |
+| 特性 | TCP | UDP |
+| ------------ | -------------------------- | ----------------------------------- |
+| **连接性** | 面向连接 | 无连接 |
+| **可靠性** | 可靠 | 不可靠 (尽力而为) |
+| **状态维护** | 有状态 | 无状态 |
+| **传输效率** | 较低 | 较高 |
+| **传输形式** | 面向字节流 | 面向数据报 (报文) |
+| **头部开销** | 20 - 60 字节 | 8 字节 |
+| **通信模式** | 点对点 (单播) | 单播、多播、广播 |
+| **常见应用** | HTTP/HTTPS, FTP, SMTP, SSH | DNS, DHCP, SNMP, TFTP, VoIP, 视频流 |
### 什么时候选择 TCP，什么时候选 UDP?
-- **UDP 一般用于即时通信**，比如：语音、 视频、直播等等。这些场景对传输数据的准确性要求不是特别高，比如你看视频即使少个一两帧，实际给人的感觉区别也不大。
-- **TCP 用于对传输准确性要求特别高的场景**，比如文件传输、发送和接收邮件、远程登录等等。
+选择 TCP 还是 UDP，主要取决于你的应用**对数据传输的可靠性要求有多高，以及对实时性和效率的要求有多高**。
+
+当**数据准确性和完整性至关重要，一点都不能出错**时，通常选择 TCP。因为 TCP 提供了一整套机制（三次握手、确认应答、重传、流量控制等）来保证数据能够可靠、有序地送达。典型应用场景如下：
+
+- **Web 浏览 (HTTP/HTTPS):** 网页内容、图片、脚本必须完整加载才能正确显示。
+- **文件传输 (FTP, SCP):** 文件内容不允许有任何字节丢失或错序。
+- **邮件收发 (SMTP, POP3, IMAP):** 邮件内容需要完整无误地送达。
+- **远程登录 (SSH, Telnet):** 命令和响应需要准确传输。
+- ......
+
+当**实时性、速度和效率优先，并且应用能容忍少量数据丢失或乱序**时，通常选择 UDP。UDP 开销小、传输快，没有建立连接和保证可靠性的复杂过程。典型应用场景如下：
+
+- **实时音视频通信 (VoIP, 视频会议, 直播):** 偶尔丢失一两个数据包（可能导致画面或声音短暂卡顿）通常比因为等待重传（TCP 机制）导致长时间延迟更可接受。应用层可能会有自己的补偿机制。
+- **在线游戏:** 需要快速传输玩家位置、状态等信息，对实时性要求极高，旧的数据很快就没用了，丢失少量数据影响通常不大。
+- **DHCP (动态主机配置协议):** 客户端在请求 IP 时自身没有 IP 地址，无法满足 TCP 建立连接的前提条件，并且 DHCP 有广播需求、交互模式简单以及自带可靠性机制。
+- **物联网 (IoT) 数据上报:** 某些场景下，传感器定期上报数据，丢失个别数据点可能不影响整体趋势分析。
+- ......
### HTTP 基于 TCP 还是 UDP？
@@ -43,9 +73,21 @@ tag:
🐛 修正（参见 [issue#1915](https://github.com/Snailclimb/JavaGuide/issues/1915)）：
-HTTP/3.0 之前是基于 TCP 协议的，而 HTTP/3.0 将弃用 TCP，改用 **基于 UDP 的 QUIC 协议** 。
+HTTP/3.0 之前是基于 TCP 协议的，而 HTTP/3.0 将弃用 TCP，改用 **基于 UDP 的 QUIC 协议** ：
+
+- **HTTP/1.x 和 HTTP/2.0**：这两个版本的 HTTP 协议都明确建立在 TCP 之上。TCP 提供了可靠的、面向连接的传输，确保数据按序、无差错地到达，这对于网页内容的正确展示非常重要。发送 HTTP 请求前，需要先通过 TCP 的三次握手建立连接。
+- **HTTP/3.0**：这是一个重大的改变。HTTP/3 弃用了 TCP，转而使用 QUIC 协议，而 QUIC 是构建在 UDP 之上的。
+
+
+
+**为什么 HTTP/3 要做这个改变呢？主要有两大原因：**
-此变化解决了 HTTP/2 中存在的队头阻塞问题。队头阻塞是指在 HTTP/2.0 中，多个 HTTP 请求和响应共享一个 TCP 连接，如果其中一个请求或响应因为网络拥塞或丢包而被阻塞，那么后续的请求或响应也无法发送，导致整个连接的效率降低。这是由于 HTTP/2.0 在单个 TCP 连接上使用了多路复用，受到 TCP 拥塞控制的影响，少量的丢包就可能导致整个 TCP 连接上的所有流被阻塞。HTTP/3.0 在一定程度上解决了队头阻塞问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。
+1. 解决队头阻塞 (Head-of-Line Blocking，简写：HOL blocking) 问题。
+2. 减少连接建立的延迟。
+
+下面我们来详细介绍这两大优化。
+
+在 HTTP/2 中，虽然可以在一个 TCP 连接上并发传输多个请求/响应流（多路复用），但 TCP 本身的特性（保证有序、可靠）意味着如果其中一个流的某个 TCP 报文丢失或延迟，整个 TCP 连接都会被阻塞，等待该报文重传。这会导致所有在这个 TCP 连接上的 HTTP/2 流都受到影响，即使其他流的数据包已经到达。**QUIC (运行在 UDP 上) 解决了这个问题**。QUIC 内部实现了自己的多路复用和流控制机制。不同的 HTTP 请求/响应流在 QUIC 层面是真正独立的。如果一个流的数据包丢失，它只会阻塞该流，而不会影响同一 QUIC 连接上的其他流（本质上是多路复用+轮询），大大提高了并发传输的效率。
除了解决队头阻塞问题，HTTP/3.0 还可以减少握手过程的延迟。在 HTTP/2.0 中，如果要建立一个安全的 HTTPS 连接，需要经过 TCP 三次握手和 TLS 握手：
@@ -59,25 +101,40 @@ HTTP/3.0 之前是基于 TCP 协议的，而 HTTP/3.0 将弃用 TCP，改用 **
-
-
+- 从一次线上问题说起，详解 TCP 半连接队列、全连接队列：
+
diff --git a/docs/cs-basics/network/the-whole-process-of-accessing-web-pages.md b/docs/cs-basics/network/the-whole-process-of-accessing-web-pages.md
index c09c10e6ab8..906d16fae2e 100644
--- a/docs/cs-basics/network/the-whole-process-of-accessing-web-pages.md
+++ b/docs/cs-basics/network/the-whole-process-of-accessing-web-pages.md
@@ -5,7 +5,7 @@ tag:
- 计算机网络
---
-开发岗中总是会考很多计算机网络的知识点，但如果让面试官只靠一道题，便涵盖最多的计网知识点，那可能就是 **网页浏览的全过程** 了。本篇文章将带大家从头到尾过一遍这道被考烂的面试题，必会！！！
+开发岗中总是会考很多计算机网络的知识点，但如果让面试官只考一道题，便涵盖最多的计网知识点，那可能就是 **网页浏览的全过程** 了。本篇文章将带大家从头到尾过一遍这道被考烂的面试题，必会！！！
总的来说，网络通信模型可以用下图来表示，也就是大家只要熟记网络结构五层模型，按照这个体系，很多知识点都能顺出来了。访问网页的过程也是如此。
@@ -76,4 +76,4 @@ TCP 协议保证了数据传输的可靠性，是数据包传输的主力协议
- 转发：将分组从路由器的输入端口转移到合适的输出端口。
- 路由：确定分组从源到目的经过的路径。
-所以到目前为止，我们的数据包经过了应用层、传输层的封装，来到了网络层，终于开始准备在物理层面传输了，第一个要解决的问题就是——**往哪里传输？或者说，要把数据包发到哪个路由器上？**这便是 BGP 协议要解决的问题。
+所以到目前为止，我们的数据包经过了应用层、传输层的封装，来到了网络层，终于开始准备在物理层面传输了，第一个要解决的问题就是——**往哪里传输？或者说，要把数据包发到哪个路由器上？** 这便是 BGP 协议要解决的问题。
diff --git a/docs/cs-basics/operating-system/linux-intro.md b/docs/cs-basics/operating-system/linux-intro.md
index ead135776cc..1486fe45c90 100644
--- a/docs/cs-basics/operating-system/linux-intro.md
+++ b/docs/cs-basics/operating-system/linux-intro.md
@@ -70,7 +70,7 @@ inode 是 Linux/Unix 文件系统的基础。那 inode 到是什么?有什么作
通过以下五点可以概括 inode 到底是什么：
-1. 硬盘的最小存储单位是扇区(Sector)，块(block)由多个扇区组成。文件数据存储在块中。块的最常见的大小是 4kb，约为 8 个连续的扇区组成（每个扇区存储 512 字节）。一个文件可能会占用多个 block，但是一个块只能存放一个文件。虽然，我们将文件存储在了块(block)中，但是我们还需要一个空间来存储文件的 **元信息 metadata**：如某个文件被分成几块、每一块在的地址、文件拥有者，创建时间，权限，大小等。这种 **存储文件元信息的区域就叫 inode**，译为索引节点：**i（index）+node**。 **每个文件都有一个唯一的 inode，存储文件的元信息。**
+1. 硬盘以扇区 (Sector) 为最小物理存储单位，而操作系统和文件系统以块 (Block) 为单位进行读写，块由多个扇区组成。文件数据存储在这些块中。现代硬盘扇区通常为 4KB，与一些常见块大小相同，但操作系统也支持更大的块大小，以提升大文件读写性能。文件元信息（例如权限、大小、修改时间以及数据块位置）存储在 inode（索引节点）中。每个文件都有唯一的 inode。inode 本身不存储文件数据，而是存储指向数据块的指针，操作系统通过这些指针找到并读取文件数据。 固态硬盘 (SSD) 虽然没有物理扇区，但使用逻辑块，其概念与传统硬盘的块类似。
2. inode 是一种固定大小的数据结构，其大小在文件系统创建时就确定了，并且在文件的生命周期内保持不变。
3. inode 的访问速度非常快，因为系统可以直接通过 inode 号码定位到文件的元数据信息，无需遍历整个文件系统。
4. inode 的数量是有限的，每个文件系统只能包含固定数量的 inode。这意味着当文件系统中的 inode 用完时，无法再创建新的文件或目录，即使磁盘上还有可用空间。因此，在创建文件系统时，需要根据文件和目录的预期数量来合理分配 inode 的数量。
@@ -185,8 +185,8 @@ Linux 使用一种称为目录树的层次结构来组织文件和目录。目
### 目录操作
- `ls`：显示目录中的文件和子目录的列表。例如：`ls /home`，显示 `/home` 目录下的文件和子目录列表。
-- `ll`：`ll` 是 `ls -l` 的别名，ll 命令可以看到该目录下的所有目录和文件的详细信息
-- `mkdir [选项] 目录名`：创建新目录（增）。例如：`mkdir -m 755 my_directory`，创建一个名为 `my_directory` 的新目录，并将其权限设置为 755，即所有用户对该目录有读、写和执行的权限。
+- `ll`：`ll` 是 `ls -l` 的别名，ll 命令可以看到该目录下的所有目录和文件的详细信息。
+- `mkdir [选项] 目录名`：创建新目录（增）。例如：`mkdir -m 755 my_directory`，创建一个名为 `my_directory` 的新目录，并将其权限设置为 755，其中所有者拥有读、写、执行权限，所属组和其他用户只有读、执行权限，无法修改目录内容（如创建或删除文件）。如果希望所有用户（包括所属组和其他用户）对目录都拥有读、写、执行权限，则应设置权限为 `777`，即：`mkdir -m 777 my_directory`。
- `find [路径] [表达式]`：在指定目录及其子目录中搜索文件或目录（查），非常强大灵活。例如：① 列出当前目录及子目录下所有文件和文件夹: `find .`；② 在`/home`目录下查找以 `.txt` 结尾的文件名:`find /home -name "*.txt"` ,忽略大小写: `find /home -i name "*.txt"` ；③ 当前目录及子目录下查找所有以 `.txt` 和 `.pdf` 结尾的文件:`find . \( -name "*.txt" -o -name "*.pdf" \)`或`find . -name "*.txt" -o -name "*.pdf"`。
- `pwd`：显示当前工作目录的路径。
- `rmdir [选项] 目录名`：删除空目录（删）。例如：`rmdir -p my_directory`，删除名为 `my_directory` 的空目录，并且会递归删除`my_directory`的空父目录，直到遇到非空目录或根目录。
@@ -355,6 +355,8 @@ Linux 系统是一个多用户多任务的分时操作系统，任何一个要
- `ifconfig` 或 `ip`：用于查看系统的网络接口信息，包括网络接口的 IP 地址、MAC 地址、状态等。
- `netstat [选项]`：用于查看系统的网络连接状态和网络统计信息，可以查看当前的网络连接情况、监听端口、网络协议等。
- `ss [选项]`：比 `netstat` 更好用，提供了更快速、更详细的网络连接信息。
+- `nload`：`sar` 和 `nload` 都可以监控网络流量，但`sar` 的输出是文本形式的数据，不够直观。`nload` 则是一个专门用于实时监控网络流量的工具，提供图形化的终端界面，更加直观。不过，`nload` 不保存历史数据，所以它不适合用于长期趋势分析。并且，系统并没有默认安装它，需要手动安装。
+- `sudo hostnamectl set-hostname 新主机名`:更改主机名，并且重启后依然有效。`sudo hostname 新主机名`也可以更改主机名。不过需要注意的是，使用 `hostname` 命令直接更改主机名只是临时生效，系统重启后会恢复为原来的主机名。
### 其他
diff --git a/docs/cs-basics/operating-system/operating-system-basic-questions-01.md b/docs/cs-basics/operating-system/operating-system-basic-questions-01.md
index 1693a59a74c..db7fb7bfa23 100644
--- a/docs/cs-basics/operating-system/operating-system-basic-questions-01.md
+++ b/docs/cs-basics/operating-system/operating-system-basic-questions-01.md
@@ -151,7 +151,7 @@ _玩玩电脑游戏还是必须要有 Windows 的，所以我现在是一台 Win
1. 用户态的程序发起系统调用，因为系统调用中涉及一些特权指令（只能由操作系统内核态执行的指令），用户态程序权限不足，因此会中断执行，也就是 Trap（Trap 是一种中断）。
2. 发生中断后，当前 CPU 执行的程序会中断，跳转到中断处理程序。内核程序开始执行，也就是开始处理系统调用。
-3. 内核处理完成后，主动触发 Trap，这样会再次发生中断，切换回用户态工作。
+3. 当系统调用处理完成后，操作系统使用特权指令（如 `iret`、`sysret` 或 `eret`）切换回用户态，恢复用户态的上下文，继续执行用户程序。
@@ -201,10 +201,10 @@ _玩玩电脑游戏还是必须要有 Windows 的，所以我现在是一台 Win
下面是几种常见的线程同步的方式：
-1. **互斥锁(Mutex)**：采用互斥对象机制，只有拥有互斥对象的线程才有访问公共资源的权限。因为互斥对象只有一个，所以可以保证公共资源不会被多个线程同时访问。比如 Java 中的 `synchronized` 关键词和各种 `Lock` 都是这种机制。
-2. **读写锁（Read-Write Lock）**：允许多个线程同时读取共享资源，但只有一个线程可以对共享资源进行写操作。
-3. **信号量(Semaphore)**：它允许同一时刻多个线程访问同一资源，但是需要控制同一时刻访问此资源的最大线程数量。
-4. **屏障（Barrier）**：屏障是一种同步原语，用于等待多个线程到达某个点再一起继续执行。当一个线程到达屏障时，它会停止执行并等待其他线程到达屏障，直到所有线程都到达屏障后，它们才会一起继续执行。比如 Java 中的 `CyclicBarrier` 是这种机制。
+1. **互斥锁(Mutex)** ：采用互斥对象机制，只有拥有互斥对象的线程才有访问公共资源的权限。因为互斥对象只有一个，所以可以保证公共资源不会被多个线程同时访问。比如 Java 中的 `synchronized` 关键词和各种 `Lock` 都是这种机制。
+2. **读写锁（Read-Write Lock）** ：允许多个线程同时读取共享资源，但只有一个线程可以对共享资源进行写操作。
+3. **信号量(Semaphore)** ：它允许同一时刻多个线程访问同一资源，但是需要控制同一时刻访问此资源的最大线程数量。
+4. **屏障（Barrier）** ：屏障是一种同步原语，用于等待多个线程到达某个点再一起继续执行。当一个线程到达屏障时，它会停止执行并等待其他线程到达屏障，直到所有线程都到达屏障后，它们才会一起继续执行。比如 Java 中的 `CyclicBarrier` 是这种机制。
5. **事件(Event)** :Wait/Notify：通过通知操作的方式来保持多线程同步，还可以方便的实现多线程优先级的比较操作。
### PCB 是什么？包含哪些信息？
@@ -238,12 +238,12 @@ PCB 主要包含下面几部分的内容：
> 下面这部分总结参考了:[《进程间通信 IPC (InterProcess Communication)》](https://www.jianshu.com/p/c1015f5ffa74) 这篇文章，推荐阅读，总结的非常不错。
-1. **管道/匿名管道(Pipes)**：用于具有亲缘关系的父子进程间或者兄弟进程之间的通信。
+1. **管道/匿名管道(Pipes)** ：用于具有亲缘关系的父子进程间或者兄弟进程之间的通信。
2. **有名管道(Named Pipes)** : 匿名管道由于没有名字，只能用于亲缘关系的进程间通信。为了克服这个缺点，提出了有名管道。有名管道严格遵循 **先进先出(First In First Out)** 。有名管道以磁盘文件的方式存在，可以实现本机任意两个进程通信。
-3. **信号(Signal)**：信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生；
-4. **消息队列(Message Queuing)**：消息队列是消息的链表,具有特定的格式,存放在内存中并由消息队列标识符标识。管道和消息队列的通信数据都是先进先出的原则。与管道（无名管道：只存在于内存中的文件；命名管道：存在于实际的磁盘介质或者文件系统）不同的是消息队列存放在内核中，只有在内核重启(即，操作系统重启)或者显式地删除一个消息队列时，该消息队列才会被真正的删除。消息队列可以实现消息的随机查询,消息不一定要以先进先出的次序读取,也可以按消息的类型读取.比 FIFO 更有优势。**消息队列克服了信号承载信息量少，管道只能承载无格式字 节流以及缓冲区大小受限等缺点。**
-5. **信号量(Semaphores)**：信号量是一个计数器，用于多进程对共享数据的访问，信号量的意图在于进程间同步。这种通信方式主要用于解决与同步相关的问题并避免竞争条件。
-6. **共享内存(Shared memory)**：使得多个进程可以访问同一块内存空间，不同进程可以及时看到对方进程中对共享内存中数据的更新。这种方式需要依靠某种同步操作，如互斥锁和信号量等。可以说这是最有用的进程间通信方式。
+3. **信号(Signal)** ：信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生；
+4. **消息队列(Message Queuing)** ：消息队列是消息的链表,具有特定的格式,存放在内存中并由消息队列标识符标识。管道和消息队列的通信数据都是先进先出的原则。与管道（无名管道：只存在于内存中的文件；命名管道：存在于实际的磁盘介质或者文件系统）不同的是消息队列存放在内核中，只有在内核重启(即，操作系统重启)或者显式地删除一个消息队列时，该消息队列才会被真正的删除。消息队列可以实现消息的随机查询,消息不一定要以先进先出的次序读取,也可以按消息的类型读取.比 FIFO 更有优势。消息队列克服了信号承载信息量少，管道只能承载无格式字 节流以及缓冲区大小受限等缺点。
+5. **信号量(Semaphores)** ：信号量是一个计数器，用于多进程对共享数据的访问，信号量的意图在于进程间同步。这种通信方式主要用于解决与同步相关的问题并避免竞争条件。
+6. **共享内存(Shared memory)** ：使得多个进程可以访问同一块内存空间，不同进程可以及时看到对方进程中对共享内存中数据的更新。这种方式需要依靠某种同步操作，如互斥锁和信号量等。可以说这是最有用的进程间通信方式。
7. **套接字(Sockets)** : 此方法主要用于在客户端和服务器之间通过网络进行通信。套接字是支持 TCP/IP 的网络通信的基本操作单元，可以看做是不同主机之间的进程进行双向通信的端点，简单的说就是通信的两方的一种约定，用套接字中的相关函数来完成通信过程。
### 进程的调度算法有哪些?
@@ -255,7 +255,7 @@ PCB 主要包含下面几部分的内容：
- **先到先服务调度算法(FCFS，First Come, First Served)** : 从就绪队列中选择一个最先进入该队列的进程为之分配资源，使它立即执行并一直执行到完成或发生某事件而被阻塞放弃占用 CPU 时再重新调度。
- **短作业优先的调度算法(SJF，Shortest Job First)** : 从就绪队列中选出一个估计运行时间最短的进程为之分配资源，使它立即执行并一直执行到完成或发生某事件而被阻塞放弃占用 CPU 时再重新调度。
- **时间片轮转调度算法（RR，Round-Robin）** : 时间片轮转调度是一种最古老，最简单，最公平且使用最广的算法。每个进程被分配一个时间段，称作它的时间片，即该进程允许运行的时间。
-- **多级反馈队列调度算法（MFQ，Multi-level Feedback Queue）**：前面介绍的几种进程调度的算法都有一定的局限性。如**短进程优先的调度算法，仅照顾了短进程而忽略了长进程** 。多级反馈队列调度算法既能使高优先级的作业得到响应又能使短作业（进程）迅速完成。，因而它是目前**被公认的一种较好的进程调度算法**，UNIX 操作系统采取的便是这种调度算法。
+- **多级反馈队列调度算法（MFQ，Multi-level Feedback Queue）**：前面介绍的几种进程调度的算法都有一定的局限性。如**短进程优先的调度算法，仅照顾了短进程而忽略了长进程** 。多级反馈队列调度算法既能使高优先级的作业得到响应又能使短作业（进程）迅速完成，因而它是目前**被公认的一种较好的进程调度算法**，UNIX 操作系统采取的便是这种调度算法。
- **优先级调度算法（Priority）**：为每个流程分配优先级，首先执行具有最高优先级的进程，依此类推。具有相同优先级的进程以 FCFS 方式执行。可以根据内存要求，时间要求或任何其他资源要求来确定优先级。
### 什么是僵尸进程和孤儿进程？
@@ -424,7 +424,7 @@ Thread[线程 2,5,main]waiting get resource1
操作系统中的每一刻时刻的**系统状态**都可以用**进程-资源分配图**来表示，进程-资源分配图是描述进程和资源申请及分配关系的一种有向图，可用于**检测系统是否处于死锁状态**。
-用一个方框表示每一个资源类，方框中的黑点表示该资源类中的各个资源，每个键进程用一个圆圈表示，用 **有向边** 来表示**进程申请资源和资源被分配的情况**。
+用一个方框表示每一个资源类，方框中的黑点表示该资源类中的各个资源，用一个圆圈表示每一个进程，用 **有向边** 来表示**进程申请资源和资源被分配的情况**。
图中 2-21 是**进程-资源分配图**的一个例子，其中共有三个资源类，每个进程的资源占有和申请情况已清楚地表示在图中。在这个例子中，由于存在 **占有和等待资源的环路** ，导致一组进程永远处于等待资源的状态，发生了 **死锁**。
diff --git a/docs/cs-basics/operating-system/operating-system-basic-questions-02.md b/docs/cs-basics/operating-system/operating-system-basic-questions-02.md
index f35fb948701..1d3fc0968bd 100644
--- a/docs/cs-basics/operating-system/operating-system-basic-questions-02.md
+++ b/docs/cs-basics/operating-system/operating-system-basic-questions-02.md
@@ -68,7 +68,7 @@ head:
非连续内存管理存在下面 3 种方式：
-- **段式管理**：以段(—段连续的物理内存)的形式管理/分配物理内存。应用程序的虚拟地址空间被分为大小不等的段，段是有实际意义的，每个段定义了一组逻辑信息，例如有主程序段 MAIN、子程序段 X、数据段 D 及栈段 S 等。
+- **段式管理**：以段(一段连续的物理内存)的形式管理/分配物理内存。应用程序的虚拟地址空间被分为大小不等的段，段是有实际意义的，每个段定义了一组逻辑信息，例如有主程序段 MAIN、子程序段 X、数据段 D 及栈段 S 等。
- **页式管理**：把物理内存分为连续等长的物理页，应用程序的虚拟地址空间也被划分为连续等长的虚拟页，是现代操作系统广泛使用的一种内存管理方式。
- **段页式管理机制**：结合了段式管理和页式管理的一种内存管理机制，把物理内存先分成若干段，每个段又继续分成若干大小相等的页。
@@ -131,7 +131,7 @@ MMU 将虚拟地址翻译为物理地址的主要机制有 3 种:
### 分段机制
-**分段机制（Segmentation）** 以段(—段 **连续** 的物理内存)的形式管理/分配物理内存。应用程序的虚拟地址空间被分为大小不等的段，段是有实际意义的，每个段定义了一组逻辑信息，例如有主程序段 MAIN、子程序段 X、数据段 D 及栈段 S 等。
+**分段机制（Segmentation）** 以段(一段 **连续** 的物理内存)的形式管理/分配物理内存。应用程序的虚拟地址空间被分为大小不等的段，段是有实际意义的，每个段定义了一组逻辑信息，例如有主程序段 MAIN、子程序段 X、数据段 D 及栈段 S 等。
#### 段表有什么用？地址翻译过程是怎样的？
@@ -188,7 +188,7 @@ MMU 将虚拟地址翻译为物理地址的主要机制有 3 种:
-在分页机制下，每个应用程序都会有一个对应的页表。
+在分页机制下，每个进程都会有一个对应的页表。
分页机制下的虚拟地址由两部分组成：
@@ -215,7 +215,7 @@ MMU 将虚拟地址翻译为物理地址的主要机制有 3 种:
系统运行的应用程序多起来的话，页表的开销还是非常大的。而且，绝大部分应用程序可能只能用到页表中的几项，其他的白白浪费了。
-为了解决这个问题，操作系统引入了 **多级页表** ，多级页表对应多个页表，每个页表也前一个页表相关联。32 位系统一般为二级页表，64 位系统一般为四级页表。
+为了解决这个问题，操作系统引入了 **多级页表** ，多级页表对应多个页表，每个页表与前一个页表相关联。32 位系统一般为二级页表，64 位系统一般为四级页表。
这里以二级页表为例进行介绍：二级列表分为一级页表和二级页表。一级页表共有 1024 个页表项，一级页表又关联二级页表，二级页表同样共有 1024 个页表项。二级页表中的一级页表项是一对多的关系，二级页表按需加载（只会用到很少一部分二级页表），进而节省空间占用。
@@ -282,7 +282,7 @@ TLB 的设计思想非常简单，但命中率往往非常高，效果很好。
1. **最佳页面置换算法（OPT，Optimal）**：优先选择淘汰的页面是以后永不使用的，或者是在最长时间内不再被访问的页面，这样可以保证获得最低的缺页率。但由于人们目前无法预知进程在内存下的若干页面中哪个是未来最长时间内不再被访问的，因而该算法无法实现，只是理论最优的页面置换算法，可以作为衡量其他置换算法优劣的标准。
-2. **先进先出页面置换算法（FIFO，First In First Out）** : 最简单的一种页面置换算法，总是淘汰最先进入内存的页面，即选择在内存中驻留时间最久的页面进行淘汰。该算法易于实现和理解，一般只需要通过一个 FIFO 队列即可需求。不过，它的性能并不是很好。
+2. **先进先出页面置换算法（FIFO，First In First Out）** : 最简单的一种页面置换算法，总是淘汰最先进入内存的页面，即选择在内存中驻留时间最久的页面进行淘汰。该算法易于实现和理解，一般只需要通过一个 FIFO 队列即可满足需求。不过，它的性能并不是很好。
3. **最近最久未使用页面置换算法（LRU ，Least Recently Used）**：LRU 算法赋予每个页面一个访问字段，用来记录一个页面自上次被访问以来所经历的时间 T，当须淘汰一个页面时，选择现有页面中其 T 值最大的，即最近最久未使用的页面予以淘汰。LRU 算法是根据各页之前的访问情况来实现，因此是易于实现的。OPT 算法是根据各页未来的访问情况来实现，因此是不可实现的。
4. **最少使用页面置换算法（LFU，Least Frequently Used）** : 和 LRU 算法比较像，不过该置换算法选择的是之前一段时间内使用最少的页面作为淘汰页。
5. **时钟页面置换算法（Clock）**：可以认为是一种最近未使用算法，即逐出的页面都是最近没有使用的那个。
@@ -317,12 +317,16 @@ LRU 算法是实际使用中应用的比较多，也被认为是最接近 OPT
### 段页机制
-结合了段式管理和页式管理的一种内存管理机制，把物理内存先分成若干段，每个段又继续分成若干大小相等的页。
+结合了段式管理和页式管理的一种内存管理机制。程序视角中，内存被划分为多个逻辑段，每个逻辑段进一步被划分为固定大小的页。
在段页式机制下，地址翻译的过程分为两个步骤：
-1. 段式地址映射。
-2. 页式地址映射。
+1. **段式地址映射（虚拟地址 → 线性地址）：**
+ - 虚拟地址 = 段选择符（段号）+ 段内偏移。
+ - 根据段号查段表，找到段基址，加上段内偏移得到线性地址。
+2. **页式地址映射（线性地址 → 物理地址）：**
+ - 线性地址 = 页号 + 页内偏移。
+ - 根据页号查页表，找到物理页框号，加上页内偏移得到物理地址。
### 局部性原理
diff --git a/docs/database/basis.md b/docs/database/basis.md
index 4afcece5ab1..1df5d538fb8 100644
--- a/docs/database/basis.md
+++ b/docs/database/basis.md
@@ -86,8 +86,8 @@ ER 图由下面 3 个要素组成：
为什么不要用外键呢？大部分人可能会这样回答：
-1. **增加了复杂性：** a. 每次做 DELETE 或者 UPDATE 都必须考虑外键约束，会导致开发的时候很痛苦, 测试数据极为不方便; b. 外键的主从关系是定的，假如那天需求有变化，数据库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦。
-2. **增加了额外工作**：数据库需要增加维护外键的工作，比如当我们做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，保证数据的的一致性和正确性，这样会不得不消耗资源；（个人觉得这个不是不用外键的原因，因为即使你不使用外键，你在应用层面也还是要保证的。所以，我觉得这个影响可以忽略不计。）
+1. **增加了复杂性：** a. 每次做 DELETE 或者 UPDATE 都必须考虑外键约束，会导致开发的时候很痛苦, 测试数据极为不方便; b. 外键的主从关系是定的，假如哪天需求有变化，数据库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦。
+2. **增加了额外工作**：数据库需要增加维护外键的工作，比如当我们做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，保证数据的的一致性和正确性，这样会不得不消耗数据库资源。如果在应用层面去维护的话，可以减小数据库压力；
3. **对分库分表不友好**：因为分库分表下外键是无法生效的。
4. ……
diff --git a/docs/database/mongodb/mongodb-questions-01.md b/docs/database/mongodb/mongodb-questions-01.md
index 860b1f2b248..81b7db98890 100644
--- a/docs/database/mongodb/mongodb-questions-01.md
+++ b/docs/database/mongodb/mongodb-questions-01.md
@@ -149,7 +149,7 @@ WiredTiger maintains a table's data in memory using a data structure called a B-
此外，WiredTiger 还支持 [LSM(Log Structured Merge)](https://source.wiredtiger.com/3.1.0/lsm.html) 树作为存储结构，MongoDB 在使用 WiredTiger 作为存储引擎时，默认使用的是 B+ 树。
-如果想要了解 MongoDB 使用 B 树的原因，可以看看这篇文章：[为什么 MongoDB 使用 B 树？](https://mp.weixin.qq.com/s/mMWdpbYRiT6LQcdaj4hgXQ)。
+如果想要了解 MongoDB 使用 B+ 树的原因，可以看看这篇文章：[【驳斥八股文系列】别瞎分析了，MongoDB 使用的是 B+ 树，不是你们以为的 B 树](https://zhuanlan.zhihu.com/p/519658576)。
使用 B+ 树时，WiredTiger 以 **page** 为基本单位往磁盘读写数据。B+ 树的每个节点为一个 page，共有三种类型的 page：
diff --git a/docs/database/mysql/a-thousand-lines-of-mysql-study-notes.md b/docs/database/mysql/a-thousand-lines-of-mysql-study-notes.md
index 42384aaec7e..cb30376687b 100644
--- a/docs/database/mysql/a-thousand-lines-of-mysql-study-notes.md
+++ b/docs/database/mysql/a-thousand-lines-of-mysql-study-notes.md
@@ -621,7 +621,7 @@ CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] VIEW view_name
### 锁表
-```mysql
+```sql
/* 锁表 */
表锁定只用于防止其它客户端进行不正当地读取和写入
MyISAM 支持表锁，InnoDB 支持行锁
@@ -633,7 +633,7 @@ MyISAM 支持表锁，InnoDB 支持行锁
### 触发器
-```mysql
+```sql
/* 触发器 */ ------------------
触发程序是与表有关的命名数据库对象，当该表出现特定事件时，将激活该对象
监听：记录的增加、修改、删除。
@@ -686,7 +686,7 @@ end
### SQL 编程
-```mysql
+```sql
/* SQL编程 */ ------------------
--// 局部变量 ----------
-- 变量声明
@@ -821,7 +821,7 @@ INOUT，表示混合型
### 存储过程
-```mysql
+```sql
/* 存储过程 */ ------------------
存储过程是一段可执行性代码的集合。相比函数，更偏向于业务逻辑。
调用：CALL 过程名
@@ -842,7 +842,7 @@ END
### 用户和权限管理
-```mysql
+```sql
/* 用户和权限管理 */ ------------------
-- root密码重置
1. 停止MySQL服务
@@ -924,7 +924,7 @@ GRANT OPTION -- 允许授予权限
### 表维护
-```mysql
+```sql
/* 表维护 */
-- 分析和存储表的关键字分布
ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE 表名 ...
@@ -937,7 +937,7 @@ OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...
### 杂项
-```mysql
+```sql
/* 杂项 */ ------------------
1. 可用反引号（`）为标识符（库名、表名、字段名、索引、别名）包裹，以避免与关键字重名！中文也可以作为标识符！
2. 每个库目录存在一个保存当前数据库的选项文件db.opt。
diff --git a/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md b/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md
index c402fcff3e8..38c333b3308 100644
--- a/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md
+++ b/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md
@@ -11,17 +11,17 @@ tag:
## 数据库命名规范
-- 所有数据库对象名称必须使用小写字母并用下划线分割
-- 所有数据库对象名称禁止使用 MySQL 保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来）
-- 数据库对象的命名要能做到见名识意，并且最后不要超过 32 个字符
-- 临时库表必须以 `tmp_` 为前缀并以日期为后缀，备份表必须以 `bak_` 为前缀并以日期 (时间戳) 为后缀
-- 所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低）
+- 所有数据库对象名称必须使用小写字母并用下划线分割。
+- 所有数据库对象名称禁止使用 MySQL 保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来）。
+- 数据库对象的命名要能做到见名识义，并且最好不要超过 32 个字符。
+- 临时库表必须以 `tmp_` 为前缀并以日期为后缀，备份表必须以 `bak_` 为前缀并以日期 (时间戳) 为后缀。
+- 所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低）。
## 数据库基本设计规范
### 所有表必须使用 InnoDB 存储引擎
-没有特殊要求（即 InnoDB 无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用 InnoDB 存储引擎（MySQL5.5 之前默认使用 Myisam，5.6 以后默认的为 InnoDB）。
+没有特殊要求（即 InnoDB 无法满足的功能如：列存储、存储空间数据等）的情况下，所有表必须使用 InnoDB 存储引擎（MySQL5.5 之前默认使用 MyISAM，5.6 以后默认的为 InnoDB）。
InnoDB 支持事务，支持行级锁，更好的恢复性，高并发下性能更好。
@@ -33,19 +33,19 @@ InnoDB 支持事务，支持行级锁，更好的恢复性，高并发下性能
### 所有表和字段都需要添加注释
-使用 comment 从句添加表和列的备注，从一开始就进行数据字典的维护
+使用 comment 从句添加表和列的备注，从一开始就进行数据字典的维护。
### 尽量控制单表数据量的大小，建议控制在 500 万以内
500 万并不是 MySQL 数据库的限制，过大会造成修改表结构，备份，恢复都会有很大的问题。
-可以用历史数据归档（应用于日志数据），分库分表（应用于业务数据）等手段来控制数据量大小
+可以用历史数据归档（应用于日志数据），分库分表（应用于业务数据）等手段来控制数据量大小。
### 谨慎使用 MySQL 分区表
-分区表在物理上表现为多个文件，在逻辑上表现为一个表；
+分区表在物理上表现为多个文件，在逻辑上表现为一个表。
-谨慎选择分区键，跨分区查询效率可能更低；
+谨慎选择分区键，跨分区查询效率可能更低。
建议采用物理分表的方式管理大数据。
@@ -71,7 +71,7 @@ InnoDB 支持事务，支持行级锁，更好的恢复性，高并发下性能
### 禁止在线上做数据库压力测试
-### 禁止从开发环境,测试环境直接连接生产环境数据库
+### 禁止从开发环境、测试环境直接连接生产环境数据库
安全隐患极大，要对生产环境抱有敬畏之心！
@@ -79,22 +79,22 @@ InnoDB 支持事务，支持行级锁，更好的恢复性，高并发下性能
### 优先选择符合存储需要的最小的数据类型
-存储字节越小，占用也就空间越小，性能也越好。
+存储字节越小，占用空间也就越小，性能也越好。
-**a.某些字符串可以转换成数字类型存储比如可以将 IP 地址转换成整型数据。**
+**a.某些字符串可以转换成数字类型存储，比如可以将 IP 地址转换成整型数据。**
数字是连续的，性能更好，占用空间也更小。
-MySQL 提供了两个方法来处理 ip 地址
+MySQL 提供了两个方法来处理 ip 地址：
-- `INET_ATON()`：把 ip 转为无符号整型 (4-8 位)
-- `INET_NTOA()` :把整型的 ip 转为地址
+- `INET_ATON()`：把 ip 转为无符号整型 (4-8 位)；
+- `INET_NTOA()`：把整型的 ip 转为地址。
-插入数据前，先用 `INET_ATON()` 把 ip 地址转为整型，显示数据时，使用 `INET_NTOA()` 把整型的 ip 地址转为地址显示即可。
+插入数据前，先用 `INET_ATON()` 把 ip 地址转为整型；显示数据时，使用 `INET_NTOA()` 把整型的 ip 地址转为地址显示即可。
-**b.对于非负型的数据 (如自增 ID,整型 IP，年龄) 来说,要优先使用无符号整型来存储。**
+**b.对于非负型的数据 (如自增 ID、整型 IP、年龄) 来说，要优先使用无符号整型来存储。**
-无符号相对于有符号可以多出一倍的存储空间
+无符号相对于有符号可以多出一倍的存储空间：
```sql
SIGNED INT -2147483648~2147483647
@@ -103,7 +103,7 @@ UNSIGNED INT 0~4294967295
**c.小数值类型（比如年龄、状态表示如 0/1）优先使用 TINYINT 类型。**
-### 避免使用 TEXT,BLOB 数据类型，最常见的 TEXT 类型可以存储 64k 的数据
+### 避免使用 TEXT、BLOB 数据类型，最常见的 TEXT 类型可以存储 64k 的数据
**a. 建议把 BLOB 或是 TEXT 列分离到单独的扩展表中。**
@@ -113,30 +113,30 @@ MySQL 内存临时表不支持 TEXT、BLOB 这样的大数据类型，如果查
**2、TEXT 或 BLOB 类型只能使用前缀索引**
-因为 MySQL 对索引字段长度是有限制的，所以 TEXT 类型只能使用前缀索引，并且 TEXT 列上是不能有默认值的
+因为 MySQL 对索引字段长度是有限制的，所以 TEXT 类型只能使用前缀索引，并且 TEXT 列上是不能有默认值的。
### 避免使用 ENUM 类型
-- 修改 ENUM 值需要使用 ALTER 语句；
-- ENUM 类型的 ORDER BY 操作效率低，需要额外操作；
-- ENUM 数据类型存在一些限制比如建议不要使用数值作为 ENUM 的枚举值。
+- 修改 ENUM 值需要使用 ALTER 语句。
+- ENUM 类型的 ORDER BY 操作效率低，需要额外操作。
+- ENUM 数据类型存在一些限制，比如建议不要使用数值作为 ENUM 的枚举值。
相关阅读：[是否推荐使用 MySQL 的 enum 类型？ - 架构文摘 - 知乎](https://www.zhihu.com/question/404422255/answer/1661698499) 。
### 尽可能把所有列定义为 NOT NULL
-除非有特别的原因使用 NULL 值，应该总是让字段保持 NOT NULL。
+除非有特别的原因使用 NULL 值，否则应该总是让字段保持 NOT NULL。
-- 索引 NULL 列需要额外的空间来保存，所以要占用更多的空间；
+- 索引 NULL 列需要额外的空间来保存，所以要占用更多的空间。
- 进行比较和计算时要对 NULL 值做特别的处理。
相关阅读：[技术分享 | MySQL 默认值选型（是空，还是 NULL）](https://opensource.actionsky.com/20190710-mysql/) 。
### 一定不要用字符串存储日期
-对于日期类型来说， 一定不要用字符串存储日期。可以考虑 DATETIME、TIMESTAMP 和 数值型时间戳。
+对于日期类型来说，一定不要用字符串存储日期。可以考虑 DATETIME、TIMESTAMP 和数值型时间戳。
-这三种种方式都有各自的优势，根据实际场景选择最合适的才是王道。下面再对这三种方式做一个简单的对比，以供大家实际开发中选择正确的存放时间的数据类型：
+这三种种方式都有各自的优势，根据实际场景选择最合适的才是王道。下面再对这三种方式做一个简单的对比，以供大家在实际开发中选择正确的存放时间的数据类型：
| 类型 | 存储空间 | 日期格式 | 日期范围 | 是否带时区信息 |
| ------------ | -------- | ------------------------------ | ------------------------------------------------------------ | -------------- |
@@ -148,10 +148,10 @@ MySQL 时间类型选择的详细介绍请看这篇：[MySQL 时间类型数据
### 同财务相关的金额类数据必须使用 decimal 类型
-- **非精准浮点**：float,double
+- **非精准浮点**：float、double
- **精准浮点**：decimal
-decimal 类型为精准浮点数，在计算时不会丢失精度。占用空间由定义的宽度决定，每 4 个字节可以存储 9 位数字，并且小数点要占用一个字节。并且，decimal 可用于存储比 bigint 更大的整型数据
+decimal 类型为精准浮点数，在计算时不会丢失精度。占用空间由定义的宽度决定，每 4 个字节可以存储 9 位数字，并且小数点要占用一个字节。并且，decimal 可用于存储比 bigint 更大的整型数据。
不过， 由于 decimal 需要额外的空间和计算开销，应该尽量只在需要对数据进行精确计算时才使用 decimal 。
@@ -161,13 +161,13 @@ decimal 类型为精准浮点数，在计算时不会丢失精度。占用空间
## 索引设计规范
-### 限制每张表上的索引数量,建议单张表索引不超过 5 个
+### 限制每张表上的索引数量，建议单张表索引不超过 5 个
-索引并不是越多越好！索引可以提高效率同样可以降低效率。
+索引并不是越多越好！索引可以提高效率，同样可以降低效率。
索引可以增加查询效率，但同样也会降低插入和更新的效率，甚至有些情况下会降低查询效率。
-因为 MySQL 优化器在选择如何优化查询时，会根据统一信息，对每一个可以用到的索引来进行评估，以生成出一个最好的执行计划，如果同时有很多个索引都可以用于查询，就会增加 MySQL 优化器生成执行计划的时间，同样会降低查询性能。
+因为 MySQL 优化器在选择如何优化查询时，会根据统一信息，对每一个可以用到的索引来进行评估，以生成出一个最好的执行计划。如果同时有很多个索引都可以用于查询，就会增加 MySQL 优化器生成执行计划的时间，同样会降低查询性能。
### 禁止使用全文索引
@@ -175,46 +175,46 @@ decimal 类型为精准浮点数，在计算时不会丢失精度。占用空间
### 禁止给表中的每一列都建立单独的索引
-5.6 版本之前，一个 sql 只能使用到一个表中的一个索引，5.6 以后，虽然有了合并索引的优化方式，但是还是远远没有使用一个联合索引的查询方式好。
+5.6 版本之前，一个 sql 只能使用到一个表中的一个索引；5.6 以后，虽然有了合并索引的优化方式，但是还是远远没有使用一个联合索引的查询方式好。
### 每个 InnoDB 表必须有个主键
InnoDB 是一种索引组织表：数据的存储的逻辑顺序和索引的顺序是相同的。每个表都可以有多个索引，但是表的存储顺序只能有一种。
-InnoDB 是按照主键索引的顺序来组织表的
+InnoDB 是按照主键索引的顺序来组织表的。
-- 不要使用更新频繁的列作为主键，不使用多列主键（相当于联合索引）
-- 不要使用 UUID,MD5,HASH,字符串列作为主键（无法保证数据的顺序增长）
-- 主键建议使用自增 ID 值
+- 不要使用更新频繁的列作为主键，不使用多列主键（相当于联合索引）。
+- 不要使用 UUID、MD5、HASH、字符串列作为主键（无法保证数据的顺序增长）。
+- 主键建议使用自增 ID 值。
### 常见索引列建议
-- 出现在 SELECT、UPDATE、DELETE 语句的 WHERE 从句中的列
-- 包含在 ORDER BY、GROUP BY、DISTINCT 中的字段
-- 并不要将符合 1 和 2 中的字段的列都建立一个索引， 通常将 1、2 中的字段建立联合索引效果更好
-- 多表 join 的关联列
+- 出现在 SELECT、UPDATE、DELETE 语句的 WHERE 从句中的列。
+- 包含在 ORDER BY、GROUP BY、DISTINCT 中的字段。
+- 不要将符合 1 和 2 中的字段的列都建立一个索引，通常将 1、2 中的字段建立联合索引效果更好。
+- 多表 join 的关联列。
### 如何选择索引列的顺序
-建立索引的目的是：希望通过索引进行数据查找，减少随机 IO，增加查询性能 ，索引能过滤出越少的数据，则从磁盘中读入的数据也就越少。
+建立索引的目的是：希望通过索引进行数据查找，减少随机 IO，增加查询性能，索引能过滤出越少的数据，则从磁盘中读入的数据也就越少。
-- 区分度最高的放在联合索引的最左侧（区分度=列中不同值的数量/列的总行数）
-- 尽量把字段长度小的列放在联合索引的最左侧（因为字段长度越小，一页能存储的数据量越大，IO 性能也就越好）
-- 使用最频繁的列放到联合索引的左侧（这样可以比较少的建立一些索引）
+- **区分度最高的列放在联合索引的最左侧**：这是最重要的原则。区分度越高，通过索引筛选出的数据就越少，I/O 操作也就越少。计算区分度的方法是 `count(distinct column) / count(*)`。
+- **最频繁使用的列放在联合索引的左侧**：这符合最左前缀匹配原则。将最常用的查询条件列放在最左侧，可以最大程度地利用索引。
+- **字段长度**：字段长度对联合索引非叶子节点的影响很小，因为它存储了所有联合索引字段的值。字段长度主要影响主键和包含在其他索引中的字段的存储空间，以及这些索引的叶子节点的大小。因此，在选择联合索引列的顺序时，字段长度的优先级最低。对于主键和包含在其他索引中的字段，选择较短的字段长度可以节省存储空间和提高 I/O 性能。
### 避免建立冗余索引和重复索引（增加了查询优化器生成执行计划的时间）
-- 重复索引示例：primary key(id)、index(id)、unique index(id)
-- 冗余索引示例：index(a,b,c)、index(a,b)、index(a)
+- 重复索引示例：primary key(id)、index(id)、unique index(id)。
+- 冗余索引示例：index(a,b,c)、index(a,b)、index(a)。
-### 对于频繁的查询优先考虑使用覆盖索引
+### 对于频繁的查询，优先考虑使用覆盖索引
-> 覆盖索引：就是包含了所有查询字段 (where,select,order by,group by 包含的字段) 的索引
+> 覆盖索引：就是包含了所有查询字段 (where、select、order by、group by 包含的字段) 的索引
-**覆盖索引的好处：**
+**覆盖索引的好处**：
-- **避免 InnoDB 表进行索引的二次查询，也就是回表操作:** InnoDB 是以聚集索引的顺序来存储的，对于 InnoDB 来说，二级索引在叶子节点中所保存的是行的主键信息，如果是用二级索引查询数据的话，在查找到相应的键值后，还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中，二级索引的键值中可以获取所有的数据，避免了对主键的二次查询（回表），减少了 IO 操作，提升了查询效率。
-- **可以把随机 IO 变成顺序 IO 加快查询效率:** 由于覆盖索引是按键值的顺序存储的，对于 IO 密集型的范围查找来说，对比随机从磁盘读取每一行的数据 IO 要少的多，因此利用覆盖索引在访问时也可以把磁盘的随机读取的 IO 转变成索引查找的顺序 IO。
+- **避免 InnoDB 表进行索引的二次查询，也就是回表操作**：InnoDB 是以聚集索引的顺序来存储的，对于 InnoDB 来说，二级索引在叶子节点中所保存的是行的主键信息，如果是用二级索引查询数据的话，在查找到相应的键值后，还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中，二级索引的键值中可以获取所有的数据，避免了对主键的二次查询（回表），减少了 IO 操作，提升了查询效率。
+- **可以把随机 IO 变成顺序 IO 加快查询效率**：由于覆盖索引是按键值的顺序存储的，对于 IO 密集型的范围查找来说，对比随机从磁盘读取每一行的数据 IO 要少的多，因此利用覆盖索引在访问时也可以把磁盘的随机读取的 IO 转变成索引查找的顺序 IO。
---
@@ -222,9 +222,9 @@ InnoDB 是按照主键索引的顺序来组织表的
**尽量避免使用外键约束**
-- 不建议使用外键约束（foreign key），但一定要在表与表之间的关联键上建立索引
-- 外键可用于保证数据的参照完整性，但建议在业务端实现
-- 外键会影响父表和子表的写操作从而降低性能
+- 不建议使用外键约束（foreign key），但一定要在表与表之间的关联键上建立索引。
+- 外键可用于保证数据的参照完整性，但建议在业务端实现。
+- 外键会影响父表和子表的写操作从而降低性能。
## 数据库 SQL 开发规范
@@ -238,7 +238,7 @@ InnoDB 是按照主键索引的顺序来组织表的
### 充分利用表上已经存在的索引
-避免使用双%号的查询条件。如：`a like '%123%'`，（如果无前置%,只有后置%，是可以用到列上的索引的）
+避免使用双%号的查询条件。如：`a like '%123%'`（如果无前置%,只有后置%，是可以用到列上的索引的）。
一个 SQL 只能利用到复合索引中的一列进行范围查询。如：有 a,b,c 列的联合索引，在查询条件中有 a 列的范围查询，则在 b,c 列上的索引将不会被用到。
@@ -248,18 +248,18 @@ InnoDB 是按照主键索引的顺序来组织表的
- `SELECT *` 会消耗更多的 CPU。
- `SELECT *` 无用字段增加网络带宽资源消耗，增加数据传输时间，尤其是大字段（如 varchar、blob、text）。
-- `SELECT *` 无法使用 MySQL 优化器覆盖索引的优化（基于 MySQL 优化器的“覆盖索引”策略又是速度极快，效率极高，业界极为推荐的查询优化方式）
-- `SELECT <字段列表>` 可减少表结构变更带来的影响、
+- `SELECT *` 无法使用 MySQL 优化器覆盖索引的优化（基于 MySQL 优化器的“覆盖索引”策略又是速度极快、效率极高、业界极为推荐的查询优化方式）。
+- `SELECT <字段列表>` 可减少表结构变更带来的影响。
### 禁止使用不含字段列表的 INSERT 语句
-如：
+**不推荐**：
```sql
insert into t values ('a','b','c');
```
-应使用：
+**推荐**：
```sql
insert into t(c1,c2,c3) values ('a','b','c');
@@ -273,7 +273,7 @@ insert into t(c1,c2,c3) values ('a','b','c');
### 避免数据类型的隐式转换
-隐式转换会导致索引失效如:
+隐式转换会导致索引失效，如：
```sql
select name,phone from customer where id = '111';
@@ -283,9 +283,9 @@ select name,phone from customer where id = '111';
### 避免使用子查询，可以把子查询优化为 join 操作
-通常子查询在 in 子句中，且子查询中为简单 SQL(不包含 union、group by、order by、limit 从句) 时,才可以把子查询转化为关联查询进行优化。
+通常子查询在 in 子句中，且子查询中为简单 SQL(不包含 union、group by、order by、limit 从句) 时，才可以把子查询转化为关联查询进行优化。
-**子查询性能差的原因：** 子查询的结果集无法使用索引，通常子查询的结果集会被存储到临时表中，不论是内存临时表还是磁盘临时表都不会存在索引，所以查询性能会受到一定的影响。特别是对于返回结果集比较大的子查询，其对查询性能的影响也就越大。由于子查询会产生大量的临时表也没有索引，所以会消耗过多的 CPU 和 IO 资源，产生大量的慢查询。
+**子查询性能差的原因**：子查询的结果集无法使用索引，通常子查询的结果集会被存储到临时表中，不论是内存临时表还是磁盘临时表都不会存在索引，所以查询性能会受到一定的影响。特别是对于返回结果集比较大的子查询，其对查询性能的影响也就越大。由于子查询会产生大量的临时表也没有索引，所以会消耗过多的 CPU 和 IO 资源，产生大量的慢查询。
### 避免使用 JOIN 关联太多的表
@@ -293,7 +293,7 @@ select name,phone from customer where id = '111';
在 MySQL 中，对于同一个 SQL 多关联（join）一个表，就会多分配一个关联缓存，如果在一个 SQL 中关联的表越多，所占用的内存也就越大。
-如果程序中大量的使用了多表关联的操作，同时 join_buffer_size 设置的也不合理的情况下，就容易造成服务器内存溢出的情况，就会影响到服务器数据库性能的稳定性。
+如果程序中大量地使用了多表关联的操作，同时 join_buffer_size 设置得也不合理，就容易造成服务器内存溢出的情况，就会影响到服务器数据库性能的稳定性。
同时对于关联操作来说，会产生临时表操作，影响查询效率，MySQL 最多允许关联 61 个表，建议不超过 5 个。
@@ -303,25 +303,25 @@ select name,phone from customer where id = '111';
### 对应同一列进行 or 判断时，使用 in 代替 or
-in 的值不要超过 500 个，in 操作可以更有效的利用索引，or 大多数情况下很少能利用到索引。
+in 的值不要超过 500 个。in 操作可以更有效的利用索引，or 大多数情况下很少能利用到索引。
### 禁止使用 order by rand() 进行随机排序
-order by rand() 会把表中所有符合条件的数据装载到内存中，然后在内存中对所有数据根据随机生成的值进行排序，并且可能会对每一行都生成一个随机值，如果满足条件的数据集非常大，就会消耗大量的 CPU 和 IO 及内存资源。
+order by rand() 会把表中所有符合条件的数据装载到内存中，然后在内存中对所有数据根据随机生成的值进行排序，并且可能会对每一行都生成一个随机值。如果满足条件的数据集非常大，就会消耗大量的 CPU 和 IO 及内存资源。
推荐在程序中获取一个随机值，然后从数据库中获取数据的方式。
### WHERE 从句中禁止对列进行函数转换和计算
-对列进行函数转换或计算时会导致无法使用索引
+对列进行函数转换或计算时会导致无法使用索引。
-**不推荐：**
+**不推荐**：
```sql
where date(create_time)='20190101'
```
-**推荐：**
+**推荐**：
```sql
where create_time >= '20190101' and create_time < '20190102'
@@ -329,43 +329,43 @@ where create_time >= '20190101' and create_time < '20190102'
### 在明显不会有重复值时使用 UNION ALL 而不是 UNION
-- UNION 会把两个结果集的所有数据放到临时表中后再进行去重操作
-- UNION ALL 不会再对结果集进行去重操作
+- UNION 会把两个结果集的所有数据放到临时表中后再进行去重操作。
+- UNION ALL 不会再对结果集进行去重操作。
### 拆分复杂的大 SQL 为多个小 SQL
-- 大 SQL 逻辑上比较复杂，需要占用大量 CPU 进行计算的 SQL
-- MySQL 中，一个 SQL 只能使用一个 CPU 进行计算
-- SQL 拆分后可以通过并行执行来提高处理效率
+- 大 SQL 逻辑上比较复杂，需要占用大量 CPU 进行计算的 SQL。
+- MySQL 中，一个 SQL 只能使用一个 CPU 进行计算。
+- SQL 拆分后可以通过并行执行来提高处理效率。
### 程序连接不同的数据库使用不同的账号，禁止跨库查询
-- 为数据库迁移和分库分表留出余地
-- 降低业务耦合度
-- 避免权限过大而产生的安全风险
+- 为数据库迁移和分库分表留出余地。
+- 降低业务耦合度。
+- 避免权限过大而产生的安全风险。
## 数据库操作行为规范
-### 超 100 万行的批量写 (UPDATE,DELETE,INSERT) 操作,要分批多次进行操作
+### 超 100 万行的批量写 (UPDATE、DELETE、INSERT) 操作，要分批多次进行操作
**大批量操作可能会造成严重的主从延迟**
-主从环境中,大批量操作可能会造成严重的主从延迟，大批量的写操作一般都需要执行一定长的时间，而只有当主库上执行完成后，才会在其他从库上执行，所以会造成主库与从库长时间的延迟情况
+主从环境中，大批量操作可能会造成严重的主从延迟，大批量的写操作一般都需要执行一定长的时间，而只有当主库上执行完成后，才会在其他从库上执行，所以会造成主库与从库长时间的延迟情况。
**binlog 日志为 row 格式时会产生大量的日志**
-大批量写操作会产生大量日志，特别是对于 row 格式二进制数据而言，由于在 row 格式中会记录每一行数据的修改，我们一次修改的数据越多，产生的日志量也就会越多，日志的传输和恢复所需要的时间也就越长，这也是造成主从延迟的一个原因
+大批量写操作会产生大量日志，特别是对于 row 格式二进制数据而言，由于在 row 格式中会记录每一行数据的修改，我们一次修改的数据越多，产生的日志量也就会越多，日志的传输和恢复所需要的时间也就越长，这也是造成主从延迟的一个原因。
**避免产生大事务操作**
大批量修改数据，一定是在一个事务中进行的，这就会造成表中大批量数据进行锁定，从而导致大量的阻塞，阻塞会对 MySQL 的性能产生非常大的影响。
-特别是长时间的阻塞会占满所有数据库的可用连接，这会使生产环境中的其他应用无法连接到数据库，因此一定要注意大批量写操作要进行分批
+特别是长时间的阻塞会占满所有数据库的可用连接，这会使生产环境中的其他应用无法连接到数据库，因此一定要注意大批量写操作要进行分批。
### 对于大表使用 pt-online-schema-change 修改表结构
-- 避免大表修改产生的主从延迟
-- 避免在对表字段进行修改时进行锁表
+- 避免大表修改产生的主从延迟。
+- 避免在对表字段进行修改时进行锁表。
对大表数据结构的修改一定要谨慎，会造成严重的锁表操作，尤其是生产环境，是不能容忍的。
@@ -373,13 +373,13 @@ pt-online-schema-change 它会首先建立一个与原表结构相同的新表
### 禁止为程序使用的账号赋予 super 权限
-- 当达到最大连接数限制时，还运行 1 个有 super 权限的用户连接
-- super 权限只能留给 DBA 处理问题的账号使用
+- 当达到最大连接数限制时，还运行 1 个有 super 权限的用户连接。
+- super 权限只能留给 DBA 处理问题的账号使用。
-### 对于程序连接数据库账号,遵循权限最小原则
+### 对于程序连接数据库账号，遵循权限最小原则
-- 程序使用数据库账号只能在一个 DB 下使用，不准跨库
-- 程序使用的账号原则上不准有 drop 权限
+- 程序使用数据库账号只能在一个 DB 下使用，不准跨库。
+- 程序使用的账号原则上不准有 drop 权限。
## 推荐阅读
diff --git a/docs/database/mysql/mysql-index.md b/docs/database/mysql/mysql-index.md
index 59564375fc7..a21d133feea 100644
--- a/docs/database/mysql/mysql-index.md
+++ b/docs/database/mysql/mysql-index.md
@@ -15,20 +15,20 @@ tag:
**索引是一种用于快速查询和检索数据的数据结构，其本质可以看成是一种排序好的数据结构。**
-索引的作用就相当于书的目录。打个比方: 我们在查字典的时候，如果没有目录，那我们就只能一页一页的去找我们需要查的那个字，速度很慢。如果有目录了，我们只需要先去目录里查找字的位置，然后直接翻到那一页就行了。
+索引的作用就相当于书的目录。打个比方：我们在查字典的时候，如果没有目录，那我们就只能一页一页地去找我们需要查的那个字，速度很慢；如果有目录了，我们只需要先去目录里查找字的位置，然后直接翻到那一页就行了。
-索引底层数据结构存在很多种类型，常见的索引结构有: B 树， B+树 和 Hash、红黑树。在 MySQL 中，无论是 Innodb 还是 MyIsam，都使用了 B+树作为索引结构。
+索引底层数据结构存在很多种类型，常见的索引结构有：B 树、 B+ 树 和 Hash、红黑树。在 MySQL 中，无论是 Innodb 还是 MyISAM，都使用了 B+ 树作为索引结构。
## 索引的优缺点
**优点**：
-- 使用索引可以大大加快数据的检索速度（大大减少检索的数据量）, 减少 IO 次数，这也是创建索引的最主要的原因。
+- 使用索引可以大大加快数据的检索速度（大大减少检索的数据量），减少 IO 次数，这也是创建索引的最主要的原因。
- 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
**缺点**：
-- 创建索引和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态的修改，会降低 SQL 执行效率。
+- 创建和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态地修改，这会降低 SQL 执行效率。
- 索引需要使用物理文件存储，也会耗费一定空间。
但是，**使用索引一定能提高查询性能吗?**
@@ -39,7 +39,7 @@ tag:
### Hash 表
-哈希表是键值对的集合，通过键(key)即可快速取出对应的值(value)，因此哈希表可以快速检索数据（接近 O（1））。
+哈希表是键值对的集合，通过键(key)即可快速取出对应的值(value)，因此哈希表可以快速检索数据（接近 O(1)）。
**为何能够通过 key 快速取出 value 呢？** 原因在于 **哈希算法**（也叫散列算法）。通过哈希算法，我们可以快速找到 key 对应的 index，找到了 index 也就找到了对应的 value。
@@ -50,7 +50,7 @@ index = hash % array_size
-但是！哈希算法有个 **Hash 冲突** 问题，也就是说多个不同的 key 最后得到的 index 相同。通常情况下，我们常用的解决办法是 **链地址法**。链地址法就是将哈希冲突数据存放在链表中。就比如 JDK1.8 之前 `HashMap` 就是通过链地址法来解决哈希冲突的。不过，JDK1.8 以后`HashMap`为了减少链表过长的时候搜索时间过长引入了红黑树。
+但是！哈希算法有个 **Hash 冲突** 问题，也就是说多个不同的 key 最后得到的 index 相同。通常情况下，我们常用的解决办法是 **链地址法**。链地址法就是将哈希冲突数据存放在链表中。就比如 JDK1.8 之前 `HashMap` 就是通过链地址法来解决哈希冲突的。不过，JDK1.8 以后`HashMap`为了提高链表过长时的搜索效率，引入了红黑树。
@@ -60,15 +60,15 @@ MySQL 的 InnoDB 存储引擎不直接支持常规的哈希索引，但是，Inn
既然哈希表这么快，**为什么 MySQL 没有使用其作为索引的数据结构呢？** 主要是因为 Hash 索引不支持顺序和范围查询。假如我们要对表中的数据进行排序或者进行范围查询，那 Hash 索引可就不行了。并且，每次 IO 只能取一个。
-试想一种情况:
+试想一种情况：
```java
SELECT * FROM tb1 WHERE id < 500;
```
-在这种范围查询中，优势非常大，直接遍历比 500 小的叶子节点就够了。而 Hash 索引是根据 hash 算法来定位的，难不成还要把 1 - 499 的数据，每个都进行一次 hash 计算来定位吗?这就是 Hash 最大的缺点了。
+在这种范围查询中，优势非常大，直接遍历比 500 小的叶子节点就够了。而 Hash 索引是根据 hash 算法来定位的，难不成还要把 1 - 499 的数据，每个都进行一次 hash 计算来定位吗？这就是 Hash 最大的缺点了。
-### 二叉查找树(BST)
+### 二叉查找树（BST）
二叉查找树（Binary Search Tree）是一种基于二叉树的数据结构，它具有以下特点：
@@ -76,7 +76,7 @@ SELECT * FROM tb1 WHERE id < 500;
2. 右子树所有节点的值均大于根节点的值。
3. 左右子树也分别为二叉查找树。
-当二叉查找树是平衡的时候，也就是树的每个节点的左右子树深度相差不超过 1 的时候，查询的时间复杂度为 O(log2(N))，具有比较高的效率。然而，当二叉查找树不平衡时，例如在最坏情况下（有序插入节点），树会退化成线性链表（也被称为斜树），导致查询效率急剧下降，时间复杂退化为 O（N）。
+当二叉查找树是平衡的时候，也就是树的每个节点的左右子树深度相差不超过 1 的时候，查询的时间复杂度为 O(log2(N))，具有比较高的效率。然而，当二叉查找树不平衡时，例如在最坏情况下（有序插入节点），树会退化成线性链表（也被称为斜树），导致查询效率急剧下降，时间复杂退化为 O(N)。
@@ -88,11 +88,11 @@ SELECT * FROM tb1 WHERE id < 500;
AVL 树是计算机科学中最早被发明的自平衡二叉查找树，它的名称来自于发明者 G.M. Adelson-Velsky 和 E.M. Landis 的名字缩写。AVL 树的特点是保证任何节点的左右子树高度之差不超过 1，因此也被称为高度平衡二叉树，它的查找、插入和删除在平均和最坏情况下的时间复杂度都是 O(logn)。
-
+
AVL 树采用了旋转操作来保持平衡。主要有四种旋转操作：LL 旋转、RR 旋转、LR 旋转和 RL 旋转。其中 LL 旋转和 RR 旋转分别用于处理左左和右右失衡，而 LR 旋转和 RL 旋转则用于处理左右和右左失衡。
-由于 AVL 树需要频繁地进行旋转操作来保持平衡，因此会有较大的计算开销进而降低了数据库写操作的性能。并且， 在使用 AVL 树时，每个树节点仅存储一个数据，而每次进行磁盘 IO 时只能读取一个节点的数据，如果需要查询的数据分布在多个节点上，那么就需要进行多次磁盘 IO。 **磁盘 IO 是一项耗时的操作，在设计数据库索引时，我们需要优先考虑如何最大限度地减少磁盘 IO 操作的次数。**
+由于 AVL 树需要频繁地进行旋转操作来保持平衡，因此会有较大的计算开销进而降低了数据库写操作的性能。并且， 在使用 AVL 树时，每个树节点仅存储一个数据，而每次进行磁盘 IO 时只能读取一个节点的数据，如果需要查询的数据分布在多个节点上，那么就需要进行多次磁盘 IO。**磁盘 IO 是一项耗时的操作，在设计数据库索引时，我们需要优先考虑如何最大限度地减少磁盘 IO 操作的次数。**
实际应用中，AVL 树使用的并不多。
@@ -112,26 +112,26 @@ AVL 树采用了旋转操作来保持平衡。主要有四种旋转操作：LL
**红黑树的应用还是比较广泛的，TreeMap、TreeSet 以及 JDK1.8 的 HashMap 底层都用到了红黑树。对于数据在内存中的这种情况来说，红黑树的表现是非常优异的。**
-### B 树& B+树
+### B 树& B+ 树
-B 树也称 B-树,全称为 **多路平衡查找树** ，B+ 树是 B 树的一种变体。B 树和 B+树中的 B 是 `Balanced` （平衡）的意思。
+B 树也称 B- 树，全称为 **多路平衡查找树**，B+ 树是 B 树的一种变体。B 树和 B+ 树中的 B 是 `Balanced`（平衡）的意思。
目前大部分数据库系统及文件系统都采用 B-Tree 或其变种 B+Tree 作为索引结构。
-**B 树& B+树两者有何异同呢？**
+**B 树& B+ 树两者有何异同呢？**
-- B 树的所有节点既存放键(key) 也存放数据(data)，而 B+树只有叶子节点存放 key 和 data，其他内节点只存放 key。
-- B 树的叶子节点都是独立的;B+树的叶子节点有一条引用链指向与它相邻的叶子节点。
-- B 树的检索的过程相当于对范围内的每个节点的关键字做二分查找，可能还没有到达叶子节点，检索就结束了。而 B+树的检索效率就很稳定了，任何查找都是从根节点到叶子节点的过程，叶子节点的顺序检索很明显。
-- 在 B 树中进行范围查询时，首先找到要查找的下限，然后对 B 树进行中序遍历，直到找到查找的上限；而 B+树的范围查询，只需要对链表进行遍历即可。
+- B 树的所有节点既存放键(key)也存放数据(data)，而 B+ 树只有叶子节点存放 key 和 data，其他内节点只存放 key。
+- B 树的叶子节点都是独立的；B+ 树的叶子节点有一条引用链指向与它相邻的叶子节点。
+- B 树的检索的过程相当于对范围内的每个节点的关键字做二分查找，可能还没有到达叶子节点，检索就结束了。而 B+ 树的检索效率就很稳定了，任何查找都是从根节点到叶子节点的过程，叶子节点的顺序检索很明显。
+- 在 B 树中进行范围查询时，首先找到要查找的下限，然后对 B 树进行中序遍历，直到找到查找的上限；而 B+ 树的范围查询，只需要对链表进行遍历即可。
-综上，B+树与 B 树相比，具备更少的 IO 次数、更稳定的查询效率和更适于范围查询这些优势。
+综上，B+ 树与 B 树相比，具备更少的 IO 次数、更稳定的查询效率和更适于范围查询这些优势。
在 MySQL 中，MyISAM 引擎和 InnoDB 引擎都是使用 B+Tree 作为索引结构，但是，两者的实现方式不太一样。（下面的内容整理自《Java 工程师修炼之道》）
> MyISAM 引擎中，B+Tree 叶节点的 data 域存放的是数据记录的地址。在索引检索的时候，首先按照 B+Tree 搜索算法搜索索引，如果指定的 Key 存在，则取出其 data 域的值，然后以 data 域的值为地址读取相应的数据记录。这被称为“**非聚簇索引（非聚集索引）**”。
>
-> InnoDB 引擎中，其数据文件本身就是索引文件。相比 MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按 B+Tree 组织的一个索引结构，树的叶节点 data 域保存了完整的数据记录。这个索引的 key 是数据表的主键，因此 InnoDB 表数据文件本身就是主索引。这被称为“**聚簇索引（聚集索引）**”，而其余的索引都作为 **辅助索引** ，辅助索引的 data 域存储相应记录主键的值而不是地址，这也是和 MyISAM 不同的地方。在根据主索引搜索时，直接找到 key 所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。 因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。
+> InnoDB 引擎中，其数据文件本身就是索引文件。相比 MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按 B+Tree 组织的一个索引结构，树的叶节点 data 域保存了完整的数据记录。这个索引的 key 是数据表的主键，因此 InnoDB 表数据文件本身就是主索引。这被称为“**聚簇索引（聚集索引）**”，而其余的索引都作为 **辅助索引**，辅助索引的 data 域存储相应记录主键的值而不是地址，这也是和 MyISAM 不同的地方。在根据主索引搜索时，直接找到 key 所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。 因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。
## 索引类型总结
@@ -140,12 +140,12 @@ B 树也称 B-树,全称为 **多路平衡查找树** ，B+ 树是 B 树的一
- BTree 索引：MySQL 里默认和最常用的索引类型。只有叶子节点存储 value，非叶子节点只有指针和 key。存储引擎 MyISAM 和 InnoDB 实现 BTree 索引都是使用 B+Tree，但二者实现方式不一样（前面已经介绍了）。
- 哈希索引：类似键值对的形式，一次即可定位。
- RTree 索引：一般不会使用，仅支持 geometry 数据类型，优势在于范围查找，效率较低，通常使用搜索引擎如 ElasticSearch 代替。
-- 全文索引：对文本的内容进行分词，进行搜索。目前只有 `CHAR`、`VARCHAR` ，`TEXT` 列上可以创建全文索引。一般不会使用，效率较低，通常使用搜索引擎如 ElasticSearch 代替。
+- 全文索引：对文本的内容进行分词，进行搜索。目前只有 `CHAR`、`VARCHAR`、`TEXT` 列上可以创建全文索引。一般不会使用，效率较低，通常使用搜索引擎如 ElasticSearch 代替。
按照底层存储方式角度划分：
- 聚簇索引（聚集索引）：索引结构和数据一起存放的索引，InnoDB 中的主键索引就属于聚簇索引。
-- 非聚簇索引（非聚集索引）：索引结构和数据分开存放的索引，二级索引(辅助索引)就属于非聚簇索引。MySQL 的 MyISAM 引擎，不管主键还是非主键，使用的都是非聚簇索引。
+- 非聚簇索引（非聚集索引）：索引结构和数据分开存放的索引，二级索引（辅助索引）就属于非聚簇索引。MySQL 的 MyISAM 引擎，不管主键还是非主键，使用的都是非聚簇索引。
按照应用维度划分：
@@ -154,7 +154,8 @@ B 树也称 B-树,全称为 **多路平衡查找树** ，B+ 树是 B 树的一
- 唯一索引：加速查询 + 列值唯一（可以有 NULL）。
- 覆盖索引：一个索引包含（或者说覆盖）所有需要查询的字段的值。
- 联合索引：多列值组成一个索引，专门用于组合搜索，其效率大于索引合并。
-- 全文索引：对文本的内容进行分词，进行搜索。目前只有 `CHAR`、`VARCHAR` ，`TEXT` 列上可以创建全文索引。一般不会使用，效率较低，通常使用搜索引擎如 ElasticSearch 代替。
+- 全文索引：对文本的内容进行分词，进行搜索。目前只有 `CHAR`、`VARCHAR`、`TEXT` 列上可以创建全文索引。一般不会使用，效率较低，通常使用搜索引擎如 ElasticSearch 代替。
+- 前缀索引：对文本的前几个字符创建索引，相比普通索引建立的数据更小，因为只取前几个字符。
MySQL 8.x 中实现的索引新特性：
@@ -162,7 +163,7 @@ MySQL 8.x 中实现的索引新特性：
- 降序索引：之前的版本就支持通过 desc 来指定索引为降序，但实际上创建的仍然是常规的升序索引。直到 MySQL 8.x 版本才开始真正支持降序索引。另外，在 MySQL 8.x 版本中，不再对 GROUP BY 语句进行隐式排序。
- 函数索引：从 MySQL 8.0.13 版本开始支持在索引中使用函数或者表达式的值，也就是在索引中可以包含函数或者表达式。
-## 主键索引(Primary Key)
+## 主键索引（Primary Key）
数据表的主键列使用的就是主键索引。
@@ -176,16 +177,16 @@ MySQL 8.x 中实现的索引新特性：
二级索引（Secondary Index）的叶子节点存储的数据是主键的值，也就是说，通过二级索引可以定位主键的位置，二级索引又称为辅助索引/非主键索引。
-唯一索引，普通索引，前缀索引等索引都属于二级索引。
+唯一索引、普通索引、前缀索引等索引都属于二级索引。
-PS: 不懂的同学可以暂存疑，慢慢往下看，后面会有答案的，也可以自行搜索。
+PS：不懂的同学可以暂存疑，慢慢往下看，后面会有答案的，也可以自行搜索。
-1. **唯一索引(Unique Key)**:唯一索引也是一种约束。唯一索引的属性列不能出现重复的数据，但是允许数据为 NULL，一张表允许创建多个唯一索引。 建立唯一索引的目的大部分时候都是为了该属性列的数据的唯一性，而不是为了查询效率。
-2. **普通索引(Index)**:普通索引的唯一作用就是为了快速查询数据，一张表允许创建多个普通索引，并允许数据重复和 NULL。
-3. **前缀索引(Prefix)**:前缀索引只适用于字符串类型的数据。前缀索引是对文本的前几个字符创建索引，相比普通索引建立的数据更小，因为只取前几个字符。
-4. **全文索引(Full Text)**:全文索引主要是为了检索大文本数据中的关键字的信息，是目前搜索引擎数据库使用的一种技术。Mysql5.6 之前只有 MYISAM 引擎支持全文索引，5.6 之后 InnoDB 也支持了全文索引。
+1. **唯一索引（Unique Key）**：唯一索引也是一种约束。唯一索引的属性列不能出现重复的数据，但是允许数据为 NULL，一张表允许创建多个唯一索引。 建立唯一索引的目的大部分时候都是为了该属性列的数据的唯一性，而不是为了查询效率。
+2. **普通索引（Index）**：普通索引的唯一作用就是为了快速查询数据。一张表允许创建多个普通索引，并允许数据重复和 NULL。
+3. **前缀索引（Prefix）**：前缀索引只适用于字符串类型的数据。前缀索引是对文本的前几个字符创建索引，相比普通索引建立的数据更小，因为只取前几个字符。
+4. **全文索引（Full Text）**：全文索引主要是为了检索大文本数据中的关键字的信息，是目前搜索引擎数据库使用的一种技术。Mysql5.6 之前只有 MyISAM 引擎支持全文索引，5.6 之后 InnoDB 也支持了全文索引。
-二级索引:
+二级索引：
@@ -197,25 +198,25 @@ PS: 不懂的同学可以暂存疑，慢慢往下看，后面会有答案的，
聚簇索引（Clustered Index）即索引结构和数据一起存放的索引，并不是一种单独的索引类型。InnoDB 中的主键索引就属于聚簇索引。
-在 MySQL 中，InnoDB 引擎的表的 `.ibd`文件就包含了该表的索引和数据，对于 InnoDB 引擎表来说，该表的索引(B+树)的每个非叶子节点存储索引，叶子节点存储索引和索引对应的数据。
+在 MySQL 中，InnoDB 引擎的表的 `.ibd`文件就包含了该表的索引和数据，对于 InnoDB 引擎表来说，该表的索引（B+ 树）的每个非叶子节点存储索引，叶子节点存储索引和索引对应的数据。
#### 聚簇索引的优缺点
**优点**：
-- **查询速度非常快**：聚簇索引的查询速度非常的快，因为整个 B+树本身就是一颗多叉平衡树，叶子节点也都是有序的，定位到索引的节点，就相当于定位到了数据。相比于非聚簇索引， 聚簇索引少了一次读取数据的 IO 操作。
+- **查询速度非常快**：聚簇索引的查询速度非常的快，因为整个 B+ 树本身就是一颗多叉平衡树，叶子节点也都是有序的，定位到索引的节点，就相当于定位到了数据。相比于非聚簇索引， 聚簇索引少了一次读取数据的 IO 操作。
- **对排序查找和范围查找优化**：聚簇索引对于主键的排序查找和范围查找速度非常快。
**缺点**：
-- **依赖于有序的数据**：因为 B+树是多路平衡树，如果索引的数据不是有序的，那么就需要在插入时排序，如果数据是整型还好，否则类似于字符串或 UUID 这种又长又难比较的数据，插入或查找的速度肯定比较慢。
+- **依赖于有序的数据**：因为 B+ 树是多路平衡树，如果索引的数据不是有序的，那么就需要在插入时排序，如果数据是整型还好，否则类似于字符串或 UUID 这种又长又难比较的数据，插入或查找的速度肯定比较慢。
- **更新代价大**：如果对索引列的数据被修改时，那么对应的索引也将会被修改，而且聚簇索引的叶子节点还存放着数据，修改代价肯定是较大的，所以对于主键索引来说，主键一般都是不可被修改的。
### 非聚簇索引（非聚集索引）
#### 非聚簇索引介绍
-非聚簇索引(Non-Clustered Index)即索引结构和数据分开存放的索引，并不是一种单独的索引类型。二级索引(辅助索引)就属于非聚簇索引。MySQL 的 MyISAM 引擎，不管主键还是非主键，使用的都是非聚簇索引。
+非聚簇索引（Non-Clustered Index）即索引结构和数据分开存放的索引，并不是一种单独的索引类型。二级索引（辅助索引）就属于非聚簇索引。MySQL 的 MyISAM 引擎，不管主键还是非主键，使用的都是非聚簇索引。
非聚簇索引的叶子节点并不一定存放数据的指针，因为二级索引的叶子节点就存放的是主键，根据主键再回表查数据。
@@ -223,22 +224,22 @@ PS: 不懂的同学可以暂存疑，慢慢往下看，后面会有答案的，
**优点**：
-更新代价比聚簇索引要小 。非聚簇索引的更新代价就没有聚簇索引那么大了，非聚簇索引的叶子节点是不存放数据的。
+更新代价比聚簇索引要小。非聚簇索引的更新代价就没有聚簇索引那么大了，非聚簇索引的叶子节点是不存放数据的。
**缺点**：
-- **依赖于有序的数据**:跟聚簇索引一样，非聚簇索引也依赖于有序的数据
-- **可能会二次查询(回表)**:这应该是非聚簇索引最大的缺点了。 当查到索引对应的指针或主键后，可能还需要根据指针或主键再到数据文件或表中查询。
+- **依赖于有序的数据**：跟聚簇索引一样，非聚簇索引也依赖于有序的数据。
+- **可能会二次查询（回表）**：这应该是非聚簇索引最大的缺点了。当查到索引对应的指针或主键后，可能还需要根据指针或主键再到数据文件或表中查询。
-这是 MySQL 的表的文件截图:
+这是 MySQL 的表的文件截图：
-聚簇索引和非聚簇索引:
+聚簇索引和非聚簇索引：
-#### 非聚簇索引一定回表查询吗(覆盖索引)?
+#### 非聚簇索引一定回表查询吗（覆盖索引）？
**非聚簇索引不一定回表查询。**
@@ -250,7 +251,7 @@ PS: 不懂的同学可以暂存疑，慢慢往下看，后面会有答案的，
那么这个索引的 key 本身就是 name，查到对应的 name 直接返回就行了，无需回表查询。
-即使是 MYISAM 也是这样，虽然 MYISAM 的主键索引确实需要回表，因为它的主键索引的叶子节点存放的是指针。但是！**如果 SQL 查的就是主键呢?**
+即使是 MyISAM 也是这样，虽然 MyISAM 的主键索引确实需要回表，因为它的主键索引的叶子节点存放的是指针。但是！**如果 SQL 查的就是主键呢?**
```sql
SELECT id FROM table WHERE id=1;
@@ -262,7 +263,7 @@ SELECT id FROM table WHERE id=1;
### 覆盖索引
-如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为 **覆盖索引（Covering Index）** 。
+如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为 **覆盖索引（Covering Index）**。
在 InnoDB 存储引擎中，非主键索引的叶子节点包含的是主键的值。这意味着，当使用非主键索引进行查询时，数据库会先找到对应的主键值，然后再通过主键索引来定位和检索完整的行数据。这个过程被称为“回表”。
@@ -275,7 +276,7 @@ SELECT id FROM table WHERE id=1;
我们这里简单演示一下覆盖索引的效果。
-1、创建一个名为 `cus_order` 的表，来实际测试一下这种排序方式。为了测试方便， `cus_order` 这张表只有 `id`、`score`、`name`这 3 个字段。
+1、创建一个名为 `cus_order` 的表，来实际测试一下这种排序方式。为了测试方便，`cus_order` 这张表只有 `id`、`score`、`name` 这 3 个字段。
```sql
CREATE TABLE `cus_order` (
@@ -319,7 +320,7 @@ CALL BatchinsertDataToCusOder(1, 1000000); # 插入100w+的随机数据
SELECT `score`,`name` FROM `cus_order` ORDER BY `score` DESC;
```
-使用 `EXPLAIN` 命令分析这条 SQL 语句，通过 `Extra` 这一列的 `Using filesort` ，我们发现是没有用到覆盖索引的。
+使用 `EXPLAIN` 命令分析这条 SQL 语句，通过 `Extra` 这一列的 `Using filesort`，我们发现是没有用到覆盖索引的。
@@ -335,7 +336,7 @@ ALTER TABLE `cus_order` ADD INDEX id_score_name(score, name);
-通过 `Extra` 这一列的 `Using index` ，说明这条 SQL 语句成功使用了覆盖索引。
+通过 `Extra` 这一列的 `Using index`，说明这条 SQL 语句成功使用了覆盖索引。
关于 `EXPLAIN` 命令的详细介绍请看：[MySQL 执行计划分析](./mysql-query-execution-plan.md)这篇文章。
@@ -355,13 +356,13 @@ ALTER TABLE `cus_order` ADD INDEX id_score_name(score, name);
最左匹配原则会一直向右匹配，直到遇到范围查询（如 >、<）为止。对于 >=、<=、BETWEEN 以及前缀匹配 LIKE 的范围查询，不会停止匹配（相关阅读：[联合索引的最左匹配原则全网都在说的一个错误结论](https://mp.weixin.qq.com/s/8qemhRg5MgXs1So5YCv0fQ)）。
-假设有一个联合索引`(column1, column2, column3)`，其从左到右的所有前缀为`(column1)`、`(column1, column2)`、`(column1, column2, column3)`（创建 1 个联合索引相当于创建了 3 个索引），包含这些列的所有查询都会走索引而不会全表扫描。
+假设有一个联合索引 `(column1, column2, column3)`，其从左到右的所有前缀为 `(column1)`、`(column1, column2)`、`(column1, column2, column3)`（创建 1 个联合索引相当于创建了 3 个索引），包含这些列的所有查询都会走索引而不会全表扫描。
我们在使用联合索引时，可以将区分度高的字段放在最左边，这也可以过滤更多数据。
我们这里简单演示一下最左前缀匹配的效果。
-1、创建一个名为 `student` 的表，这张表只有 `id`、`name`、`class`这 3 个字段。
+1、创建一个名为 `student` 的表，这张表只有 `id`、`name`、`class` 这 3 个字段。
```sql
CREATE TABLE `student` (
@@ -385,13 +386,21 @@ EXPLAIN SELECT * FROM student WHERE name = 'Anne Henry' AND class = 'lIrm08RYVk'
SELECT * FROM student WHERE class = 'lIrm08RYVk';
```
+再来看一个常见的面试题：如果有索引 `联合索引（a，b，c）`，查询 `a=1 AND c=1` 会走索引么？`c=1` 呢？`b=1 AND c=1` 呢？
+
+先不要往下看答案，给自己 3 分钟时间想一想。
+
+1. 查询 `a=1 AND c=1`：根据最左前缀匹配原则，查询可以使用索引的前缀部分。因此，该查询仅在 `a=1` 上使用索引，然后对结果进行 `c=1` 的过滤。
+2. 查询 `c=1`：由于查询中不包含最左列 `a`，根据最左前缀匹配原则，整个索引都无法被使用。
+3. 查询 `b=1 AND c=1`：和第二种一样的情况，整个索引都不会使用。
+
MySQL 8.0.13 版本引入了索引跳跃扫描（Index Skip Scan，简称 ISS），它可以在某些索引查询场景下提高查询效率。在没有 ISS 之前，不满足最左前缀匹配原则的联合索引查询中会执行全表扫描。而 ISS 允许 MySQL 在某些情况下避免全表扫描，即使查询条件不符合最左前缀。不过，这个功能比较鸡肋， 和 Oracle 中的没法比，MySQL 8.0.31 还报告了一个 bug：[Bug #109145 Using index for skip scan cause incorrect result](https://bugs.mysql.com/bug.php?id=109145)（后续版本已经修复）。个人建议知道有这个东西就好，不需要深究，实际项目也不一定能用上。
## 索引下推
-**索引下推（Index Condition Pushdown，简称 ICP）** 是 **MySQL 5.6** 版本中提供的一项索引优化功能，它允许存储引擎在索引遍历过程中，执行部分 `WHERE`字句的判断条件，直接过滤掉不满足条件的记录，从而减少回表次数，提高查询效率。
+**索引下推（Index Condition Pushdown，简称 ICP）** 是 **MySQL 5.6** 版本中提供的一项索引优化功能，它允许存储引擎在索引遍历过程中，执行部分 `WHERE` 字句的判断条件，直接过滤掉不满足条件的记录，从而减少回表次数，提高查询效率。
-假设我们有一个名为 `user` 的表，其中包含 `id`, `username`, `zipcode`和 `birthdate` 4 个字段，创建了联合索引`(zipcode, birthdate)`。
+假设我们有一个名为 `user` 的表，其中包含 `id`、`username`、`zipcode` 和 `birthdate` 4 个字段，创建了联合索引 `(zipcode, birthdate)`。
```sql
CREATE TABLE `user` (
@@ -408,7 +417,7 @@ SELECT * FROM user WHERE zipcode = '431200' AND MONTH(birthdate) = 3;
```
- 没有索引下推之前，即使 `zipcode` 字段利用索引可以帮助我们快速定位到 `zipcode = '431200'` 的用户，但我们仍然需要对每一个找到的用户进行回表操作，获取完整的用户数据，再去判断 `MONTH(birthdate) = 3`。
-- 有了索引下推之后，存储引擎会在使用`zipcode` 字段索引查找`zipcode = '431200'` 的用户时，同时判断`MONTH(birthdate) = 3`。这样，只有同时满足条件的记录才会被返回，减少了回表次数。
+- 有了索引下推之后，存储引擎会在使用 `zipcode` 字段索引查找 `zipcode = '431200'` 的用户时，同时判断 `MONTH(birthdate) = 3`。这样，只有同时满足条件的记录才会被返回，减少了回表次数。
@@ -420,14 +429,14 @@ SELECT * FROM user WHERE zipcode = '431200' AND MONTH(birthdate) = 3;
MySQL 可以简单分为 Server 层和存储引擎层这两层。Server 层处理查询解析、分析、优化、缓存以及与客户端的交互等操作，而存储引擎层负责数据的存储和读取，MySQL 支持 InnoDB、MyISAM、Memory 等多种存储引擎。
-索引下推的**下推**其实就是指将部分上层（Server 层）负责的事情，交给了下层（存储引擎层）去处理。
+索引下推的 **下推** 其实就是指将部分上层（Server 层）负责的事情，交给了下层（存储引擎层）去处理。
我们这里结合索引下推原理再对上面提到的例子进行解释。
没有索引下推之前：
- 存储引擎层先根据 `zipcode` 索引字段找到所有 `zipcode = '431200'` 的用户的主键 ID，然后二次回表查询，获取完整的用户数据；
-- 存储引擎层把所有 `zipcode = '431200'` 的用户数据全部交给 Server 层，Server 层根据`MONTH(birthdate) = 3`这一条件再进一步做筛选。
+- 存储引擎层把所有 `zipcode = '431200'` 的用户数据全部交给 Server 层，Server 层根据 `MONTH(birthdate) = 3` 这一条件再进一步做筛选。
有了索引下推之后：
@@ -440,8 +449,8 @@ MySQL 可以简单分为 Server 层和存储引擎层这两层。Server 层处
最后，总结一下索引下推应用范围：
1. 适用于 InnoDB 引擎和 MyISAM 引擎的查询。
-2. 适用于执行计划是 range, ref, eq_ref, ref_or_null 的范围查询。
-3. 对于 InnoDB 表，仅用于非聚簇索引。索引下推的目标是减少全行读取次数，从而减少 I/O 操作。对于 InnoDB 聚集索引，完整的记录已经读入 InnoDB 缓冲区。在这种情况下使用索引下推 不会减少 I/O。
+2. 适用于执行计划是 range、ref、eq_ref、ref_or_null 的范围查询。
+3. 对于 InnoDB 表，仅用于非聚簇索引。索引下推的目标是减少全行读取次数，从而减少 I/O 操作。对于 InnoDB 聚集索引，完整的记录已经读入 InnoDB 缓冲区。在这种情况下使用索引下推不会减少 I/O。
4. 子查询不能使用索引下推，因为子查询通常会创建临时表来处理结果，而这些临时表是没有索引的。
5. 存储过程不能使用索引下推，因为存储引擎无法调用存储函数。
@@ -449,7 +458,7 @@ MySQL 可以简单分为 Server 层和存储引擎层这两层。Server 层处
### 选择合适的字段创建索引
-- **不为 NULL 的字段**：索引字段的数据应该尽量不为 NULL，因为对于数据为 NULL 的字段，数据库较难优化。如果字段频繁被查询，但又避免不了为 NULL，建议使用 0,1,true,false 这样语义较为清晰的短值或短字符作为替代。
+- **不为 NULL 的字段**：索引字段的数据应该尽量不为 NULL，因为对于数据为 NULL 的字段，数据库较难优化。如果字段频繁被查询，但又避免不了为 NULL，建议使用 0、1、true、false 这样语义较为清晰的短值或短字符作为替代。
- **被频繁查询的字段**：我们创建索引的字段应该是查询操作非常频繁的字段。
- **被作为条件查询的字段**：被作为 WHERE 条件查询的字段，应该被考虑建立索引。
- **频繁需要排序的字段**：索引已经排序，这样查询可以利用索引的排序，加快排序查询时间。
@@ -461,7 +470,7 @@ MySQL 可以简单分为 Server 层和存储引擎层这两层。Server 层处
### 限制每张表上的索引数量
-索引并不是越多越好，建议单张表索引不超过 5 个！索引可以提高效率同样可以降低效率。
+索引并不是越多越好，建议单张表索引不超过 5 个！索引可以提高效率，同样可以降低效率。
索引可以增加查询效率，但同样也会降低插入和更新的效率，甚至有些情况下会降低查询效率。
@@ -469,11 +478,11 @@ MySQL 可以简单分为 Server 层和存储引擎层这两层。Server 层处
### 尽可能的考虑建立联合索引而不是单列索引
-因为索引是需要占用磁盘空间的，可以简单理解为每个索引都对应着一颗 B+树。如果一个表的字段过多，索引过多，那么当这个表的数据达到一个体量后，索引占用的空间也是很多的，且修改索引时，耗费的时间也是较多的。如果是联合索引，多个字段在一个索引上，那么将会节约很大磁盘空间，且修改数据的操作效率也会提升。
+因为索引是需要占用磁盘空间的，可以简单理解为每个索引都对应着一颗 B+ 树。如果一个表的字段过多，索引过多，那么当这个表的数据达到一个体量后，索引占用的空间也是很多的，且修改索引时，耗费的时间也是较多的。如果是联合索引，多个字段在一个索引上，那么将会节约很大磁盘空间，且修改数据的操作效率也会提升。
### 注意避免冗余索引
-冗余索引指的是索引的功能相同，能够命中索引(a, b)就肯定能命中索引(a) ，那么索引(a)就是冗余索引。如（name,city ）和（name ）这两个索引就是冗余索引，能够命中前者的查询肯定是能够命中后者的 在大多数情况下，都应该尽量扩展已有的索引而不是创建新索引。
+冗余索引指的是索引的功能相同，能够命中索引(a, b)就肯定能命中索引(a) ，那么索引(a)就是冗余索引。如(name,city)和(name)这两个索引就是冗余索引，能够命中前者的查询肯定是能够命中后者的。在大多数情况下，都应该尽量扩展已有的索引而不是创建新索引。
### 字符串类型的字段使用前缀索引代替普通索引
@@ -483,13 +492,13 @@ MySQL 可以简单分为 Server 层和存储引擎层这两层。Server 层处
索引失效也是慢查询的主要原因之一，常见的导致索引失效的情况有下面这些：
-- ~~使用 `SELECT *` 进行查询;~~ `SELECT *` 不会直接导致索引失效（如果不走索引大概率是因为 where 查询范围过大导致的），但它可能会带来一些其他的性能问题比如造成网络传输和数据处理的浪费、无法使用索引覆盖;
-- 创建了组合索引，但查询条件未遵守最左匹配原则;
-- 在索引列上进行计算、函数、类型转换等操作;
-- 以 % 开头的 LIKE 查询比如 `LIKE '%abc';`;
-- 查询条件中使用 OR，且 OR 的前后条件中有一个列没有索引，涉及的索引都不会被使用到;
-- IN 的取值范围较大时会导致索引失效，走全表扫描(NOT IN 和 IN 的失效场景相同);
-- 发生[隐式转换](https://javaguide.cn/database/mysql/index-invalidation-caused-by-implicit-conversion.html);
+- ~~使用 `SELECT *` 进行查询;~~ `SELECT *` 不会直接导致索引失效（如果不走索引大概率是因为 where 查询范围过大导致的），但它可能会带来一些其他的性能问题比如造成网络传输和数据处理的浪费、无法使用索引覆盖；
+- 创建了组合索引，但查询条件未遵守最左匹配原则；
+- 在索引列上进行计算、函数、类型转换等操作；
+- 以 % 开头的 LIKE 查询比如 `LIKE '%abc';`；
+- 查询条件中使用 OR，且 OR 的前后条件中有一个列没有索引，涉及的索引都不会被使用到；
+- IN 的取值范围较大时会导致索引失效，走全表扫描（NOT IN 和 IN 的失效场景相同）；
+- 发生[隐式转换](https://javaguide.cn/database/mysql/index-invalidation-caused-by-implicit-conversion.html)；
- ……
推荐阅读这篇文章：[美团暑期实习一面：MySQl 索引失效的场景有哪些？](https://mp.weixin.qq.com/s/mwME3qukHBFul57WQLkOYg)。
@@ -500,7 +509,7 @@ MySQL 可以简单分为 Server 层和存储引擎层这两层。Server 层处
MySQL 5.7 可以通过查询 `sys` 库的 `schema_unused_indexes` 视图来查询哪些索引从未被使用。
-### 知道如何分析语句是否走索引查询
+### 知道如何分析 SQL 语句是否走索引查询
我们可以使用 `EXPLAIN` 命令来分析 SQL 的 **执行计划** ，这样就知道语句是否命中索引了。执行计划是指一条 SQL 语句在经过 MySQL 查询优化器的优化会后，具体的执行方式。
diff --git a/docs/database/mysql/mysql-logs.md b/docs/database/mysql/mysql-logs.md
index 9ee2d5cc105..ac7e29db2f3 100644
--- a/docs/database/mysql/mysql-logs.md
+++ b/docs/database/mysql/mysql-logs.md
@@ -9,27 +9,27 @@ tag:
## 前言
-`MySQL` 日志 主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志 `binlog`（归档日志）和事务日志 `redo log`（重做日志）和 `undo log`（回滚日志）。
+MySQL 日志 主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志 binlog（归档日志）和事务日志 redo log（重做日志）和 undo log（回滚日志）。
-今天就来聊聊 `redo log`（重做日志）、`binlog`（归档日志）、两阶段提交、`undo log` （回滚日志）。
+今天就来聊聊 redo log（重做日志）、binlog（归档日志）、两阶段提交、undo log（回滚日志）。
## redo log
-`redo log`（重做日志）是`InnoDB`存储引擎独有的，它让`MySQL`拥有了崩溃恢复能力。
+redo log（重做日志）是 InnoDB 存储引擎独有的，它让 MySQL 拥有了崩溃恢复能力。
-比如 `MySQL` 实例挂了或宕机了，重启时，`InnoDB`存储引擎会使用`redo log`恢复数据，保证数据的持久性与完整性。
+比如 MySQL 实例挂了或宕机了，重启时，InnoDB 存储引擎会使用 redo log 恢复数据，保证数据的持久性与完整性。
-`MySQL` 中数据是以页为单位，你查询一条记录，会从硬盘把一页的数据加载出来，加载出来的数据叫数据页，会放入到 `Buffer Pool` 中。
+MySQL 中数据是以页为单位，你查询一条记录，会从硬盘把一页的数据加载出来，加载出来的数据叫数据页，会放入到 `Buffer Pool` 中。
-后续的查询都是先从 `Buffer Pool` 中找，没有命中再去硬盘加载，减少硬盘 `IO` 开销，提升性能。
+后续的查询都是先从 `Buffer Pool` 中找，没有命中再去硬盘加载，减少硬盘 IO 开销，提升性能。
更新表数据的时候，也是如此，发现 `Buffer Pool` 里存在要更新的数据，就直接在 `Buffer Pool` 里更新。
-然后会把“在某个数据页上做了什么修改”记录到重做日志缓存（`redo log buffer`）里，接着刷盘到 `redo log` 文件里。
+然后会把“在某个数据页上做了什么修改”记录到重做日志缓存（`redo log buffer`）里，接着刷盘到 redo log 文件里。
@@ -64,15 +64,15 @@ InnoDB 将 redo log 刷到磁盘上有几种情况：
刷盘策略`innodb_flush_log_at_trx_commit` 的默认值为 1，设置为 1 的时候才不会丢失任何数据。为了保证事务的持久性，我们必须将其设置为 1。
-另外，`InnoDB` 存储引擎有一个后台线程，每隔`1` 秒，就会把 `redo log buffer` 中的内容写到文件系统缓存（`page cache`），然后调用 `fsync` 刷盘。
+另外，InnoDB 存储引擎有一个后台线程，每隔`1` 秒，就会把 `redo log buffer` 中的内容写到文件系统缓存（`page cache`），然后调用 `fsync` 刷盘。
-也就是说，一个没有提交事务的 `redo log` 记录，也可能会刷盘。
+也就是说，一个没有提交事务的 redo log 记录，也可能会刷盘。
**为什么呢？**
-因为在事务执行过程 `redo log` 记录是会写入`redo log buffer` 中，这些 `redo log` 记录会被后台线程刷盘。
+因为在事务执行过程 redo log 记录是会写入`redo log buffer` 中，这些 redo log 记录会被后台线程刷盘。
@@ -84,15 +84,15 @@ InnoDB 将 redo log 刷到磁盘上有几种情况：
-为`0`时，如果`MySQL`挂了或宕机可能会有`1`秒数据的丢失。
+为`0`时，如果 MySQL 挂了或宕机可能会有`1`秒数据的丢失。
#### innodb_flush_log_at_trx_commit=1
-为`1`时， 只要事务提交成功，`redo log`记录就一定在硬盘里，不会有任何数据丢失。
+为`1`时， 只要事务提交成功，redo log 记录就一定在硬盘里，不会有任何数据丢失。
-如果事务执行期间`MySQL`挂了或宕机，这部分日志丢了，但是事务并没有提交，所以日志丢了也不会有损失。
+如果事务执行期间 MySQL 挂了或宕机，这部分日志丢了，但是事务并没有提交，所以日志丢了也不会有损失。
#### innodb_flush_log_at_trx_commit=2
@@ -100,13 +100,13 @@ InnoDB 将 redo log 刷到磁盘上有几种情况：
为`2`时， 只要事务提交成功，`redo log buffer`中的内容只写入文件系统缓存（`page cache`）。
-如果仅仅只是`MySQL`挂了不会有任何数据丢失，但是宕机可能会有`1`秒数据的丢失。
+如果仅仅只是 MySQL 挂了不会有任何数据丢失，但是宕机可能会有`1`秒数据的丢失。
### 日志文件组
-硬盘上存储的 `redo log` 日志文件不只一个，而是以一个**日志文件组**的形式出现的，每个的`redo`日志文件大小都是一样的。
+硬盘上存储的 redo log 日志文件不只一个，而是以一个**日志文件组**的形式出现的，每个的`redo`日志文件大小都是一样的。
-比如可以配置为一组`4`个文件，每个文件的大小是 `1GB`，整个 `redo log` 日志文件组可以记录`4G`的内容。
+比如可以配置为一组`4`个文件，每个文件的大小是 `1GB`，整个 redo log 日志文件组可以记录`4G`的内容。
它采用的是环形数组形式，从头开始写，写到末尾又回到头循环写，如下图所示。
@@ -117,15 +117,15 @@ InnoDB 将 redo log 刷到磁盘上有几种情况：
- **write pos** 是当前记录的位置，一边写一边后移
- **checkpoint** 是当前要擦除的位置，也是往后推移
-每次刷盘 `redo log` 记录到**日志文件组**中，`write pos` 位置就会后移更新。
+每次刷盘 redo log 记录到**日志文件组**中，`write pos` 位置就会后移更新。
-每次 `MySQL` 加载**日志文件组**恢复数据时，会清空加载过的 `redo log` 记录，并把 `checkpoint` 后移更新。
+每次 MySQL 加载**日志文件组**恢复数据时，会清空加载过的 redo log 记录，并把 `checkpoint` 后移更新。
-`write pos` 和 `checkpoint` 之间的还空着的部分可以用来写入新的 `redo log` 记录。
+`write pos` 和 `checkpoint` 之间的还空着的部分可以用来写入新的 redo log 记录。
-如果 `write pos` 追上 `checkpoint` ，表示**日志文件组**满了，这时候不能再写入新的 `redo log` 记录，`MySQL` 得停下来，清空一些记录，把 `checkpoint` 推进一下。
+如果 `write pos` 追上 `checkpoint` ，表示**日志文件组**满了，这时候不能再写入新的 redo log 记录，MySQL 得停下来，清空一些记录，把 `checkpoint` 推进一下。
@@ -172,9 +172,9 @@ MySQL830 mysql:8.0.32
### redo log 小结
-相信大家都知道 `redo log` 的作用和它的刷盘时机、存储形式。
+相信大家都知道 redo log 的作用和它的刷盘时机、存储形式。
-现在我们来思考一个问题：**只要每次把修改后的数据页直接刷盘不就好了，还有 `redo log` 什么事？**
+现在我们来思考一个问题：**只要每次把修改后的数据页直接刷盘不就好了，还有 redo log 什么事？**
它们不都是刷盘么？差别在哪里？
@@ -190,32 +190,32 @@ MySQL830 mysql:8.0.32
而且数据页刷盘是随机写，因为一个数据页对应的位置可能在硬盘文件的随机位置，所以性能是很差。
-如果是写 `redo log`，一行记录可能就占几十 `Byte`，只包含表空间号、数据页号、磁盘文件偏移
+如果是写 redo log，一行记录可能就占几十 `Byte`，只包含表空间号、数据页号、磁盘文件偏移
量、更新值，再加上是顺序写，所以刷盘速度很快。
-所以用 `redo log` 形式记录修改内容，性能会远远超过刷数据页的方式，这也让数据库的并发能力更强。
+所以用 redo log 形式记录修改内容，性能会远远超过刷数据页的方式，这也让数据库的并发能力更强。
> 其实内存的数据页在一定时机也会刷盘，我们把这称为页合并，讲 `Buffer Pool`的时候会对这块细说
## binlog
-`redo log` 它是物理日志，记录内容是“在某个数据页上做了什么修改”，属于 `InnoDB` 存储引擎。
+redo log 它是物理日志，记录内容是“在某个数据页上做了什么修改”，属于 InnoDB 存储引擎。
-而 `binlog` 是逻辑日志，记录内容是语句的原始逻辑，类似于“给 ID=2 这一行的 c 字段加 1”，属于`MySQL Server` 层。
+而 binlog 是逻辑日志，记录内容是语句的原始逻辑，类似于“给 ID=2 这一行的 c 字段加 1”，属于`MySQL Server` 层。
-不管用什么存储引擎，只要发生了表数据更新，都会产生 `binlog` 日志。
+不管用什么存储引擎，只要发生了表数据更新，都会产生 binlog 日志。
-那 `binlog` 到底是用来干嘛的？
+那 binlog 到底是用来干嘛的？
-可以说`MySQL`数据库的**数据备份、主备、主主、主从**都离不开`binlog`，需要依靠`binlog`来同步数据，保证数据一致性。
+可以说 MySQL 数据库的**数据备份、主备、主主、主从**都离不开 binlog，需要依靠 binlog 来同步数据，保证数据一致性。
-`binlog`会记录所有涉及更新数据的逻辑操作，并且是顺序写。
+binlog 会记录所有涉及更新数据的逻辑操作，并且是顺序写。
### 记录格式
-`binlog` 日志有三种格式，可以通过`binlog_format`参数指定。
+binlog 日志有三种格式，可以通过`binlog_format`参数指定。
- **statement**
- **row**
@@ -237,21 +237,21 @@ MySQL830 mysql:8.0.32
这样就能保证同步数据的一致性，通常情况下都是指定为`row`，这样可以为数据库的恢复与同步带来更好的可靠性。
-但是这种格式，需要更大的容量来记录，比较占用空间，恢复与同步时会更消耗`IO`资源，影响执行速度。
+但是这种格式，需要更大的容量来记录，比较占用空间，恢复与同步时会更消耗 IO 资源，影响执行速度。
所以就有了一种折中的方案，指定为`mixed`，记录的内容是前两者的混合。
-`MySQL`会判断这条`SQL`语句是否可能引起数据不一致，如果是，就用`row`格式，否则就用`statement`格式。
+MySQL 会判断这条`SQL`语句是否可能引起数据不一致，如果是，就用`row`格式，否则就用`statement`格式。
### 写入机制
-`binlog`的写入时机也非常简单，事务执行过程中，先把日志写到`binlog cache`，事务提交的时候，再把`binlog cache`写到`binlog`文件中。
+binlog 的写入时机也非常简单，事务执行过程中，先把日志写到`binlog cache`，事务提交的时候，再把`binlog cache`写到 binlog 文件中。
-因为一个事务的`binlog`不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为`binlog cache`。
+因为一个事务的 binlog 不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为`binlog cache`。
我们可以通过`binlog_cache_size`参数控制单个线程 binlog cache 大小，如果存储内容超过了这个参数，就要暂存到磁盘（`Swap`）。
-`binlog`日志刷盘流程如下
+binlog 日志刷盘流程如下
@@ -272,57 +272,63 @@ MySQL830 mysql:8.0.32
-在出现`IO`瓶颈的场景里，将`sync_binlog`设置成一个比较大的值，可以提升性能。
+在出现 IO 瓶颈的场景里，将`sync_binlog`设置成一个比较大的值，可以提升性能。
-同样的，如果机器宕机，会丢失最近`N`个事务的`binlog`日志。
+同样的，如果机器宕机，会丢失最近`N`个事务的 binlog 日志。
## 两阶段提交
-`redo log`（重做日志）让`InnoDB`存储引擎拥有了崩溃恢复能力。
+redo log（重做日志）让 InnoDB 存储引擎拥有了崩溃恢复能力。
-`binlog`（归档日志）保证了`MySQL`集群架构的数据一致性。
+binlog（归档日志）保证了 MySQL 集群架构的数据一致性。
虽然它们都属于持久化的保证，但是侧重点不同。
-在执行更新语句过程，会记录`redo log`与`binlog`两块日志，以基本的事务为单位，`redo log`在事务执行过程中可以不断写入，而`binlog`只有在提交事务时才写入，所以`redo log`与`binlog`的写入时机不一样。
+在执行更新语句过程，会记录 redo log 与 binlog 两块日志，以基本的事务为单位，redo log 在事务执行过程中可以不断写入，而 binlog 只有在提交事务时才写入，所以 redo log 与 binlog 的写入时机不一样。
-回到正题，`redo log`与`binlog`两份日志之间的逻辑不一致，会出现什么问题？
+回到正题，redo log 与 binlog 两份日志之间的逻辑不一致，会出现什么问题？
我们以`update`语句为例，假设`id=2`的记录，字段`c`值是`0`，把字段`c`值更新成`1`，`SQL`语句为`update T set c=1 where id=2`。
-假设执行过程中写完`redo log`日志后，`binlog`日志写期间发生了异常，会出现什么情况呢？
+假设执行过程中写完 redo log 日志后，binlog 日志写期间发生了异常，会出现什么情况呢？
-由于`binlog`没写完就异常，这时候`binlog`里面没有对应的修改记录。因此，之后用`binlog`日志恢复数据时，就会少这一次更新，恢复出来的这一行`c`值是`0`，而原库因为`redo log`日志恢复，这一行`c`值是`1`，最终数据不一致。
+由于 binlog 没写完就异常，这时候 binlog 里面没有对应的修改记录。因此，之后用 binlog 日志恢复数据时，就会少这一次更新，恢复出来的这一行`c`值是`0`，而原库因为 redo log 日志恢复，这一行`c`值是`1`，最终数据不一致。
-为了解决两份日志之间的逻辑一致问题，`InnoDB`存储引擎使用**两阶段提交**方案。
+为了解决两份日志之间的逻辑一致问题，InnoDB 存储引擎使用**两阶段提交**方案。
-原理很简单，将`redo log`的写入拆成了两个步骤`prepare`和`commit`，这就是**两阶段提交**。
+原理很简单，将 redo log 的写入拆成了两个步骤`prepare`和`commit`，这就是**两阶段提交**。
-使用**两阶段提交**后，写入`binlog`时发生异常也不会有影响，因为`MySQL`根据`redo log`日志恢复数据时，发现`redo log`还处于`prepare`阶段，并且没有对应`binlog`日志，就会回滚该事务。
+使用**两阶段提交**后，写入 binlog 时发生异常也不会有影响，因为 MySQL 根据 redo log 日志恢复数据时，发现 redo log 还处于`prepare`阶段，并且没有对应 binlog 日志，就会回滚该事务。
-再看一个场景，`redo log`设置`commit`阶段发生异常，那会不会回滚事务呢？
+再看一个场景，redo log 设置`commit`阶段发生异常，那会不会回滚事务呢？
-并不会回滚事务，它会执行上图框住的逻辑，虽然`redo log`是处于`prepare`阶段，但是能通过事务`id`找到对应的`binlog`日志，所以`MySQL`认为是完整的，就会提交事务恢复数据。
+并不会回滚事务，它会执行上图框住的逻辑，虽然 redo log 是处于`prepare`阶段，但是能通过事务`id`找到对应的 binlog 日志，所以 MySQL 认为是完整的，就会提交事务恢复数据。
## undo log
> 这部分内容为 JavaGuide 的补充：
-我们知道如果想要保证事务的原子性，就需要在异常发生时，对已经执行的操作进行**回滚**，在 MySQL 中，恢复机制是通过 **回滚日志（undo log）** 实现的，所有事务进行的修改都会先记录到这个回滚日志中，然后再执行相关的操作。如果执行过程中遇到异常的话，我们直接利用 **回滚日志** 中的信息将数据回滚到修改之前的样子即可！并且，回滚日志会先于数据持久化到磁盘上。这样就保证了即使遇到数据库突然宕机等情况，当用户再次启动数据库的时候，数据库还能够通过查询回滚日志来回滚将之前未完成的事务。
+每一个事务对数据的修改都会被记录到 undo log ，当执行事务过程中出现错误或者需要执行回滚操作的话，MySQL 可以利用 undo log 将数据恢复到事务开始之前的状态。
-另外，`MVCC` 的实现依赖于：**隐藏字段、Read View、undo log**。在内部实现中，`InnoDB` 通过数据行的 `DB_TRX_ID` 和 `Read View` 来判断数据的可见性，如不可见，则通过数据行的 `DB_ROLL_PTR` 找到 `undo log` 中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事务中，用户只能看到该事务创建 `Read View` 之前已经提交的修改和该事务本身做的修改
+undo log 属于逻辑日志，记录的是 SQL 语句，比如说事务执行一条 DELETE 语句，那 undo log 就会记录一条相对应的 INSERT 语句。同时，undo log 的信息也会被记录到 redo log 中，因为 undo log 也要实现持久性保护。并且，undo-log 本身是会被删除清理的，例如 INSERT 操作，在事务提交之后就可以清除掉了；UPDATE/DELETE 操作在事务提交不会立即删除，会加入 history list，由后台线程 purge 进行清理。
+
+undo log 是采用 segment（段）的方式来记录的，每个 undo 操作在记录的时候占用一个 **undo log segment**（undo 日志段），undo log segment 包含在 **rollback segment**（回滚段）中。事务开始时，需要为其分配一个 rollback segment。每个 rollback segment 有 1024 个 undo log segment，这有助于管理多个并发事务的回滚需求。
+
+通常情况下， **rollback segment header**（通常在回滚段的第一个页）负责管理 rollback segment。rollback segment header 是 rollback segment 的一部分，通常在回滚段的第一个页。**history list** 是 rollback segment header 的一部分，它的主要作用是记录所有已经提交但还没有被清理（purge）的事务的 undo log。这个列表使得 purge 线程能够找到并清理那些不再需要的 undo log 记录。
+
+另外，`MVCC` 的实现依赖于：**隐藏字段、Read View、undo log**。在内部实现中，InnoDB 通过数据行的 `DB_TRX_ID` 和 `Read View` 来判断数据的可见性，如不可见，则通过数据行的 `DB_ROLL_PTR` 找到 undo log 中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事务中，用户只能看到该事务创建 `Read View` 之前已经提交的修改和该事务本身做的修改
## 总结
@@ -330,7 +336,7 @@ MySQL830 mysql:8.0.32
MySQL InnoDB 引擎使用 **redo log(重做日志)** 保证事务的**持久性**，使用 **undo log(回滚日志)** 来保证事务的**原子性**。
-`MySQL`数据库的**数据备份、主备、主主、主从**都离不开`binlog`，需要依靠`binlog`来同步数据，保证数据一致性。
+MySQL 数据库的**数据备份、主备、主主、主从**都离不开 binlog，需要依靠 binlog 来同步数据，保证数据一致性。
## 参考
diff --git a/docs/database/mysql/mysql-query-execution-plan.md b/docs/database/mysql/mysql-query-execution-plan.md
index 48eb5a1e5ed..8866737b934 100644
--- a/docs/database/mysql/mysql-query-execution-plan.md
+++ b/docs/database/mysql/mysql-query-execution-plan.md
@@ -18,7 +18,7 @@ head:
## 什么是执行计划？
-**执行计划** 是指一条 SQL 语句在经过 **MySQL 查询优化器** 的优化会后，具体的执行方式。
+**执行计划** 是指一条 SQL 语句在经过 **MySQL 查询优化器** 的优化后，具体的执行方式。
执行计划通常用于 SQL 性能分析、优化等场景。通过 `EXPLAIN` 的结果，可以了解到如数据表的查询顺序、数据查询操作的操作类型、哪些索引可以被命中、哪些索引实际会命中、每个数据表有多少行记录被查询等信息。
@@ -69,7 +69,7 @@ mysql> explain SELECT * FROM dept_emp WHERE emp_no IN (SELECT emp_no FROM dept_e
### id
-SELECT 标识符，是查询中 SELECT 的序号，用来标识整个查询中 SELELCT 语句的顺序。
+`SELECT` 标识符，用于标识每个 `SELECT` 语句的执行顺序。
id 如果相同，从上往下依次执行。id 不同，id 值越大，执行优先级越高，如果行引用其他行的并集结果，则该值可以为 NULL。
@@ -94,7 +94,9 @@ id 如果相同，从上往下依次执行。id 不同，id 值越大，执行
### type（重要）
-查询执行的类型，描述了查询是如何执行的。所有值的顺序从最优到最差排序为：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
+查询执行的类型，描述了查询是如何执行的。所有值的顺序从最优到最差排序为：
+
+system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
常见的几种类型具体含义如下：
diff --git a/docs/database/mysql/mysql-questions-01.md b/docs/database/mysql/mysql-questions-01.md
index d0f0568ea53..7f93eb605e6 100644
--- a/docs/database/mysql/mysql-questions-01.md
+++ b/docs/database/mysql/mysql-questions-01.md
@@ -158,19 +158,28 @@ DATETIME 类型没有时区信息，TIMESTAMP 和时区有关。
TIMESTAMP 只需要使用 4 个字节的存储空间，但是 DATETIME 需要耗费 8 个字节的存储空间。但是，这样同样造成了一个问题，Timestamp 表示的时间范围更小。
-- DATETIME：1000-01-01 00:00:00 ~ 9999-12-31 23:59:59
-- Timestamp：1970-01-01 00:00:01 ~ 2037-12-31 23:59:59
+- DATETIME：'1000-01-01 00:00:00.000000' 到 '9999-12-31 23:59:59.999999'
+- Timestamp：'1970-01-01 00:00:01.000000' UTC 到 '2038-01-19 03:14:07.999999' UTC
-关于两者的详细对比，请参考我写的[MySQL 时间类型数据存储建议](./some-thoughts-on-database-storage-time.md)。
+关于两者的详细对比，请参考我写的 [MySQL 时间类型数据存储建议](./some-thoughts-on-database-storage-time.md)。
### NULL 和 '' 的区别是什么？
-`NULL` 跟 `''`(空字符串)是两个完全不一样的值，区别如下：
-
-- `NULL` 代表一个不确定的值,就算是两个 `NULL`,它俩也不一定相等。例如，`SELECT NULL=NULL`的结果为 false，但是在我们使用`DISTINCT`,`GROUP BY`,`ORDER BY`时,`NULL`又被认为是相等的。
-- `''`的长度是 0，是不占用空间的，而`NULL` 是需要占用空间的。
-- `NULL` 会影响聚合函数的结果。例如，`SUM`、`AVG`、`MIN`、`MAX` 等聚合函数会忽略 `NULL` 值。 `COUNT` 的处理方式取决于参数的类型。如果参数是 `*`(`COUNT(*)`)，则会统计所有的记录数，包括 `NULL` 值；如果参数是某个字段名(`COUNT(列名)`)，则会忽略 `NULL` 值，只统计非空值的个数。
-- 查询 `NULL` 值时，必须使用 `IS NULL` 或 `IS NOT NULLl` 来判断，而不能使用 =、!=、 <、> 之类的比较运算符。而`''`是可以使用这些比较运算符的。
+`NULL` 和 `''` (空字符串) 是两个完全不同的值，它们分别表示不同的含义，并在数据库中有着不同的行为。`NULL` 代表缺失或未知的数据，而 `''` 表示一个已知存在的空字符串。它们的主要区别如下：
+
+1. **含义**:
+ - `NULL` 代表一个不确定的值，它不等于任何值，包括它自身。因此，`SELECT NULL = NULL` 的结果是 `NULL`，而不是 `true` 或 `false`。 `NULL` 意味着缺失或未知的信息。虽然 `NULL` 不等于任何值，但在某些操作中，数据库系统会将 `NULL` 值视为相同的类别进行处理，例如：`DISTINCT`,`GROUP BY`,`ORDER BY`。需要注意的是，这些操作将 `NULL` 值视为相同的类别进行处理，并不意味着 `NULL` 值之间是相等的。 它们只是在特定操作中被特殊处理，以保证结果的正确性和一致性。 这种处理方式是为了方便数据操作，而不是改变了 `NULL` 的语义。
+ - `''` 表示一个空字符串，它是一个已知的值。
+2. **存储空间**:
+ - `NULL` 的存储空间占用取决于数据库的实现，通常需要一些空间来标记该值为空。
+ - `''` 的存储空间占用通常较小，因为它只存储一个空字符串的标志，不需要存储实际的字符。
+3. **比较运算**:
+ - 任何值与 `NULL` 进行比较（例如 `=`, `!=`, `>`, `<` 等）的结果都是 `NULL`，表示结果不确定。要判断一个值是否为 `NULL`，必须使用 `IS NULL` 或 `IS NOT NULL`。
+ - `''` 可以像其他字符串一样进行比较运算。例如，`'' = ''` 的结果是 `true`。
+4. **聚合函数**:
+ - 大多数聚合函数（例如 `SUM`, `AVG`, `MIN`, `MAX`）会忽略 `NULL` 值。
+ - `COUNT(*)` 会统计所有行数，包括包含 `NULL` 值的行。`COUNT(列名)` 会统计指定列中非 `NULL` 值的行数。
+ - 空字符串 `''` 会被聚合函数计算在内。例如，`SUM` 会将其视为 0，`MIN` 和 `MAX` 会将其视为一个空字符串。
看了上面的介绍之后，相信你对另外一个高频面试题：“为什么 MySQL 不建议使用 `NULL` 作为列默认值？”也有了答案。
@@ -178,6 +187,37 @@ TIMESTAMP 只需要使用 4 个字节的存储空间，但是 DATETIME 需要耗
MySQL 中没有专门的布尔类型，而是用 TINYINT(1) 类型来表示布尔值。TINYINT(1) 类型可以存储 0 或 1，分别对应 false 或 true。
+### 手机号存储用 INT 还是 VARCHAR？
+
+存储手机号，**强烈推荐使用 VARCHAR 类型**，而不是 INT 或 BIGINT。主要原因如下：
+
+1. **格式兼容性与完整性：**
+ - 手机号可能包含前导零（如某些地区的固话区号）、国家代码前缀（'+'），甚至可能带有分隔符（'-' 或空格）。INT 或 BIGINT 这种数字类型会自动丢失这些重要的格式信息（比如前导零会被去掉，'+' 和 '-' 无法存储）。
+ - VARCHAR 可以原样存储各种格式的号码，无论是国内的 11 位手机号，还是带有国家代码的国际号码，都能完美兼容。
+2. **非算术性：**手机号虽然看起来是数字，但我们从不对它进行数学运算（比如求和、平均值）。它本质上是一个标识符，更像是一个字符串。用 VARCHAR 更符合其数据性质。
+3. **查询灵活性：**
+ - 业务中常常需要根据号段（前缀）进行查询，例如查找所有 "138" 开头的用户。使用 VARCHAR 类型配合 `LIKE '138%'` 这样的 SQL 查询既直观又高效。
+ - 如果使用数字类型，进行类似的前缀匹配通常需要复杂的函数转换（如 CAST 或 SUBSTRING），或者使用范围查询（如 `WHERE phone >= 13800000000 AND phone < 13900000000`），这不仅写法繁琐，而且可能无法有效利用索引，导致性能下降。
+4. **加密存储的要求（非常关键）：**
+ - 出于数据安全和隐私合规的要求，手机号这类敏感个人信息通常必须加密存储在数据库中。
+ - 加密后的数据（密文）是一长串字符串（通常由字母、数字、符号组成，或经过 Base64/Hex 编码），INT 或 BIGINT 类型根本无法存储这种密文。只有 VARCHAR、TEXT 或 BLOB 等类型可以。
+
+**关于 VARCHAR 长度的选择：**
+
+- **如果不加密存储（强烈不推荐！）：** 考虑到国际号码和可能的格式符，VARCHAR(20) 到 VARCHAR(32) 通常是一个比较安全的范围，足以覆盖全球绝大多数手机号格式。VARCHAR(15) 可能对某些带国家码和格式符的号码来说不够用。
+- **如果进行加密存储（推荐的标准做法）：** 长度必须根据所选加密算法产生的密文最大长度，以及可能的编码方式（如 Base64 会使长度增加约 1/3）来精确计算和设定。通常会需要更长的 VARCHAR 长度，例如 VARCHAR(128), VARCHAR(256) 甚至更长。
+
+最后，来一张表格总结一下：
+
+| 对比维度 | VARCHAR 类型（推荐） | INT/BIGINT 类型（不推荐） | 说明/备注 |
+| ---------------- | --------------------------------- | ---------------------------- | --------------------------------------------------------------------------- |
+| **格式兼容性** | ✔ 能存前导零、"+"、"-"、空格等 | ✘ 自动丢失前导零，不能存符号 | VARCHAR 能原样存储各种手机号格式，INT/BIGINT 只支持单纯数字，且前导零会消失 |
+| **完整性** | ✔ 不丢失任何格式信息 | ✘ 丢失格式信息 | 例如 "013800012345" 存进 INT 会变成 13800012345，"+" 也无法存储 |
+| **非算术性** | ✔ 适合存储“标识符” | ✘ 只适合做数值运算 | 手机号本质是字符串标识符，不做数学运算，VARCHAR 更贴合实际用途 |
+| **查询灵活性** | ✔ 支持 `LIKE '138%'` 等 | ✘ 查询前缀不方便或性能差 | 使用 VARCHAR 可高效按号段/前缀查询，数字类型需转为字符串或其他复杂处理 |
+| **加密存储支持** | ✔ 可存储加密密文（字母、符号等） | ✘ 无法存储密文 | 加密手机号后密文是字符串/二进制，只有 VARCHAR、TEXT、BLOB 等能兼容 |
+| **长度设置建议** | 15~20（未加密），加密视情况而定 | 无意义 | 不加密时 VARCHAR(15~20) 通用，加密后长度取决于算法和编码方式 |
+
## MySQL 基础架构
> 建议配合 [SQL 语句在 MySQL 中的执行过程](./how-sql-executed-in-mysql.md) 这篇文章来理解 MySQL 基础架构。另外，“一个 SQL 语句在 MySQL 中的执行流程”也是面试中比较常问的一个问题。
@@ -193,7 +233,7 @@ MySQL 中没有专门的布尔类型，而是用 TINYINT(1) 类型来表示布
- **分析器：** 没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。
- **优化器：** 按照 MySQL 认为最优的方案去执行。
- **执行器：** 执行语句，然后从存储引擎返回数据。 执行语句之前会先判断是否有权限，如果没有权限的话，就会报错。
-- **插件式存储引擎**：主要负责数据的存储和读取，采用的是插件式架构，支持 InnoDB、MyISAM、Memory 等多种存储引擎。
+- **插件式存储引擎**：主要负责数据的存储和读取，采用的是插件式架构，支持 InnoDB、MyISAM、Memory 等多种存储引擎。InnoDB 是 MySQL 的默认存储引擎，绝大部分场景使用 InnoDB 就是最好的选择。
## MySQL 存储引擎
@@ -249,7 +289,11 @@ mysql> SHOW VARIABLES LIKE '%storage_engine%';
MySQL 存储引擎采用的是 **插件式架构** ，支持多种存储引擎，我们甚至可以为不同的数据库表设置不同的存储引擎以适应不同场景的需要。**存储引擎是基于表的，而不是数据库。**
-并且，你还可以根据 MySQL 定义的存储引擎实现标准接口来编写一个属于自己的存储引擎。这些非官方提供的存储引擎可以称为第三方存储引擎，区别于官方存储引擎。像目前最常用的 InnoDB 其实刚开始就是一个第三方存储引擎，后面由于过于优秀，其被 Oracle 直接收购了。
+下图展示了具有可插拔存储引擎的 MySQL 架构（）：
+
+
+
+你还可以根据 MySQL 定义的存储引擎实现标准接口来编写一个属于自己的存储引擎。这些非官方提供的存储引擎可以称为第三方存储引擎，区别于官方存储引擎。像目前最常用的 InnoDB 其实刚开始就是一个第三方存储引擎，后面由于过于优秀，其被 Oracle 直接收购了。
MySQL 官方文档也有介绍到如何编写一个自定义存储引擎，地址： 。
@@ -263,13 +307,13 @@ MySQL 5.5 版本之后，InnoDB 是 MySQL 的默认存储引擎。
言归正传！咱们下面还是来简单对比一下两者：
-**1.是否支持行级锁**
+**1、是否支持行级锁**
MyISAM 只有表级锁(table-level locking)，而 InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。
也就说，MyISAM 一锁就是锁住了整张表，这在并发写的情况下是多么滴憨憨啊！这也是为什么 InnoDB 在并发写的时候，性能更牛皮了！
-**2.是否支持事务**
+**2、是否支持事务**
MyISAM 不提供事务支持。
@@ -277,7 +321,7 @@ InnoDB 提供事务支持，实现了 SQL 标准定义了四个隔离级别，
关于 MySQL 事务的详细介绍，可以看看我写的这篇文章：[MySQL 事务隔离级别详解](./transaction-isolation-level.md)。
-**3.是否支持外键**
+**3、是否支持外键**
MyISAM 不支持，而 InnoDB 支持。
@@ -291,19 +335,19 @@ MyISAM 不支持，而 InnoDB 支持。
总结：一般我们也是不建议在数据库层面使用外键的，应用层面可以解决。不过，这样会对数据的一致性造成威胁。具体要不要使用外键还是要根据你的项目来决定。
-**4.是否支持数据库异常崩溃后的安全恢复**
+**4、是否支持数据库异常崩溃后的安全恢复**
MyISAM 不支持，而 InnoDB 支持。
使用 InnoDB 的数据库在异常崩溃后，数据库重新启动的时候会保证数据库恢复到崩溃前的状态。这个恢复的过程依赖于 `redo log` 。
-**5.是否支持 MVCC**
+**5、是否支持 MVCC**
MyISAM 不支持，而 InnoDB 支持。
讲真，这个对比有点废话，毕竟 MyISAM 连行级锁都不支持。MVCC 可以看作是行级锁的一个升级，可以有效减少加锁操作，提高性能。
-**6.索引实现不一样。**
+**6、索引实现不一样。**
虽然 MyISAM 引擎和 InnoDB 引擎都是使用 B+Tree 作为索引结构，但是两者的实现方式不太一样。
@@ -311,12 +355,16 @@ InnoDB 引擎中，其数据文件本身就是索引文件。相比 MyISAM，索
详细区别，推荐你看看我写的这篇文章：[MySQL 索引详解](./mysql-index.md)。
-**7.性能有差别。**
+**7、性能有差别。**
InnoDB 的性能比 MyISAM 更强大，不管是在读写混合模式下还是只读模式下，随着 CPU 核数的增加，InnoDB 的读写能力呈线性增长。MyISAM 因为读写不能并发，它的处理能力跟核数没关系。
+**8、数据缓存策略和机制实现不同。**
+
+InnoDB 使用缓冲池（Buffer Pool）缓存数据页和索引页，MyISAM 使用键缓存（Key Cache）仅缓存索引页而不缓存数据页。
+
**总结**：
- InnoDB 支持行级别的锁粒度，MyISAM 不支持，只支持表级别的锁粒度。
@@ -333,15 +381,13 @@ InnoDB 的性能比 MyISAM 更强大，不管是在读写混合模式下还是
### MyISAM 和 InnoDB 如何选择？
-大多数时候我们使用的都是 InnoDB 存储引擎，在某些读密集的情况下，使用 MyISAM 也是合适的。不过，前提是你的项目不介意 MyISAM 不支持事务、崩溃恢复等缺点（可是~我们一般都会介意啊！）。
+大多数时候我们使用的都是 InnoDB 存储引擎，在某些读密集的情况下，使用 MyISAM 也是合适的。不过，前提是你的项目不介意 MyISAM 不支持事务、崩溃恢复等缺点（可是~我们一般都会介意啊）。
《MySQL 高性能》上面有一句话这样写到:
> 不要轻易相信“MyISAM 比 InnoDB 快”之类的经验之谈，这个结论往往不是绝对的。在很多我们已知场景中，InnoDB 的速度都可以让 MyISAM 望尘莫及，尤其是用到了聚簇索引，或者需要访问的数据都可以放入内存的应用。
-一般情况下我们选择 InnoDB 都是没有问题的，但是某些情况下你并不在乎可扩展能力和并发能力，也不需要事务支持，也不在乎崩溃后的安全恢复问题的话，选择 MyISAM 也是一个不错的选择。但是一般情况下，我们都是需要考虑到这些问题的。
-
-因此，对于咱们日常开发的业务系统来说，你几乎找不到什么理由再使用 MyISAM 作为自己的 MySQL 数据库的存储引擎。
+因此，对于咱们日常开发的业务系统来说，你几乎找不到什么理由使用 MyISAM 了，老老实实用默认的 InnoDB 就可以了！
## MySQL 索引
@@ -349,7 +395,7 @@ MySQL 索引相关的问题比较多，对于面试和工作都比较重要，
## MySQL 查询缓存
-执行查询语句的时候，会先查询缓存。不过，MySQL 8.0 版本后移除，因为这个功能不太实用
+MySQL 查询缓存是查询结果缓存。执行查询语句的时候，会先查询缓存，如果缓存中有对应的查询结果，就会直接返回。
`my.cnf` 加入以下配置，重启 MySQL 开启查询缓存
@@ -365,7 +411,7 @@ set global query_cache_type=1;
set global query_cache_size=600000;
```
-如上，**开启查询缓存后在同样的查询条件以及数据情况下，会直接在缓存中返回结果**。这里的查询条件包括查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息。
+查询缓存会在同样的查询条件和数据情况下，直接返回缓存中的结果。但需要注意的是，查询缓存的匹配条件非常严格，任何细微的差异都会导致缓存无法命中。这里的查询条件包括查询语句本身、当前使用的数据库、以及其他可能影响结果的因素，如客户端协议版本号等。
**查询缓存不命中的情况：**
@@ -373,12 +419,16 @@ set global query_cache_size=600000;
2. 如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、MySQL 库中的系统表，其查询结果也不会被缓存。
3. 缓存建立之后，MySQL 的查询缓存系统会跟踪查询中涉及的每张表，如果这些表（数据或结构）发生变化，那么和这张表相关的所有缓存数据都将失效。
-**缓存虽然能够提升数据库的查询性能，但是缓存同时也带来了额外的开销，每次查询后都要做一次缓存操作，失效后还要销毁。** 因此，开启查询缓存要谨慎，尤其对于写密集的应用来说更是如此。如果开启，要注意合理控制缓存空间大小，一般来说其大小设置为几十 MB 比较合适。此外，**还可以通过 `sql_cache` 和 `sql_no_cache` 来控制某个查询语句是否需要缓存：**
+**缓存虽然能够提升数据库的查询性能，但是缓存同时也带来了额外的开销，每次查询后都要做一次缓存操作，失效后还要销毁。** 因此，开启查询缓存要谨慎，尤其对于写密集的应用来说更是如此。如果开启，要注意合理控制缓存空间大小，一般来说其大小设置为几十 MB 比较合适。此外，还可以通过 `sql_cache` 和 `sql_no_cache` 来控制某个查询语句是否需要缓存：
```sql
SELECT sql_no_cache COUNT(*) FROM usr;
```
+MySQL 5.6 开始，查询缓存已默认禁用。MySQL 8.0 开始，已经不再支持查询缓存了（具体可以参考这篇文章：[MySQL 8.0: Retiring Support for the Query Cache](https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/)）。
+
+
+
## MySQL 日志
MySQL 日志常见的面试题有：
@@ -508,7 +558,7 @@ COMMIT;
- 不可重复读的重点是内容修改或者记录减少比如多次读取一条记录发现其中某些记录的值被修改；
- 幻读的重点在于记录新增比如多次执行同一条查询语句（DQL）时，发现查到的记录增加了。
-幻读其实可以看作是不可重复读的一种特殊情况，单独把区分幻读的原因主要是解决幻读和不可重复读的方案不一样。
+幻读其实可以看作是不可重复读的一种特殊情况，单独把幻读区分出来的原因主要是解决幻读和不可重复读的方案不一样。
举个例子：执行 `delete` 和 `update` 操作的时候，可以直接对记录加锁，保证事务安全。而执行 `insert` 操作的时候，由于记录锁（Record Lock）只能锁住已经存在的记录，为了避免插入新记录，需要依赖间隙锁（Gap Lock）。也就是说执行 `insert` 操作的时候需要依赖 Next-Key Lock（Record Lock+Gap Lock） 进行加锁来保证不出现幻读。
@@ -516,7 +566,7 @@ COMMIT;
MySQL 中并发事务的控制方式无非就两种：**锁** 和 **MVCC**。锁可以看作是悲观控制的模式，多版本并发控制（MVCC，Multiversion concurrency control）可以看作是乐观控制的模式。
-**锁** 控制方式下会通过锁来显示控制共享资源而不是通过调度手段，MySQL 中主要是通过 **读写锁** 来实现并发控制。
+**锁** 控制方式下会通过锁来显式控制共享资源而不是通过调度手段，MySQL 中主要是通过 **读写锁** 来实现并发控制。
- **共享锁（S 锁）**：又称读锁，事务在读取记录的时候获取共享锁，允许多个事务同时获取（锁兼容）。
- **排他锁（X 锁）**：又称写锁/独占锁，事务在修改记录的时候获取排他锁，不允许多个事务同时获取。如果一个记录已经被加了排他锁，那其他事务不能再对这条记录加任何类型的锁（锁不兼容）。
@@ -534,31 +584,26 @@ MVCC 在 MySQL 中实现所依赖的手段主要是: **隐藏字段、read view
### SQL 标准定义了哪些事务隔离级别?
-SQL 标准定义了四个隔离级别：
+SQL 标准定义了四种事务隔离级别，用来平衡事务的隔离性（Isolation）和并发性能。级别越高，数据一致性越好，但并发性能可能越低。这四个级别是：
-- **READ-UNCOMMITTED(读取未提交)** ：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
-- **READ-COMMITTED(读取已提交)** ：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
-- **REPEATABLE-READ(可重复读)** ：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
+- **READ-UNCOMMITTED(读取未提交)** ：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。这种级别在实际应用中很少使用，因为它对数据一致性的保证太弱。
+- **READ-COMMITTED(读取已提交)** ：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。这是大多数数据库（如 Oracle, SQL Server）的默认隔离级别。
+- **REPEATABLE-READ(可重复读)** ：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。MySQL InnoDB 存储引擎的默认隔离级别正是 REPEATABLE READ。并且，InnoDB 在此级别下通过 MVCC（多版本并发控制） 和 Next-Key Locks（间隙锁+行锁） 机制，在很大程度上解决了幻读问题。
- **SERIALIZABLE(可串行化)** ：最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
----
-
-| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
-| :--------------: | :--: | :--------: | :--: |
-| READ-UNCOMMITTED | √ | √ | √ |
-| READ-COMMITTED | × | √ | √ |
-| REPEATABLE-READ | × | × | √ |
-| SERIALIZABLE | × | × | × |
-
-### MySQL 的隔离级别是基于锁实现的吗？
-
-MySQL 的隔离级别基于锁和 MVCC 机制共同实现的。
-
-SERIALIZABLE 隔离级别是通过锁来实现的，READ-COMMITTED 和 REPEATABLE-READ 隔离级别是基于 MVCC 实现的。不过， SERIALIZABLE 之外的其他隔离级别可能也需要用到锁机制，就比如 REPEATABLE-READ 在当前读情况下需要使用加锁读来保证不会出现幻读。
+| 隔离级别 | 脏读 (Dirty Read) | 不可重复读 (Non-Repeatable Read) | 幻读 (Phantom Read) |
+| ---------------- | ----------------- | -------------------------------- | ---------------------- |
+| READ UNCOMMITTED | √ | √ | √ |
+| READ COMMITTED | × | √ | √ |
+| REPEATABLE READ | × | × | √ (标准) / ≈× (InnoDB) |
+| SERIALIZABLE | × | × | × |
### MySQL 的默认隔离级别是什么?
-MySQL InnoDB 存储引擎的默认支持的隔离级别是 **REPEATABLE-READ（可重读）**。我们可以通过`SELECT @@tx_isolation;`命令来查看，MySQL 8.0 该命令改为`SELECT @@transaction_isolation;`
+MySQL InnoDB 存储引擎的默认隔离级别是 **REPEATABLE READ**。可以通过以下命令查看：
+
+- MySQL 8.0 之前：`SELECT @@tx_isolation;`
+- MySQL 8.0 及之后：`SELECT @@transaction_isolation;`
```sql
mysql> SELECT @@tx_isolation;
@@ -571,6 +616,12 @@ mysql> SELECT @@tx_isolation;
关于 MySQL 事务隔离级别的详细介绍，可以看看我写的这篇文章：[MySQL 事务隔离级别详解](./transaction-isolation-level.md)。
+### MySQL 的隔离级别是基于锁实现的吗？
+
+MySQL 的隔离级别基于锁和 MVCC 机制共同实现的。
+
+SERIALIZABLE 隔离级别是通过锁来实现的，READ-COMMITTED 和 REPEATABLE-READ 隔离级别是基于 MVCC 实现的。不过， SERIALIZABLE 之外的其他隔离级别可能也需要用到锁机制，就比如 REPEATABLE-READ 在当前读情况下需要使用加锁读来保证不会出现幻读。
+
## MySQL 锁
锁是一种常见的并发事务的控制方式。
@@ -596,7 +647,7 @@ InnoDB 的行锁是针对索引字段加的锁，表级锁是针对非索引字
InnoDB 行锁是通过对索引数据页上的记录加锁实现的，MySQL InnoDB 支持三种行锁定方式：
-- **记录锁（Record Lock）**：也被称为记录锁，属于单个行记录上的锁。
+- **记录锁（Record Lock）**：属于单个行记录上的锁。
- **间隙锁（Gap Lock）**：锁定一个范围，不包括记录本身。
- **临键锁（Next-Key Lock）**：Record Lock+Gap Lock，锁定一个范围，包含记录本身，主要目的是为了解决幻读问题（MySQL 事务部分提到过）。记录锁只能锁住已经存在的记录，为了避免插入新记录，需要依赖间隙锁。
@@ -638,7 +689,7 @@ SELECT ... FOR UPDATE;
- **意向共享锁（Intention Shared Lock，IS 锁）**：事务有意向对表中的某些记录加共享锁（S 锁），加共享锁前必须先取得该表的 IS 锁。
- **意向排他锁（Intention Exclusive Lock，IX 锁）**：事务有意向对表中的某些记录加排他锁（X 锁），加排他锁之前必须先取得该表的 IX 锁。
-**意向锁是由数据引擎自己维护的，用户无法手动操作意向锁，在为数据行加共享/排他锁之前，InooDB 会先获取该数据行所在在数据表的对应意向锁。**
+**意向锁是由数据引擎自己维护的，用户无法手动操作意向锁，在为数据行加共享/排他锁之前，InnoDB 会先获取该数据行所在在数据表的对应意向锁。**
意向锁之间是互相兼容的。
@@ -819,15 +870,44 @@ mysql> EXPLAIN SELECT `score`,`name` FROM `cus_order` ORDER BY `score` DESC;
[数据冷热分离详解](../../high-performance/data-cold-hot-separation.md)
-### 常见的数据库优化方法有哪些？
+### MySQL 性能怎么优化？
+
+MySQL 性能优化是一个系统性工程，涉及多个方面，在面试中不可能面面俱到。因此，建议按照“点-线-面”的思路展开，从核心问题入手，再逐步扩展，展示出你对问题的思考深度和解决能力。
+
+**1. 抓住核心：慢 SQL 定位与分析**
+
+性能优化的第一步永远是找到瓶颈。面试时，建议先从 **慢 SQL 定位和分析** 入手，这不仅能展示你解决问题的思路，还能体现你对数据库性能监控的熟练掌握：
+
+- **监控工具：** 介绍常用的慢 SQL 监控工具，如 **MySQL 慢查询日志**、**Performance Schema** 等，说明你对这些工具的熟悉程度以及如何通过它们定位问题。
+- **EXPLAIN 命令：** 详细说明 `EXPLAIN` 命令的使用，分析查询计划、索引使用情况，可以结合实际案例展示如何解读分析结果，比如执行顺序、索引使用情况、全表扫描等。
+
+**2. 由点及面：索引、表结构和 SQL 优化**
+
+定位到慢 SQL 后，接下来就要针对具体问题进行优化。 这里可以重点介绍索引、表结构和 SQL 编写规范等方面的优化技巧：
+
+- **索引优化：** 这是 MySQL 性能优化的重点，可以介绍索引的创建原则、覆盖索引、最左前缀匹配原则等。如果能结合你项目的实际应用来说明如何选择合适的索引，会更加分一些。
+- **表结构优化：** 优化表结构设计，包括选择合适的字段类型、避免冗余字段、合理使用范式和反范式设计等等。
+- **SQL 优化：** 避免使用 `SELECT *`、尽量使用具体字段、使用连接查询代替子查询、合理使用分页查询、批量操作等，都是 SQL 编写过程中需要注意的细节。
+
+**3. 进阶方案：架构优化**
+
+当面试官对基础优化知识比较满意时，可能会深入探讨一些架构层面的优化方案。以下是一些常见的架构优化策略：
+
+- **读写分离：** 将读操作和写操作分离到不同的数据库实例，提升数据库的并发处理能力。
+- **分库分表：** 将数据分散到多个数据库实例或数据表中，降低单表数据量，提升查询效率。但要权衡其带来的复杂性和维护成本，谨慎使用。
+- **数据冷热分离**：根据数据的访问频率和业务重要性，将数据分为冷数据和热数据，冷数据一般存储在低成本、低性能的介质中，热数据存储在高性能存储介质中。
+- **缓存机制：** 使用 Redis 等缓存中间件，将热点数据缓存到内存中，减轻数据库压力。这个非常常用，提升效果非常明显，性价比极高！
+
+**4. 其他优化手段**
+
+除了慢 SQL 定位、索引优化和架构优化，还可以提及一些其他优化手段，展示你对 MySQL 性能调优的全面理解：
+
+- **连接池配置：** 配置合理的数据库连接池（如 **连接池大小**、**超时时间** 等），能够有效提升数据库连接的效率，避免频繁的连接开销。
+- **硬件配置：** 提升硬件性能也是优化的重要手段之一。使用高性能服务器、增加内存、使用 **SSD** 硬盘等硬件升级，都可以有效提升数据库的整体性能。
+
+**5.总结**
-- [索引优化](./mysql-index.md)
-- [读写分离和分库分表](../../high-performance/read-and-write-separation-and-library-subtable.md)
-- [数据冷热分离](../../high-performance/data-cold-hot-separation.md)
-- [SQL 优化](../../high-performance/sql-optimization.md)
-- [深度分页优化](../../high-performance/deep-pagination-optimization.md)
-- 适当冗余数据
-- 使用更高的硬件配置
+在面试中，建议按优先级依次介绍慢 SQL 定位、[索引优化](./mysql-index.md)、表结构设计和 [SQL 优化](../../high-performance/sql-optimization.md)等内容。架构层面的优化，如[读写分离和分库分表](../../high-performance/read-and-write-separation-and-library-subtable.md)、[数据冷热分离](../../high-performance/data-cold-hot-separation.md) 应作为最后的手段，除非在特定场景下有明显的性能瓶颈，否则不应轻易使用，因其引入的复杂性会带来额外的维护成本。
## MySQL 学习资料推荐
diff --git a/docs/database/mysql/some-thoughts-on-database-storage-time.md b/docs/database/mysql/some-thoughts-on-database-storage-time.md
index 75329434c1b..e22ce2800da 100644
--- a/docs/database/mysql/some-thoughts-on-database-storage-time.md
+++ b/docs/database/mysql/some-thoughts-on-database-storage-time.md
@@ -3,30 +3,43 @@ title: MySQL日期类型选择建议
category: 数据库
tag:
- MySQL
+head:
+ - - meta
+ - name: keywords
+ content: MySQL 日期类型选择, MySQL 时间存储最佳实践, MySQL 时间存储效率, MySQL DATETIME 和 TIMESTAMP 区别, MySQL 时间戳存储, MySQL 数据库时间存储类型, MySQL 开发日期推荐, MySQL 字符串存储日期的缺点, MySQL 时区设置方法, MySQL 日期范围对比, 高性能 MySQL 日期存储, MySQL UNIX_TIMESTAMP 用法, 数值型时间戳优缺点, MySQL 时间存储性能优化, MySQL TIMESTAMP 时区转换, MySQL 时间格式转换, MySQL 时间存储空间对比, MySQL 时间类型选择建议, MySQL 日期类型性能分析, 数据库时间存储优化
---
-我们平时开发中不可避免的就是要存储时间，比如我们要记录操作表中这条记录的时间、记录转账的交易时间、记录出发时间、用户下单时间等等。你会发现时间这个东西与我们开发的联系还是非常紧密的，用的好与不好会给我们的业务甚至功能带来很大的影响。所以，我们有必要重新出发，好好认识一下这个东西。
+在日常的软件开发工作中，存储时间是一项基础且常见的需求。无论是记录数据的操作时间、金融交易的发生时间，还是行程的出发时间、用户的下单时间等等，时间信息与我们的业务逻辑和系统功能紧密相关。因此，正确选择和使用 MySQL 的日期时间类型至关重要，其恰当与否甚至可能对业务的准确性和系统的稳定性产生显著影响。
+
+本文旨在帮助开发者重新审视并深入理解 MySQL 中不同的时间存储方式，以便做出更合适项目业务场景的选择。
## 不要用字符串存储日期
-和绝大部分对数据库不太了解的新手一样，我在大学的时候就这样干过，甚至认为这样是一个不错的表示日期的方法。毕竟简单直白，容易上手。
+和许多数据库初学者一样，笔者在早期学习阶段也曾尝试使用字符串（如 VARCHAR）类型来存储日期和时间，甚至一度认为这是一种简单直观的方法。毕竟，'YYYY-MM-DD HH:MM:SS' 这样的格式看起来清晰易懂。
但是，这是不正确的做法，主要会有下面两个问题：
-1. 字符串占用的空间更大！
-2. 字符串存储的日期效率比较低（逐个字符进行比对），无法用日期相关的 API 进行计算和比较。
+1. **空间效率**：与 MySQL 内建的日期时间类型相比，字符串通常需要占用更多的存储空间来表示相同的时间信息。
+2. **查询与计算效率低下**：
+ - **比较操作复杂且低效**：基于字符串的日期比较需要按照字典序逐字符进行，这不仅不直观（例如，'2024-05-01' 会小于 '2024-1-10'），而且效率远低于使用原生日期时间类型进行的数值或时间点比较。
+ - **计算功能受限**：无法直接利用数据库提供的丰富日期时间函数进行运算（例如，计算两个日期之间的间隔、对日期进行加减操作等），需要先转换格式，增加了复杂性。
+ - **索引性能不佳**：基于字符串的索引在处理范围查询（如查找特定时间段内的数据）时，其效率和灵活性通常不如原生日期时间类型的索引。
-## Datetime 和 Timestamp 之间的抉择
+## DATETIME 和 TIMESTAMP 选择
-Datetime 和 Timestamp 是 MySQL 提供的两种比较相似的保存时间的数据类型，可以精确到秒。他们两者究竟该如何选择呢？
+`DATETIME` 和 `TIMESTAMP` 是 MySQL 中两种非常常用的、用于存储包含日期和时间信息的数据类型。它们都可以存储精确到秒（MySQL 5.6.4+ 支持更高精度的小数秒）的时间值。那么，在实际应用中，我们应该如何在这两者之间做出选择呢？
-下面我们来简单对比一下二者。
+下面我们从几个关键维度对它们进行对比：
### 时区信息
-**DateTime 类型是没有时区信息的（时区无关）** ，DateTime 类型保存的时间都是当前会话所设置的时区对应的时间。这样就会有什么问题呢？当你的时区更换之后，比如你的服务器更换地址或者更换客户端连接时区设置的话，就会导致你从数据库中读出的时间错误。
+`DATETIME` 类型存储的是**字面量的日期和时间值**，它本身**不包含任何时区信息**。当你插入一个 `DATETIME` 值时，MySQL 存储的就是你提供的那个确切的时间，不会进行任何时区转换。
+
+**这样就会有什么问题呢？** 如果你的应用需要支持多个时区，或者服务器、客户端的时区可能发生变化，那么使用 `DATETIME` 时，应用程序需要自行处理时区的转换和解释。如果处理不当（例如，假设所有存储的时间都属于同一个时区，但实际环境变化了），可能会导致时间显示或计算上的混乱。
-**Timestamp 和时区有关**。Timestamp 类型字段的值会随着服务器时区的变化而变化，自动换算成相应的时间，说简单点就是在不同时区，查询到同一个条记录此字段的值会不一样。
+**`TIMESTAMP` 和时区有关**。存储时，MySQL 会将当前会话时区下的时间值转换成 UTC（协调世界时）进行内部存储。当查询 `TIMESTAMP` 字段时，MySQL 又会将存储的 UTC 时间转换回当前会话所设置的时区来显示。
+
+这意味着，对于同一条记录的 `TIMESTAMP` 字段，在不同的会话时区设置下查询，可能会看到不同的本地时间表示，但它们都对应着同一个绝对时间点（UTC 时间）。这对于需要全球化、多时区支持的应用来说非常有用。
下面实际演示一下！
@@ -41,16 +54,16 @@ CREATE TABLE `time_zone_test` (
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
```
-插入数据：
+插入一条数据（假设当前会话时区为系统默认，例如 UTC+0）:：
```sql
INSERT INTO time_zone_test(date_time,time_stamp) VALUES(NOW(),NOW());
```
-查看数据：
+查询数据（在同一时区会话下）：
```sql
-select date_time,time_stamp from time_zone_test;
+SELECT date_time, time_stamp FROM time_zone_test;
```
结果：
@@ -63,17 +76,16 @@ select date_time,time_stamp from time_zone_test;
+---------------------+---------------------+
```
-现在我们运行
-
-修改当前会话的时区:
+现在，修改当前会话的时区为东八区 (UTC+8):
```sql
-set time_zone='+8:00';
+SET time_zone = '+8:00';
```
-再次查看数据：
+再次查询数据：
-```plain
+```bash
+# TIMESTAMP 的值自动转换为 UTC+8 时间
+---------------------+---------------------+
| date_time | time_stamp |
+---------------------+---------------------+
@@ -81,7 +93,7 @@ set time_zone='+8:00';
+---------------------+---------------------+
```
-**扩展：一些关于 MySQL 时区设置的一个常用 sql 命令**
+**扩展：MySQL 时区设置常用 SQL 命令**
```sql
# 查看当前会话时区
@@ -102,28 +114,26 @@ SET GLOBAL time_zone = 'Europe/Helsinki';
-在 MySQL 5.6.4 之前，DateTime 和 Timestamp 的存储空间是固定的，分别为 8 字节和 4 字节。但是从 MySQL 5.6.4 开始，它们的存储空间会根据毫秒精度的不同而变化，DateTime 的范围是 5~8 字节，Timestamp 的范围是 4~7 字节。
+在 MySQL 5.6.4 之前，DateTime 和 TIMESTAMP 的存储空间是固定的，分别为 8 字节和 4 字节。但是从 MySQL 5.6.4 开始，它们的存储空间会根据毫秒精度的不同而变化，DateTime 的范围是 5~8 字节，TIMESTAMP 的范围是 4~7 字节。
### 表示范围
-Timestamp 表示的时间范围更小，只能到 2038 年：
+`TIMESTAMP` 表示的时间范围更小，只能到 2038 年：
-- DateTime：1000-01-01 00:00:00.000000 ~ 9999-12-31 23:59:59.499999
-- Timestamp：1970-01-01 00:00:01.000000 ~ 2038-01-19 03:14:07.499999
+- `DATETIME`：'1000-01-01 00:00:00.000000' 到 '9999-12-31 23:59:59.999999'
+- `TIMESTAMP`：'1970-01-01 00:00:01.000000' UTC 到 '2038-01-19 03:14:07.999999' UTC
### 性能
-由于 TIMESTAMP 需要根据时区进行转换，所以从毫秒数转换到 TIMESTAMP 时，不仅要调用一个简单的函数，还要调用操作系统底层的系统函数。这个系统函数为了保证操作系统时区的一致性，需要进行加锁操作，这就降低了效率。
-
-DATETIME 不涉及时区转换，所以不会有这个问题。
+由于 `TIMESTAMP` 在存储和检索时需要进行 UTC 与当前会话时区的转换，这个过程可能涉及到额外的计算开销，尤其是在需要调用操作系统底层接口获取或处理时区信息时。虽然现代数据库和操作系统对此进行了优化，但在某些极端高并发或对延迟极其敏感的场景下，`DATETIME` 因其不涉及时区转换，处理逻辑相对更简单直接，可能会表现出微弱的性能优势。
-为了避免 TIMESTAMP 的时区转换问题，建议使用指定的时区，而不是依赖于操作系统时区。
+为了获得可预测的行为并可能减少 `TIMESTAMP` 的转换开销，推荐的做法是在应用程序层面统一管理时区，或者在数据库连接/会话级别显式设置 `time_zone` 参数，而不是依赖服务器的默认或操作系统时区。
## 数值时间戳是更好的选择吗？
-很多时候，我们也会使用 int 或者 bigint 类型的数值也就是数值时间戳来表示时间。
+除了上述两种类型，实践中也常用整数类型（`INT` 或 `BIGINT`）来存储所谓的“Unix 时间戳”（即从 1970 年 1 月 1 日 00:00:00 UTC 起至目标时间的总秒数，或毫秒数）。
-这种存储方式的具有 Timestamp 类型的所具有一些优点，并且使用它的进行日期排序以及对比等操作的效率会更高，跨系统也很方便，毕竟只是存放的数值。缺点也很明显，就是数据的可读性太差了，你无法直观的看到具体时间。
+这种存储方式的具有 `TIMESTAMP` 类型的所具有一些优点，并且使用它的进行日期排序以及对比等操作的效率会更高，跨系统也很方便，毕竟只是存放的数值。缺点也很明显，就是数据的可读性太差了，你无法直观的看到具体时间。
时间戳的定义如下：
@@ -132,7 +142,8 @@ DATETIME 不涉及时区转换，所以不会有这个问题。
数据库中实际操作：
```sql
-mysql> select UNIX_TIMESTAMP('2020-01-11 09:53:32');
+-- 将日期时间字符串转换为 Unix 时间戳 (秒)
+mysql> SELECT UNIX_TIMESTAMP('2020-01-11 09:53:32');
+---------------------------------------+
| UNIX_TIMESTAMP('2020-01-11 09:53:32') |
+---------------------------------------+
@@ -140,7 +151,8 @@ mysql> select UNIX_TIMESTAMP('2020-01-11 09:53:32');
+---------------------------------------+
1 row in set (0.00 sec)
-mysql> select FROM_UNIXTIME(1578707612);
+-- 将 Unix 时间戳 (秒) 转换为日期时间格式
+mysql> SELECT FROM_UNIXTIME(1578707612);
+---------------------------+
| FROM_UNIXTIME(1578707612) |
+---------------------------+
@@ -149,13 +161,26 @@ mysql> select FROM_UNIXTIME(1578707612);
1 row in set (0.01 sec)
```
+## PostgreSQL 中没有 DATETIME
+
+由于有读者提到 PostgreSQL（PG） 的时间类型，因此这里拓展补充一下。PG 官方文档对时间类型的描述地址：。
+
+
+
+可以看到，PG 没有名为 `DATETIME` 的类型：
+
+- PG 的 `TIMESTAMP WITHOUT TIME ZONE`在功能上最接近 MySQL 的 `DATETIME`。它存储日期和时间，但不包含任何时区信息，存储的是字面值。
+- PG 的`TIMESTAMP WITH TIME ZONE` (或 `TIMESTAMPTZ`) 相当于 MySQL 的 `TIMESTAMP`。它在存储时会将输入值转换为 UTC，并在检索时根据当前会话的时区进行转换显示。
+
+对于绝大多数需要记录精确发生时间点的应用场景，`TIMESTAMPTZ`是 PostgreSQL 中最推荐、最健壮的选择，因为它能最好地处理时区复杂性。
+
## 总结
-MySQL 中时间到底怎么存储才好？Datetime?Timestamp?还是数值时间戳？
+MySQL 中时间到底怎么存储才好？`DATETIME`?`TIMESTAMP`?还是数值时间戳？
并没有一个银弹，很多程序员会觉得数值型时间戳是真的好，效率又高还各种兼容，但是很多人又觉得它表现的不够直观。
-《高性能 MySQL 》这本神书的作者就是推荐 Timestamp，原因是数值表示时间不够直观。下面是原文：
+《高性能 MySQL 》这本神书的作者就是推荐 TIMESTAMP，原因是数值表示时间不够直观。下面是原文：
）:
+Redis7.0 的 SDS 的部分源码如下（）：
```c
/* Note: sdshdr5 is never used, we just access the flags byte directly.
@@ -360,7 +388,7 @@ struct __attribute__ ((__packed__)) sdshdr64 {
};
```
-通过源码可以看出，SDS 共有五种实现方式 SDS_TYPE_5（并未用到）、SDS_TYPE_8、SDS_TYPE_16、SDS_TYPE_32、SDS_TYPE_64，其中只有后四种实际用到。Redis 会根据初始化的长度决定使用哪种类型，从而减少内存的使用。
+通过源码可以看出，SDS 共有五种实现方式：SDS_TYPE_5（并未用到）、SDS_TYPE_8、SDS_TYPE_16、SDS_TYPE_32、SDS_TYPE_64，其中只有后四种实际用到。Redis 会根据初始化的长度决定使用哪种类型，从而减少内存的使用。
| 类型 | 字节 | 位 |
| -------- | ---- | --- |
@@ -372,10 +400,10 @@ struct __attribute__ ((__packed__)) sdshdr64 {
对于后四种实现都包含了下面这 4 个属性：
-- `len`：字符串的长度也就是已经使用的字节数
-- `alloc`：总共可用的字符空间大小，alloc-len 就是 SDS 剩余的空间大小
-- `buf[]`：实际存储字符串的数组
-- `flags`：低三位保存类型标志
+- `len`：字符串的长度也就是已经使用的字节数。
+- `alloc`：总共可用的字符空间大小，alloc-len 就是 SDS 剩余的空间大小。
+- `buf[]`：实际存储字符串的数组。
+- `flags`：低三位保存类型标志。
SDS 相比于 C 语言中的字符串有如下提升：
@@ -417,9 +445,9 @@ struct sdshdr {
### 使用 Redis 实现一个排行榜怎么做？
-Redis 中有一个叫做 `Sorted Set` （有序集合）的数据类型经常被用在各种排行榜的场景，比如直播间送礼物的排行榜、朋友圈的微信步数排行榜、王者荣耀中的段位排行榜、话题热度排行榜等等。
+Redis 中有一个叫做 `Sorted Set`（有序集合）的数据类型经常被用在各种排行榜的场景，比如直播间送礼物的排行榜、朋友圈的微信步数排行榜、王者荣耀中的段位排行榜、话题热度排行榜等等。
-相关的一些 Redis 命令: `ZRANGE` (从小到大排序)、 `ZREVRANGE` （从大到小排序）、`ZREVRANK` (指定元素排名)。
+相关的一些 Redis 命令：`ZRANGE`（从小到大排序）、`ZREVRANGE`（从大到小排序）、`ZREVRANK`（指定元素排名）。
@@ -427,15 +455,15 @@ Redis 中有一个叫做 `Sorted Set` （有序集合）的数据类型经常被
-### Redis 的有序集合底层为什么要用跳表，而不用平衡树、红黑树或者 B+树？
+### Redis 的有序集合底层为什么要用跳表，而不用平衡树、红黑树或者 B+ 树？
这道面试题很多大厂比较喜欢问，难度还是有点大的。
- 平衡树 vs 跳表：平衡树的插入、删除和查询的时间复杂度和跳表一样都是 **O(log n)**。对于范围查询来说，平衡树也可以通过中序遍历的方式达到和跳表一样的效果。但是它的每一次插入或者删除操作都需要保证整颗树左右节点的绝对平衡，只要不平衡就要通过旋转操作来保持平衡，这个过程是比较耗时的。跳表诞生的初衷就是为了克服平衡树的一些缺点。跳表使用概率平衡而不是严格强制的平衡，因此，跳表中的插入和删除算法比平衡树的等效算法简单得多，速度也快得多。
- 红黑树 vs 跳表：相比较于红黑树来说，跳表的实现也更简单一些，不需要通过旋转和染色（红黑变换）来保证黑平衡。并且，按照区间来查找数据这个操作，红黑树的效率没有跳表高。
-- B+树 vs 跳表：B+树更适合作为数据库和文件系统中常用的索引结构之一，它的核心思想是通过可能少的 IO 定位到尽可能多的索引来获得查询数据。对于 Redis 这种内存数据库来说，它对这些并不感冒，因为 Redis 作为内存数据库它不可能存储大量的数据，所以对于索引不需要通过 B+树这种方式进行维护，只需按照概率进行随机维护即可，节约内存。而且使用跳表实现 zset 时相较前者来说更简单一些，在进行插入时只需通过索引将数据插入到链表中合适的位置再随机维护一定高度的索引即可，也不需要像 B+树那样插入时发现失衡时还需要对节点分裂与合并。
+- B+ 树 vs 跳表：B+ 树更适合作为数据库和文件系统中常用的索引结构之一，它的核心思想是通过可能少的 IO 定位到尽可能多的索引来获得查询数据。对于 Redis 这种内存数据库来说，它对这些并不感冒，因为 Redis 作为内存数据库它不可能存储大量的数据，所以对于索引不需要通过 B+ 树这种方式进行维护，只需按照概率进行随机维护即可，节约内存。而且使用跳表实现 zset 时相较前者来说更简单一些，在进行插入时只需通过索引将数据插入到链表中合适的位置再随机维护一定高度的索引即可，也不需要像 B+ 树那样插入时发现失衡时还需要对节点分裂与合并。
-另外，我还单独写了一篇文章从有序集合的基本使用到跳表的源码分析和实现，让你会对 Redis 的有序集合底层实现的跳表有着更深刻的理解和掌握 ：[Redis 为什么用跳表实现有序集合](./redis-skiplist.md)。
+另外，我还单独写了一篇文章从有序集合的基本使用到跳表的源码分析和实现，让你会对 Redis 的有序集合底层实现的跳表有着更深刻的理解和掌握：[Redis 为什么用跳表实现有序集合](./redis-skiplist.md)。
### Set 的应用场景是什么？
@@ -443,8 +471,8 @@ Redis 中 `Set` 是一种无序集合，集合中的元素没有先后顺序但
`Set` 的常见应用场景如下：
-- 存放的数据不能重复的场景：网站 UV 统计（数据量巨大的场景还是 `HyperLogLog`更适合一些）、文章点赞、动态点赞等等。
-- 需要获取多个数据源交集、并集和差集的场景：共同好友(交集)、共同粉丝(交集)、共同关注(交集)、好友推荐（差集）、音乐推荐（差集）、订阅号推荐（差集+交集） 等等。
+- 存放的数据不能重复的场景：网站 UV 统计（数据量巨大的场景还是 `HyperLogLog` 更适合一些）、文章点赞、动态点赞等等。
+- 需要获取多个数据源交集、并集和差集的场景：共同好友（交集）、共同粉丝（交集）、共同关注（交集）、好友推荐（差集）、音乐推荐（差集）、订阅号推荐（差集+交集）等等。
- 需要随机获取数据源中的元素的场景：抽奖系统、随机点名等等。
### 使用 Set 实现抽奖系统怎么做？
@@ -453,11 +481,11 @@ Redis 中 `Set` 是一种无序集合，集合中的元素没有先后顺序但
- `SADD key member1 member2 ...`：向指定集合添加一个或多个元素。
- `SPOP key count`：随机移除并获取指定集合中一个或多个元素，适合不允许重复中奖的场景。
-- `SRANDMEMBER key count` : 随机获取指定集合中指定数量的元素，适合允许重复中奖的场景。
+- `SRANDMEMBER key count`：随机获取指定集合中指定数量的元素，适合允许重复中奖的场景。
### 使用 Bitmap 统计活跃用户怎么做？
-Bitmap 存储的是连续的二进制数字（0 和 1），通过 Bitmap, 只需要一个 bit 位来表示某个元素对应的值或者状态，key 就是对应元素本身 。我们知道 8 个 bit 可以组成一个 byte，所以 Bitmap 本身会极大的节省储存空间。
+Bitmap 存储的是连续的二进制数字（0 和 1），通过 Bitmap，只需要一个 bit 位来表示某个元素对应的值或者状态，key 就是对应元素本身。我们知道 8 个 bit 可以组成一个 byte，所以 Bitmap 本身会极大的节省储存空间。
你可以将 Bitmap 看作是一个存储二进制数字（0 和 1）的数组，数组中每个元素的下标叫做 offset（偏移量）。
@@ -476,7 +504,7 @@ Bitmap 存储的是连续的二进制数字（0 和 1），通过 Bitmap, 只需
(integer) 0
```
-统计 20210308~20210309 总活跃用户数:
+统计 20210308~20210309 总活跃用户数：
```bash
> BITOP and desk1 20210308 20210309
@@ -485,7 +513,7 @@ Bitmap 存储的是连续的二进制数字（0 和 1），通过 Bitmap, 只需
(integer) 1
```
-统计 20210308~20210309 在线活跃用户数:
+统计 20210308~20210309 在线活跃用户数：
```bash
> BITOP or desk2 20210308 20210309
@@ -515,17 +543,17 @@ PFCOUNT PAGE_1:UV
## Redis 持久化机制（重要）
-Redis 持久化机制（RDB 持久化、AOF 持久化、RDB 和 AOF 的混合持久化） 相关的问题比较多，也比较重要，于是我单独抽了一篇文章来总结 Redis 持久化机制相关的知识点和问题：[Redis 持久化机制详解](https://javaguide.cn/database/redis/redis-persistence.html) 。
+Redis 持久化机制（RDB 持久化、AOF 持久化、RDB 和 AOF 的混合持久化）相关的问题比较多，也比较重要，于是我单独抽了一篇文章来总结 Redis 持久化机制相关的知识点和问题：[Redis 持久化机制详解](https://javaguide.cn/database/redis/redis-persistence.html)。
## Redis 线程模型（重要）
-对于读写命令来说，Redis 一直是单线程模型。不过，在 Redis 4.0 版本之后引入了多线程来执行一些大键值对的异步删除操作， Redis 6.0 版本之后引入了多线程来处理网络请求（提高网络 IO 读写性能）。
+对于读写命令来说，Redis 一直是单线程模型。不过，在 Redis 4.0 版本之后引入了多线程来执行一些大键值对的异步删除操作，Redis 6.0 版本之后引入了多线程来处理网络请求（提高网络 IO 读写性能）。
### Redis 单线程模型了解吗？
-**Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型** （Netty 的线程模型也基于 Reactor 模式，Reactor 模式不愧是高性能 IO 的基石），这套事件处理模型对应的是 Redis 中的文件事件处理器（file event handler）。由于文件事件处理器（file event handler）是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。
+**Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型**（Netty 的线程模型也基于 Reactor 模式，Reactor 模式不愧是高性能 IO 的基石），这套事件处理模型对应的是 Redis 中的文件事件处理器（file event handler）。由于文件事件处理器（file event handler）是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。
-《Redis 设计与实现》有一段话是如是介绍文件事件处理器的，我觉得写得挺不错。
+《Redis 设计与实现》有一段话是这样介绍文件事件处理器的，我觉得写得挺不错。
> Redis 基于 Reactor 模式开发了自己的网络事件处理器：这个处理器被称为文件事件处理器（file event handler）。
>
@@ -549,27 +577,31 @@ Redis 通过 **IO 多路复用程序** 来监听来自客户端的大量连接
-相关阅读：[Redis 事件机制详解](http://remcarpediem.net/article/1aa2da89/) 。
+相关阅读：[Redis 事件机制详解](http://remcarpediem.net/article/1aa2da89/)。
### Redis6.0 之前为什么不使用多线程？
-虽然说 Redis 是单线程模型，但是，实际上，**Redis 在 4.0 之后的版本中就已经加入了对多线程的支持。**
+虽然说 Redis 是单线程模型，但实际上，**Redis 在 4.0 之后的版本中就已经加入了对多线程的支持。**
+
+不过，Redis 4.0 增加的多线程主要是针对一些大键值对的删除操作的命令，使用这些命令就会使用主线程之外的其他线程来“异步处理”，从而减少对主线程的影响。
-不过，Redis 4.0 增加的多线程主要是针对一些大键值对的删除操作的命令，使用这些命令就会使用主线程之外的其他线程来“异步处理”。
+为此，Redis 4.0 之后新增了几个异步命令：
-为此，Redis 4.0 之后新增了`UNLINK`（可以看作是 `DEL` 的异步版本）、`FLUSHALL ASYNC`（清空所有数据库的所有 key，不仅仅是当前 `SELECT` 的数据库）、`FLUSHDB ASYNC`（清空当前 `SELECT` 数据库中的所有 key）等异步命令。
+- `UNLINK`：可以看作是 `DEL` 命令的异步版本。
+- `FLUSHALL ASYNC`：用于清空所有数据库的所有键，不限于当前 `SELECT` 的数据库。
+- `FLUSHDB ASYNC`：用于清空当前 `SELECT` 数据库中的所有键。
-大体上来说，Redis 6.0 之前主要还是单线程处理。
+总的来说，直到 Redis 6.0 之前，Redis 的主要操作仍然是单线程处理的。
**那 Redis6.0 之前为什么不使用多线程？** 我觉得主要原因有 3 点：
- 单线程编程容易并且更容易维护；
-- Redis 的性能瓶颈不在 CPU ，主要在内存和网络；
+- Redis 的性能瓶颈不在 CPU，主要在内存和网络；
- 多线程就会存在死锁、线程上下文切换等问题，甚至会影响性能。
-相关阅读：[为什么 Redis 选择单线程模型？](https://draveness.me/whys-the-design-redis-single-thread/) 。
+相关阅读：[为什么 Redis 选择单线程模型？](https://draveness.me/whys-the-design-redis-single-thread/)。
### Redis6.0 之后为何引入了多线程？
@@ -588,13 +620,13 @@ io-threads 4 #设置1的话只会开启主线程，官网建议4核的机器建
- io-threads 的个数一旦设置，不能通过 config 动态设置。
- 当设置 ssl 后，io-threads 将不工作。
-开启多线程后，默认只会使用多线程进行 IO 写入 writes，即发送数据给客户端，如果需要开启多线程 IO 读取 reads，同样需要修改 redis 配置文件 `redis.conf` :
+开启多线程后，默认只会使用多线程进行 IO 写入 writes，即发送数据给客户端，如果需要开启多线程 IO 读取 reads，同样需要修改 redis 配置文件 `redis.conf`：
```bash
io-threads-do-reads yes
```
-但是官网描述开启多线程读并不能有太大提升，因此一般情况下并不建议开启
+但是官网描述开启多线程读并不能有太大提升，因此一般情况下并不建议开启。
相关阅读：
@@ -606,8 +638,8 @@ io-threads-do-reads yes
我们虽然经常说 Redis 是单线程模型（主要逻辑是单线程完成的），但实际还有一些后台线程用于执行一些比较耗时的操作：
- 通过 `bio_close_file` 后台线程来释放 AOF / RDB 等过程中产生的临时文件资源。
-- 通过 `bio_aof_fsync` 后台线程调用 `fsync` 函数将系统内核缓冲区还未同步到到磁盘的数据强制刷到磁盘（ AOF 文件）。
-- 通过 `bio_lazy_free`后台线程释放大对象（已删除）占用的内存空间.
+- 通过 `bio_aof_fsync` 后台线程调用 `fsync` 函数将系统内核缓冲区还未同步到到磁盘的数据强制刷到磁盘（AOF 文件）。
+- 通过 `bio_lazy_free` 后台线程释放大对象（已删除）占用的内存空间.
在`bio.h` 文件中有定义（Redis 6.0 版本，源码地址：）：
@@ -636,11 +668,11 @@ void bioKillThreads(void);
## Redis 内存管理
-### Redis 给缓存数据设置过期时间有啥用？
+### Redis 给缓存数据设置过期时间有什么用？
一般情况下，我们设置保存的缓存数据的时候都会设置一个过期时间。为什么呢？
-因为内存是有限的，如果缓存中的所有数据都是一直保存的话，分分钟直接 Out of memory。
+内存是有限且珍贵的，如果不对缓存数据设置过期时间，那内存占用就会一直增长，最终可能会导致 OOM 问题。通过设置合理的过期时间，Redis 会自动删除暂时不需要的数据，为新的缓存数据腾出空间。
Redis 自带了给缓存数据设置过期时间的功能，比如：
@@ -653,7 +685,7 @@ OK
(integer) 56
```
-注意：**Redis 中除了字符串类型有自己独有设置过期时间的命令 `setex` 外，其他方法都需要依靠 `expire` 命令来设置过期时间 。另外， `persist` 命令可以移除一个键的过期时间。**
+注意 ⚠️：Redis 中除了字符串类型有自己独有设置过期时间的命令 `setex` 外，其他方法都需要依靠 `expire` 命令来设置过期时间 。另外，`persist` 命令可以移除一个键的过期时间。
**过期时间除了有助于缓解内存的消耗，还有什么其他用么？**
@@ -663,9 +695,9 @@ OK
### Redis 是如何判断数据是否过期的呢？
-Redis 通过一个叫做过期字典（可以看作是 hash 表）来保存数据过期的时间。过期字典的键指向 Redis 数据库中的某个 key(键)，过期字典的值是一个 long long 类型的整数，这个整数保存了 key 所指向的数据库键的过期时间（毫秒精度的 UNIX 时间戳）。
+Redis 通过一个叫做过期字典（可以看作是 hash 表）来保存数据过期的时间。过期字典的键指向 Redis 数据库中的某个 key（键），过期字典的值是一个 long long 类型的整数，这个整数保存了 key 所指向的数据库键的过期时间（毫秒精度的 UNIX 时间戳）。
-
+
过期字典是存储在 redisDb 这个结构里的：
@@ -679,43 +711,162 @@ typedef struct redisDb {
} redisDb;
```
-### 过期的数据的删除策略了解么？
+在查询一个 key 的时候，Redis 首先检查该 key 是否存在于过期字典中（时间复杂度为 O(1)），如果不在就直接返回，在的话需要判断一下这个 key 是否过期，过期直接删除 key 然后返回 null。
+
+### Redis 过期 key 删除策略了解么？
如果假设你设置了一批 key 只能存活 1 分钟，那么 1 分钟后，Redis 是怎么对这批 key 进行删除的呢？
-常用的过期数据的删除策略就两个（重要！自己造缓存轮子的时候需要格外考虑的东西）：
+常用的过期数据的删除策略就下面这几种：
+
+1. **惰性删除**：只会在取出/查询 key 的时候才对数据进行过期检查。这种方式对 CPU 最友好，但是可能会造成太多过期 key 没有被删除。
+2. **定期删除**：周期性地随机从设置了过期时间的 key 中抽查一批，然后逐个检查这些 key 是否过期，过期就删除 key。相比于惰性删除，定期删除对内存更友好，对 CPU 不太友好。
+3. **延迟队列**：把设置过期时间的 key 放到一个延迟队列里，到期之后就删除 key。这种方式可以保证每个过期 key 都能被删除，但维护延迟队列太麻烦，队列本身也要占用资源。
+4. **定时删除**：每个设置了过期时间的 key 都会在设置的时间到达时立即被删除。这种方法可以确保内存中不会有过期的键，但是它对 CPU 的压力最大，因为它需要为每个键都设置一个定时器。
+
+**Redis 采用的是那种删除策略呢？**
+
+Redis 采用的是 **定期删除+惰性/懒汉式删除** 结合的策略，这也是大部分缓存框架的选择。定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，结合起来使用既能兼顾 CPU 友好，又能兼顾内存友好。
+
+下面是我们详细介绍一下 Redis 中的定期删除具体是如何做的。
+
+Redis 的定期删除过程是随机的（周期性地随机从设置了过期时间的 key 中抽查一批），所以并不保证所有过期键都会被立即删除。这也就解释了为什么有的 key 过期了，并没有被删除。并且，Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。
+
+另外，定期删除还会受到执行时间和过期 key 的比例的影响：
+
+- 执行时间已经超过了阈值，那么就中断这一次定期删除循环，以避免使用过多的 CPU 时间。
+- 如果这一批过期的 key 比例超过一个比例，就会重复执行此删除流程，以更积极地清理过期 key。相应地，如果过期的 key 比例低于这个比例，就会中断这一次定期删除循环，避免做过多的工作而获得很少的内存回收。
+
+Redis 7.2 版本的执行时间阈值是 **25ms**，过期 key 比例设定值是 **10%**。
+
+```c
+#define ACTIVE_EXPIRE_CYCLE_FAST_DURATION 1000 /* Microseconds. */
+#define ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 25 /* Max % of CPU to use. */
+#define ACTIVE_EXPIRE_CYCLE_ACCEPTABLE_STALE 10 /* % of stale keys after which
+ we do extra efforts. */
+```
+
+**每次随机抽查数量是多少？**
+
+`expire.c` 中定义了每次随机抽查的数量，Redis 7.2 版本为 20，也就是说每次会随机选择 20 个设置了过期时间的 key 判断是否过期。
+
+```c
+#define ACTIVE_EXPIRE_CYCLE_KEYS_PER_LOOP 20 /* Keys for each DB loop. */
+```
+
+**如何控制定期删除的执行频率？**
+
+在 Redis 中，定期删除的频率是由 **hz** 参数控制的。hz 默认为 10，代表每秒执行 10 次，也就是每秒钟进行 10 次尝试来查找并删除过期的 key。
+
+hz 的取值范围为 1~500。增大 hz 参数的值会提升定期删除的频率。如果你想要更频繁地执行定期删除任务，可以适当增加 hz 的值，但这会增加 CPU 的使用率。根据 Redis 官方建议，hz 的值不建议超过 100，对于大部分用户使用默认的 10 就足够了。
+
+下面是 hz 参数的官方注释，我翻译了其中的重要信息（Redis 7.2 版本）。
-1. **惰性删除**：只会在取出 key 的时候才对数据进行过期检查。这样对 CPU 最友好，但是可能会造成太多过期 key 没有被删除。
-2. **定期删除**：每隔一段时间抽取一批 key 执行删除过期 key 操作。并且，Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。
+
-定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，所以 Redis 采用的是 **定期删除+惰性/懒汉式删除** 。
+类似的参数还有一个 **dynamic-hz**，这个参数开启之后 Redis 就会在 hz 的基础上动态计算一个值。Redis 提供并默认启用了使用自适应 hz 值的能力，
-但是，仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉了很多过期 key 的情况。这样就导致大量过期 key 堆积在内存里，然后就 Out of memory 了。
+这两个参数都在 Redis 配置文件 `redis.conf` 中：
-怎么解决这个问题呢？答案就是：**Redis 内存淘汰机制。**
+```properties
+# 默认为 10
+hz 10
+# 默认开启
+dynamic-hz yes
+```
+
+多提一嘴，除了定期删除过期 key 这个定期任务之外，还有一些其他定期任务例如关闭超时的客户端连接、更新统计信息，这些定期任务的执行频率也是通过 hz 参数决定。
+
+**为什么定期删除不是把所有过期 key 都删除呢？**
+
+这样会对性能造成太大的影响。如果我们 key 数量非常庞大的话，挨个遍历检查是非常耗时的，会严重影响性能。Redis 设计这种策略的目的是为了平衡内存和性能。
+
+**为什么 key 过期之后不立马把它删掉呢？这样不是会浪费很多内存空间吗？**
+
+因为不太好办到，或者说这种删除方式的成本太高了。假如我们使用延迟队列作为删除策略，这样存在下面这些问题：
+
+1. 队列本身的开销可能很大：key 多的情况下，一个延迟队列可能无法容纳。
+2. 维护延迟队列太麻烦：修改 key 的过期时间就需要调整期在延迟队列中的位置，并且还需要引入并发控制。
+
+### 大量 key 集中过期怎么办？
-### Redis 内存淘汰机制了解么？
+当 Redis 中存在大量 key 在同一时间点集中过期时，可能会导致以下问题：
+
+- **请求延迟增加**：Redis 在处理过期 key 时需要消耗 CPU 资源，如果过期 key 数量庞大，会导致 Redis 实例的 CPU 占用率升高，进而影响其他请求的处理速度，造成延迟增加。
+- **内存占用过高**：过期的 key 虽然已经失效，但在 Redis 真正删除它们之前，仍然会占用内存空间。如果过期 key 没有及时清理，可能会导致内存占用过高，甚至引发内存溢出。
+
+为了避免这些问题，可以采取以下方案：
+
+1. **尽量避免 key 集中过期**：在设置键的过期时间时尽量随机一点。
+2. **开启 lazy free 机制**：修改 `redis.conf` 配置文件，将 `lazyfree-lazy-expire` 参数设置为 `yes`，即可开启 lazy free 机制。开启 lazy free 机制后，Redis 会在后台异步删除过期的 key，不会阻塞主线程的运行，从而降低对 Redis 性能的影响。
+
+### Redis 内存淘汰策略了解么？
> 相关问题：MySQL 里有 2000w 数据，Redis 中只存 20w 的数据，如何保证 Redis 中的数据都是热点数据?
-Redis 提供 6 种数据淘汰策略：
+Redis 的内存淘汰策略只有在运行内存达到了配置的最大内存阈值时才会触发，这个阈值是通过 `redis.conf` 的 `maxmemory` 参数来定义的。64 位操作系统下，`maxmemory` 默认为 0，表示不限制内存大小。32 位操作系统下，默认的最大内存值是 3GB。
+
+你可以使用命令 `config get maxmemory` 来查看 `maxmemory` 的值。
+
+```bash
+> config get maxmemory
+maxmemory
+0
+```
+
+Redis 提供了 6 种内存淘汰策略：
1. **volatile-lru（least recently used）**：从已设置过期时间的数据集（`server.db[i].expires`）中挑选最近最少使用的数据淘汰。
2. **volatile-ttl**：从已设置过期时间的数据集（`server.db[i].expires`）中挑选将要过期的数据淘汰。
3. **volatile-random**：从已设置过期时间的数据集（`server.db[i].expires`）中任意选择数据淘汰。
-4. **allkeys-lru（least recently used）**：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。
+4. **allkeys-lru（least recently used）**：从数据集（`server.db[i].dict`）中移除最近最少使用的数据淘汰。
5. **allkeys-random**：从数据集（`server.db[i].dict`）中任意选择数据淘汰。
-6. **no-eviction**：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！
+6. **no-eviction**（默认内存淘汰策略）：禁止驱逐数据，当内存不足以容纳新写入数据时，新写入操作会报错。
4.0 版本后增加以下两种：
7. **volatile-lfu（least frequently used）**：从已设置过期时间的数据集（`server.db[i].expires`）中挑选最不经常使用的数据淘汰。
-8. **allkeys-lfu（least frequently used）**：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key。
+8. **allkeys-lfu（least frequently used）**：从数据集（`server.db[i].dict`）中移除最不经常使用的数据淘汰。
+
+`allkeys-xxx` 表示从所有的键值中淘汰数据，而 `volatile-xxx` 表示从设置了过期时间的键值中淘汰数据。
+
+`config.c` 中定义了内存淘汰策略的枚举数组：
+
+```c
+configEnum maxmemory_policy_enum[] = {
+ {"volatile-lru", MAXMEMORY_VOLATILE_LRU},
+ {"volatile-lfu", MAXMEMORY_VOLATILE_LFU},
+ {"volatile-random",MAXMEMORY_VOLATILE_RANDOM},
+ {"volatile-ttl",MAXMEMORY_VOLATILE_TTL},
+ {"allkeys-lru",MAXMEMORY_ALLKEYS_LRU},
+ {"allkeys-lfu",MAXMEMORY_ALLKEYS_LFU},
+ {"allkeys-random",MAXMEMORY_ALLKEYS_RANDOM},
+ {"noeviction",MAXMEMORY_NO_EVICTION},
+ {NULL, 0}
+};
+```
+
+你可以使用 `config get maxmemory-policy` 命令来查看当前 Redis 的内存淘汰策略。
+
+```bash
+> config get maxmemory-policy
+maxmemory-policy
+noeviction
+```
+
+可以通过 `config set maxmemory-policy 内存淘汰策略` 命令修改内存淘汰策略，立即生效，但这种方式重启 Redis 之后就失效了。修改 `redis.conf` 中的 `maxmemory-policy` 参数不会因为重启而失效，不过，需要重启之后修改才能生效。
+
+```properties
+maxmemory-policy noeviction
+```
+
+关于淘汰策略的详细说明可以参考 Redis 官方文档：
- RedisSearch 终极使用指南，你值得拥有！：
- WHY Redis choose single thread (vs multi threads): [https://medium.com/@jychen7/sharing-redis-single-thread-vs-multi-threads-5870bd44d153](https://medium.com/@jychen7/sharing-redis-single-thread-vs-multi-threads-5870bd44d153)
diff --git a/docs/database/redis/redis-questions-02.md b/docs/database/redis/redis-questions-02.md
index a13bb8c0647..08e5e0a8e43 100644
--- a/docs/database/redis/redis-questions-02.md
+++ b/docs/database/redis/redis-questions-02.md
@@ -28,7 +28,7 @@ Redis 事务实际开发中使用的非常少，功能比较鸡肋，不要将
### 如何使用 Redis 事务？
-Redis 可以通过 **`MULTI`，`EXEC`，`DISCARD` 和 `WATCH`** 等命令来实现事务(Transaction)功能。
+Redis 可以通过 **`MULTI`、`EXEC`、`DISCARD` 和 `WATCH`** 等命令来实现事务（Transaction）功能。
```bash
> MULTI
@@ -47,8 +47,8 @@ QUEUED
这个过程是这样的：
1. 开始事务（`MULTI`）；
-2. 命令入队(批量操作 Redis 的命令，先进先出（FIFO）的顺序执行)；
-3. 执行事务(`EXEC`)。
+2. 命令入队（批量操作 Redis 的命令，先进先出（FIFO）的顺序执行）；
+3. 执行事务（`EXEC`）。
你也可以通过 [`DISCARD`](https://redis.io/commands/discard) 命令取消一个事务，它会清空事务队列中保存的所有命令。
@@ -138,10 +138,10 @@ Redis 官网相关介绍 [https://redis.io/topics/transactions](https://redis.io
Redis 的事务和我们平时理解的关系型数据库的事务不同。我们知道事务具有四大特性：**1. 原子性**，**2. 隔离性**，**3. 持久性**，**4. 一致性**。
-1. **原子性（Atomicity）：** 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
-2. **隔离性（Isolation）：** 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
-3. **持久性（Durability）：** 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。
-4. **一致性（Consistency）：** 执行事务前后，数据保持一致，多个事务对同一个数据读取的结果是相同的；
+1. **原子性（Atomicity）**：事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
+2. **隔离性（Isolation）**：并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
+3. **持久性（Durability）**：一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响；
+4. **一致性（Consistency）**：执行事务前后，数据保持一致，多个事务对同一个数据读取的结果是相同的。
Redis 事务在运行错误的情况下，除了执行过程中出现错误的命令外，其他命令都能正常执行。并且，Redis 事务是不支持回滚（roll back）操作的。因此，Redis 事务其实是不满足原子性的。
@@ -149,28 +149,28 @@ Redis 官网也解释了自己为啥不支持回滚。简单来说就是 Redis
-**相关 issue** :
+**相关 issue**：
-- [issue#452: 关于 Redis 事务不满足原子性的问题](https://github.com/Snailclimb/JavaGuide/issues/452) 。
-- [Issue#491:关于 Redis 没有事务回滚？](https://github.com/Snailclimb/JavaGuide/issues/491)
+- [issue#452: 关于 Redis 事务不满足原子性的问题](https://github.com/Snailclimb/JavaGuide/issues/452)。
+- [Issue#491:关于 Redis 没有事务回滚？](https://github.com/Snailclimb/JavaGuide/issues/491)。
### Redis 事务支持持久性吗？
-Redis 不同于 Memcached 的很重要一点就是，Redis 支持持久化，而且支持 3 种持久化方式:
+Redis 不同于 Memcached 的很重要一点就是，Redis 支持持久化，而且支持 3 种持久化方式：
-- 快照（snapshotting，RDB）
-- 只追加文件（append-only file, AOF）
-- RDB 和 AOF 的混合持久化(Redis 4.0 新增)
+- 快照（snapshotting，RDB）；
+- 只追加文件（append-only file，AOF）；
+- RDB 和 AOF 的混合持久化（Redis 4.0 新增）。
-与 RDB 持久化相比，AOF 持久化的实时性更好。在 Redis 的配置文件中存在三种不同的 AOF 持久化方式（ `fsync`策略），它们分别是：
+与 RDB 持久化相比，AOF 持久化的实时性更好。在 Redis 的配置文件中存在三种不同的 AOF 持久化方式（`fsync` 策略），它们分别是：
```bash
-appendfsync always #每次有数据修改发生时都会调用fsync函数同步AOF文件,fsync完成后线程返回,这样会严重降低Redis的速度
+appendfsync always #每次有数据修改发生时，都会调用fsync函数同步AOF文件，fsync完成后线程返回，这样会严重降低Redis的速度
appendfsync everysec #每秒钟调用fsync函数同步一次AOF文件
appendfsync no #让操作系统决定何时进行同步，一般为30秒一次
```
-AOF 持久化的`fsync`策略为 no、everysec 时都会存在数据丢失的情况 。always 下可以基本是可以满足持久性要求的，但性能太差，实际开发过程中不会使用。
+AOF 持久化的 `fsync` 策略为 no、everysec 时都会存在数据丢失的情况。always 下可以基本是可以满足持久性要求的，但性能太差，实际开发过程中不会使用。
因此，Redis 事务的持久性也是没办法保证的。
@@ -180,7 +180,7 @@ Redis 从 2.6 版本开始支持执行 Lua 脚本，它的功能和事务非常
一段 Lua 脚本可以视作一条命令执行，一段 Lua 脚本执行过程中不会有其他脚本或 Redis 命令同时执行，保证了操作不会被其他指令插入或打扰。
-不过，如果 Lua 脚本运行时出错并中途结束，出错之后的命令是不会被执行的。并且，出错之前执行的命令是无法被撤销的，无法实现类似关系型数据库执行失败可以回滚的那种原子性效果。因此， **严格来说的话，通过 Lua 脚本来批量执行 Redis 命令实际也是不完全满足原子性的。**
+不过，如果 Lua 脚本运行时出错并中途结束，出错之后的命令是不会被执行的。并且，出错之前执行的命令是无法被撤销的，无法实现类似关系型数据库执行失败可以回滚的那种原子性效果。因此，**严格来说的话，通过 Lua 脚本来批量执行 Redis 命令实际也是不完全满足原子性的。**
如果想要让 Lua 脚本中的命令全部执行，必须保证语句语法和命令都是对的。
@@ -190,34 +190,34 @@ Redis 从 2.6 版本开始支持执行 Lua 脚本，它的功能和事务非常
除了下面介绍的内容之外，再推荐两篇不错的文章：
-- [你的 Redis 真的变慢了吗？性能优化如何做 - 阿里开发者](https://mp.weixin.qq.com/s/nNEuYw0NlYGhuKKKKoWfcQ)
-- [Redis 常见阻塞原因总结 - JavaGuide](https://javaguide.cn/database/redis/redis-common-blocking-problems-summary.html)
+- [你的 Redis 真的变慢了吗？性能优化如何做 - 阿里开发者](https://mp.weixin.qq.com/s/nNEuYw0NlYGhuKKKKoWfcQ)。
+- [Redis 常见阻塞原因总结 - JavaGuide](https://javaguide.cn/database/redis/redis-common-blocking-problems-summary.html)。
### 使用批量操作减少网络传输
一个 Redis 命令的执行可以简化为以下 4 步：
-1. 发送命令
-2. 命令排队
-3. 命令执行
-4. 返回结果
+1. 发送命令；
+2. 命令排队；
+3. 命令执行；
+4. 返回结果。
-其中，第 1 步和第 4 步耗费时间之和称为 **Round Trip Time (RTT,往返时间)** ，也就是数据在网络上传输的时间。
+其中，第 1 步和第 4 步耗费时间之和称为 **Round Trip Time（RTT，往返时间）**，也就是数据在网络上传输的时间。
使用批量操作可以减少网络传输次数，进而有效减小网络开销，大幅减少 RTT。
-另外，除了能减少 RTT 之外，发送一次命令的 socket I/O 成本也比较高（涉及上下文切换，存在`read()`和`write()`系统调用），批量操作还可以减少 socket I/O 成本。这个在官方对 pipeline 的介绍中有提到： 。
+这里以阿里云 Redis 为例说明，它支持 bigkey 实时分析、发现，文档地址：。
@@ -381,7 +381,7 @@ bigkey 的常见处理以及优化办法如下（这些方法可以配合起来
- **分割 bigkey**：将一个 bigkey 分割为多个小 key。例如，将一个含有上万字段数量的 Hash 按照一定策略（比如二次哈希）拆分为多个 Hash。
- **手动清理**：Redis 4.0+ 可以使用 `UNLINK` 命令来异步删除一个或多个指定的 key。Redis 4.0 以下可以考虑使用 `SCAN` 命令结合 `DEL` 命令来分批次删除。
- **采用合适的数据结构**：例如，文件二进制数据不使用 String 保存、使用 HyperLogLog 统计页面 UV、Bitmap 保存状态信息（0/1）。
-- **开启 lazy-free（惰性删除/延迟释放）** ：lazy-free 特性是 Redis 4.0 开始引入的，指的是让 Redis 采用异步方式延迟释放 key 使用的内存，将该操作交给单独的子线程处理，避免阻塞主线程。
+- **开启 lazy-free（惰性删除/延迟释放）**：lazy-free 特性是 Redis 4.0 开始引入的，指的是让 Redis 采用异步方式延迟释放 key 使用的内存，将该操作交给单独的子线程处理，避免阻塞主线程。
### Redis hotkey（热 Key）
@@ -432,13 +432,13 @@ maxmemory-policy allkeys-lfu
需要注意的是，`hotkeys` 参数命令也会增加 Redis 实例的 CPU 和内存消耗（全局扫描），因此需要谨慎使用。
-**2、使用`MONITOR` 命令。**
+**2、使用 `MONITOR` 命令。**
`MONITOR` 命令是 Redis 提供的一种实时查看 Redis 的所有操作的方式，可以用于临时监控 Redis 实例的操作情况，包括读写、删除等操作。
由于该命令对 Redis 性能的影响比较大，因此禁止长时间开启 `MONITOR`（生产环境中建议谨慎使用该命令）。
-```java
+```bash
# redis-cli
127.0.0.1:6379> MONITOR
OK
@@ -473,7 +473,7 @@ OK
如果你用的是公有云的 Redis 服务的话，可以看看其是否提供了 key 分析功能（一般都提供了）。
-这里以阿里云 Redis 为例说明，它支持 hotkey 实时分析、发现，文档地址： 。
+这里以阿里云 Redis 为例说明，它支持 hotkey 实时分析、发现，文档地址：。
@@ -497,16 +497,16 @@ hotkey 的常见处理以及优化办法如下（这些方法可以配合起来
我们知道一个 Redis 命令的执行可以简化为以下 4 步：
-1. 发送命令
-2. 命令排队
-3. 命令执行
-4. 返回结果
+1. 发送命令；
+2. 命令排队；
+3. 命令执行；
+4. 返回结果。
Redis 慢查询统计的是命令执行这一步骤的耗时，慢查询命令也就是那些命令执行时间较长的命令。
Redis 为什么会有慢查询命令呢？
-Redis 中的大部分命令都是 O(1)时间复杂度，但也有少部分 O(n) 时间复杂度的命令，例如：
+Redis 中的大部分命令都是 O(1) 时间复杂度，但也有少部分 O(n) 时间复杂度的命令，例如：
- `KEYS *`：会返回所有符合规则的 key。
- `HGETALL`：会返回一个 Hash 中所有的键值对。
@@ -517,23 +517,25 @@ Redis 中的大部分命令都是 O(1)时间复杂度，但也有少部分 O(n)
由于这些命令时间复杂度是 O(n)，有时候也会全表扫描，随着 n 的增大，执行耗时也会越长。不过， 这些命令并不是一定不能使用，但是需要明确 N 的值。另外，有遍历的需求可以使用 `HSCAN`、`SSCAN`、`ZSCAN` 代替。
-除了这些 O(n)时间复杂度的命令可能会导致慢查询之外， 还有一些时间复杂度可能在 O(N) 以上的命令，例如：
+除了这些 O(n) 时间复杂度的命令可能会导致慢查询之外，还有一些时间复杂度可能在 O(N) 以上的命令，例如：
-- `ZRANGE`/`ZREVRANGE`：返回指定 Sorted Set 中指定排名范围内的所有元素。时间复杂度为 O(log(n)+m)，n 为所有元素的数量， m 为返回的元素数量，当 m 和 n 相当大时，O(n) 的时间复杂度更小。
-- `ZREMRANGEBYRANK`/`ZREMRANGEBYSCORE`：移除 Sorted Set 中指定排名范围/指定 score 范围内的所有元素。时间复杂度为 O(log(n)+m)，n 为所有元素的数量， m 被删除元素的数量，当 m 和 n 相当大时，O(n) 的时间复杂度更小。
+- `ZRANGE`/`ZREVRANGE`：返回指定 Sorted Set 中指定排名范围内的所有元素。时间复杂度为 O(log(n)+m)，n 为所有元素的数量，m 为返回的元素数量，当 m 和 n 相当大时，O(n) 的时间复杂度更小。
+- `ZREMRANGEBYRANK`/`ZREMRANGEBYSCORE`：移除 Sorted Set 中指定排名范围/指定 score 范围内的所有元素。时间复杂度为 O(log(n)+m)，n 为所有元素的数量，m 被删除元素的数量，当 m 和 n 相当大时，O(n) 的时间复杂度更小。
- ……
#### 如何找到慢查询命令？
+Redis 提供了一个内置的**慢查询日志 (Slow Log)** 功能，专门用来记录执行时间超过指定阈值的命令。这对于排查性能瓶颈、找出导致 Redis 阻塞的“慢”操作非常有帮助，原理和 MySQL 的慢查询日志类似。
+
在 `redis.conf` 文件中，我们可以使用 `slowlog-log-slower-than` 参数设置耗时命令的阈值，并使用 `slowlog-max-len` 参数设置耗时命令的最大记录条数。
-当 Redis 服务器检测到执行时间超过 `slowlog-log-slower-than`阈值的命令时，就会将该命令记录在慢查询日志(slow log) 中，这点和 MySQL 记录慢查询语句类似。当慢查询日志超过设定的最大记录条数之后，Redis 会把最早的执行命令依次舍弃。
+当 Redis 服务器检测到执行时间超过 `slowlog-log-slower-than` 阈值的命令时，就会将该命令记录在慢查询日志（slow log）中，这点和 MySQL 记录慢查询语句类似。当慢查询日志超过设定的最大记录条数之后，Redis 会把最早的执行命令依次舍弃。
-⚠️注意：由于慢查询日志会占用一定内存空间，如果设置最大记录条数过大，可能会导致内存占用过高的问题。
+⚠️ 注意：由于慢查询日志会占用一定内存空间，如果设置最大记录条数过大，可能会导致内存占用过高的问题。
-`slowlog-log-slower-than`和`slowlog-max-len`的默认配置如下(可以自行修改)：
+`slowlog-log-slower-than` 和 `slowlog-max-len` 的默认配置如下（可以自行修改）：
-```nginx
+```properties
# The following time is expressed in microseconds, so 1000000 is equivalent
# to one second. Note that a negative number disables the slow log, while
# a value of zero forces the logging of every command.
@@ -553,9 +555,9 @@ CONFIG SET slowlog-log-slower-than 10000
CONFIG SET slowlog-max-len 128
```
-获取慢查询日志的内容很简单，直接使用`SLOWLOG GET` 命令即可。
+获取慢查询日志的内容很简单，直接使用 `SLOWLOG GET` 命令即可。
-```java
+```bash
127.0.0.1:6379> SLOWLOG GET #慢日志查询
1) 1) (integer) 5
2) (integer) 1684326682
@@ -569,12 +571,12 @@ CONFIG SET slowlog-max-len 128
慢查询日志中的每个条目都由以下六个值组成：
-1. 唯一渐进的日志标识符。
-2. 处理记录命令的 Unix 时间戳。
-3. 执行所需的时间量，以微秒为单位。
-4. 组成命令参数的数组。
-5. 客户端 IP 地址和端口。
-6. 客户端名称。
+1. **唯一 ID**: 日志条目的唯一标识符。
+2. **时间戳 (Timestamp)**: 命令执行完成时的 Unix 时间戳。
+3. **耗时 (Duration)**: 命令执行所花费的时间，单位是**微秒**。
+4. **命令及参数 (Command)**: 执行的具体命令及其参数数组。
+5. **客户端信息 (Client IP:Port)**: 执行命令的客户端地址和端口。
+6. **客户端名称 (Client Name)**: 如果客户端设置了名称 (CLIENT SETNAME)。
`SLOWLOG GET` 命令默认返回最近 10 条的的慢查询命令，你也自己可以指定返回的慢查询命令的数量 `SLOWLOG GET N`。
@@ -593,7 +595,7 @@ OK
**相关问题**：
-1. 什么是内存碎片?为什么会有 Redis 内存碎片?
+1. 什么是内存碎片？为什么会有 Redis 内存碎片？
2. 如何清理 Redis 内存碎片？
**参考答案**：[Redis 内存碎片详解](https://javaguide.cn/database/redis/redis-memory-fragmentation.html)。
@@ -604,7 +606,7 @@ OK
#### 什么是缓存穿透？
-缓存穿透说简单点就是大量请求的 key 是不合理的，**根本不存在于缓存中，也不存在于数据库中** 。这就导致这些请求直接到了数据库上，根本没有经过缓存这一层，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。
+缓存穿透说简单点就是大量请求的 key 是不合理的，**根本不存在于缓存中，也不存在于数据库中**。这就导致这些请求直接到了数据库上，根本没有经过缓存这一层，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。
@@ -616,9 +618,9 @@ OK
**1）缓存无效 key**
-如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间，具体命令如下：`SET key value EX 10086` 。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。
+如果缓存和数据库都查不到某个 key 的数据，就写一个到 Redis 中去并设置过期时间，具体命令如下：`SET key value EX 10086`。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点，比如 1 分钟。
-另外，这里多说一嘴，一般情况下我们是这样设计 key 的：`表名:列名:主键名:主键值` 。
+另外，这里多说一嘴，一般情况下我们是这样设计 key 的：`表名:列名:主键名:主键值`。
如果用 Java 代码展示的话，差不多是下面这样的：
@@ -655,21 +657,25 @@ Bloom Filter 会使用一个较大的 bit 数组来保存所有的数据，数
具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。
-加入布隆过滤器之后的缓存处理流程图如下。
+加入布隆过滤器之后的缓存处理流程图如下：
-更多关于布隆过滤器的详细介绍可以看看我的这篇原创：[不了解布隆过滤器？一文给你整的明明白白！](https://javaguide.cn/cs-basics/data-structure/bloom-filter.html) ，强烈推荐。
+更多关于布隆过滤器的详细介绍可以看看我的这篇原创：[不了解布隆过滤器？一文给你整的明明白白！](https://javaguide.cn/cs-basics/data-structure/bloom-filter.html)，强烈推荐。
**3）接口限流**
根据用户或者 IP 对接口进行限流，对于异常频繁的访问行为，还可以采取黑名单机制，例如将异常 IP 列入黑名单。
+后面提到的缓存击穿和雪崩都可以配合接口限流来解决，毕竟这些问题的关键都是有很多请求落到了数据库上造成数据库压力过大。
+
+限流的具体方案可以参考这篇文章：[服务限流详解](https://javaguide.cn/high-availability/limit-request.html)。
+
### 缓存击穿
#### 什么是缓存击穿？
-缓存击穿中，请求的 key 对应的是 **热点数据** ，该数据 **存在于数据库中，但不存在于缓存中（通常是因为缓存中的那份数据已经过期）** 。这就可能会导致瞬时大量的请求直接打到了数据库上，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。
+缓存击穿中，请求的 key 对应的是 **热点数据**，该数据 **存在于数据库中，但不存在于缓存中（通常是因为缓存中的那份数据已经过期）**。这就可能会导致瞬时大量的请求直接打到了数据库上，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。
@@ -677,9 +683,9 @@ Bloom Filter 会使用一个较大的 bit 数组来保存所有的数据，数
#### 有哪些解决办法？
-1. 设置热点数据永不过期或者过期时间比较长。
-2. 针对热点数据提前预热，将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。
-3. 请求数据库写数据到缓存之前，先获取互斥锁，保证只有一个请求会落到数据库上，减少数据库的压力。
+1. **永不过期**（不推荐）：设置热点数据永不过期或者过期时间比较长。
+2. **提前预热**（推荐）：针对热点数据提前预热，将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。
+3. **加锁**（看情况）：在缓存失效后，通过设置互斥锁确保只有一个请求去查询数据库并更新缓存。
#### 缓存穿透和缓存击穿有什么区别？
@@ -699,23 +705,22 @@ Bloom Filter 会使用一个较大的 bit 数组来保存所有的数据，数
-举个例子：数据库中的大量数据在同一时间过期，这个时候突然有大量的请求需要访问这些过期的数据。这就导致大量的请求直接落到数据库上，对数据库造成了巨大的压力。
+举个例子：缓存中的大量数据在同一时间过期，这个时候突然有大量的请求需要访问这些过期的数据。这就导致大量的请求直接落到数据库上，对数据库造成了巨大的压力。
#### 有哪些解决办法？
-**针对 Redis 服务不可用的情况：**
+**针对 Redis 服务不可用的情况**：
-1. 采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。
-2. 限流，避免同时处理大量的请求。
-3. 多级缓存，例如本地缓存+Redis 缓存的组合，当 Redis 缓存出现问题时，还可以从本地缓存中获取到部分数据。
+1. **Redis 集群**：采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。Redis Cluster 和 Redis Sentinel 是两种最常用的 Redis 集群实现方案，详细介绍可以参考：[Redis 集群详解(付费)](https://javaguide.cn/database/redis/redis-cluster.html)。
+2. **多级缓存**：设置多级缓存，例如本地缓存+Redis 缓存的二级缓存组合，当 Redis 缓存出现问题时，还可以从本地缓存中获取到部分数据。
-**针对热点缓存失效的情况：**
+**针对大量缓存同时失效的情况**：
-1. 设置不同的失效时间比如随机设置缓存的失效时间。
-2. 缓存永不失效（不太推荐，实用性太差）。
-3. 缓存预热，也就是在程序启动后或运行过程中，主动将热点数据加载到缓存中。
+1. **设置随机失效时间**（可选）：为缓存设置随机的失效时间，例如在固定过期时间的基础上加上一个随机值，这样可以避免大量缓存同时到期，从而减少缓存雪崩的风险。
+2. **提前预热**（推荐）：针对热点数据提前预热，将其存入缓存中并设置合理的过期时间，比如秒杀场景下的数据在秒杀结束之前不过期。
+3. **持久缓存策略**（看情况）：虽然一般不推荐设置缓存永不过期，但对于某些关键性和变化不频繁的数据，可以考虑这种策略。
-**缓存预热如何实现？**
+#### 缓存预热如何实现？
常见的缓存预热方式有两种：
@@ -724,20 +729,32 @@ Bloom Filter 会使用一个较大的 bit 数组来保存所有的数据，数
#### 缓存雪崩和缓存击穿有什么区别？
-缓存雪崩和缓存击穿比较像，但缓存雪崩导致的原因是缓存中的大量或者所有数据失效，缓存击穿导致的原因主要是某个热点数据不存在与缓存中（通常是因为缓存中的那份数据已经过期）。
+缓存雪崩和缓存击穿比较像，但缓存雪崩导致的原因是缓存中的大量或者所有数据失效，缓存击穿导致的原因主要是某个热点数据不存在于缓存中（通常是因为缓存中的那份数据已经过期）。
### 如何保证缓存和数据库数据的一致性？
-细说的话可以扯很多，但是我觉得其实没太大必要（小声 BB：很多解决方案我也没太弄明白）。我个人觉得引入缓存之后，如果为了短时间的不一致性问题，选择让系统设计变得更加复杂的话，完全没必要。
+缓存和数据库一致性是个挺常见的技术挑战。引入缓存主要是为了提升性能、减轻数据库压力，但确实会带来数据不一致的风险。绝对的一致性往往意味着更高的系统复杂度和性能开销，所以实践中我们通常会根据业务场景选择合适的策略，在性能和一致性之间找到一个平衡点。
+
+下面单独对 **Cache Aside Pattern（旁路缓存模式）** 来聊聊。这是非常常用的一种缓存读写策略，它的读写逻辑是这样的：
+
+- **读操作**：
+ 1. 先尝试从缓存读取数据。
+ 2. 如果缓存命中，直接返回数据。
+ 3. 如果缓存未命中，从数据库查询数据，将查到的数据放入缓存并返回数据。
+- **写操作**：
+ 1. 先更新数据库。
+ 2. 再直接删除缓存中对应的数据。
+
+图解如下：
-下面单独对 **Cache Aside Pattern（旁路缓存模式）** 来聊聊。
+
-Cache Aside Pattern 中遇到写请求是这样的：更新数据库，然后直接删除缓存 。
+
如果更新数据库成功，而删除缓存这一步失败的情况的话，简单说有两个解决方案：
-1. **缓存失效时间变短（不推荐，治标不治本）**：我们让缓存数据的过期时间变短，这样的话缓存就会从数据库中加载数据。另外，这种解决办法对于先操作缓存后操作数据库的场景不适用。
-2. **增加缓存更新重试机制（常用）**：如果缓存服务当前不可用导致缓存删除失败的话，我们就隔一段时间进行重试，重试次数可以自己定。不过，这里更适合引入消息队列实现异步重试，将删除缓存重试的消息投递到消息队列，然后由专门的消费者来重试，直到成功。虽然说多引入了一个消息队列，但其整体带来的收益还是要更高一些。
+1. **缓存失效时间（TTL - Time To Live）变短**（不推荐，治标不治本）：我们让缓存数据的过期时间变短，这样的话缓存就会从数据库中加载数据。另外，这种解决办法对于先操作缓存后操作数据库的场景不适用。
+2. **增加缓存更新重试机制**（常用）：如果缓存服务当前不可用导致缓存删除失败的话，我们就隔一段时间进行重试，重试次数可以自己定。不过，这里更适合引入消息队列实现异步重试，将删除缓存重试的消息投递到消息队列，然后由专门的消费者来重试，直到成功。虽然说多引入了一个消息队列，但其整体带来的收益还是要更高一些。
相关文章推荐：[缓存和数据库一致性问题，看这篇就够了 - 水滴与银弹](https://mp.weixin.qq.com/s?__biz=MzIyOTYxNDI5OA==&mid=2247487312&idx=1&sn=fa19566f5729d6598155b5c676eee62d&chksm=e8beb8e5dfc931f3e35655da9da0b61c79f2843101c130cf38996446975014f958a6481aacf1&scene=178&cur_album_id=1699766580538032128#rd)。
@@ -750,18 +767,18 @@ Cache Aside Pattern 中遇到写请求是这样的：更新数据库，然后直
**Redis Sentinel**：
1. 什么是 Sentinel？ 有什么用？
-2. Sentinel 如何检测节点是否下线？主观下线与客观下线的区别?
+2. Sentinel 如何检测节点是否下线？主观下线与客观下线的区别？
3. Sentinel 是如何实现故障转移的？
4. 为什么建议部署多个 sentinel 节点（哨兵集群）？
-5. Sentinel 如何选择出新的 master（选举机制）?
-6. 如何从 Sentinel 集群中选择出 Leader ？
+5. Sentinel 如何选择出新的 master（选举机制）？
+6. 如何从 Sentinel 集群中选择出 Leader？
7. Sentinel 可以防止脑裂吗？
**Redis Cluster**：
1. 为什么需要 Redis Cluster？解决了什么问题？有什么优势？
2. Redis Cluster 是如何分片的？
-3. 为什么 Redis Cluster 的哈希槽是 16384 个?
+3. 为什么 Redis Cluster 的哈希槽是 16384 个？
4. 如何确定给定 key 的应该分布到哪个哈希槽中？
5. Redis Cluster 支持重新分配哈希槽吗？
6. Redis Cluster 扩容缩容期间可以提供服务吗？
@@ -774,23 +791,23 @@ Cache Aside Pattern 中遇到写请求是这样的：更新数据库，然后直
实际使用 Redis 的过程中，我们尽量要准守一些常见的规范，比如：
1. 使用连接池：避免频繁创建关闭客户端连接。
-2. 尽量不使用 O(n)指令，使用 O(n) 命令时要关注 n 的数量：像 `KEYS *`、`HGETALL`、`LRANGE`、`SMEMBERS`、`SINTER`/`SUNION`/`SDIFF`等 O(n) 命令并非不能使用，但是需要明确 n 的值。另外，有遍历的需求可以使用 `HSCAN`、`SSCAN`、`ZSCAN` 代替。
-3. 使用批量操作减少网络传输：原生批量操作命令（比如 `MGET`、`MSET`等等）、pipeline、Lua 脚本。
-4. 尽量不适用 Redis 事务：Redis 事务实现的功能比较鸡肋，可以使用 Lua 脚本代替。
+2. 尽量不使用 O(n) 指令，使用 O(n) 命令时要关注 n 的数量：像 `KEYS *`、`HGETALL`、`LRANGE`、`SMEMBERS`、`SINTER`/`SUNION`/`SDIFF` 等 O(n) 命令并非不能使用，但是需要明确 n 的值。另外，有遍历的需求可以使用 `HSCAN`、`SSCAN`、`ZSCAN` 代替。
+3. 使用批量操作减少网络传输：原生批量操作命令（比如 `MGET`、`MSET` 等等）、pipeline、Lua 脚本。
+4. 尽量不使用 Redis 事务：Redis 事务实现的功能比较鸡肋，可以使用 Lua 脚本代替。
5. 禁止长时间开启 monitor：对性能影响比较大。
6. 控制 key 的生命周期：避免 Redis 中存放了太多不经常被访问的数据。
7. ……
-相关文章推荐：[阿里云 Redis 开发规范](https://developer.aliyun.com/article/531067) 。
+相关文章推荐：[阿里云 Redis 开发规范](https://developer.aliyun.com/article/531067)。
## 参考
- 《Redis 开发与运维》
- 《Redis 设计与实现》
-- Redis Transactions :
-- Bigkey 问题的解决思路与方式探索:
+- Bigkey 问题的解决思路与方式探索：
- Redis 延迟问题全面排障指南：
diff --git a/docs/database/redis/redis-skiplist.md b/docs/database/redis/redis-skiplist.md
index 8546aa8eb04..11f0c32b665 100644
--- a/docs/database/redis/redis-skiplist.md
+++ b/docs/database/redis/redis-skiplist.md
@@ -40,14 +40,14 @@ tag:
6) "60"
```
-此时我们通过 `object` 指令查看 zset 的数据结构，可以看到当前有序集合存储的还是是**ziplist(压缩列表)**。
+此时我们通过 `object` 指令查看 zset 的数据结构，可以看到当前有序集合存储的还是**ziplist(压缩列表)**。
```bash
127.0.0.1:6379> object encoding rankList
"ziplist"
```
-因为设计者考虑到 Redis 数据存放于内存，为了节约宝贵的内存空间在有序集合在元素小于 64 字节且个数小于 128 的时候，会使用 ziplist，而这个阈值的默认值的设置就来自下面这两个配置项。
+因为设计者考虑到 Redis 数据存放于内存，为了节约宝贵的内存空间，在有序集合元素小于 64 字节且个数小于 128 的时候，会使用 ziplist，而这个阈值的默认值的设置就来自下面这两个配置项。
```bash
zset-max-ziplist-value 64
@@ -78,7 +78,7 @@ zset-max-ziplist-entries 128
为了更好的回答上述问题以及更好的理解和掌握跳表，这里可以通过手写一个简单的跳表的形式来帮助读者理解跳表这个数据结构。
-我们都知道有序链表在添加、查询、删除的平均时间复杂都都是**O(n)**即线性增长，所以一旦节点数量达到一定体量后其性能表现就会非常差劲。而跳表我们完全可以理解为在原始链表基础上，建立多级索引，通过多级索引检索定位将增删改查的时间复杂度变为**O(log n)**。
+我们都知道有序链表在添加、查询、删除的平均时间复杂都都是 **O(n)** 即线性增长，所以一旦节点数量达到一定体量后其性能表现就会非常差劲。而跳表我们完全可以理解为在原始链表基础上，建立多级索引，通过多级索引检索定位将增删改查的时间复杂度变为 **O(log n)** 。
可能这里说的有些抽象，我们举个例子，以下图跳表为例，其原始链表存储按序存储 1-10，有 2 级索引，每级索引的索引个数都是基于下层元素个数的一半。
@@ -145,8 +145,8 @@ r=n/2^k
1. 跳表的高度计算从原始链表开始，即默认情况下插入的元素的高度为 1，代表没有索引，只有元素节点。
2. 设计一个为插入元素生成节点索引高度 level 的方法。
3. 进行一次随机运算，随机数值范围为 0-1 之间。
-4. 如果随机数大于 0.5 则为当前元素添加一级索引，自此我们保证生成一级索引的概率为**50%**，这也就保证了 1 级索引理想情况下只有一半的元素会生成索引。
-5. 同理后续每次随机算法得到的值大于 0.5 时，我们的索引高度就加 1，这样就可以保证节点生成的 2 级索引概率为**25%**，3 级索引为**12.5%**……
+4. 如果随机数大于 0.5 则为当前元素添加一级索引，自此我们保证生成一级索引的概率为 **50%** ，这也就保证了 1 级索引理想情况下只有一半的元素会生成索引。
+5. 同理后续每次随机算法得到的值大于 0.5 时，我们的索引高度就加 1，这样就可以保证节点生成的 2 级索引概率为 **25%** ，3 级索引为 **12.5%** ……
我们回过头，上述插入 7 之后，我们通过随机算法得到 2，即要为其建立 1 级索引：
@@ -283,33 +283,39 @@ public void add(int value) {
查询逻辑比较简单，从跳表最高级的索引开始定位找到小于要查的 value 的最大值，以下图为例，我们希望查找到节点 8：
-1. 跳表的 3 级索引首先找找到 5 的索引，5 的 3 级索引**forwards[3]**指向空，索引直接向下。
-2. 来到 5 的 2 级索引，其后继**forwards[2]**指向 8，继续向下。
-3. 5 的 1 级索引**forwards[1]**指向索引 6，继续向前。
-4. 索引 6 的**forwards[1]**指向索引 8，继续向下。
-5. 我们在原始节点向前找到节点 7。
-6. 节点 7 后续就是节点 8，继续向前为节点 8，无法继续向下，结束搜寻。
-7. 判断 7 的前驱，等于 8，查找结束。
-
+- **从最高层级开始 (3 级索引)** ：查找指针 `p` 从头节点开始。在 3 级索引上，`p` 的后继 `forwards[2]`（假设最高 3 层，索引从 0 开始）指向节点 `5`。由于 `5 < 8`，指针 `p` 向右移动到节点 `5`。节点 `5` 在 3 级索引上的后继 `forwards[2]` 为 `null`（或指向一个大于 `8` 的节点，图中未画出）。当前层级向右查找结束，指针 `p` 保持在节点 `5`，**向下移动到 2 级索引**。
+- **在 2 级索引**：当前指针 `p` 为节点 `5`。`p` 的后继 `forwards[1]` 指向节点 `8`。由于 `8` 不小于 `8`（即 `8 < 8` 为 `false`），当前层级向右查找结束（`p` 不会移动到节点 `8`）。指针 `p` 保持在节点 `5`，**向下移动到 1 级索引**。
+- **在 1 级索引** ：当前指针 `p` 为节点 `5`。`p` 的后继 `forwards[0]` 指向最底层的节点 `5`。由于 `5 < 8`，指针 `p` 向右移动到最底层的节点 `5`。此时，当前指针 `p` 为最底层的节点 `5`。其后继 `forwards[0]` 指向最底层的节点 `6`。由于 `6 < 8`，指针 `p` 向右移动到最底层的节点 `6`。当前指针 `p` 为最底层的节点 `6`。其后继 `forwards[0]` 指向最底层的节点 `7`。由于 `7 < 8`，指针 `p` 向右移动到最底层的节点 `7`。当前指针 `p` 为最底层的节点 `7`。其后继 `forwards[0]` 指向最底层的节点 `8`。由于 `8` 不小于 `8`（即 `8 < 8` 为 `false`），当前层级向右查找结束。此时，已经遍历完所有层级，`for` 循环结束。
+- **最终定位与检查** ：经过所有层级的查找，指针 `p` 最终停留在最底层（0 级索引）的节点 `7`。这个节点是整个跳表中值小于目标值 `8` 的那个最大的节点。检查节点 `7` 的**后继节点**（即 `p.forwards[0]`）：`p.forwards[0]` 指向节点 `8`。判断 `p.forwards[0].data`（即节点 `8` 的值）是否等于目标值 `8`。条件满足（`8 == 8`），**查找成功，找到节点 `8`**。
+
所以我们的代码实现也很上述步骤差不多，从最高级索引开始向前查找，如果不为空且小于要查找的值，则继续向前搜寻，遇到不小于的节点则继续向下，如此往复，直到得到当前跳表中小于查找值的最大节点，查看其前驱是否等于要查找的值：
```java
public Node get(int value) {
- Node p = h;
- //找到小于value的最大值
+ Node p = h; // 从头节点开始
+
+ // 从最高层级索引开始，逐层向下
for (int i = levelCount - 1; i >= 0; i--) {
+ // 在当前层级向右查找，直到 p.forwards[i] 为 null
+ // 或者 p.forwards[i].data 大于等于目标值 value
while (p.forwards[i] != null && p.forwards[i].data < value) {
- p = p.forwards[i];
+ p = p.forwards[i]; // 向右移动
}
+ // 此时 p.forwards[i] 为 null，或者 p.forwards[i].data >= value
+ // 或者 p 是当前层级中小于 value 的最大节点（如果存在这样的节点）
}
- //如果p的前驱节点等于value则直接返回
+
+ // 经过所有层级的查找，p 现在是原始链表（0级索引）中
+ // 小于目标值 value 的最大节点（或者头节点，如果所有元素都大于等于 value）
+
+ // 检查 p 在原始链表中的下一个节点是否是目标值
if (p.forwards[0] != null && p.forwards[0].data == value) {
- return p.forwards[0];
+ return p.forwards[0]; // 找到了，返回该节点
}
- return null;
+ return null; // 未找到
}
```
@@ -599,13 +605,19 @@ Node{data=21, maxLevel=3}
Node{data=23, maxLevel=1}
```
+**Redis 跳表的特点**：
+
+1. 采用**双向链表**，不同于上面的示例，存在一个回退指针。主要用于简化操作，例如删除某个元素时，还需要找到该元素的前驱节点，使用回退指针会非常方便。
+2. `score` 值可以重复，如果 `score` 值一样，则按照 ele（节点存储的值，为 sds）字典排序
+3. Redis 跳跃表默认允许最大的层数是 32，被源码中 `ZSKIPLIST_MAXLEVEL` 定义。
+
## 和其余三种数据结构的比较
最后，我们再来回答一下文章开头的那道面试题: “Redis 的有序集合底层为什么要用跳表，而不用平衡树、红黑树或者 B+树？”。
### 平衡树 vs 跳表
-先来说说它和平衡树的比较，平衡树我们又会称之为 **AVL 树**，是一个严格的平衡二叉树，平衡条件必须满足（所有节点的左右子树高度差不超过 1，即平衡因子为范围为 `[-1,1]`）。平衡树的插入、删除和查询的时间复杂度和跳表一样都是 **O(log n)**。
+先来说说它和平衡树的比较，平衡树我们又会称之为 **AVL 树**，是一个严格的平衡二叉树，平衡条件必须满足（所有节点的左右子树高度差不超过 1，即平衡因子为范围为 `[-1,1]`）。平衡树的插入、删除和查询的时间复杂度和跳表一样都是 **O(log n)** 。
对于范围查询来说，它也可以通过中序遍历的方式达到和跳表一样的效果。但是它的每一次插入或者删除操作都需要保证整颗树左右节点的绝对平衡，只要不平衡就要通过旋转操作来保持平衡，这个过程是比较耗时的。
@@ -674,7 +686,7 @@ private Node add(Node node, K key, V value) {
### 红黑树 vs 跳表
-红黑树（Red Black Tree）也是一种自平衡二叉查找树，它的查询性能略微逊色于 AVL 树，但插入和删除效率更高。红黑树的插入、删除和查询的时间复杂度和跳表一样都是 **O(log n)**。
+红黑树（Red Black Tree）也是一种自平衡二叉查找树，它的查询性能略微逊色于 AVL 树，但插入和删除效率更高。红黑树的插入、删除和查询的时间复杂度和跳表一样都是 **O(log n)** 。
红黑树是一个**黑平衡树**，即从任意节点到另外一个叶子叶子节点，它所经过的黑节点是一样的。当对它进行插入操作时，需要通过旋转和染色（红黑变换）来保证黑平衡。不过，相较于 AVL 树为了维持平衡的开销要小一些。关于红黑树的详细介绍，可以查看这篇文章：[红黑树](https://javaguide.cn/cs-basics/data-structure/red-black-tree.html)。
@@ -726,7 +738,7 @@ private Node < K, V > add(Node < K, V > node, K key, V val) {
1. **多叉树结构**：它是一棵多叉树，每个节点可以包含多个子节点，减小了树的高度，查询效率高。
2. **存储效率高**:其中非叶子节点存储多个 key，叶子节点存储 value，使得每个节点更够存储更多的键，根据索引进行范围查询时查询效率更高。-
-3. **平衡性**：它是绝对的平衡，即树的各个分支高度相差不大，确保查询和插入时间复杂度为**O(log n)**。
+3. **平衡性**：它是绝对的平衡，即树的各个分支高度相差不大，确保查询和插入时间复杂度为 **O(log n)** 。
4. **顺序访问**：叶子节点间通过链表指针相连，范围查询表现出色。
5. **数据均匀分布**：B+树插入时可能会导致数据重新分布，使得数据在整棵树分布更加均匀，保证范围查询和删除效率。
diff --git a/docs/database/sql/sql-questions-01.md b/docs/database/sql/sql-questions-01.md
index c0e3b2f826b..4bf08f0fa0b 100644
--- a/docs/database/sql/sql-questions-01.md
+++ b/docs/database/sql/sql-questions-01.md
@@ -1095,13 +1095,14 @@ WHERE b.prod_id = 'BR01'
```sql
# 写法 1：子查询
-SELECT o.cust_id AS cust_id, tb.total_ordered AS total_ordered
-FROM (SELECT order_num, Sum(item_price * quantity) AS total_ordered
+SELECT o.cust_id, SUM(tb.total_ordered) AS `total_ordered`
+FROM (SELECT order_num, SUM(item_price * quantity) AS total_ordered
FROM OrderItems
GROUP BY order_num) AS tb,
Orders o
WHERE tb.order_num = o.order_num
-ORDER BY total_ordered DESC
+GROUP BY o.cust_id
+ORDER BY total_ordered DESC;
# 写法 2：连接表
SELECT b.cust_id, Sum(a.quantity * a.item_price) AS total_ordered
@@ -1111,6 +1112,8 @@ GROUP BY cust_id
ORDER BY total_ordered DESC
```
+关于写法一详细介绍可以参考： [issue#2402：写法 1 存在的错误以及修改方法](https://github.com/Snailclimb/JavaGuide/issues/2402)。
+
### 从 Products 表中检索所有的产品名称以及对应的销售总数
`Products` 表中检索所有的产品名称：`prod_name`、产品 id：`prod_id`
@@ -1653,12 +1656,12 @@ ORDER BY prod_name
注意：`vend_id` 列会显示在多个表中，因此在每次引用它时都需要完全限定它。
```sql
-SELECT vend_id, COUNT(prod_id) AS prod_id
-FROM Vendors
-LEFT JOIN Products
+SELECT v.vend_id, COUNT(prod_id) AS prod_id
+FROM Vendors v
+LEFT JOIN Products p
USING(vend_id)
-GROUP BY vend_id
-ORDER BY vend_id
+GROUP BY v.vend_id
+ORDER BY v.vend_id
```
## 组合查询
diff --git a/docs/database/sql/sql-questions-03.md b/docs/database/sql/sql-questions-03.md
index 6ae8642c647..f5acd8fc5c8 100644
--- a/docs/database/sql/sql-questions-03.md
+++ b/docs/database/sql/sql-questions-03.md
@@ -216,9 +216,9 @@ WHERE info.exam_id = record.exam_id
| total_pv | complete_pv | complete_exam_cnt |
| -------- | ----------- | ----------------- |
-| 11 | 7 | 2 |
+| 10 | 7 | 2 |
-解释：表示截止当前，有 11 次试卷作答记录，已完成的作答次数为 7 次（中途退出的为未完成状态，其交卷时间和份数为 NULL），已完成的试卷有 9001 和 9002 两份。
+解释：表示截止当前，有 10 次试卷作答记录，已完成的作答次数为 7 次（中途退出的为未完成状态，其交卷时间和份数为 NULL），已完成的试卷有 9001 和 9002 两份。
**思路**： 这题一看到统计次数，肯定第一时间就要想到用`COUNT`这个函数来解决，问题是要统计不同的记录，该怎么来写？使用子查询就能解决这个题目(这题用 case when 也能写出来，解法类似，逻辑不同而已)；首先在做这个题之前，让我们先来了解一下`COUNT`的基本用法；
diff --git a/docs/database/sql/sql-questions-04.md b/docs/database/sql/sql-questions-04.md
index c15eb8e2243..84f1a2b3c8c 100644
--- a/docs/database/sql/sql-questions-04.md
+++ b/docs/database/sql/sql-questions-04.md
@@ -142,20 +142,20 @@ WHERE ranking <= 3
试卷作答记录表 `exam_record`（`uid` 用户 ID, `exam_id` 试卷 ID, `start_time` 开始作答时间, `submit_time` 交卷时间, `score` 得分）：
-| id | uid | exam_id | start_time | submit_time | score |
-| --- | ---- | ------- | ------------------- | ------------------- | ------ |
-| 1 | 1001 | 9001 | 2021-09-01 09:01:01 | 2021-09-01 09:51:01 | 78 |
-| 2 | 1001 | 9002 | 2021-09-01 09:01:01 | 2021-09-01 09:31:00 | 81 |
-| 3 | 1002 | 9002 | 2021-09-01 12:01:01 | 2021-09-01 12:31:01 | 81 |
-| 4 | 1003 | 9001 | 2021-09-01 19:01:01 | 2021-09-01 19:59:01 | 86 |
-| 5 | 1003 | 9002 | 2021-09-01 12:01:01 | 2021-09-01 12:31:51 | 89 |
-| 6 | 1004 | 9002 | 2021-09-01 19:01:01 | 2021-09-01 19:30:01 | 85 |
-| 7 | 1005 | 9001 | 2021-09-01 12:01:01 | 2021-09-01 12:31:02 | 85 |
-| 8 | 1006 | 9001 | 2021-09-07 10:01:01 | 2021-09-07 10:21:01 | 84 |
-| 9 | 1003 | 9001 | 2021-09-08 12:01:01 | 2021-09-08 12:11:01 | 40 |
-| 10 | 1003 | 9002 | 2021-09-01 14:01:01 | (NULL) | (NULL) |
-| 11 | 1005 | 9001 | 2021-09-01 14:01:01 | (NULL) | (NULL) |
-| 12 | 1003 | 9003 | 2021-09-08 15:01:01 | (NULL) | (NULL) |
+| id | uid | exam_id | start_time | submit_time | score |
+| ---- | ---- | ------- | ------------------- | ------------------- | ------ |
+| 1 | 1001 | 9001 | 2021-09-01 09:01:01 | 2021-09-01 09:51:01 | 78 |
+| 2 | 1001 | 9002 | 2021-09-01 09:01:01 | 2021-09-01 09:31:00 | 81 |
+| 3 | 1002 | 9002 | 2021-09-01 12:01:01 | 2021-09-01 12:31:01 | 81 |
+| 4 | 1003 | 9001 | 2021-09-01 19:01:01 | 2021-09-01 19:59:01 | 86 |
+| 5 | 1003 | 9002 | 2021-09-01 12:01:01 | 2021-09-01 12:31:51 | 89 |
+| 6 | 1004 | 9002 | 2021-09-01 19:01:01 | 2021-09-01 19:30:01 | 85 |
+| 7 | 1005 | 9001 | 2021-09-01 12:01:01 | 2021-09-01 12:31:02 | 85 |
+| 8 | 1006 | 9001 | 2021-09-07 10:02:01 | 2021-09-07 10:21:01 | 84 |
+| 9 | 1003 | 9001 | 2021-09-08 12:01:01 | 2021-09-08 12:11:01 | 40 |
+| 10 | 1003 | 9002 | 2021-09-01 14:01:01 | (NULL) | (NULL) |
+| 11 | 1005 | 9001 | 2021-09-01 14:01:01 | (NULL) | (NULL) |
+| 12 | 1003 | 9003 | 2021-09-08 15:01:01 | (NULL) | (NULL) |
找到第二快和第二慢用时之差大于试卷时长的一半的试卷信息，按试卷 ID 降序排序。由示例数据结果输出如下：
@@ -163,7 +163,7 @@ WHERE ranking <= 3
| ------- | -------- | ------------------- |
| 9001 | 60 | 2021-09-01 06:00:00 |
-**解释**：试卷 9001 被作答用时有 50 分钟、50 分钟、30 分 1 秒、11 分钟、10 分钟，第二快和第二慢用时之差为 50 分钟-11 分钟=39 分钟，试卷时长为 60 分钟，因此满足大于试卷时长一半的条件，输出试卷 ID、时长、发布时间。
+**解释**：试卷 9001 被作答用时有 50 分钟、58 分钟、30 分 1 秒、19 分钟、10 分钟，第二快和第二慢用时之差为 50 分钟-19 分钟=31 分钟，试卷时长为 60 分钟，因此满足大于试卷时长一半的条件，输出试卷 ID、时长、发布时间。
**思路：**
diff --git a/docs/database/sql/sql-syntax-summary.md b/docs/database/sql/sql-syntax-summary.md
index c5805f7657d..cff0b931495 100644
--- a/docs/database/sql/sql-syntax-summary.md
+++ b/docs/database/sql/sql-syntax-summary.md
@@ -148,7 +148,7 @@ WHERE username = 'root';
### 删除数据
- `DELETE` 语句用于删除表中的记录。
-- `TRUNCATE TABLE` 可以清空表，也就是删除所有行。
+- `TRUNCATE TABLE` 可以清空表，也就是删除所有行。说明：`TRUNCATE` 语句不属于 DML 语法而是 DDL 语法。
**删除表中的指定数据**
@@ -257,11 +257,11 @@ ORDER BY cust_name DESC;
**使用 WHERE 和 HAVING 过滤数据**
```sql
-SELECT cust_name, COUNT(*) AS num
+SELECT cust_name, COUNT(*) AS NumberOfOrders
FROM Customers
WHERE cust_email IS NOT NULL
GROUP BY cust_name
-HAVING COUNT(*) >= 1;
+HAVING COUNT(*) > 1;
```
**`having` vs `where`**：
@@ -396,7 +396,7 @@ WHERE prod_price BETWEEN 3 AND 5;
**AND 示例**
-```ini
+```sql
SELECT prod_id, prod_name, prod_price
FROM products
WHERE vend_id = 'DLL01' AND prod_price <= 4;
diff --git a/docs/distributed-system/distributed-id-design.md b/docs/distributed-system/distributed-id-design.md
index adbf61c9803..5b737f34593 100644
--- a/docs/distributed-system/distributed-id-design.md
+++ b/docs/distributed-system/distributed-id-design.md
@@ -99,7 +99,7 @@ UA 是一个特殊字符串头，服务器依次可以识别出客户使用的
abcdefghijklmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXZY0123456789
-之前说过，兑换码要求近可能简洁，那么设计时就需要考虑兑换码的字符数，假设上限为 12 位，而字符空间有 60 位，那么可以表示的空间范围为 60^12=130606940160000000000000(也就是可以 12 位的兑换码可以生成天量,应该够运营同学挥霍了)，转换成 2 进制：
+之前说过，兑换码要求尽可能简洁，那么设计时就需要考虑兑换码的字符数，假设上限为 12 位，而字符空间有 60 位，那么可以表示的空间范围为 60^12=130606940160000000000000(也就是可以 12 位的兑换码可以生成天量,应该够运营同学挥霍了)，转换成 2 进制：
1001000100000000101110011001101101110011000000000000000000000(61 位)
diff --git a/docs/distributed-system/distributed-id.md b/docs/distributed-system/distributed-id.md
index aa7d129faf3..9920f8f7753 100644
--- a/docs/distributed-system/distributed-id.md
+++ b/docs/distributed-system/distributed-id.md
@@ -228,12 +228,16 @@ UUID.randomUUID()
我们这里重点关注一下这个 Version(版本)，不同的版本对应的 UUID 的生成规则是不同的。
-5 种不同的 Version(版本)值分别对应的含义（参考[维基百科对于 UUID 的介绍](https://zh.wikipedia.org/wiki/通用唯一识别码)）：
+8 种不同的 Version(版本)值分别对应的含义（参考[维基百科对于 UUID 的介绍](https://zh.wikipedia.org/wiki/通用唯一识别码)）：
-- **版本 1** : UUID 是根据时间和节点 ID（通常是 MAC 地址）生成；
-- **版本 2** : UUID 是根据标识符（通常是组或用户 ID）、时间和节点 ID 生成；
-- **版本 3、版本 5** : 版本 5 - 确定性 UUID 通过散列（hashing）名字空间（namespace）标识符和名称生成；
-- **版本 4** : UUID 使用[随机性](https://zh.wikipedia.org/wiki/随机性)或[伪随机性](https://zh.wikipedia.org/wiki/伪随机性)生成。
+- **版本 1 (基于时间和节点 ID)** : 基于时间戳（通常是当前时间）和节点 ID（通常为设备的 MAC 地址）生成。当包含 MAC 地址时，可以保证全球唯一性，但也因此存在隐私泄露的风险。
+- **版本 2 (基于标识符、时间和节点 ID)** : 与版本 1 类似，也基于时间和节点 ID，但额外包含了本地标识符（例如用户 ID 或组 ID）。
+- **版本 3 (基于命名空间和名称的 MD5 哈希)**：使用 MD5 哈希算法，将命名空间标识符（一个 UUID）和名称字符串组合计算得到。相同的命名空间和名称总是生成相同的 UUID（**确定性生成**）。
+- **版本 4 (基于随机数)**：几乎完全基于随机数生成，通常使用伪随机数生成器（PRNG）或加密安全随机数生成器（CSPRNG）来生成。 虽然理论上存在碰撞的可能性，但理论上碰撞概率极低（2^122 的可能性），可以认为在实际应用中是唯一的。
+- **版本 5 (基于命名空间和名称的 SHA-1 哈希)**：类似于版本 3，但使用 SHA-1 哈希算法。
+- **版本 6 (基于时间戳、计数器和节点 ID)**：改进了版本 1，将时间戳放在最高有效位（Most Significant Bit，MSB），使得 UUID 可以直接按时间排序。
+- **版本 7 (基于时间戳和随机数据)**：基于 Unix 时间戳和随机数据生成。 由于时间戳位于最高有效位，因此支持按时间排序。并且，不依赖 MAC 地址或节点 ID，避免了隐私问题。
+- **版本 8 (自定义)**：允许用户根据自己的需求定义 UUID 的生成方式。其结构和内容由用户决定，提供更大的灵活性。
下面是 Version 1 版本下生成的 UUID 的示例：
@@ -261,7 +265,7 @@ int version = uuid.version();// 4
最后，我们再简单分析一下 **UUID 的优缺点** （面试的时候可能会被问到的哦！） :
-- **优点**：生成速度比较快、简单易用
+- **优点**：生成速度通常比较快、简单易用
- **缺点**：存储消耗空间大（32 个字符串，128 位）、 不安全（基于 MAC 地址生成 UUID 的算法会造成 MAC 地址泄露)、无序（非自增）、没有具体业务含义、需要解决重复 ID 问题（当机器时间不对的情况下，可能导致会产生重复 ID）
#### Snowflake(雪花算法)
diff --git a/docs/distributed-system/distributed-lock-implementations.md b/docs/distributed-system/distributed-lock-implementations.md
index ddd0b93b820..cb4504c4a7a 100644
--- a/docs/distributed-system/distributed-lock-implementations.md
+++ b/docs/distributed-system/distributed-lock-implementations.md
@@ -56,7 +56,7 @@ OK
```
- **lockKey**：加锁的锁名；
-- **uniqueValue**：能够唯一标示锁的随机字符串；
+- **uniqueValue**：能够唯一标识锁的随机字符串；
- **NX**：只有当 lockKey 对应的 key 值不存在的时候才能 SET 成功；
- **EX**：过期时间设置（秒为单位）EX 3 标示这个锁有一个 3 秒的自动过期时间。与 EX 对应的是 PX（毫秒为单位），这两个都是过期时间设置。
@@ -202,13 +202,11 @@ Redlock 是直接操作 Redis 节点的，并不是通过 Redis 集群操作的
Redlock 实现比较复杂，性能比较差，发生时钟变迁的情况下还存在安全性隐患。《数据密集型应用系统设计》一书的作者 Martin Kleppmann 曾经专门发文（[How to do distributed locking - Martin Kleppmann - 2016](https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html)）怼过 Redlock，他认为这是一个很差的分布式锁实现。感兴趣的朋友可以看看[Redis 锁从面试连环炮聊到神仙打架](https://mp.weixin.qq.com/s?__biz=Mzg3NjU3NTkwMQ==&mid=2247505097&idx=1&sn=5c03cb769c4458350f4d4a321ad51f5a&source=41#wechat_redirect)这篇文章，有详细介绍到 antirez 和 Martin Kleppmann 关于 Redlock 的激烈辩论。
-实际项目中不建议使用 Redlock 算法，成本和收益不成正比。
-
-如果不是非要实现绝对可靠的分布式锁的话，其实单机版 Redis 就完全够了，实现简单，性能也非常高。如果你必须要实现一个绝对可靠的分布式锁的话，可以基于 ZooKeeper 来做，只是性能会差一些。
+实际项目中不建议使用 Redlock 算法，成本和收益不成正比，可以考虑基于 Redis 主从复制+哨兵模式实现分布式锁。
## 基于 ZooKeeper 实现分布式锁
-Redis 实现分布式锁性能较高，ZooKeeper 实现分布式锁可靠性更高。实际项目中，我们应该根据业务的具体需求来选择。
+ZooKeeper 相比于 Redis 实现分布式锁，除了提供相对更高的可靠性之外，在功能层面还有一个非常有用的特性：**Watch 机制**。这个机制可以用来实现公平的分布式锁。不过，使用 ZooKeeper 实现的分布式锁在性能方面相对较差，因此如果对性能要求比较高的话，ZooKeeper 可能就不太适合了。
### 如何基于 ZooKeeper 实现分布式锁？
@@ -365,14 +363,19 @@ private static class LockData
## 总结
-在这篇文章中，我介绍了实现分布式锁的两种常见方式： Redis 和 ZooKeeper。至于具体选择 Redis 还是 ZooKeeper 来实现分布式锁，还是要看业务的具体需求。
+在这篇文章中，我介绍了实现分布式锁的两种常见方式：**Redis** 和 **ZooKeeper**。至于具体选择 Redis 还是 ZooKeeper 来实现分布式锁，还是要根据业务的具体需求来决定。
+
+- 如果对性能要求比较高的话，建议使用 Redis 实现分布式锁。推荐优先选择 **Redisson** 提供的现成分布式锁，而不是自己实现。实际项目中不建议使用 Redlock 算法，成本和收益不成正比，可以考虑基于 Redis 主从复制+哨兵模式实现分布式锁。
+- 如果对可靠性要求比较高，建议使用 ZooKeeper 实现分布式锁，推荐基于 **Curator** 框架来实现。不过，现在很多项目都不会用到 ZooKeeper，如果单纯是因为分布式锁而引入 ZooKeeper 的话，那是不太可取的，不建议这样做，为了一个小小的功能增加了系统的复杂度。
+
+需要注意的是，无论选择哪种方式实现分布式锁，包括 Redis、ZooKeeper 或 Etcd（本文没介绍，但也经常用来实现分布式锁），都无法保证 100% 的安全性，特别是在遇到进程垃圾回收（GC）、网络延迟等异常情况下。
-- 如果对性能要求比较高的话，建议使用 Redis 实现分布式锁（优先选择 Redisson 提供的现成的分布式锁，而不是自己实现）。
-- 如果对可靠性要求比较高的话，建议使用 ZooKeeper 实现分布式锁（推荐基于 Curator 框架实现）。不过，现在很多项目都不会用到 ZooKeeper，如果单纯是因为分布式锁而引入 ZooKeeper 的话，那是不太可取的，不建议这样做，为了一个小小的功能增加了系统的复杂度。
+为了进一步提高系统的可靠性，建议引入一个兜底机制。例如，可以通过 **版本号（Fencing Token）机制** 来避免并发冲突。
-最后，再分享两篇我觉得写的还不错的文章：
+最后，再分享几篇我觉得写的还不错的文章：
- [分布式锁实现原理与最佳实践 - 阿里云开发者](https://mp.weixin.qq.com/s/JzCHpIOiFVmBoAko58ZuGw)
- [聊聊分布式锁 - 字节跳动技术团队](https://mp.weixin.qq.com/s/-N4x6EkxwAYDGdJhwvmZLw)
+- [Redis、ZooKeeper、Etcd，谁有最好用的分布式锁？ - 腾讯云开发者](https://mp.weixin.qq.com/s/yZC6VJGxt1ANZkn0SljZBg)
diff --git a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md
index e343f6cc3db..856378a0cd5 100644
--- a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md
+++ b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md
@@ -9,7 +9,7 @@ tag:
## 什么是 ZooKeeper
-`ZooKeeper` 由 `Yahoo` 开发，后来捐赠给了 `Apache` ，现已成为 `Apache` 顶级项目。`ZooKeeper` 是一个开源的分布式应用程序协调服务器，其为分布式系统提供一致性服务。其一致性是通过基于 `Paxos` 算法的 `ZAB` 协议完成的。其主要功能包括：配置维护、分布式同步、集群管理、分布式事务等。
+`ZooKeeper` 由 `Yahoo` 开发，后来捐赠给了 `Apache` ，现已成为 `Apache` 顶级项目。`ZooKeeper` 是一个开源的分布式应用程序协调服务器，其为分布式系统提供一致性服务。其一致性是通过基于 `Paxos` 算法的 `ZAB` 协议完成的。其主要功能包括：配置维护、分布式同步、集群管理等。
简单来说， `ZooKeeper` 是一个 **分布式协调服务框架** 。分布式？协调服务？这啥玩意？🤔🤔
diff --git a/docs/distributed-system/protocol/gossip-protocl.md b/docs/distributed-system/protocol/gossip-protocl.md
index 67c5c16139e..5590401a9b6 100644
--- a/docs/distributed-system/protocol/gossip-protocl.md
+++ b/docs/distributed-system/protocol/gossip-protocl.md
@@ -53,7 +53,7 @@ Redis Cluster 的节点之间会相互发送多种 Gossip 消息：
-有了 Redis Cluster 之后，不需要专门部署 Sentinel 集群服务了。Redis Cluster 相当于是内置了 Sentinel 机制，Redis Cluster 内部的各个 Redis 节点通过 Gossip 协议互相探测健康状态，在故障时可以自动切换。
+有了 Redis Cluster 之后，不需要专门部署 Sentinel 集群服务了。Redis Cluster 相当于是内置了 Sentinel 机制，Redis Cluster 内部的各个 Redis 节点通过 Gossip 协议共享集群内信息。
关于 Redis Cluster 的详细介绍，可以查看这篇文章 [Redis 集群详解(付费)](https://javaguide.cn/database/redis/redis-cluster.html) 。
diff --git a/docs/high-availability/fallback-and-circuit-breaker.md b/docs/high-availability/fallback-and-circuit-breaker.md
index e9aa9188d4f..59725fa0521 100644
--- a/docs/high-availability/fallback-and-circuit-breaker.md
+++ b/docs/high-availability/fallback-and-circuit-breaker.md
@@ -6,6 +6,8 @@ icon: circuit
**降级&熔断** 相关的面试题为我的[知识星球](https://javaguide.cn/about-the-author/zhishixingqiu-two-years.html)（点击链接即可查看详细介绍以及加入方法）专属内容，已经整理到了[《Java 面试指北》](https://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html)中。
+
+
diff --git a/docs/high-availability/idempotency.md b/docs/high-availability/idempotency.md
new file mode 100644
index 00000000000..41384457ccb
--- /dev/null
+++ b/docs/high-availability/idempotency.md
@@ -0,0 +1,13 @@
+---
+title: 接口幂等方案总结(付费)
+category: 高可用
+icon: security-fill
+---
+
+**接口幂等** 相关的面试题为我的[知识星球](https://javaguide.cn/about-the-author/zhishixingqiu-two-years.html)（点击链接即可查看详细介绍以及加入方法）专属内容，已经整理到了[《Java 面试指北》](https://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html)中。
+
+
+
+
+
+
diff --git a/docs/high-availability/limit-request.md b/docs/high-availability/limit-request.md
index 80ce00002b1..22db662eedf 100644
--- a/docs/high-availability/limit-request.md
+++ b/docs/high-availability/limit-request.md
@@ -239,7 +239,7 @@ Resilience4j 不仅提供限流，还提供了熔断、负载保护、自动重
分布式限流常见的方案：
-- **借助中间件架限流**：可以借助 Sentinel 或者使用 Redis 来自己实现对应的限流逻辑。
+- **借助中间件限流**：可以借助 Sentinel 或者使用 Redis 来自己实现对应的限流逻辑。
- **网关层限流**：比较常用的一种方案，直接在网关层把限流给安排上了。不过，通常网关层限流通常也需要借助到中间件/框架。就比如 Spring Cloud Gateway 的分布式限流实现`RedisRateLimiter`就是基于 Redis+Lua 来实现的，再比如 Spring Cloud Gateway 还可以整合 Sentinel 来做限流。
如果你要基于 Redis 来手动实现限流逻辑的话，建议配合 Lua 脚本来做。
diff --git a/docs/high-availability/performance-test.md b/docs/high-availability/performance-test.md
index fe2ce94647f..47201441d7e 100644
--- a/docs/high-availability/performance-test.md
+++ b/docs/high-availability/performance-test.md
@@ -8,15 +8,15 @@ icon: et-performance
这篇文章是我会结合自己的实际经历以及在测试这里取的经所得，除此之外，我还借鉴了一些优秀书籍，希望对你有帮助。
-## 一 不同角色看网站性能
+## 不同角色看网站性能
-### 1.1 用户
+### 用户
当用户打开一个网站的时候，最关注的是什么？当然是网站响应速度的快慢。比如我们点击了淘宝的主页，淘宝需要多久将首页的内容呈现在我的面前，我点击了提交订单按钮需要多久返回结果等等。
所以，用户在体验我们系统的时候往往根据你的响应速度的快慢来评判你的网站的性能。
-### 1.2 开发人员
+### 开发人员
用户与开发人员都关注速度，这个速度实际上就是我们的系统**处理用户请求的速度**。
@@ -31,7 +31,7 @@ icon: et-performance
7. 项目使用的 Redis 缓存多大？服务器性能如何？用的是机械硬盘还是固态硬盘？
8. ……
-### 1.3 测试人员
+### 测试人员
测试人员一般会根据性能测试工具来测试，然后一般会做出一个表格。这个表格可能会涵盖下面这些重要的内容：
@@ -40,63 +40,87 @@ icon: et-performance
3. 吞吐量；
4. ……
-### 1.4 运维人员
+### 运维人员
运维人员会倾向于根据基础设施和资源的利用率来判断网站的性能，比如我们的服务器资源使用是否合理、数据库资源是否存在滥用的情况、当然，这是传统的运维人员，现在 Devops 火起来后，单纯干运维的很少了。我们这里暂且还保留有这个角色。
-## 二 性能测试需要注意的点
+## 性能测试需要注意的点
几乎没有文章在讲性能测试的时候提到这个问题，大家都会讲如何去性能测试，有哪些性能测试指标这些东西。
-### 2.1 了解系统的业务场景
+### 了解系统的业务场景
**性能测试之前更需要你了解当前的系统的业务场景。** 对系统业务了解的不够深刻，我们很容易犯测试方向偏执的错误，从而导致我们忽略了对系统某些更需要性能测试的地方进行测试。比如我们的系统可以为用户提供发送邮件的功能，用户配置成功邮箱后只需输入相应的邮箱之后就能发送，系统每天大概能处理上万次发邮件的请求。很多人看到这个可能就直接开始使用相关工具测试邮箱发送接口，但是，发送邮件这个场景可能不是当前系统的性能瓶颈，这么多人用我们的系统发邮件， 还可能有很多人一起发邮件，单单这个场景就这么人用，那用户管理可能才是性能瓶颈吧！
-### 2.2 历史数据非常有用
+### 历史数据非常有用
-当前系统所留下的历史数据非常重要，一般情况下，我们可以通过相应的些历史数据初步判定这个系统哪些接口调用的比较多、哪些 service 承受的压力最大，这样的话，我们就可以针对这些地方进行更细致的性能测试与分析。
+当前系统所留下的历史数据非常重要，一般情况下，我们可以通过相应的些历史数据初步判定这个系统哪些接口调用的比较多、哪些服务承受的压力最大，这样的话，我们就可以针对这些地方进行更细致的性能测试与分析。
另外，这些地方也就像这个系统的一个短板一样，优化好了这些地方会为我们的系统带来质的提升。
-### 三 性能测试的指标
+## 常见性能指标
-### 3.1 响应时间
+### 响应时间
-**响应时间就是用户发出请求到用户收到系统处理结果所需要的时间。** 重要吗？实在太重要！
+**响应时间 RT(Response-time)就是用户发出请求到用户收到系统处理结果所需要的时间。**
-比较出名的 2-5-8 原则是这样描述的：通常来说，2 到 5 秒，页面体验会比较好，5 到 8 秒还可以接受，8 秒以上基本就很难接受了。另外，据统计当网站慢一秒就会流失十分之一的客户。
+RT 是一个非常重要且直观的指标，RT 数值大小直接反应了系统处理用户请求速度的快慢。
-但是，在某些场景下我们也并不需要太看重 2-5-8 原则 ，比如我觉得系统导出导入大数据量这种就不需要，系统生成系统报告这种也不需要。
+### 并发数
-### 3.2 并发数
+**并发数可以简单理解为系统能够同时供多少人访问使用也就是说系统同时能处理的请求数量。**
-**并发数是系统能同时处理请求的数目即同时提交请求的用户数目。**
+并发数反应了系统的负载能力。
-不得不说，高并发是现在后端架构中非常非常火热的一个词了，这个与当前的互联网环境以及中国整体的互联网用户量都有很大关系。一般情况下，你的系统并发量越大，说明你的产品做的就越大。但是，并不是每个系统都需要达到像淘宝、12306 这种亿级并发量的。
+### QPS 和 TPS
-### 3.3 吞吐量
+- **QPS（Query Per Second）** ：服务器每秒可以执行的查询次数；
+- **TPS（Transaction Per Second）** ：服务器每秒处理的事务数（这里的一个事务可以理解为客户发出请求到收到服务器的过程）；
-吞吐量指的是系统单位时间内系统处理的请求数量。衡量吞吐量有几个重要的参数：QPS（TPS）、并发数、响应时间。
+书中是这样描述 QPS 和 TPS 的区别的。
-1. QPS（Query Per Second）：服务器每秒可以执行的查询次数；
-2. TPS（Transaction Per Second）：服务器每秒处理的事务数（这里的一个事务可以理解为客户发出请求到收到服务器的过程）；
-3. 并发数；系统能同时处理请求的数目即同时提交请求的用户数目。
-4. 响应时间：一般取多次请求的平均响应时间
+> QPS vs TPS：QPS 基本类似于 TPS，但是不同的是，对于一个页面的一次访问，形成一个 TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。如，访问一个页面会请求服务器 2 次，一次访问，产生一个“T”，产生 2 个“Q”。
-理清他们的概念，就很容易搞清楚他们之间的关系了。
+### 吞吐量
-- **QPS（TPS）** = 并发数/平均响应时间
-- **并发数** = QPS\*平均响应时间
+**吞吐量指的是系统单位时间内系统处理的请求数量。**
-书中是这样描述 QPS 和 TPS 的区别的。
+一个系统的吞吐量与请求对系统的资源消耗等紧密关联。请求对系统资源消耗越多，系统吞吐能力越低，反之则越高。
-> QPS vs TPS：QPS 基本类似于 TPS，但是不同的是，对于一个页面的一次访问，形成一个 TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。如，访问一个页面会请求服务器 2 次，一次访问，产生一个“T”，产生 2 个“Q”。
+TPS、QPS 都是吞吐量的常用量化指标。
+
+- **QPS（TPS）** = 并发数/平均响应时间(RT)
+- **并发数** = QPS \* 平均响应时间(RT)
+
+## 系统活跃度指标
+
+### PV(Page View)
+
+访问量, 即页面浏览量或点击量，衡量网站用户访问的网页数量；在一定统计周期内用户每打开或刷新一个页面就记录 1 次，多次打开或刷新同一页面则浏览量累计。UV 从网页打开的数量/刷新的次数的角度来统计的。
+
+### UV(Unique Visitor)
-### 3.4 性能计数器
+独立访客，统计 1 天内访问某站点的用户数。1 天内相同访客多次访问网站，只计算为 1 个独立访客。UV 是从用户个体的角度来统计的。
-**性能计数器是描述服务器或者操作系统的一些数据指标如内存使用、CPU 使用、磁盘与网络 I/O 等情况。**
+### DAU(Daily Active User)
-### 四 几种常见的性能测试
+日活跃用户数量。
+
+### MAU(monthly active users)
+
+月活跃用户人数。
+
+举例：某网站 DAU 为 1200w， 用户日均使用时长 1 小时，RT 为 0.5s，求并发量和 QPS。
+
+平均并发量 = DAU（1200w）\* 日均使用时长（1 小时，3600 秒） /一天的秒数（86400）=1200w/24 = 50w
+
+真实并发量（考虑到某些时间段使用人数比较少） = DAU（1200w）\* 日均使用时长（1 小时，3600 秒） /一天的秒数-访问量比较小的时间段假设为 8 小时（57600）=1200w/16 = 75w
+
+峰值并发量 = 平均并发量 \* 6 = 300w
+
+QPS = 真实并发量/RT = 75W/0.5=150w/s
+
+## 性能测试分类
### 性能测试
@@ -118,25 +142,27 @@ icon: et-performance
模拟真实场景，给系统一定压力，看看业务是否能稳定运行。
-## 五 常用性能测试工具
+## 常用性能测试工具
+
+### 后端常用
-这里就不多扩展了，有时间的话会单独拎一个熟悉的说一下。
+既然系统设计涉及到系统性能方面的问题，那在面试的时候，面试官就很可能会问：**你是如何进行性能测试的？**
-### 5.1 后端常用
+推荐 4 个比较常用的性能测试工具：
-没记错的话，除了 LoadRunner 其他几款性能测试工具都是开源免费的。
+1. **Jmeter** ：Apache JMeter 是 JAVA 开发的性能测试工具。
+2. **LoadRunner**：一款商业的性能测试工具。
+3. **Galtling** ：一款基于 Scala 开发的高性能服务器性能测试工具。
+4. **ab** ：全称为 Apache Bench 。Apache 旗下的一款测试工具，非常实用。
-1. Jmeter：Apache JMeter 是 JAVA 开发的性能测试工具。
-2. LoadRunner：一款商业的性能测试工具。
-3. Galtling：一款基于 Scala 开发的高性能服务器性能测试工具。
-4. ab：全称为 Apache Bench 。Apache 旗下的一款测试工具，非常实用。
+没记错的话，除了 **LoadRunner** 其他几款性能测试工具都是开源免费的。
-### 5.2 前端常用
+### 前端常用
-1. Fiddler：抓包工具，它可以修改请求的数据，甚至可以修改服务器返回的数据，功能非常强大，是 Web 调试的利器。
-2. HttpWatch: 可用于录制 HTTP 请求信息的工具。
+1. **Fiddler**：抓包工具，它可以修改请求的数据，甚至可以修改服务器返回的数据，功能非常强大，是 Web 调试的利器。
+2. **HttpWatch**: 可用于录制 HTTP 请求信息的工具。
-## 六 常见的性能优化策略
+## 常见的性能优化策略
性能优化之前我们需要对请求经历的各个环节进行分析，排查出可能出现性能瓶颈的地方，定位问题。
diff --git a/docs/high-performance/data-cold-hot-separation.md b/docs/high-performance/data-cold-hot-separation.md
index cf706c68c9d..d7ae70c2bfd 100644
--- a/docs/high-performance/data-cold-hot-separation.md
+++ b/docs/high-performance/data-cold-hot-separation.md
@@ -23,7 +23,7 @@ head:
1. **时间维度区分**：按照数据的创建时间、更新时间、过期时间等，将一定时间段内的数据视为热数据，超过该时间段的数据视为冷数据。例如，订单系统可以将 1 年前的订单数据作为冷数据，1 年内的订单数据作为热数据。这种方法适用于数据的访问频率和时间有较强的相关性的场景。
2. **访问频率区分**：将高频访问的数据视为热数据，低频访问的数据视为冷数据。例如，内容系统可以将浏览量非常低的文章作为冷数据，浏览量较高的文章作为热数据。这种方法需要记录数据的访问频率，成本较高，适合访问频率和数据本身有较强的相关性的场景。
-几年前的数据并不一定都是热数据，例如一些优质文章发表几年后依然有很多人访问，大部分普通用户新发表的文章却基本没什么人访问。
+几年前的数据并不一定都是冷数据，例如一些优质文章发表几年后依然有很多人访问，大部分普通用户新发表的文章却基本没什么人访问。
这两种区分冷热数据的方法各有优劣，实际项目中，可以将两者结合使用。
diff --git a/docs/high-performance/deep-pagination-optimization.md b/docs/high-performance/deep-pagination-optimization.md
index 8a419dadb84..0d39e627cef 100644
--- a/docs/high-performance/deep-pagination-optimization.md
+++ b/docs/high-performance/deep-pagination-optimization.md
@@ -19,6 +19,18 @@ head:
SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10
```
+## 深度分页问题的原因
+
+当查询偏移量过大时，MySQL 的查询优化器可能会选择全表扫描而不是利用索引来优化查询。这是因为扫描索引和跳过大量记录可能比直接全表扫描更耗费资源。
+
+
+
+不同机器上这个查询偏移量过大的临界点可能不同，取决于多个因素，包括硬件配置（如 CPU 性能、磁盘速度）、表的大小、索引的类型和统计信息等。
+
+
+
+MySQL 的查询优化器采用基于成本的策略来选择最优的查询执行计划。它会根据 CPU 和 I/O 的成本来决定是否使用索引扫描或全表扫描。如果优化器认为全表扫描的成本更低，它就会放弃使用索引。不过，即使偏移量很大，如果查询中使用了覆盖索引（covering index），MySQL 仍然可能会使用索引，避免回表操作。
+
## 深度分页优化建议
这里以 MySQL 数据库为例介绍一下如何优化深度分页。
@@ -34,7 +46,11 @@ SELECT * FROM t_order WHERE id > 100000 AND id <= 100010 ORDER BY id
SELECT * FROM t_order WHERE id > 100000 LIMIT 10
```
-这种优化方式限制比较大，且一般项目的 ID 也没办法保证完全连续。
+这种基于 ID 范围的深度分页优化方式存在很大限制：
+
+1. **ID 连续性要求高**: 实际项目中，数据库自增 ID 往往因为各种原因（例如删除数据、事务回滚等）导致 ID 不连续，难以保证连续性。
+2. **排序问题**: 如果查询需要按照其他字段（例如创建时间、更新时间等）排序，而不是按照 ID 排序，那么这种方法就不再适用。
+3. **并发场景**: 在高并发场景下，单纯依赖记录上次查询的最后一条记录的 ID 进行分页，容易出现数据重复或遗漏的问题。
### 子查询
@@ -48,31 +64,45 @@ SELECT * FROM t_order WHERE id > 100000 LIMIT 10
```sql
# 通过子查询来获取 id 的起始值，把 limit 1000000 的条件转移到子查询
-SELECT * FROM t_order WHERE id >= (SELECT id FROM t_order limit 1000000, 1) LIMIT 10;
+SELECT * FROM t_order WHERE id >= (SELECT id FROM t_order where id > 1000000 limit 1) LIMIT 10;
```
+**工作原理**:
+
+1. 子查询 `(SELECT id FROM t_order where id > 1000000 limit 1)` 会利用主键索引快速定位到第 1000001 条记录，并返回其 ID 值。
+2. 主查询 `SELECT * FROM t_order WHERE id >= ... LIMIT 10` 将子查询返回的起始 ID 作为过滤条件，使用 `id >=` 获取从该 ID 开始的后续 10 条记录。
+
不过，子查询的结果会产生一张新表，会影响性能，应该尽量避免大量使用子查询。并且，这种方法只适用于 ID 是正序的。在复杂分页场景，往往需要通过过滤条件，筛选到符合条件的 ID，此时的 ID 是离散且不连续的。
当然，我们也可以利用子查询先去获取目标分页的 ID 集合，然后再根据 ID 集合获取内容，但这种写法非常繁琐，不如使用 INNER JOIN 延迟关联。
### 延迟关联
-延迟关联的优化思路，跟子查询的优化思路其实是一样的：都是把条件转移到主键索引树，减少回表的次数。不同点是，延迟关联使用了 INNER JOIN（内连接） 包含子查询。
+延迟关联与子查询的优化思路类似，都是通过将 `LIMIT` 操作转移到主键索引树上，减少回表次数。相比直接使用子查询，延迟关联通过 `INNER JOIN` 将子查询结果集成到主查询中，避免了子查询可能产生的临时表。在执行 `INNER JOIN` 时，MySQL 优化器能够利用索引进行高效的连接操作（如索引扫描或其他优化策略），因此在深度分页场景下，性能通常优于直接使用子查询。
```sql
-SELECT t1.* FROM t_order t1
-INNER JOIN (SELECT id FROM t_order limit 1000000, 10) t2
-ON t1.id = t2.id;
+-- 使用 INNER JOIN 进行延迟关联
+SELECT t1.*
+FROM t_order t1
+INNER JOIN (SELECT id FROM t_order where id > 1000000 LIMIT 10) t2 ON t1.id = t2.id;
```
+**工作原理**:
+
+1. 子查询 `(SELECT id FROM t_order where id > 1000000 LIMIT 10)` 利用主键索引快速定位目标分页的 10 条记录的 ID。
+2. 通过 `INNER JOIN` 将子查询结果与主表 `t_order` 关联，获取完整的记录数据。
+
除了使用 INNER JOIN 之外，还可以使用逗号连接子查询。
```sql
+-- 使用逗号进行延迟关联
SELECT t1.* FROM t_order t1,
-(SELECT id FROM t_order limit 1000000, 10) t2
+(SELECT id FROM t_order where id > 1000000 LIMIT 10) t2
WHERE t1.id = t2.id;
```
+**注意**: 虽然逗号连接子查询也能实现类似的效果，但为了代码可读性和可维护性，建议使用更规范的 `INNER JOIN` 语法。
+
### 覆盖索引
索引中已经包含了所有需要获取的字段的查询方式称为覆盖索引。
@@ -89,7 +119,19 @@ ORDER BY code
LIMIT 1000000, 10;
```
-不过，当查询的结果集占表的总行数的很大一部分时，可能就不会走索引了，自动转换为全表扫描。当然了，也可以通过 `FORCE INDEX` 来强制查询优化器走索引，但这种提升效果一般不明显。
+**⚠️注意**:
+
+- 当查询的结果集占表的总行数的很大一部分时，MySQL 查询优化器可能选择放弃使用索引，自动转换为全表扫描。
+- 虽然可以使用 `FORCE INDEX` 强制查询优化器走索引，但这种方式可能会导致查询优化器无法选择更优的执行计划，效果并不总是理想。
+
+## 总结
+
+本文总结了几种常见的深度分页优化方案:
+
+1. **范围查询**: 基于 ID 连续性进行分页，通过记录上一页最后一条记录的 ID 来获取下一页数据。适合 ID 连续且按 ID 查询的场景，但在 ID 不连续或需要按其他字段排序时存在局限。
+2. **子查询**: 先通过子查询获取分页的起始主键值，再根据主键进行筛选分页。利用主键索引提高效率，但子查询会生成临时表，复杂场景下性能不佳。
+3. **延迟关联 (INNER JOIN)**: 使用 `INNER JOIN` 将分页操作转移到主键索引上，减少回表次数。相比子查询，延迟关联的性能更优，适合大数据量的分页查询。
+4. **覆盖索引**: 通过索引直接获取所需字段，避免回表操作，减少 IO 开销，适合查询特定字段的场景。但当结果集较大时，MySQL 可能会选择全表扫描。
## 参考
diff --git a/docs/high-performance/images/message-queue/message-queue-pub-sub-model.png b/docs/high-performance/images/message-queue/message-queue-pub-sub-model.png
deleted file mode 100644
index a5a77736493..00000000000
Binary files a/docs/high-performance/images/message-queue/message-queue-pub-sub-model.png and /dev/null differ
diff --git a/docs/high-performance/images/message-queue/message-queue-queue-model.png b/docs/high-performance/images/message-queue/message-queue-queue-model.png
deleted file mode 100644
index 8fb2cd6a7ba..00000000000
Binary files a/docs/high-performance/images/message-queue/message-queue-queue-model.png and /dev/null differ
diff --git a/docs/high-performance/load-balancing.md b/docs/high-performance/load-balancing.md
index b0b88e0a872..619df980574 100644
--- a/docs/high-performance/load-balancing.md
+++ b/docs/high-performance/load-balancing.md
@@ -24,7 +24,7 @@ head:
负载均衡可以简单分为 **服务端负载均衡** 和 **客户端负载均衡** 这两种。
-服务端负载均衡涉及到的知识点更多，工作中遇到的也比较多，因为，我会花更多时间来介绍。
+服务端负载均衡涉及到的知识点更多，工作中遇到的也比较多，因此，我会花更多时间来介绍。
### 服务端负载均衡
@@ -85,7 +85,7 @@ head:
客户端负载均衡器和服务运行在同一个进程或者说 Java 程序里，不存在额外的网络开销。不过，客户端负载均衡的实现会受到编程语言的限制，比如说 Spring Cloud Load Balancer 就只能用于 Java 语言。
-Java 领域主流的微服务框架 Dubbo、Spring Cloud 等都内置了开箱即用的客户端负载均衡实现。Dubbo 属于是默认自带了负载均衡功能，Spring Cloud 是通过组件的形式实现的负载均衡，属于可选项，比较常用的是 Spring Cloud Load Balancer（官方，推荐） 和 Ribbon（Netflix，已被启用）。
+Java 领域主流的微服务框架 Dubbo、Spring Cloud 等都内置了开箱即用的客户端负载均衡实现。Dubbo 属于是默认自带了负载均衡功能，Spring Cloud 是通过组件的形式实现的负载均衡，属于可选项，比较常用的是 Spring Cloud Load Balancer（官方，推荐） 和 Ribbon（Netflix，已被弃用）。
下图是我画的一个简单的基于 Spring Cloud Load Balancer（Ribbon 也类似） 的客户端负载均衡示意图：
diff --git a/docs/high-performance/message-queue/kafka-questions-01.md b/docs/high-performance/message-queue/kafka-questions-01.md
index 7e690399689..070858cc1f8 100644
--- a/docs/high-performance/message-queue/kafka-questions-01.md
+++ b/docs/high-performance/message-queue/kafka-questions-01.md
@@ -120,7 +120,7 @@ ZooKeeper 主要为 Kafka 提供元数据的管理的功能。
不过，要提示一下：**如果要使用 KRaft 模式的话，建议选择较高版本的 Kafka，因为这个功能还在持续完善优化中。Kafka 3.3.1 版本是第一个将 KRaft（Kafka Raft）共识协议标记为生产就绪的版本。**
-
+
## Kafka 消费顺序、消息丢失和重复消费
diff --git a/docs/high-performance/message-queue/message-queue.md b/docs/high-performance/message-queue/message-queue.md
index d7b3c6ff368..5874f290298 100644
--- a/docs/high-performance/message-queue/message-queue.md
+++ b/docs/high-performance/message-queue/message-queue.md
@@ -23,9 +23,9 @@ tag:
参与消息传递的双方称为 **生产者** 和 **消费者** ，生产者负责发送消息，消费者负责处理消息。
-
+
-我们知道操作系统中的进程通信的一种很重要的方式就是消息队列。我们这里提到的消息队列稍微有点区别，更多指的是各个服务以及系统内部各个组件/模块之前的通信，属于一种 **中间件** 。
+操作系统中的进程通信的一种很重要的方式就是消息队列。我们这里提到的消息队列稍微有点区别，更多指的是各个服务以及系统内部各个组件/模块之前的通信，属于一种 **中间件** 。
维基百科是这样介绍中间件的：
@@ -41,19 +41,21 @@ tag:
## 消息队列有什么用？
-通常来说，使用消息队列能为我们的系统带来下面三点好处：
+通常来说，使用消息队列主要能为我们的系统带来下面三点好处：
-1. **通过异步处理提高系统性能（减少响应所需时间）**
-2. **削峰/限流**
-3. **降低系统耦合性。**
+1. 异步处理
+2. 削峰/限流
+3. 降低系统耦合性
+
+除了这三点之外，消息队列还有其他的一些应用场景，例如实现分布式事务、顺序保证和数据流处理。
如果在面试的时候你被面试官问到这个问题的话，一般情况是你在你的简历上涉及到消息队列这方面的内容，这个时候推荐你结合你自己的项目来回答。
-### 通过异步处理提高系统性能（减少响应所需时间）
+### 异步处理
-将用户的请求数据存储到消息队列之后就立即返回结果。随后，系统再对消息进行消费。
+将用户请求中包含的耗时操作，通过消息队列实现异步处理，将对应的消息发送到消息队列之后就立即返回结果，减少响应时间，提高用户体验。随后，系统再对消息进行消费。
因为用户请求数据写入消息队列之后就立即返回给用户了，但是请求数据在后续的业务校验、写数据库等操作中可能失败。因此，**使用消息队列进行异步处理之后，需要适当修改业务流程进行配合**，比如用户在提交订单之后，订单数据写入消息队列，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功，以免交易纠纷。这就类似我们平时手机订火车票和电影票。
@@ -67,11 +69,11 @@ tag:
### 降低系统耦合性
-使用消息队列还可以降低系统耦合性。我们知道如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影响较小，这样系统的可扩展性无疑更好一些。还是直接上图吧：
+使用消息队列还可以降低系统耦合性。如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影响较小，这样系统的可扩展性无疑更好一些。
-
+生产者（客户端）发送消息到消息队列中去，消费者（服务端）处理消息，需要消费的系统直接去消息队列取消息进行消费即可而不需要和其他系统有耦合，这显然也提高了系统的扩展性。
-生产者（客户端）发送消息到消息队列中去，接受者（服务端）处理消息，需要消费的系统直接去消息队列取消息进行消费即可而不需要和其他系统有耦合，这显然也提高了系统的扩展性。
+
**消息队列使用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。** 从上图可以看到**消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合**，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。**对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计**。
@@ -85,7 +87,7 @@ tag:
### 实现分布式事务
-我们知道分布式事务的解决方案之一就是 MQ 事务。
+分布式事务的解决方案之一就是 MQ 事务。
RocketMQ、 Kafka、Pulsar、QMQ 都提供了事务相关的功能。事务允许事件流应用将消费，处理，生产消息整个过程定义为一个原子操作。
@@ -93,6 +95,26 @@ RocketMQ、 Kafka、Pulsar、QMQ 都提供了事务相关的功能。事务允
+### 顺序保证
+
+在很多应用场景中，处理数据的顺序至关重要。消息队列保证数据按照特定的顺序被处理，适用于那些对数据顺序有严格要求的场景。大部分消息队列，例如 RocketMQ、RabbitMQ、Pulsar、Kafka，都支持顺序消息。
+
+### 延时/定时处理
+
+消息发送后不会立即被消费，而是指定一个时间，到时间后再消费。大部分消息队列，例如 RocketMQ、RabbitMQ、Pulsar，都支持定时/延时消息。
+
+
+
+### 即时通讯
+
+MQTT（消息队列遥测传输协议）是一种轻量级的通讯协议，采用发布/订阅模式，非常适合于物联网（IoT）等需要在低带宽、高延迟或不可靠网络环境下工作的应用。它支持即时消息传递，即使在网络条件较差的情况下也能保持通信的稳定性。
+
+RabbitMQ 内置了 MQTT 插件用于实现 MQTT 功能（默认不启用，需要手动开启）。
+
+### 数据流处理
+
+针对分布式系统产生的海量数据流，如业务日志、监控数据、用户行为等，消息队列可以实时或批量收集这些数据，并将其导入到大数据处理引擎中，实现高效的数据流管理和处理。
+
## 使用消息队列会带来哪些问题？
- **系统可用性降低：** 系统可用性在某种程度上降低，为什么这样说呢？在加入 MQ 之前，你不用考虑消息丢失或者说 MQ 挂掉等等的情况，但是，引入 MQ 之后你就需要去考虑了！
@@ -119,13 +141,13 @@ JMS 定义了五种不同的消息正文格式以及调用的消息类型，允
#### 点到点（P2P）模型
-
+
使用**队列（Queue）**作为消息通信载体；满足**生产者与消费者模式**，一条消息只能被一个消费者使用，未被消费的消息在队列中保留直到被消费或超时。比如：我们生产者发送 100 条消息的话，两个消费者来消费一般情况下两个消费者会按照消息发送的顺序各自消费一半（也就是你一个我一个的消费。）
#### 发布/订阅（Pub/Sub）模型
-
+
发布订阅模型（Pub/Sub） 使用**主题（Topic）**作为消息通信载体，类似于**广播模式**；发布者发布一条消息，该消息通过主题传递给所有的订阅者。
@@ -184,7 +206,7 @@ Kafka 是一个分布式系统，由通过高性能 TCP 网络协议进行通信
不过，要提示一下：**如果要使用 KRaft 模式的话，建议选择较高版本的 Kafka，因为这个功能还在持续完善优化中。Kafka 3.3.1 版本是第一个将 KRaft（Kafka Raft）共识协议标记为生产就绪的版本。**
-
+
Kafka 官网： 。
+
+对于考研浙江大学的同学来说，PAT（甲级）成绩在一年内可以作为硕士研究生招生考试上机复试成绩。
+
+
+
+## PMP
+
+PMP（Project Management Professional）认证由美国项目管理协会（PMI）提供，是全球范围内认可度最高的项目管理专业人士资格认证。PMP 认证旨在提升项目管理专业人士的知识和技能，确保项目顺利完成。
+
+
+
+PMP 是“一证在手，全球通用”的资格认证，对项目管理人士来说，PMP 证书含金量还是比较高的。放眼全球，很多成功企业都会将 PMP 认证作为项目经理的入职标准。
+
+但是！真正有价值的不是 PMP 证书，而是《PMBOK》 那套项目管理体系，在《PMBOK》（PMP 考试指定用书）中也包含了非常多商业活动、实业项目、组织规划、建筑行业等各个领域的项目案例。
+
+另外，PMP 证书不是一个高大上的证书，而是一个基础的证书。
+
+## ACP
+
+ACP（Agile Certified Practitioner）认证同样由美国项目管理协会（PMI）提供，是项目管理领域的另一个重要认证。与 PMP（Project Management Professional）注重传统的瀑布方法论不同，ACP 专注于敏捷项目管理方法论，如 Scrum、Kanban、Lean、Extreme Programming（XP）等。
+
+## OCP
+
+Oracle Certified Professional（OCP）是 Oracle 公司提供的一项专业认证，专注于 Oracle 数据库及相关技术。这个认证旨在验证和认证个人在使用和管理 Oracle 数据库方面的专业知识和技能。
+
+下图展示了 Oracle 认证的不同路径和相应的认证级别，分别是核心路径（Core Track）和专业路径（Speciality Track）。
+
+
+
+## 阿里云认证
+
+阿里云（Alibaba Cloud）提供的专业认证，认证方向包括云计算、大数据、人工智能、Devops 等。职业认证分为 ACA、ACP、ACE 三个等级，除了职业认证之外，还有一个开发者 Clouder 认证，这是专门为开发者设立的专项技能认证。
+
+
+
+官网地址：
+
+## 微软认证
+
+微软的认证体系主要针对其 Azure 云平台，分为基础级别、助理级别和专家级别，认证方向包括云计算、数据管理、开发、生产力工具等。
+
+
+
+## Elastic 认证
+
+Elastic 认证是由 Elastic 公司提供的一系列专业认证，旨在验证个人在使用 Elastic Stack（包括 Elasticsearch、Logstash、Kibana 、Beats 等）方面的技能和知识。
+
+如果你在日常开发核心工作是负责 ElasticSearch 相关业务的话，还是比较建议考的，含金量挺高。
+
+目前 Elastic 认证证书分为四类：Elastic Certified Engineer、Elastic Certified Analyst、Elastic Certified Observability Engineer、Elastic Certified SIEM Specialist。
+
+比较建议考 **Elastic Certified Engineer**，这个是 Elastic Stack 的基础认证，考察安装、配置、管理和维护 Elasticsearch 集群等核心技能。
+
+
+
+## 其他
+
+- PostgreSQL 认证：国内的 PostgreSQL 认证分为专员级（PCA）、专家级（PCP）和大师级（PCM），主要考查 PostgreSQL 数据库管理和优化，价格略贵，不是很推荐。
+- Kubernetes 认证：Cloud Native Computing Foundation (CNCF) 提供了几个官方认证，例如 Certified Kubernetes Administrator (CKA)、Certified Kubernetes Application Developer (CKAD)，主要考察 Kubernetes 方面的技能和知识。
diff --git a/docs/home.md b/docs/home.md
index 81b557b1249..047a09fe9ad 100644
--- a/docs/home.md
+++ b/docs/home.md
@@ -41,7 +41,7 @@ title: JavaGuide（Java学习&面试指南）
- [Java 集合常见知识点&面试题总结(上)](./java/collection/java-collection-questions-01.md) (必看 :+1:)
- [Java 集合常见知识点&面试题总结(下)](./java/collection/java-collection-questions-02.md) (必看 :+1:)
-- [Java 容器使用注意事项总结](./java/collection/java-collection-precautions-for-use.md)
+- [Java 集合使用注意事项总结](./java/collection/java-collection-precautions-for-use.md)
**源码分析**：
@@ -72,6 +72,8 @@ title: JavaGuide（Java学习&面试指南）
**重要知识点详解**：
+- [乐观锁和悲观锁详解](./java/concurrent/optimistic-lock-and-pessimistic-lock.md)
+- [CAS 详解](./java/concurrent/cas.md)
- [JMM（Java 内存模型）详解](./java/concurrent/jmm.md)
- **线程池**：[Java 线程池详解](./java/concurrent/java-thread-pool-summary.md)、[Java 线程池最佳实践](./java/concurrent/java-thread-pool-best-practices.md)
- [ThreadLocal 详解](./java/concurrent/threadlocal.md)
@@ -107,6 +109,8 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8](https://docs.oracle.
- [Java 19 新特性概览](./java/new-features/java19.md)
- [Java 20 新特性概览](./java/new-features/java20.md)
- [Java 21 新特性概览](./java/new-features/java21.md)
+- [Java 22 & 23 新特性概览](./java/new-features/java22-23.md)
+- [Java 24 新特性概览](./java/new-features/java24.md)
## 计算机基础
@@ -295,15 +299,13 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8](https://docs.oracle.
- [JWT 优缺点分析以及常见问题解决方案](./system-design/security/advantages-and-disadvantages-of-jwt.md)
- [SSO 单点登录详解](./system-design/security/sso-intro.md)
- [权限系统设计详解](./system-design/security/design-of-authority-system.md)
-- [常见加密算法总结](./system-design/security/encryption-algorithms.md)
-
-#### 数据脱敏
-数据脱敏说的就是我们根据特定的规则对敏感信息数据进行变形，比如我们把手机号、身份证号某些位数使用 \* 来代替。
+#### 数据安全
-#### 敏感词过滤
-
-[敏感词过滤方案总结](./system-design/security/sentive-words-filter.md)
+- [常见加密算法总结](./system-design/security/encryption-algorithms.md)
+- [敏感词过滤方案总结](./system-design/security/sentive-words-filter.md)
+- [数据脱敏方案总结](./system-design/security/data-desensitization.md)
+- [为什么前后端都要做数据校验](./system-design/security/data-validation.md)
### 定时任务
diff --git a/docs/interview-preparation/how-to-handle-interview-nerves.md b/docs/interview-preparation/how-to-handle-interview-nerves.md
new file mode 100644
index 00000000000..1a1a79409f9
--- /dev/null
+++ b/docs/interview-preparation/how-to-handle-interview-nerves.md
@@ -0,0 +1,67 @@
+---
+title: 面试太紧张怎么办？
+category: 面试准备
+icon: security-fill
+---
+
+很多小伙伴在第一次技术面试时都会感到紧张甚至害怕，面试结束后还会有种“懵懵的”感觉。我也经历过类似的状况，可以说是深有体会。其实，**紧张是很正常的**——它代表你对面试的重视，也来自于对未知结果的担忧。但如果过度紧张，反而会影响你的临场发挥。
+
+下面，我就分享一些自己的心得，帮大家更好地应对面试中的紧张情绪。
+
+## 试着接受紧张情绪，调整心态
+
+首先要明白，紧张是正常情绪，特别是初次或前几次面试时，多少都会有点忐忑。不要过分排斥这种情绪，可以适当地“拥抱”它：
+
+- **搞清楚面试的本质**：面试本质上是一场与面试官的深入交流，是一个双向选择的过程。面试失败并不意味着你的价值和努力被否定，而可能只是因为你与目标岗位暂时不匹配，或者仅仅是一次 KPI 面试，这家公司可能压根就没有真正的招聘需求。失败的原因也可能是某些知识点、项目经验或表达方式未能充分展现出你的能力。即便这次面试未通过，也不妨碍你继续尝试其他公司，完全不慌！
+- **不要害怕面试官**：很多求职者平时和同学朋友交流沟通的蛮好，一到面试就害怕了。面试官和求职者双方是平等的，以后说不定就是同事关系。也不要觉得面试官就很厉害，实际上，面试官的水平也参差不齐。他们提出的问题，可能自己也没有完全理解。
+- **给自己积极的心理暗示**：告诉自己“有点紧张没关系，这只能让我更专注，心跳加快是我在给自己打气，我一定可以回答的很好！”。
+
+## 提前准备，减少不确定性
+
+**不确定性越多，越容易紧张。** 如果你能够在面试前做充分的准备，很多“未知”就会消失，紧张情绪自然会减轻很多。
+
+### 认真准备技术面试
+
+- **优先梳理核心知识点**：比如计算基础、数据库、Java 基础、Java 集合、并发编程、SpringBoot（这里以 Java 后端方向为例）等。如果时间不够，可以分轻重缓急，有重点地复习。强烈推荐阅读一下 [Java 面试重点总结(重要)](https://javaguide.cn/interview-preparation/key-points-of-interview.html)这篇文章。
+- **精心准备项目经历**：认真思考你简历上最重要的项目（面试以前两个项目为主，尤其是第一个），它们的技术难点、业务逻辑、架构设计，以及可能被面试官深挖的点。把你的思考总结成可能出现的面试问题，并尝试回答。
+
+### 模拟面试和自测
+
+- **约朋友或同学互相提问**：以真实的面试场景来进行演练，并及时对回答进行诊断和反馈。
+- **线上练习**：很多平台都提供 AI 模拟面试，能比较真实地模拟面试官提问情境。
+- **面经**：平时可以多看一些前辈整理的面经，尤其是目标岗位或目标公司的面经，总结高频考点和常见问题。
+- **技术面试题自测**：在 [《Java 面试指北》](https://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html) 的 「技术面试题自测篇」 ，我总结了 Java 面试中最重要的知识点的最常见的面试题并按照面试提问的方式展现出来。其中，每一个问题都有提示和重要程度说明，非常适合用来自测。
+
+[《Java 面试指北》](https://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html) 的 「技术面试题自测篇」概览：
+
+
+
+### 多表达
+
+平时要多说，多表达出来，不要只是在心里面想，不然真正面试的时候会发现想的和说的不太一样。
+
+我前面推荐的模拟面试和自测，有一部分原因就是为了能够多多表达。
+
+### 多面试
+
+- **先小厂后大厂**：可以先去一些规模较小或者对你来说压力没那么大的公司试试手，积累一些实战经验，增加一些信心；等熟悉了面试流程、能够更从容地回答问题后，再去挑战自己心仪的大厂或热门公司。
+- **积累“失败经验”**：不要怕被拒，有些时候被拒绝却能从中学到更多。多复盘，多思考到底是哪个环节出了问题，再用更好的状态迎接下一次面试。
+
+### 保证休息
+
+- **留出充裕时间**：面试前尽量不要排太多事情，保证自己能有个好状态去参加面试。
+- **保证休息**：充足睡眠有助于情绪稳定，也能让你在面试时更清晰地思考问题。
+
+## 遇到不会的问题不要慌
+
+一场面试，不太可能面试官提的每一个问题你都能轻松应对，除非这场面试非常简单。
+
+在面试过程中，遇到不会的问题，首先要做的是快速回顾自己过往的知识，看是否能找到突破口。如果实在没有思路的话，可以真诚地向面试要一些提示比如谈谈你对这个问题的理解以及困惑点。一定不要觉得向面试官要提示很可耻，只要沟通没问题，这其实是很正常的。最怕的就是自己不会，还乱回答一通，这样会让面试官觉得你技术态度有问题。
+
+## 面试结束后的复盘
+
+很多人关注面试前的准备，却忽略了面试后的复盘，这一步真的非常非常非常重要：
+
+1. **记录面试中的问题**：无论回答得好坏，都把它们写下来。如果问到了一些没想过的问题，可以认真思考并在面试后补上答案。
+2. **反思自己的表现**：有没有遇到卡壳的地方？是知识没准备到还是过于紧张导致表达混乱？下次如何改进？
+3. **持续完善自己的“面试题库”**：把新的问题补充进去，不断拓展自己的知识面，也逐步降低对未知问题的恐惧感。
diff --git a/docs/interview-preparation/internship-experience.md b/docs/interview-preparation/internship-experience.md
new file mode 100644
index 00000000000..4e16fc7e0b5
--- /dev/null
+++ b/docs/interview-preparation/internship-experience.md
@@ -0,0 +1,56 @@
+---
+title: 校招没有实习经历怎么办？
+category: 面试准备
+icon: experience
+---
+
+由于目前的面试太卷，对于犹豫是否要找实习的同学来说，个人建议不论是本科生还是研究生都应该在参加校招面试之前，争取一下不错的实习机会，尤其是大厂的实习机会，日常实习或者暑期实习都可以。当然，如果大厂实习面不上，中小厂实习也是可以接受的。
+
+不过，现在的实习是真难找，今年有非常多的同学没有找到实习，有一部分甚至是 211/985 名校的同学。
+
+如果实在是找不到合适的实习的话，那也没办法，我们应该多花时间去把下面这三件事情给做好：
+
+1. 补强项目经历
+2. 持续完善简历
+3. 准备技术面试
+
+## 补强项目经历
+
+校招没有实习经历的话，找工作比较吃亏（没办法，太卷了），需要在项目经历部分多发力弥补一下。
+
+建议你尽全力地去补强自己的项目经历，完善现有的项目或者去做更有亮点的项目，尽可能地通过项目经历去弥补一些。
+
+你面试中的重点就是你的项目经历涉及到的知识点，如果你的项目经历比较简单的话，面试官直接不知道问啥了。另外，你的项目经历中不涉及的知识点，但在技能介绍中提到的知识点也很大概率会被问到。像 Redis 这种基本是面试 Java 后端岗位必备的技能，我觉得大部分面试官应该都会问。
+
+推荐阅读一下网站的这篇文章：[项目经验指南](https://javaguide.cn/interview-preparation/project-experience-guide.html)。
+
+## **完善简历**
+
+一定一定一定要重视简历啊！建议至少花 2~3 天时间来专门完善自己的简历。并且，后续还要持续完善。
+
+对于面试官来说，筛选简历的时候会比较看重下面这些维度：
+
+1. **实习/工作经历**：看你是否有不错的实习经历，大厂且与面试岗位相关的实习/工作经历最佳。
+2. **获奖经历**：如果有含金量比较高（知名度较高的赛事比如 ACM、阿里云天池）的获奖经历的话，也是加分点，尤其是对于校招来说，这类求职者属于是很多大厂争抢的对象（但不是说获奖了就能进大厂，还是要面试表现还可以）。对于社招来说，获奖经历作用相对较小，通常会更看重过往的工作经历和项目经验。
+3. **项目经验**：项目经验对于面试来说非常重要，面试官会重点关注，同时也是有水平的面试提问的重点。
+4. **技能匹配度**：看你的技能是否满足岗位的需求。在投递简历之前，一定要确认一下自己的技能介绍中是否缺少一些你要投递的对应岗位的技能要求。
+5. **学历**：相对其他行业来说，程序员求职面试对于学历的包容度还是比较高的，只要你在其他方面有过人之出的话，也是可以弥补一下学历的缺陷的。你要知道，很多行业比如律师、金融，学历就是敲门砖，学历没达到要求，直接面试机会都没有。不过，由于现在面试越来越卷，一些大厂、国企和研究所也开始卡学历了，很多岗位都要求 211/985，甚至必须需要硕士学历。总之，学历很难改变，学校较差的话，就投递那些对学历没有明确要求的公司即可，努力提升自己的其他方面的硬实力。
+
+对于大部分求职者来说，实习/工作经历、项目经验、技能匹配度更重要一些。不过，不排除一些公司会因为学历卡人。
+
+详细的程序员简历编写指南可以参考这篇文章：[程序员简历编写指南(重要)](https://javaguide.cn/interview-preparation/resume-guide.html)。
+
+## **准备技术面试**
+
+面试之前一定要提前准备一下常见的面试题也就是八股文：
+
+- 自己面试中可能涉及哪些知识点、那些知识点是重点。
+- 面试中哪些问题会被经常问到、面试中自己该如何回答。(强烈不推荐死记硬背，第一：通过背这种方式你能记住多少？能记住多久？第二：背题的方式的学习很难坚持下去！)
+
+Java 后端面试复习的重点请看这篇文章：[Java 后端的面试重点是什么?](https://javaguide.cn/interview-preparation/key-points-of-interview.html)。
+
+不同类型的公司对于技能的要求侧重点是不同的比如腾讯、字节可能更重视计算机基础比如网络、操作系统这方面的内容。阿里、美团这种可能更重视你的项目经历、实战能力。
+
+一定不要抱着一种思想，觉得八股文或者基础问题的考查意义不大。如果你抱着这种思想复习的话，那效果可能不会太好。实际上，个人认为还是很有意义的，八股文或者基础性的知识在日常开发中也会需要经常用到。例如，线程池这块的拒绝策略、核心参数配置什么的，如果你不了解，实际项目中使用线程池可能就用的不是很明白，容易出现问题。而且，其实这种基础性的问题是最容易准备的，像各种底层原理、系统设计、场景题以及深挖你的项目这类才是最难的！
+
+八股文资料首推我的 [《Java 面试指北》](https://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html) 和 [JavaGuide](https://javaguide.cn/home.html) 。里面不仅仅是原创八股文，还有很多对实际开发有帮助的干货。除了我的资料之外，你还可以去网上找一些其他的优质的文章、视频来看。
diff --git a/docs/interview-preparation/interview-experience.md b/docs/interview-preparation/interview-experience.md
index 623aa555e73..2b58e95df10 100644
--- a/docs/interview-preparation/interview-experience.md
+++ b/docs/interview-preparation/interview-experience.md
@@ -25,6 +25,6 @@ icon: experience
有很多同学要说了：“为什么不直接给出具体答案呢？”。主要原因有如下两点：
1. 参考资料解释的要更详细一些，还可以顺便让你把相关的知识点复习一下。
-2. 给出的参考资料基本都是我的原创，假如后续我想对面试问题的答案进行完善，就不需要挨个把之前的面经写的答案给修改了（面试中的很多问题都是比较类似的）。当然了，我的原创文章也不太可能覆盖到面试的每个点，部面试问题的答案，我是精选的其他技术博主写的优质文章，文章质量都很高。
+2. 给出的参考资料基本都是我的原创，假如后续我想对面试问题的答案进行完善，就不需要挨个把之前的面经写的答案给修改了（面试中的很多问题都是比较类似的）。当然了，我的原创文章也不太可能覆盖到面试的每个点，部分面试问题的答案，我是精选的其他技术博主写的优质文章，文章质量都很高。
diff --git a/docs/interview-preparation/java-roadmap.md b/docs/interview-preparation/java-roadmap.md
new file mode 100644
index 00000000000..60dd0fa7fc0
--- /dev/null
+++ b/docs/interview-preparation/java-roadmap.md
@@ -0,0 +1,29 @@
+---
+title: Java 学习路线(最新版，4w+字)
+category: 面试准备
+icon: path
+---
+
+::: tip 重要说明
+
+本学习路线保持**年度系统性修订**，严格同步 Java 技术生态与招聘市场的最新动态，**确保内容时效性与前瞻性**。
+
+:::
+
+历时一个月精心打磨，笔者基于当下 Java 后端开发岗位招聘的最新要求，对既有学习路线进行了全面升级。本次升级涵盖技术栈增删、学习路径优化、配套学习资源更新等维度，力争构建出更符合 Java 开发者成长曲线的知识体系。
+
+
+
+这可能是你见过的最用心、最全面的 Java 后端学习路线。这份学习路线共包含 **4w+** 字，但你完全不用担心内容过多而学不完。我会根据学习难度，划分出适合找小厂工作必学的内容，以及适合逐步提升 Java 后端开发能力的学习路径。
+
+
+
+对于初学者，你可以按照这篇文章推荐的学习路线和资料进行系统性的学习；对于有经验的开发者，你可以根据这篇文章更一步地深入学习 Java 后端开发，提升个人竞争力。
+
+在看这份学习路线的过程中，建议搭配 [Java 面试重点总结(重要)](https://javaguide.cn/interview-preparation/key-points-of-interview.html)，可以让你在学习过程中更有目的性。
+
+由于这份学习路线内容太多，因此我将其整理成了 PDF 版本（共 **61** 页），方便大家阅读。这份 PDF 有黑夜和白天两种阅读版本，满足大家的不同需求。
+
+这份学习路线的获取方法很简单：直接在公众号「**JavaGuide**」后台回复“**学习路线**”即可获取。
+
+
diff --git a/docs/interview-preparation/key-points-of-interview.md b/docs/interview-preparation/key-points-of-interview.md
index 83cb3facce2..c2101dc307a 100644
--- a/docs/interview-preparation/key-points-of-interview.md
+++ b/docs/interview-preparation/key-points-of-interview.md
@@ -1,25 +1,26 @@
---
-title: Java面试重点总结(重要)
+title: Java后端面试重点总结
category: 面试准备
icon: star
---
::: tip 友情提示
-本文节选自 **[《Java 面试指北》](../zhuanlan/java-mian-shi-zhi-bei.md)**。这是一份教你如何更高效地准备面试的小册，涵盖常见八股文（系统设计、常见框架、分布式、高并发 ……）、优质面经等内容。
+本文节选自 **[《Java 面试指北》](../zhuanlan/java-mian-shi-zhi-bei.md)**。这是一份教你如何更高效地准备面试的专栏，内容和 JavaGuide 互补，涵盖常见八股文（系统设计、常见框架、分布式、高并发 ……）、优质面经等内容。
:::
## Java 后端面试哪些知识点是重点？
-**准备面试的时候，具体哪些知识点是重点呢？**
+**准备面试的时候，具体哪些知识点是重点呢？如何把握重点？**
给你几点靠谱的建议：
-1. Java 基础、集合、并发、MySQL、Redis、Spring、Spring Boot 这些 Java 后端开发必备的知识点。大厂以及中小厂的面试问的比较多的就是这些知识点（不信的话，你可以去多找一些面经看看）。我这里没有提到计算机基础相关的内容，这个会在下面提到。
-2. 你的项目经历涉及到的知识点，有水平的面试官都是会根据你的项目经历来问的。举个例子，你的项目经历使用了 Redis 来做限流，那 Redis 相关的八股文（比如 Redis 常见数据结构）以及限流相关的八股文（比如常见的限流算法）你就应该多花更多心思来搞懂！吃透！你把项目经历上的知识点吃透之后，再把你简历上哪些写熟练掌握的技术给吃透。最后，再去花时间准备其他知识点。
-3. 针对自身找工作的需求，你又可以适当地调整复习的重点。像中小厂一般问计算机基础比较少一些，有些大厂比如字节比较重视计算机基础尤其是算法。这样的话，如果你的目标是中小厂的话，计算机基础就准备面试来说不是那么重要了。如果复习时间不够的话，可以暂时先放放。
+1. Java 基础、集合、并发、MySQL、Redis 、Spring、Spring Boot 这些 Java 后端开发必备的知识点（MySQL + Redis >= Java > Spring + Spring Boot）。大厂以及中小厂的面试问的比较多的就是这些知识点。Spring 和 Spring Boot 这俩框架类的知识点相对前面的知识点来说重要性要稍低一些，但一般面试也会问一些，尤其是中小厂。并发知识一般中大厂提问更多也更难，尤其是大厂喜欢深挖底层，很容易把人问倒。计算机基础相关的内容会在下面提到。
+2. 你的项目经历涉及到的知识点是重中之重，有水平的面试官都是会根据你的项目经历来问的。举个例子，你的项目经历使用了 Redis 来做限流，那 Redis 相关的八股文（比如 Redis 常见数据结构）以及限流相关的八股文（比如常见的限流算法）你就应该多花更多心思来搞懂吃透！你把项目经历上的知识点吃透之后，再把你简历上哪些写熟练掌握的技术给吃透，最后再去花时间准备其他知识点。
+3. 针对自身找工作的需求，你又可以适当地调整复习的重点。像中小厂一般问计算机基础比较少一些，有些大厂比如字节比较重视计算机基础尤其是算法。这样的话，如果你的目标是中小厂的话，计算机基础就准备面试来说不是那么重要了。如果复习时间不够的话，可以暂时先放放，腾出时间给其他重要的知识点。
4. 一般校招的面试不会强制要求你会分布式/微服务、高并发的知识（不排除个别岗位有这方面的硬性要求），所以到底要不要掌握还是要看你个人当前的实际情况。如果你会这方面的知识的话，对面试相对来说还是会更有利一些（想要让项目经历有亮点，还是得会一些性能优化的知识。性能优化的知识这也算是高并发知识的一个小分支了）。如果你的技能介绍或者项目经历涉及到分布式/微服务、高并发的知识，那建议你尽量也要抽时间去认真准备一下，面试中很可能会被问到，尤其是项目经历用到的时候。不过，也还是主要准备写在简历上的那些知识点就好。
-5. JVM 相关的知识点，一般是大厂才会问到，面试中小厂就没必要准备了。JVM 面试中比较常问的是 [Java 内存区域](https://javaguide.cn/java/jvm/memory-area.html)、[JVM 垃圾回收](https://javaguide.cn/java/jvm/jvm-garbage-collection.html)、[类加载器和双亲委派模型](https://javaguide.cn/java/jvm/classloader.html) 以及 JVM 调优和问题排查（我之前分享过一些[常见的线上问题案例](https://t.zsxq.com/0bsAac47U)，里面就有 JVM 相关的）。
+5. JVM 相关的知识点，一般是大厂（例如美团、阿里）和一些不错的中厂（例如携程、顺丰、招银网络）才会问到，面试国企、差一点的中厂和小厂就没必要准备了。JVM 面试中比较常问的是 [Java 内存区域](https://javaguide.cn/java/jvm/memory-area.html)、[JVM 垃圾回收](https://javaguide.cn/java/jvm/jvm-garbage-collection.html)、[类加载器和双亲委派模型](https://javaguide.cn/java/jvm/classloader.html) 以及 JVM 调优和问题排查（我之前分享过一些[常见的线上问题案例](https://t.zsxq.com/0bsAac47U)，里面就有 JVM 相关的）。
6. 不同的大厂面试侧重点也会不同。比如说你要去阿里这种公司的话，项目和八股文就是重点，阿里笔试一般会有代码题，进入面试后就很少问代码题了，但是对原理性的问题问的比较深，经常会问一些你对技术的思考。再比如说你要面试字节这种公司，那计算机基础，尤其是算法是重点，字节的面试十分注重代码功底，有时候开始面试就会直接甩给你一道代码题，写出来再谈别的。也会问面试八股文，以及项目，不过，相对来说要少很多。建议你看一下这篇文章 [为了解开互联网大厂秋招内幕，我把他们全面了一遍](https://mp.weixin.qq.com/s/pBsGQNxvRupZeWt4qZReIA)，了解一下常见大厂的面试题侧重点。
+7. 多去找一些面经看看，尤其你目标公司或者类似公司对应岗位的面经。这样可以实现针对性的复习，还能顺便自测一波，检查一下自己的掌握情况。
看似 Java 后端八股文很多，实际把复习范围一缩小，重要的东西就是那些。考虑到时间问题，你不可能连一些比较冷门的知识点也给准备了。这没必要，主要精力先放在那些重要的知识点即可。
@@ -31,8 +32,12 @@ icon: star
举个例子：你的项目中需要用到 Redis 来做缓存，你对照着官网简单了解并实践了简单使用 Redis 之后，你去看了 Redis 对应的八股文。你发现 Redis 可以用来做限流、分布式锁，于是你去在项目中实践了一下并掌握了对应的八股文。紧接着，你又发现 Redis 内存不够用的情况下，还能使用 Redis Cluster 来解决，于是你就又去实践了一下并掌握了对应的八股文。
-**一定要记住你的主要目标是理解和记关键词，而不是像背课文一样一字一句地记下来！**
+**一定要记住你的主要目标是理解和记关键词，而不是像背课文一样一字一句地记下来，这样毫无意义！效率最低，对自身帮助也最小！**
-另外，记录博客或者用自己的理解把对应的知识点讲给别人听也是一个不错的选择。
+还要注意适当“投机取巧”，不要单纯死记八股，有些技术方案的实现有很多种，例如分布式 ID、分布式锁、幂等设计，想要完全记住所有方案不太现实，你就重点记忆你项目的实现方案以及选择该种实现方案的原因就好了。当然，其他方案还是建议你简单了解一下，不然也没办法和你选择的方案进行对比。
+
+想要检测自己是否搞懂或者加深印象，记录博客或者用自己的理解把对应的知识点讲给别人听也是一个不错的选择。
+
+另外，准备八股文的过程中，强烈建议你花个几个小时去根据你的简历（主要是项目经历部分）思考一下哪些地方可能被深挖，然后把你自己的思考以面试问题的形式体现出来。面试之后，你还要根据当下的面试情况复盘一波，对之前自己整理的面试问题进行完善补充。这个过程对于个人进一步熟悉自己的简历（尤其是项目经历）部分，非常非常有用。这些问题你也一定要多花一些时间搞懂吃透，能够流畅地表达出来。面试问题可以参考 [Java 面试常见问题总结（2024 最新版）](https://t.zsxq.com/0eRq7EJPy)，记得根据自己项目经历去深入拓展即可！
最后，准备技术面试的同学一定要定期复习（自测的方式非常好），不然确实会遗忘的。
diff --git a/docs/interview-preparation/project-experience-guide.md b/docs/interview-preparation/project-experience-guide.md
index f2e93df82b3..0546626f889 100644
--- a/docs/interview-preparation/project-experience-guide.md
+++ b/docs/interview-preparation/project-experience-guide.md
@@ -5,7 +5,7 @@ icon: project
---
::: tip 友情提示
-本文节选自 **[《Java 面试指北》](../zhuanlan/java-mian-shi-zhi-bei.md)**。这是一份教你如何更高效地准备面试的小册，涵盖常见八股文（系统设计、常见框架、分布式、高并发 ……）、优质面经等内容。
+本文节选自 **[《Java 面试指北》](../zhuanlan/java-mian-shi-zhi-bei.md)**。这是一份教你如何更高效地准备面试的专栏，内容和 JavaGuide 互补，涵盖常见八股文（系统设计、常见框架、分布式、高并发 ……）、优质面经等内容。
:::
## 没有项目经验怎么办?
diff --git a/docs/interview-preparation/resume-guide.md b/docs/interview-preparation/resume-guide.md
index 818274601e0..396ef4b47e4 100644
--- a/docs/interview-preparation/resume-guide.md
+++ b/docs/interview-preparation/resume-guide.md
@@ -1,5 +1,5 @@
---
-title: 程序员简历编写指南(重要)
+title: 程序员简历编写指南
category: 面试准备
icon: jianli
---
diff --git a/docs/interview-preparation/teach-you-how-to-prepare-for-the-interview-hand-in-hand.md b/docs/interview-preparation/teach-you-how-to-prepare-for-the-interview-hand-in-hand.md
index 7cc0797bcf2..ae8a4bf6f18 100644
--- a/docs/interview-preparation/teach-you-how-to-prepare-for-the-interview-hand-in-hand.md
+++ b/docs/interview-preparation/teach-you-how-to-prepare-for-the-interview-hand-in-hand.md
@@ -1,11 +1,11 @@
---
-title: 手把手教你如何准备Java面试(重要)
+title: 如何高效准备Java面试？
category: 知识星球
icon: path
---
::: tip 友情提示
-本文节选自 **[《Java 面试指北》](../zhuanlan/java-mian-shi-zhi-bei.md)**。这是一份教你如何更高效地准备面试的小册，涵盖常见八股文（系统设计、常见框架、分布式、高并发 ……）、优质面经等内容。
+本文节选自 **[《Java 面试指北》](../zhuanlan/java-mian-shi-zhi-bei.md)**。这是一份教你如何更高效地准备面试的专栏，内容和 JavaGuide 互补，涵盖常见八股文（系统设计、常见框架、分布式、高并发 ……）、优质面经等内容。
:::
你的身边一定有很多编程比你厉害但是找的工作并没有你好的朋友！**技术面试不同于编程，编程厉害不代表技术面试就一定能过。**
diff --git a/docs/java/basis/bigdecimal.md b/docs/java/basis/bigdecimal.md
index 5af0c460579..acedfadc32f 100644
--- a/docs/java/basis/bigdecimal.md
+++ b/docs/java/basis/bigdecimal.md
@@ -21,7 +21,7 @@ System.out.println(a == b);// false
**为什么浮点数 `float` 或 `double` 运算的时候会有精度丢失的风险呢？**
-这个和计算机保存浮点数的机制有很大关系。我们知道计算机是二进制的，而且计算机在表示一个数字时，宽度是有限的，无限循环的小数存储在计算机时，只能被截断，所以就会导致小数精度发生损失的情况。这也就是解释了为什么浮点数没有办法用二进制精确表示。
+这个和计算机保存小数的机制有很大关系。我们知道计算机是二进制的，而且计算机在表示一个数字时，宽度是有限的，无限循环的小数存储在计算机时，只能被截断，所以就会导致小数精度发生损失的情况。这也就是解释了为什么十进制小数没有办法用二进制精确表示。
就比如说十进制下的 0.2 就没办法精确转换成二进制小数：
@@ -40,9 +40,9 @@ System.out.println(a == b);// false
## BigDecimal 介绍
-`BigDecimal` 可以实现对浮点数的运算，不会造成精度丢失。
+`BigDecimal` 可以实现对小数的运算，不会造成精度丢失。
-通常情况下，大部分需要浮点数精确运算结果的业务场景（比如涉及到钱的场景）都是通过 `BigDecimal` 来做的。
+通常情况下，大部分需要小数精确运算结果的业务场景（比如涉及到钱的场景）都是通过 `BigDecimal` 来做的。
《阿里巴巴 Java 开发手册》中提到：**浮点数之间的等值判断，基本数据类型不能用 == 来比较，包装数据类型不能用 equals 来判断。**
@@ -50,7 +50,7 @@ System.out.println(a == b);// false
具体原因我们在上面已经详细介绍了，这里就不多提了。
-想要解决浮点数运算精度丢失这个问题，可以直接使用 `BigDecimal` 来定义浮点数的值，然后再进行浮点数的运算操作即可。
+想要解决浮点数运算精度丢失这个问题，可以直接使用 `BigDecimal` 来定义小数的值，然后再进行小数的运算操作即可。
```java
BigDecimal a = new BigDecimal("1.0");
@@ -99,20 +99,20 @@ public BigDecimal divide(BigDecimal divisor, int scale, RoundingMode roundingMod
```java
public enum RoundingMode {
- // 2.5 -> 3 , 1.6 -> 2
- // -1.6 -> -2 , -2.5 -> -3
+ // 2.4 -> 3 , 1.6 -> 2
+ // -1.6 -> -2 , -2.4 -> -3
UP(BigDecimal.ROUND_UP),
- // 2.5 -> 2 , 1.6 -> 1
- // -1.6 -> -1 , -2.5 -> -2
+ // 2.4 -> 2 , 1.6 -> 1
+ // -1.6 -> -1 , -2.4 -> -2
DOWN(BigDecimal.ROUND_DOWN),
- // 2.5 -> 3 , 1.6 -> 2
- // -1.6 -> -1 , -2.5 -> -2
+ // 2.4 -> 3 , 1.6 -> 2
+ // -1.6 -> -1 , -2.4 -> -2
CEILING(BigDecimal.ROUND_CEILING),
// 2.5 -> 2 , 1.6 -> 1
// -1.6 -> -2 , -2.5 -> -3
FLOOR(BigDecimal.ROUND_FLOOR),
- // 2.5 -> 3 , 1.6 -> 2
- // -1.6 -> -2 , -2.5 -> -3
+ // 2.4 -> 2 , 1.6 -> 2
+ // -1.6 -> -2 , -2.4 -> -2
HALF_UP(BigDecimal.ROUND_HALF_UP),
//......
}
@@ -230,7 +230,7 @@ public class BigDecimalUtil {
/**
* 提供（相对）精确的除法运算，当发生除不尽的情况时，精确到
- * 小数点以后10位，以后的数字四舍五入。
+ * 小数点以后10位，以后的数字四舍六入五成双。
*
* @param v1 被除数
* @param v2 除数
@@ -242,7 +242,7 @@ public class BigDecimalUtil {
/**
* 提供（相对）精确的除法运算。当发生除不尽的情况时，由scale参数指
- * 定精度，以后的数字四舍五入。
+ * 定精度，以后的数字四舍六入五成双。
*
* @param v1 被除数
* @param v2 除数
@@ -260,11 +260,11 @@ public class BigDecimalUtil {
}
/**
- * 提供精确的小数位四舍五入处理。
+ * 提供精确的小数位四舍六入五成双处理。
*
- * @param v 需要四舍五入的数字
+ * @param v 需要四舍六入五成双的数字
* @param scale 小数点后保留几位
- * @return 四舍五入后的结果
+ * @return 四舍六入五成双后的结果
*/
public static double round(double v, int scale) {
if (scale < 0) {
@@ -288,7 +288,7 @@ public class BigDecimalUtil {
}
/**
- * 提供精确的类型转换(Int)不进行四舍五入
+ * 提供精确的类型转换(Int)不进行四舍六入五成双
*
* @param v 需要被转换的数字
* @return 返回转换结果
diff --git a/docs/java/basis/generics-and-wildcards.md b/docs/java/basis/generics-and-wildcards.md
index f65781e01e6..bd9cd4b00bf 100644
--- a/docs/java/basis/generics-and-wildcards.md
+++ b/docs/java/basis/generics-and-wildcards.md
@@ -5,7 +5,7 @@ tag:
- Java基础
---
-**泛型&通配符** 相关的面试题为我的[知识星球](https://javaguide.cn/about-the-author/zhishixingqiu-two-years.html)（点击链接即可查看详细介绍以及加入方法）专属内容，已经整理到了[《Java 面试指北》](hhttps://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html)（点击链接即可查看详细介绍以及获取方法）中。
+**泛型&通配符** 相关的面试题为我的[知识星球](https://javaguide.cn/about-the-author/zhishixingqiu-two-years.html)（点击链接即可查看详细介绍以及加入方法）专属内容，已经整理到了[《Java 面试指北》](https://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html)（点击链接即可查看详细介绍以及获取方法）中。
[《Java 面试指北》](hhttps://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html) 的部分内容展示如下，你可以将其看作是 [JavaGuide](https://javaguide.cn/#/) 的补充完善，两者可以配合使用。
diff --git a/docs/java/basis/java-basic-questions-01.md b/docs/java/basis/java-basic-questions-01.md
index 0613411783a..49e00a73948 100644
--- a/docs/java/basis/java-basic-questions-01.md
+++ b/docs/java/basis/java-basic-questions-01.md
@@ -6,7 +6,7 @@ tag:
head:
- - meta
- name: keywords
- content: JVM,JDK,JRE,字节码详解,Java 基本数据类型,装箱和拆箱
+ content: Java特点,Java SE,Java EE,Java ME,Java虚拟机,JVM,JDK,JRE,字节码,Java编译与解释,AOT编译,云原生,AOT与JIT对比,GraalVM,Oracle JDK与OpenJDK区别,OpenJDK,LTS支持,多线程支持,静态变量,成员变量与局部变量区别,包装类型缓存机制,自动装箱与拆箱,浮点数精度丢失,BigDecimal,Java基本数据类型,Java标识符与关键字,移位运算符,Java注释,静态方法与实例方法,方法重载与重写,可变长参数,Java性能优化
- - meta
- name: description
content: 全网质量最高的Java基础常见知识点和面试题总结，希望对你有帮助！
@@ -18,7 +18,7 @@ head:
### Java 语言有哪些特点?
-1. 简单易学；
+1. 简单易学（语法简单，上手容易）；
2. 面向对象（封装，继承，多态）；
3. 平台无关性（ Java 虚拟机实现平台无关性）；
4. 支持多线程（ C++ 语言没有内置的多线程机制，因此必须调用操作系统的多线程功能来进行多线程程序设计，而 Java 语言却提供了多线程支持）；
@@ -48,7 +48,9 @@ head:
#### JVM
-Java 虚拟机（JVM）是运行 Java 字节码的虚拟机。JVM 有针对不同系统的特定实现（Windows，Linux，macOS），目的是使用相同的字节码，它们都会给出相同的结果。字节码和不同系统的 JVM 实现是 Java 语言“一次编译，随处可以运行”的关键所在。
+Java 虚拟机（Java Virtual Machine, JVM）是运行 Java 字节码的虚拟机。JVM 有针对不同系统的特定实现（Windows，Linux，macOS），目的是使用相同的字节码，它们都会给出相同的结果。字节码和不同系统的 JVM 实现是 Java 语言“一次编译，随处可以运行”的关键所在。
+
+如下图所示，不同编程语言（Java、Groovy、Kotlin、JRuby、Clojure ...）通过各自的编译器编译成 `.class` 文件，并最终通过 JVM 在不同平台（Windows、Mac、Linux）上运行。
@@ -60,13 +62,20 @@ Java 虚拟机（JVM）是运行 Java 字节码的虚拟机。JVM 有针对不
#### JDK 和 JRE
-JDK（Java Development Kit），它是功能齐全的 Java SDK，是提供给开发者使用，能够创建和编译 Java 程序的开发套件。它包含了 JRE，同时还包含了编译 java 源码的编译器 javac 以及一些其他工具比如 javadoc（文档注释工具）、jdb（调试器）、jconsole（基于 JMX 的可视化监控⼯具）、javap（反编译工具）等等。
+JDK（Java Development Kit）是一个功能齐全的 Java 开发工具包，供开发者使用，用于创建和编译 Java 程序。它包含了 JRE（Java Runtime Environment），以及编译器 javac 和其他工具，如 javadoc（文档生成器）、jdb（调试器）、jconsole（监控工具）、javap（反编译工具）等。
+
+JRE 是运行已编译 Java 程序所需的环境，主要包含以下两个部分：
+
+1. **JVM** : 也就是我们上面提到的 Java 虚拟机。
+2. **Java 基础类库（Class Library）**：一组标准的类库，提供常用的功能和 API（如 I/O 操作、网络通信、数据结构等）。
+
+简单来说，JRE 只包含运行 Java 程序所需的环境和类库，而 JDK 不仅包含 JRE，还包括用于开发和调试 Java 程序的工具。
-JRE（Java Runtime Environment） 是 Java 运行时环境。它是运行已编译 Java 程序所需的所有内容的集合，主要包括 Java 虚拟机（JVM）、Java 基础类库（Class Library）。
+如果需要编写、编译 Java 程序或使用 Java API 文档，就需要安装 JDK。某些需要 Java 特性的应用程序（如 JSP 转换为 Servlet 或使用反射）也可能需要 JDK 来编译和运行 Java 代码。因此，即使不进行 Java 开发工作，有时也可能需要安装 JDK。
-也就是说，JRE 是 Java 运行时环境，仅包含 Java 应用程序的运行时环境和必要的类库。而 JDK 则包含了 JRE，同时还包括了 javac、javadoc、jdb、jconsole、javap 等工具，可以用于 Java 应用程序的开发和调试。如果需要进行 Java 编程工作，比如编写和编译 Java 程序、使用 Java API 文档等，就需要安装 JDK。而对于某些需要使用 Java 特性的应用程序，如 JSP 转换为 Java Servlet、使用反射等，也需要 JDK 来编译和运行 Java 代码。因此，即使不打算进行 Java 应用程序的开发工作，也有可能需要安装 JDK。
+下图清晰展示了 JDK、JRE 和 JVM 的关系。
-
+
不过，从 JDK 9 开始，就不需要区分 JDK 和 JRE 的关系了，取而代之的是模块系统（JDK 被重新组织成 94 个模块）+ [jlink](http://openjdk.java.net/jeps/282) 工具 (随 Java 9 一起发布的新命令行工具，用于生成自定义 Java 运行时映像，该映像仅包含给定应用程序所需的模块) 。并且，从 JDK 11 开始，Oracle 不再提供单独的 JRE 下载。
@@ -88,7 +97,10 @@ JRE（Java Runtime Environment） 是 Java 运行时环境。它是运行已编
我们需要格外注意的是 `.class->机器码` 这一步。在这一步 JVM 类加载器首先加载字节码文件，然后通过解释器逐行解释执行，这种方式的执行速度会相对比较慢。而且，有些方法和代码块是经常需要被调用的(也就是所谓的热点代码)，所以后面引进了 **JIT（Just in Time Compilation）** 编译器，而 JIT 属于运行时编译。当 JIT 编译器完成第一次编译后，其会将字节码对应的机器码保存下来，下次可以直接使用。而我们知道，机器码的运行效率肯定是高于 Java 解释器的。这也解释了我们为什么经常会说 **Java 是编译与解释共存的语言** 。
-> 🌈 拓展：[有关 JIT 的实现细节: JVM C1、C2 编译器](https://mp.weixin.qq.com/s/4haTyXUmh8m-dBQaEzwDJw)
+> 🌈 拓展阅读：
+>
+> - [基本功 | Java 即时编译器原理解析及实践 - 美团技术团队](https://tech.meituan.com/2020/10/22/java-jit-practice-in-meituan.html)
+> - [基于静态编译构建微服务应用 - 阿里巴巴中间件](https://mp.weixin.qq.com/s/4haTyXUmh8m-dBQaEzwDJw)
@@ -129,7 +141,7 @@ JDK 9 引入了一种新的编译模式 **AOT(Ahead of Time Compilation)** 。
**JIT 与 AOT 两者的关键指标对比**:
-
+` 修改缓存上限，但不能修改下限 -128。实际使用时，并不建议设置过大的值，避免浪费内存，甚至是 OOM。
+
+对于`Byte`,`Short`,`Long` ,`Character` 没有类似 `-XX:AutoBoxCacheMax` 参数可以修改，因此缓存范围是固定的，无法通过 JVM 参数调整。`Boolean` 则直接返回预定义的 `TRUE` 和 `FALSE` 实例，没有缓存范围的概念。
**Integer 缓存源码：**
@@ -631,7 +672,7 @@ private static long sum() {
```java
float a = 2.0f - 1.9f;
float b = 1.8f - 1.7f;
-System.out.println(a);// 0.100000024
+System.out.printf("%.9f",a);// 0.100000024
System.out.println(b);// 0.099999905
System.out.println(a == b);// false
```
@@ -661,15 +702,18 @@ System.out.println(a == b);// false
```java
BigDecimal a = new BigDecimal("1.0");
-BigDecimal b = new BigDecimal("0.9");
+BigDecimal b = new BigDecimal("1.00");
BigDecimal c = new BigDecimal("0.8");
-BigDecimal x = a.subtract(b);
+BigDecimal x = a.subtract(c);
BigDecimal y = b.subtract(c);
-System.out.println(x); /* 0.1 */
-System.out.println(y); /* 0.1 */
-System.out.println(Objects.equals(x, y)); /* true */
+System.out.println(x); /* 0.2 */
+System.out.println(y); /* 0.20 */
+// 比较内容，不是比较值
+System.out.println(Objects.equals(x, y)); /* false */
+// 比较值相等用相等compareTo，相等返回0
+System.out.println(0 == x.compareTo(y)); /* true */
```
关于 `BigDecimal` 的详细介绍，可以看看我写的这篇文章：[BigDecimal 详解](https://javaguide.cn/java/basis/bigdecimal.html)。
@@ -694,8 +738,6 @@ System.out.println(l + 1 == Long.MIN_VALUE); // true
### 成员变量与局部变量的区别？
-
-
- **语法形式**：从语法形式上看，成员变量是属于类的，而局部变量是在代码块或方法中定义的变量或是方法的参数；成员变量可以被 `public`,`private`,`static` 等修饰符所修饰，而局部变量不能被访问控制修饰符及 `static` 所修饰；但是，成员变量和局部变量都能被 `final` 所修饰。
- **存储方式**：从变量在内存中的存储方式来看，如果成员变量是使用 `static` 修饰的，那么这个成员变量是属于类的，如果没有使用 `static` 修饰，这个成员变量是属于实例的。而对象存在于堆内存，局部变量则存在于栈内存。
- **生存时间**：从变量在内存中的生存时间上看，成员变量是对象的一部分，它随着对象的创建而存在，而局部变量随着方法的调用而自动生成，随着方法的调用结束而消亡。
@@ -976,6 +1018,7 @@ public class SuperMan extends Hero{
}
public class SuperSuperMan extends SuperMan {
+ @Override
public String name() {
return "超级超级英雄";
}
@@ -989,7 +1032,7 @@ public class SuperSuperMan extends SuperMan {
### 什么是可变长参数？
-从 Java5 开始，Java 支持定义可变长参数，所谓可变长参数就是允许在调用方法时传入不定长度的参数。就比如下面的这个 `printVariable` 方法就可以接受 0 个或者多个参数。
+从 Java5 开始，Java 支持定义可变长参数，所谓可变长参数就是允许在调用方法时传入不定长度的参数。就比如下面这个方法就可以接受 0 个或者多个参数。
```java
public static void method1(String... args) {
diff --git a/docs/java/basis/java-basic-questions-02.md b/docs/java/basis/java-basic-questions-02.md
index 7ffe5e432bd..9f8739f291d 100644
--- a/docs/java/basis/java-basic-questions-02.md
+++ b/docs/java/basis/java-basic-questions-02.md
@@ -6,7 +6,7 @@ tag:
head:
- - meta
- name: keywords
- content: 面向对象,构造方法,接口,抽象类,String,Object
+ content: 面向对象, 面向过程, OOP, POP, Java对象, 构造方法, 封装, 继承, 多态, 接口, 抽象类, 默认方法, 静态方法, 私有方法, 深拷贝, 浅拷贝, 引用拷贝, Object类, equals, hashCode, ==, 字符串, String, StringBuffer, StringBuilder, 不可变性, 字符串常量池, intern, 字符串拼接, Java基础, 面试题
- - meta
- name: description
content: 全网质量最高的Java基础常见知识点和面试题总结，希望对你有帮助！
@@ -18,14 +18,26 @@ head:
### 面向对象和面向过程的区别
-两者的主要区别在于解决问题的方式不同：
+面向过程编程（Procedural-Oriented Programming，POP）和面向对象编程（Object-Oriented Programming，OOP）是两种常见的编程范式，两者的主要区别在于解决问题的方式不同：
-- 面向过程把解决问题的过程拆成一个个方法，通过一个个方法的执行解决问题。
-- 面向对象会先抽象出对象，然后用对象执行方法的方式解决问题。
+- **面向过程编程（POP）**：面向过程把解决问题的过程拆成一个个方法，通过一个个方法的执行解决问题。
+- **面向对象编程（OOP）**：面向对象会先抽象出对象，然后用对象执行方法的方式解决问题。
-另外，面向对象开发的程序一般更易维护、易复用、易扩展。
+相比较于 POP，OOP 开发的程序一般具有下面这些优点：
-相关 issue : [面向过程：面向过程性能比面向对象高？？](https://github.com/Snailclimb/JavaGuide/issues/431) 。
+- **易维护**：由于良好的结构和封装性，OOP 程序通常更容易维护。
+- **易复用**：通过继承和多态，OOP 设计使得代码更具复用性，方便扩展功能。
+- **易扩展**：模块化设计使得系统扩展变得更加容易和灵活。
+
+POP 的编程方式通常更为简单和直接，适合处理一些较简单的任务。
+
+POP 和 OOP 的性能差异主要取决于它们的运行机制，而不仅仅是编程范式本身。因此，简单地比较两者的性能是一个常见的误区（相关 issue : [面向过程：面向过程性能比面向对象高？？](https://github.com/Snailclimb/JavaGuide/issues/431) ）。
+
+
+
+在选择编程范式时，性能并不是唯一的考虑因素。代码的可维护性、可扩展性和开发效率同样重要。
+
+现代编程语言基本都支持多种编程范式，既可以用来进行面向过程编程，也可以进行面向对象编程。
下面是一个求圆的面积和周长的示例，简单分别展示了面向对象和面向过程两种不同的解决方案。
@@ -136,13 +148,13 @@ true
### 构造方法有哪些特点？是否可被 override?
-构造方法特点如下：
+构造方法具有以下特点：
-- 名字与类名相同。
-- 没有返回值，但不能用 void 声明构造函数。
-- 生成类的对象时自动执行，无需调用。
+- **名称与类名相同**：构造方法的名称必须与类名完全一致。
+- **没有返回值**：构造方法没有返回类型，且不能使用 `void` 声明。
+- **自动执行**：在生成类的对象时，构造方法会自动执行，无需显式调用。
-构造方法不能被 override（重写）,但是可以 overload（重载）,所以你可以看到一个类中有多个构造函数的情况。
+构造方法**不能被重写（override）**，但**可以被重载（overload）**。因此，一个类中可以有多个构造方法，这些构造方法可以具有不同的参数列表，以提供不同的对象初始化方式。
### 面向对象三大特征
@@ -196,21 +208,71 @@ public class Student {
- 对象类型和引用类型之间具有继承（类）/实现（接口）的关系；
- 引用类型变量发出的方法调用的到底是哪个类中的方法，必须在程序运行期间才能确定；
- 多态不能调用“只在子类存在但在父类不存在”的方法；
-- 如果子类重写了父类的方法，真正执行的是子类覆盖的方法，如果子类没有覆盖父类的方法，执行的是父类的方法。
+- 如果子类重写了父类的方法，真正执行的是子类重写的方法，如果子类没有重写父类的方法，执行的是父类的方法。
### 接口和抽象类有什么共同点和区别？
-**共同点**：
+#### 接口和抽象类的共同点
+
+- **实例化**：接口和抽象类都不能直接实例化，只能被实现（接口）或继承（抽象类）后才能创建具体的对象。
+- **抽象方法**：接口和抽象类都可以包含抽象方法。抽象方法没有方法体，必须在子类或实现类中实现。
+
+#### 接口和抽象类的区别
+
+- **设计目的**：接口主要用于对类的行为进行约束，你实现了某个接口就具有了对应的行为。抽象类主要用于代码复用，强调的是所属关系。
+- **继承和实现**：一个类只能继承一个类（包括抽象类），因为 Java 不支持多继承。但一个类可以实现多个接口，一个接口也可以继承多个其他接口。
+- **成员变量**：接口中的成员变量只能是 `public static final` 类型的，不能被修改且必须有初始值。抽象类的成员变量可以有任何修饰符（`private`, `protected`, `public`），可以在子类中被重新定义或赋值。
+- **方法**：
+ - Java 8 之前，接口中的方法默认是 `public abstract` ，也就是只能有方法声明。自 Java 8 起，可以在接口中定义 `default`（默认） 方法和 `static` （静态）方法。 自 Java 9 起，接口可以包含 `private` 方法。
+ - 抽象类可以包含抽象方法和非抽象方法。抽象方法没有方法体，必须在子类中实现。非抽象方法有具体实现，可以直接在抽象类中使用或在子类中重写。
+
+在 Java 8 及以上版本中，接口引入了新的方法类型：`default` 方法、`static` 方法和 `private` 方法。这些方法让接口的使用更加灵活。
+
+Java 8 引入的`default` 方法用于提供接口方法的默认实现，可以在实现类中被覆盖。这样就可以在不修改实现类的情况下向现有接口添加新功能，从而增强接口的扩展性和向后兼容性。
-- 都不能被实例化。
-- 都可以包含抽象方法。
-- 都可以有默认实现的方法（Java 8 可以用 `default` 关键字在接口中定义默认方法）。
+```java
+public interface MyInterface {
+ default void defaultMethod() {
+ System.out.println("This is a default method.");
+ }
+}
+```
+
+Java 8 引入的`static` 方法无法在实现类中被覆盖，只能通过接口名直接调用（ `MyInterface.staticMethod()`），类似于类中的静态方法。`static` 方法通常用于定义一些通用的、与接口相关的工具方法，一般很少用。
-**区别**：
+```java
+public interface MyInterface {
+ static void staticMethod() {
+ System.out.println("This is a static method in the interface.");
+ }
+}
+```
-- 接口主要用于对类的行为进行约束，你实现了某个接口就具有了对应的行为。抽象类主要用于代码复用，强调的是所属关系。
-- 一个类只能继承一个类，但是可以实现多个接口。
-- 接口中的成员变量只能是 `public static final` 类型的，不能被修改且必须有初始值，而抽象类的成员变量默认 default，可在子类中被重新定义，也可被重新赋值。
+Java 9 允许在接口中使用 `private` 方法。`private`方法可以用于在接口内部共享代码，不对外暴露。
+
+```java
+public interface MyInterface {
+ // default 方法
+ default void defaultMethod() {
+ commonMethod();
+ }
+
+ // static 方法
+ static void staticMethod() {
+ commonMethod();
+ }
+
+ // 私有静态方法，可以被 static 和 default 方法调用
+ private static void commonMethod() {
+ System.out.println("This is a private method used internally.");
+ }
+
+ // 实例私有方法，只能被 default 方法调用。
+ private void instanceCommonMethod() {
+ System.out.println("This is a private instance method used internally.");
+ }
+}
+```
### 深拷贝和浅拷贝区别了解吗？什么是引用拷贝？
@@ -299,13 +361,13 @@ System.out.println(person1.getAddress() == person1Copy.getAddress());
我专门画了一张图来描述浅拷贝、深拷贝、引用拷贝：
-
+
## Object
### Object 类的常见方法有哪些？
-Object 类是一个特殊的类，是所有类的父类。它主要提供了以下 11 个方法：
+Object 类是一个特殊的类，是所有类的父类，主要提供了以下 11 个方法：
```java
/**
@@ -429,7 +491,7 @@ public boolean equals(Object anObject) {
`hashCode()` 定义在 JDK 的 `Object` 类中，这就意味着 Java 中的任何类都包含有 `hashCode()` 函数。另外需要注意的是：`Object` 的 `hashCode()` 方法是本地方法，也就是用 C 语言或 C++ 实现的。
-> ⚠️ 注意：该方法在 **Oracle OpenJDK8** 中默认是 "使用线程局部状态来实现 Marsaglia's xor-shift 随机数生成", 并不是 "地址" 或者 "地址转换而来", 不同 JDK/VM 可能不同在 **Oracle OpenJDK8** 中有六种生成方式 (其中第五种是返回地址), 通过添加 VM 参数: -XX:hashCode=4 启用第五种。参考源码:
+> ⚠️ 注意：该方法在 **Oracle OpenJDK8** 中默认是 "使用线程局部状态来实现 Marsaglia's xor-shift 随机数生成", 并不是 "地址" 或者 "地址转换而来", 不同 JDK/VM 可能不同。在 **Oracle OpenJDK8** 中有六种生成方式 (其中第五种是返回地址), 通过添加 VM 参数: -XX:hashCode=4 启用第五种。参考源码:
>
> - （1127 行）
> - （537 行开始）
@@ -621,7 +683,7 @@ System.out.println(s);
如果你使用 IDEA 的话，IDEA 自带的代码检查机制也会提示你修改代码。
-不过，使用 “+” 进行字符串拼接会产生大量的临时对象的问题在 JDK9 中得到了解决。在 JDK9 当中，字符串相加 “+” 改为了用动态方法 `makeConcatWithConstants()` 来实现，而不是大量的 `StringBuilder` 了。这个改进是 JDK9 的 [JEP 280](https://openjdk.org/jeps/280) 提出的，这也意味着 JDK 9 之后，你可以放心使用“+” 进行字符串拼接了。关于这部分改进的详细介绍，推荐阅读这篇文章：还在无脑用 [StringBuilder？来重温一下字符串拼接吧](https://juejin.cn/post/7182872058743750715) 。
+在 JDK 9 中，字符串相加“+”改为用动态方法 `makeConcatWithConstants()` 来实现，通过提前分配空间从而减少了部分临时对象的创建。然而这种优化主要针对简单的字符串拼接，如： `a+b+c` 。对于循环中的大量拼接操作，仍然会逐个动态分配内存（类似于两个两个 append 的概念），并不如手动使用 StringBuilder 来进行拼接效率高。这个改进是 JDK9 的 [JEP 280](https://openjdk.org/jeps/280) 提出的，关于这部分改进的详细介绍，推荐阅读这篇文章：还在无脑用 [StringBuilder？来重温一下字符串拼接吧](https://juejin.cn/post/7182872058743750715) 以及参考 [issue#2442](https://github.com/Snailclimb/JavaGuide/issues/2442)。
### String#equals() 和 Object#equals() 有何区别？
@@ -632,21 +694,26 @@ System.out.println(s);
**字符串常量池** 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。
```java
-// 在堆中创建字符串对象”ab“
-// 将字符串对象”ab“的引用保存在字符串常量池中
+// 在字符串常量池中创建字符串对象 ”ab“
+// 将字符串对象 ”ab“ 的引用赋值给 aa
String aa = "ab";
-// 直接返回字符串常量池中字符串对象”ab“的引用
+// 直接返回字符串常量池中字符串对象 ”ab“，赋值给引用 bb
String bb = "ab";
-System.out.println(aa==bb);// true
+System.out.println(aa==bb); // true
```
更多关于字符串常量池的介绍可以看一下 [Java 内存区域详解](https://javaguide.cn/java/jvm/memory-area.html) 这篇文章。
### String s1 = new String("abc");这句话创建了几个字符串对象？
-会创建 1 或 2 个字符串对象。
+先说答案：会创建 1 或 2 个字符串对象。
-1、如果字符串常量池中不存在字符串对象“abc”的引用，那么它会在堆上创建两个字符串对象，其中一个字符串对象的引用会被保存在字符串常量池中。
+1. 字符串常量池中不存在 "abc"：会创建 2 个 字符串对象。一个在字符串常量池中，由 `ldc` 指令触发创建。一个在堆中，由 `new String()` 创建，并使用常量池中的 "abc" 进行初始化。
+2. 字符串常量池中已存在 "abc"：会创建 1 个 字符串对象。该对象在堆中，由 `new String()` 创建，并使用常量池中的 "abc" 进行初始化。
+
+下面开始详细分析。
+
+1、如果字符串常量池中不存在字符串对象 “abc”，那么它首先会在字符串常量池中创建字符串对象 "abc"，然后在堆内存中再创建其中一个字符串对象 "abc"。
示例代码（JDK 1.8）：
@@ -656,16 +723,40 @@ String s1 = new String("abc");
对应的字节码：
-
+```java
+// 在堆内存中分配一个尚未初始化的 String 对象。
+// #2 是常量池中的一个符号引用，指向 java/lang/String 类。
+// 在类加载的解析阶段，这个符号引用会被解析成直接引用，即指向实际的 java/lang/String 类。
+0 new #2
+// 复制栈顶的 String 对象引用，为后续的构造函数调用做准备。
+// 此时操作数栈中有两个相同的对象引用：一个用于传递给构造函数，另一个用于保持对新对象的引用，后续将其存储到局部变量表。
+3 dup
+// JVM 先检查字符串常量池中是否存在 "abc"。
+// 如果常量池中已存在 "abc"，则直接返回该字符串的引用；
+// 如果常量池中不存在 "abc"，则 JVM 会在常量池中创建该字符串字面量并返回它的引用。
+// 这个引用被压入操作数栈，用作构造函数的参数。
+4 ldc #3
+// 调用构造方法，使用从常量池中加载的 "abc" 初始化堆中的 String 对象
+// 新的 String 对象将包含与常量池中的 "abc" 相同的内容，但它是一个独立的对象，存储于堆中。
+6 invokespecial #4 : (Ljava/lang/String;)V>
+// 将堆中的 String 对象引用存储到局部变量表
+9 astore_1
+// 返回，结束方法
+10 return
+```
+
+`ldc (load constant)` 指令的确是从常量池中加载各种类型的常量，包括字符串常量、整数常量、浮点数常量，甚至类引用等。对于字符串常量，`ldc` 指令的行为如下：
-`ldc` 命令用于判断字符串常量池中是否保存了对应的字符串对象的引用，如果保存了的话直接返回，如果没有保存的话，会在堆中创建对应的字符串对象并将该字符串对象的引用保存到字符串常量池中。
+1. **从常量池加载字符串**：`ldc` 首先检查字符串常量池中是否已经有内容相同的字符串对象。
+2. **复用已有字符串对象**：如果字符串常量池中已经存在内容相同的字符串对象，`ldc` 会将该对象的引用加载到操作数栈上。
+3. **没有则创建新对象并加入常量池**：如果字符串常量池中没有相同内容的字符串对象，JVM 会在常量池中创建一个新的字符串对象，并将其引用加载到操作数栈中。
-2、如果字符串常量池中已存在字符串对象“abc”的引用，则只会在堆中创建 1 个字符串对象“abc”。
+2、如果字符串常量池中已存在字符串对象“abc”，则只会在堆中创建 1 个字符串对象“abc”。
示例代码（JDK 1.8）：
```java
-// 字符串常量池中已存在字符串对象“abc”的引用
+// 字符串常量池中已存在字符串对象“abc”
String s1 = "abc";
// 下面这段代码只会在堆中创建 1 个字符串对象“abc”
String s2 = new String("abc");
@@ -673,35 +764,48 @@ String s2 = new String("abc");
对应的字节码：
-
+```java
+0 ldc #2
+2 astore_1
+3 new #3
+6 dup
+7 ldc #2
+9 invokespecial #4 : (Ljava/lang/String;)V>
+12 astore_2
+13 return
+```
这里就不对上面的字节码进行详细注释了，7 这个位置的 `ldc` 命令不会在堆中创建新的字符串对象“abc”，这是因为 0 这个位置已经执行了一次 `ldc` 命令，已经在堆中创建过一次字符串对象“abc”了。7 这个位置执行 `ldc` 命令会直接返回字符串常量池中字符串对象“abc”对应的引用。
### String#intern 方法有什么作用?
-`String.intern()` 是一个 native（本地）方法，其作用是将指定的字符串对象的引用保存在字符串常量池中，可以简单分为两种情况：
+`String.intern()` 是一个 `native` (本地) 方法，用来处理字符串常量池中的字符串对象引用。它的工作流程可以概括为以下两种情况：
+
+1. **常量池中已有相同内容的字符串对象**：如果字符串常量池中已经有一个与调用 `intern()` 方法的字符串内容相同的 `String` 对象，`intern()` 方法会直接返回常量池中该对象的引用。
+2. **常量池中没有相同内容的字符串对象**：如果字符串常量池中还没有一个与调用 `intern()` 方法的字符串内容相同的对象，`intern()` 方法会将当前字符串对象的引用添加到字符串常量池中，并返回该引用。
+
+总结：
-- 如果字符串常量池中保存了对应的字符串对象的引用，就直接返回该引用。
-- 如果字符串常量池中没有保存了对应的字符串对象的引用，那就在常量池中创建一个指向该字符串对象的引用并返回。
+- `intern()` 方法的主要作用是确保字符串引用在常量池中的唯一性。
+- 当调用 `intern()` 时，如果常量池中已经存在相同内容的字符串，则返回常量池中已有对象的引用；否则，将该字符串添加到常量池并返回其引用。
示例代码（JDK 1.8） :
```java
-// 在堆中创建字符串对象”Java“
-// 将字符串对象”Java“的引用保存在字符串常量池中
+// s1 指向字符串常量池中的 "Java" 对象
String s1 = "Java";
-// 直接返回字符串常量池中字符串对象”Java“对应的引用
+// s2 也指向字符串常量池中的 "Java" 对象，和 s1 是同一个对象
String s2 = s1.intern();
-// 会在堆中在单独创建一个字符串对象
+// 在堆中创建一个新的 "Java" 对象，s3 指向它
String s3 = new String("Java");
-// 直接返回字符串常量池中字符串对象”Java“对应的引用
+// s4 指向字符串常量池中的 "Java" 对象，和 s1 是同一个对象
String s4 = s3.intern();
-// s1 和 s2 指向的是堆中的同一个对象
+// s1 和 s2 指向的是同一个常量池中的对象
System.out.println(s1 == s2); // true
-// s3 和 s4 指向的是堆中不同的对象
+// s3 指向堆中的对象，s4 指向常量池中的对象，所以不同
System.out.println(s3 == s4); // false
-// s1 和 s4 指向的是堆中的同一个对象
-System.out.println(s1 == s4); //true
+// s1 和 s4 都指向常量池中的同一个对象
+System.out.println(s1 == s4); // true
```
### String 类型的变量和常量做“+”运算时发生了什么？
@@ -782,6 +886,7 @@ public static String getStr() {
## 参考
- 深入解析 String#intern：
+- Java String 源码解读：
diff --git a/docs/java/basis/java-basic-questions-03.md b/docs/java/basis/java-basic-questions-03.md
index f2afe2d8987..496e18827da 100644
--- a/docs/java/basis/java-basic-questions-03.md
+++ b/docs/java/basis/java-basic-questions-03.md
@@ -6,7 +6,7 @@ tag:
head:
- - meta
- name: keywords
- content: Java异常,泛型,反射,IO,注解
+ content: Java异常处理, Java泛型, Java反射, Java注解, Java SPI机制, Java序列化, Java反序列化, Java IO流, Java语法糖, Java基础面试题, Checked Exception, Unchecked Exception, try-with-resources, 反射应用场景, 序列化协议, BIO, NIO, AIO, IO模型
- - meta
- name: description
content: 全网质量最高的Java基础常见知识点和面试题总结，希望对你有帮助！
@@ -55,8 +55,8 @@ head:
### Throwable 类常用方法有哪些？
-- `String getMessage()`: 返回异常发生时的简要描述
-- `String toString()`: 返回异常发生时的详细信息
+- `String getMessage()`: 返回异常发生时的详细信息
+- `String toString()`: 返回异常发生时的简要描述
- `String getLocalizedMessage()`: 返回异常对象的本地化信息。使用 `Throwable` 的子类覆盖这个方法，可以生成本地化信息。如果子类没有覆盖该方法，则该方法返回的信息与 `getMessage()`返回的结果相同
- `void printStackTrace()`: 在控制台上打印 `Throwable` 对象封装的异常信息
@@ -89,14 +89,6 @@ Finally
**注意：不要在 finally 语句块中使用 return!** 当 try 语句和 finally 语句中都有 return 语句时，try 语句块中的 return 语句会被忽略。这是因为 try 语句中的 return 返回值会先被暂存在一个本地变量中，当执行到 finally 语句中的 return 之后，这个本地变量的值就变为了 finally 语句中的 return 返回值。
-[jvm 官方文档](https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.10.2.5)中有明确提到：
-
-> If the `try` clause executes a _return_, the compiled code does the following:
->
-> 1. Saves the return value (if any) in a local variable.
-> 2. Executes a _jsr_ to the code for the `finally` clause.
-> 3. Upon return from the `finally` clause, returns the value saved in the local variable.
-
代码示例：
```java
@@ -217,7 +209,7 @@ catch (IOException e) {
- 不要把异常定义为静态变量，因为这样会导致异常栈信息错乱。每次手动抛出异常，我们都需要手动 new 一个异常对象抛出。
- 抛出的异常信息一定要有意义。
-- 建议抛出更加具体的异常比如字符串转换为数字格式错误的时候应该抛出`NumberFormatException`而不是其父类`IllegalArgumentException`。
+- 建议抛出更加具体的异常，比如字符串转换为数字格式错误的时候应该抛出`NumberFormatException`而不是其父类`IllegalArgumentException`。
- 避免重复记录日志：如果在捕获异常的地方已经记录了足够的信息（包括异常类型、错误信息和堆栈跟踪等），那么在业务代码中再次抛出这个异常时，就不应该再次记录相同的错误信息。重复记录日志会使得日志文件膨胀，并且可能会掩盖问题的实际原因，使得问题更难以追踪和解决。
- ……
@@ -286,7 +278,7 @@ class GeneratorImpl implements Generator{
实现泛型接口，指定类型：
```java
-class GeneratorImpl implements Generator{
+class GeneratorImpl implements Generator {
@Override
public String method() {
return "hello";
@@ -329,52 +321,68 @@ printArray( stringArray );
关于反射的详细解读，请看这篇文章 [Java 反射机制详解](./reflection.md) 。
-### 何谓反射？
+### 什么是反射？
+
+简单来说，Java 反射 (Reflection) 是一种**在程序运行时，动态地获取类的信息并操作类或对象（方法、属性）的能力**。
+
+通常情况下，我们写的代码在编译时类型就已经确定了，要调用哪个方法、访问哪个字段都是明确的。但反射允许我们在**运行时**才去探知一个类有哪些方法、哪些属性、它的构造函数是怎样的，甚至可以动态地创建对象、调用方法或修改属性，哪怕这些方法或属性是私有的。
-如果说大家研究过框架的底层原理或者咱们自己写过框架的话，一定对反射这个概念不陌生。反射之所以被称为框架的灵魂，主要是因为它赋予了我们在运行时分析类以及执行类中方法的能力。通过反射你可以获取任意一个类的所有属性和方法，你还可以调用这些方法和属性。
+正是这种在运行时“反观自身”并进行操作的能力，使得反射成为许多**通用框架和库的基石**。它让代码更加灵活，能够处理在编译时未知的类型。
-### 反射的优缺点？
+### 反射有什么优缺点？
-反射可以让我们的代码更加灵活、为各种框架提供开箱即用的功能提供了便利。
+**优点：**
-不过，反射让我们在运行时有了分析操作类的能力的同时，也增加了安全问题，比如可以无视泛型参数的安全检查（泛型参数的安全检查发生在编译时）。另外，反射的性能也要稍差点，不过，对于框架来说实际是影响不大的。
+1. **灵活性和动态性**：反射允许程序在运行时动态地加载类、创建对象、调用方法和访问字段。这样可以根据实际需求（如配置文件、用户输入、注解等）动态地适应和扩展程序的行为，显著提高了系统的灵活性和适应性。
+2. **框架开发的基础**：许多现代 Java 框架（如 Spring、Hibernate、MyBatis）都大量使用反射来实现依赖注入（DI）、面向切面编程（AOP）、对象关系映射（ORM）、注解处理等核心功能。反射是实现这些“魔法”功能不可或缺的基础工具。
+3. **解耦合和通用性**：通过反射，可以编写更通用、可重用和高度解耦的代码，降低模块之间的依赖。例如，可以通过反射实现通用的对象拷贝、序列化、Bean 工具等。
+
+**缺点：**
+
+1. **性能开销**：反射操作通常比直接代码调用要慢。因为涉及到动态类型解析、方法查找以及 JIT 编译器的优化受限等因素。不过，对于大多数框架场景，这种性能损耗通常是可以接受的，或者框架本身会做一些缓存优化。
+2. **安全性问题**：反射可以绕过 Java 语言的访问控制机制（如访问 `private` 字段和方法），破坏了封装性，可能导致数据泄露或程序被恶意篡改。此外，还可以绕过泛型检查，带来类型安全隐患。
+3. **代码可读性和维护性**：过度使用反射会使代码变得复杂、难以理解和调试。错误通常在运行时才会暴露，不像编译期错误那样容易发现。
相关阅读：[Java Reflection: Why is it so slow?](https://stackoverflow.com/questions/1392351/java-reflection-why-is-it-so-slow) 。
### 反射的应用场景？
-像咱们平时大部分时候都是在写业务代码，很少会接触到直接使用反射机制的场景。但是！这并不代表反射没有用。相反，正是因为反射，你才能这么轻松地使用各种框架。像 Spring/Spring Boot、MyBatis 等等框架中都大量使用了反射机制。
+我们平时写业务代码可能很少直接跟 Java 的反射（Reflection）打交道。但你可能没意识到，你天天都在享受反射带来的便利！**很多流行的框架，比如 Spring/Spring Boot、MyBatis 等，底层都大量运用了反射机制**，这才让它们能够那么灵活和强大。
+
+下面简单列举几个最场景的场景帮助大家理解。
+
+**1.依赖注入与控制反转（IoC）**
-**这些框架中也大量使用了动态代理，而动态代理的实现也依赖反射。**
+以 Spring/Spring Boot 为代表的 IoC 框架，会在启动时扫描带有特定注解（如 `@Component`, `@Service`, `@Repository`, `@Controller`）的类，利用反射实例化对象（Bean），并通过反射注入依赖（如 `@Autowired`、构造器注入等）。
-比如下面是通过 JDK 实现动态代理的示例代码，其中就使用了反射类 `Method` 来调用指定的方法。
+**2.注解处理**
+
+注解本身只是个“标记”，得有人去读这个标记才知道要做什么。反射就是那个“读取器”。框架通过反射检查类、方法、字段上有没有特定的注解，然后根据注解信息执行相应的逻辑。比如，看到 `@Value`，就用反射读取注解内容，去配置文件找对应的值，再用反射把值设置给字段。
+
+**3.动态代理与 AOP**
+
+想在调用某个方法前后自动加点料（比如打日志、开事务、做权限检查）？AOP（面向切面编程）就是干这个的，而动态代理是实现 AOP 的常用手段。JDK 自带的动态代理（Proxy 和 InvocationHandler）就离不开反射。代理对象在内部调用真实对象的方法时，就是通过反射的 `Method.invoke` 来完成的。
```java
public class DebugInvocationHandler implements InvocationHandler {
- /**
- * 代理类中的真实对象
- */
- private final Object target;
+ private final Object target; // 真实对象
- public DebugInvocationHandler(Object target) {
- this.target = target;
- }
+ public DebugInvocationHandler(Object target) { this.target = target; }
- public Object invoke(Object proxy, Method method, Object[] args) throws InvocationTargetException, IllegalAccessException {
- System.out.println("before method " + method.getName());
+ // proxy: 代理对象, method: 被调用的方法, args: 方法参数
+ public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
+ System.out.println("切面逻辑：调用方法 " + method.getName() + " 之前");
+ // 通过反射调用真实对象的同名方法
Object result = method.invoke(target, args);
- System.out.println("after method " + method.getName());
+ System.out.println("切面逻辑：调用方法 " + method.getName() + " 之后");
return result;
}
}
-
```
-另外，像 Java 中的一大利器 **注解** 的实现也用到了反射。
-
-为什么你使用 Spring 的时候 ，一个`@Component`注解就声明了一个类为 Spring Bean 呢？为什么你通过一个 `@Value`注解就读取到配置文件中的值呢？究竟是怎么起作用的呢？
+**4.对象关系映射（ORM）**
-这些都是因为你可以基于反射分析类，然后获取到类/属性/方法/方法的参数上的注解。你获取到注解之后，就可以做进一步的处理。
+像 MyBatis、Hibernate 这种框架，能帮你把数据库查出来的一行行数据，自动变成一个个 Java 对象。它是怎么知道数据库字段对应哪个 Java 属性的？还是靠反射。它通过反射获取 Java 类的属性列表，然后把查询结果按名字或配置对应起来，再用反射调用 setter 或直接修改字段值。反过来，保存对象到数据库时，也是用反射读取属性值来拼 SQL。
## 注解
@@ -417,21 +425,20 @@ SPI 将服务接口和具体的服务实现分离开来，将服务调用方和
很多框架都使用了 Java 的 SPI 机制，比如：Spring 框架、数据库加载驱动、日志接口、以及 Dubbo 的扩展实现等等。
-
+ 这篇文章。
```java
diff --git a/docs/java/basis/serialization.md b/docs/java/basis/serialization.md
index 612eb40de5b..f6ab9071967 100644
--- a/docs/java/basis/serialization.md
+++ b/docs/java/basis/serialization.md
@@ -11,8 +11,8 @@ tag:
简单来说：
-- **序列化**：将数据结构或对象转换成二进制字节流的过程
-- **反序列化**：将在序列化过程中所生成的二进制字节流转换成数据结构或者对象的过程
+- **序列化**：将数据结构或对象转换成可以存储或传输的形式，通常是二进制字节流，也可以是 JSON, XML 等文本格式
+- **反序列化**：将在序列化过程中所生成的数据转换为原始数据结构或者对象的过程
对于 Java 这种面向对象编程语言来说，我们序列化的都是对象（Object）也就是实例化后的类(Class)，但是在 C++这种半面向对象的语言中，struct(结构体)定义的是数据结构类型，而 class 对应的是对象类型。
@@ -83,7 +83,11 @@ public class RpcRequest implements Serializable {
~~`static` 修饰的变量是静态变量，位于方法区，本身是不会被序列化的。 `static` 变量是属于类的而不是对象。你反序列之后，`static` 变量的值就像是默认赋予给了对象一样，看着就像是 `static` 变量被序列化，实际只是假象罢了。~~
-**🐛 修正（参见：[issue#2174](https://github.com/Snailclimb/JavaGuide/issues/2174)）**：`static` 修饰的变量是静态变量，位于方法区，本身是不会被序列化的。但是，`serialVersionUID` 的序列化做了特殊处理，在序列化时，会将 `serialVersionUID` 序列化到二进制字节流中；在反序列化时，也会解析它并做一致性判断。
+**🐛 修正（参见：[issue#2174](https://github.com/Snailclimb/JavaGuide/issues/2174)）**：
+
+通常情况下，`static` 变量是属于类的，不属于任何单个对象实例，所以它们本身不会被包含在对象序列化的数据流里。序列化保存的是对象的状态（也就是实例变量的值）。然而，`serialVersionUID` 是一个特例，`serialVersionUID` 的序列化做了特殊处理。关键在于，`serialVersionUID` 不是作为对象状态的一部分被序列化的，而是被序列化机制本身用作一个特殊的“指纹”或“版本号”。
+
+当一个对象被序列化时，`serialVersionUID` 会被写入到序列化的二进制流中（像是在保存一个版本号，而不是保存 `static` 变量本身的状态）；在反序列化时，也会解析它并做一致性判断，以此来验证序列化对象的版本一致性。如果两者不匹配，反序列化过程将抛出 `InvalidClassException`，因为这通常意味着序列化的类的定义已经发生了更改，可能不再兼容。
官方说明如下：
@@ -91,7 +95,7 @@ public class RpcRequest implements Serializable {
>
> 如果想显式指定 `serialVersionUID` ，则需要在类中使用 `static` 和 `final` 关键字来修饰一个 `long` 类型的变量，变量名字必须为 `"serialVersionUID"` 。
-也就是说，`serialVersionUID` 只是用来被 JVM 识别，实际并没有被序列化。
+也就是说，`serialVersionUID` 本身（作为 static 变量）确实不作为对象状态被序列化。但是，它的值被 Java 序列化机制特殊处理了——作为一个版本标识符被读取并写入序列化流中，用于在反序列化时进行版本兼容性检查。
**如果有些字段不想进行序列化怎么办？**
diff --git a/docs/java/basis/spi.md b/docs/java/basis/spi.md
index baada46fb95..a2a7bccb7d3 100644
--- a/docs/java/basis/spi.md
+++ b/docs/java/basis/spi.md
@@ -14,9 +14,9 @@ head:
> 本文来自 [Kingshion](https://github.com/jjx0708) 投稿。欢迎更多朋友参与到 JavaGuide 的维护工作，这是一件非常有意义的事情。详细信息请看：[JavaGuide 贡献指南](https://javaguide.cn/javaguide/contribution-guideline.html) 。
-在面向对象的设计原则中，一般推荐模块之间基于接口编程，通常情况下调用方模块是不会感知到被调用方模块的内部具体实现。一旦代码里面涉及具体实现类，就违反了开闭原则。如果需要替换一种实现，就需要修改代码。
+面向对象设计鼓励模块间基于接口而非具体实现编程，以降低模块间的耦合，遵循依赖倒置原则，并支持开闭原则（对扩展开放，对修改封闭）。然而，直接依赖具体实现会导致在替换实现时需要修改代码，违背了开闭原则。为了解决这个问题，SPI 应运而生，它提供了一种服务发现机制，允许在程序外部动态指定具体实现。这与控制反转（IoC）的思想相似，将组件装配的控制权移交给了程序之外。
-为了实现在模块装配的时候不用在程序里面动态指明，这就需要一种服务发现机制。Java SPI 就是提供了这样一个机制：**为某个接口寻找服务实现的机制。这有点类似 IoC 的思想，将装配的控制权移交到了程序之外。**
+SPI 机制也解决了 Java 类加载体系中双亲委派模型带来的限制。[双亲委派模型](https://javaguide.cn/java/jvm/classloader.html)虽然保证了核心库的安全性和一致性，但也限制了核心库或扩展库加载应用程序类路径上的类（通常由第三方实现）。SPI 允许核心或扩展库定义服务接口，第三方开发者提供并部署实现，SPI 服务加载机制则在运行时动态发现并加载这些实现。例如，JDBC 4.0 及之后版本利用 SPI 自动发现和加载数据库驱动，开发者只需将驱动 JAR 包放置在类路径下即可，无需使用`Class.forName()`显式加载驱动类。
## SPI 介绍
@@ -28,21 +28,20 @@ SPI 将服务接口和具体的服务实现分离开来，将服务调用方和
很多框架都使用了 Java 的 SPI 机制，比如：Spring 框架、数据库加载驱动、日志接口、以及 Dubbo 的扩展实现等等。
-
+ {
其实不难发现，SPI 机制的具体实现本质上还是通过反射完成的。即：**我们按照规定将要暴露对外使用的具体实现类在 `META-INF/services/` 文件下声明。**
-另外，SPI 机制在很多框架中都有应用：Spring 框架的基本原理也是类似的方式。还有 Dubbo 框架提供同样的 SPI 扩展机制，只不过 Dubbo 和 spring 框架中的 SPI 机制具体实现方式跟咱们今天学得这个有些细微的区别，不过整体的原理都是一致的，相信大家通过对 JDK 中 SPI 机制的学习，能够一通百通，加深对其他高深框的理解。
+另外，SPI 机制在很多框架中都有应用：Spring 框架的基本原理也是类似的方式。还有 Dubbo 框架提供同样的 SPI 扩展机制，只不过 Dubbo 和 spring 框架中的 SPI 机制具体实现方式跟咱们今天学得这个有些细微的区别，不过整体的原理都是一致的，相信大家通过对 JDK 中 SPI 机制的学习，能够一通百通，加深对其他高深框架的理解。
通过 SPI 机制能够大大地提高接口设计的灵活性，但是 SPI 机制也存在一些缺点，比如：
diff --git a/docs/java/basis/syntactic-sugar.md b/docs/java/basis/syntactic-sugar.md
index 64ffd4cde17..3ce9bfc1099 100644
--- a/docs/java/basis/syntactic-sugar.md
+++ b/docs/java/basis/syntactic-sugar.md
@@ -379,6 +379,83 @@ public class OutterClass
}
```
+**为什么内部类可以使用外部类的 private 属性**：
+
+我们在 InnerClass 中增加一个方法，打印外部类的 userName 属性
+
+```java
+//省略其他属性
+public class OutterClass {
+ private String userName;
+ ......
+ class InnerClass{
+ ......
+ public void printOut(){
+ System.out.println("Username from OutterClass:"+userName);
+ }
+ }
+}
+
+// 此时，使用javap -p命令对OutterClass反编译结果：
+public classOutterClass {
+ private String userName;
+ ......
+ static String access$000(OutterClass);
+}
+// 此时，InnerClass的反编译结果：
+class OutterClass$InnerClass {
+ final OutterClass this$0;
+ ......
+ public void printOut();
+}
+
+```
+
+实际上，在编译完成之后，inner 实例内部会有指向 outer 实例的引用`this$0`，但是简单的`outer.name`是无法访问 private 属性的。从反编译的结果可以看到，outer 中会有一个桥方法`static String access$000(OutterClass)`，恰好返回 String 类型，即 userName 属性。正是通过这个方法实现内部类访问外部类私有属性。所以反编译后的`printOut()`方法大致如下：
+
+```java
+public void printOut() {
+ System.out.println("Username from OutterClass:" + OutterClass.access$000(this.this$0));
+}
+```
+
+补充：
+
+1. 匿名内部类、局部内部类、静态内部类也是通过桥方法来获取 private 属性。
+2. 静态内部类没有`this$0`的引用
+3. 匿名内部类、局部内部类通过复制使用局部变量，该变量初始化之后就不能被修改。以下是一个案例：
+
+```java
+public class OutterClass {
+ private String userName;
+
+ public void test(){
+ //这里i初始化为1后就不能再被修改
+ int i=1;
+ class Inner{
+ public void printName(){
+ System.out.println(userName);
+ System.out.println(i);
+ }
+ }
+ }
+}
+```
+
+反编译后：
+
+```java
+//javap命令反编译Inner的结果
+//i被复制进内部类，且为final
+class OutterClass$1Inner {
+ final int val$i;
+ final OutterClass this$0;
+ OutterClass$1Inner();
+ public void printName();
+}
+
+```
+
### 条件编译
—般情况下，程序中的每一行代码都要参加编译。但有时候出于对程序代码优化的考虑，希望只对其中一部分内容进行编译，此时就需要在程序中加上条件，让编译器只对满足条件的代码进行编译，将不满足条件的代码舍弃，这就是条件编译。
@@ -423,7 +500,7 @@ public class ConditionalCompilation
首先，我们发现，在反编译后的代码中没有`System.out.println("Hello, ONLINE!");`，这其实就是条件编译。当`if(ONLINE)`为 false 的时候，编译器就没有对其内的代码进行编译。
-所以，**Java 语法的条件编译，是通过判断条件为常量的 if 语句实现的。其原理也是 Java 语言的语法糖。根据 if 判断条件的真假，编译器直接把分支为 false 的代码块消除。通过该方式实现的条件编译，必须在方法体内实现，而无法在正整个 Java 类的结构或者类的属性上进行条件编译，这与 C/C++的条件编译相比，确实更有局限性。在 Java 语言设计之初并没有引入条件编译的功能，虽有局限，但是总比没有更强。**
+所以，**Java 语法的条件编译，是通过判断条件为常量的 if 语句实现的。其原理也是 Java 语言的语法糖。根据 if 判断条件的真假，编译器直接把分支为 false 的代码块消除。通过该方式实现的条件编译，必须在方法体内实现，而无法在整个 Java 类的结构或者类的属性上进行条件编译，这与 C/C++的条件编译相比，确实更有局限性。在 Java 语言设计之初并没有引入条件编译的功能，虽有局限，但是总比没有更强。**
### 断言
diff --git a/docs/java/basis/unsafe.md b/docs/java/basis/unsafe.md
index 423707532d9..fff31af808c 100644
--- a/docs/java/basis/unsafe.md
+++ b/docs/java/basis/unsafe.md
@@ -10,6 +10,8 @@ tag:
> - [Java 魔法类：Unsafe 应用解析 - 美团技术团队 -2019](https://tech.meituan.com/2019/02/14/talk-about-java-magic-class-unsafe.html)
> - [Java 双刃剑之 Unsafe 类详解 - 码农参上 - 2021](https://xie.infoq.cn/article/8b6ed4195e475bfb32dacc5cb)
+
+
阅读过 JUC 源码的同学，一定会发现很多并发工具类都调用了一个叫做 `Unsafe` 的类。
那这个类主要是用来干什么的呢？有什么使用场景呢？这篇文章就带你搞清楚！
@@ -421,7 +423,7 @@ public void objTest() throws Exception{
#### 典型应用
-- **常规对象实例化方式**：我们通常所用到的创建对象的方式，从本质上来讲，都是通过 new 机制来实现对象的创建。但是，new 机制有个特点就是当类只提供有参的构造函数且无显示声明无参构造函数时，则必须使用有参构造函数进行对象构造，而使用有参构造函数时，必须传递相应个数的参数才能完成对象实例化。
+- **常规对象实例化方式**：我们通常所用到的创建对象的方式，从本质上来讲，都是通过 new 机制来实现对象的创建。但是，new 机制有个特点就是当类只提供有参的构造函数且无显式声明无参构造函数时，则必须使用有参构造函数进行对象构造，而使用有参构造函数时，必须传递相应个数的参数才能完成对象实例化。
- **非常规的实例化方式**：而 Unsafe 中提供 allocateInstance 方法，仅通过 Class 对象就可以创建此类的实例对象，而且不需要调用其构造函数、初始化代码、JVM 安全检查等。它抑制修饰符检测，也就是即使构造器是 private 修饰的也能通过此方法实例化，只需提类对象即可创建相应的对象。由于这种特性，allocateInstance 在 java.lang.invoke、Objenesis（提供绕过类构造器的对象生成方式）、Gson（反序列化时用到）中都有相应的应用。
### 数组操作
@@ -514,11 +516,94 @@ private void increment(int x){
1 2 3 4 5 6 7 8 9
```
-在上面的例子中，使用两个线程去修改`int`型属性`a`的值，并且只有在`a`的值等于传入的参数`x`减一时，才会将`a`的值变为`x`，也就是实现对`a`的加一的操作。流程如下所示：
+如果你把上面这段代码贴到 IDE 中运行，会发现并不能得到目标输出结果。有朋友已经在 Github 上指出了这个问题：[issue#2650](https://github.com/Snailclimb/JavaGuide/issues/2650)。下面是修正后的代码：
+
+```java
+private volatile int a = 0; // 共享变量，初始值为 0
+private static final Unsafe unsafe;
+private static final long fieldOffset;
+
+static {
+ try {
+ // 获取 Unsafe 实例
+ Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
+ theUnsafe.setAccessible(true);
+ unsafe = (Unsafe) theUnsafe.get(null);
+ // 获取 a 字段的内存偏移量
+ fieldOffset = unsafe.objectFieldOffset(CasTest.class.getDeclaredField("a"));
+ } catch (Exception e) {
+ throw new RuntimeException("Failed to initialize Unsafe or field offset", e);
+ }
+}
+
+public static void main(String[] args) {
+ CasTest casTest = new CasTest();
+
+ Thread t1 = new Thread(() -> {
+ for (int i = 1; i <= 4; i++) {
+ casTest.incrementAndPrint(i);
+ }
+ });
+
+ Thread t2 = new Thread(() -> {
+ for (int i = 5; i <= 9; i++) {
+ casTest.incrementAndPrint(i);
+ }
+ });
+
+ t1.start();
+ t2.start();
+
+ // 等待线程结束，以便观察完整输出 (可选，用于演示)
+ try {
+ t1.join();
+ t2.join();
+ } catch (InterruptedException e) {
+ Thread.currentThread().interrupt();
+ }
+}
+
+// 将递增和打印操作封装在一个原子性更强的方法内
+private void incrementAndPrint(int targetValue) {
+ while (true) {
+ int currentValue = a; // 读取当前 a 的值
+ // 只有当 a 的当前值等于目标值的前一个值时，才尝试更新
+ if (currentValue == targetValue - 1) {
+ if (unsafe.compareAndSwapInt(this, fieldOffset, currentValue, targetValue)) {
+ // CAS 成功，说明成功将 a 更新为 targetValue
+ System.out.print(targetValue + " ");
+ break; // 成功更新并打印后退出循环
+ }
+ // 如果 CAS 失败，意味着在读取 currentValue 和执行 CAS 之间，a 的值被其他线程修改了，
+ // 此时 currentValue 已经不是 a 的最新值，需要重新读取并重试。
+ }
+ // 如果 currentValue != targetValue - 1，说明还没轮到当前线程更新，
+ // 或者已经被其他线程更新超过了，让出CPU给其他线程机会。
+ // 对于严格顺序递增的场景，如果 current > targetValue - 1，可能意味着逻辑错误或死循环，
+ // 但在此示例中，我们期望线程能按顺序执行。
+ Thread.yield(); // 提示CPU调度器可以切换线程，减少无效自旋
+ }
+}
+```
+
+在上述例子中，我们创建了两个线程，它们都尝试修改共享变量 a。每个线程在调用 `incrementAndPrint(targetValue)` 方法时：
+
+1. 会先读取 a 的当前值 `currentValue`。
+2. 检查 `currentValue` 是否等于 `targetValue - 1` (即期望的前一个值)。
+3. 如果条件满足，则调用`unsafe.compareAndSwapInt()` 尝试将 `a` 从 `currentValue` 更新到 `targetValue`。
+4. 如果 CAS 操作成功（返回 true），则打印 `targetValue` 并退出循环。
+5. 如果 CAS 操作失败，或者 `currentValue` 不满足条件，则当前线程会继续循环（自旋），并通过 `Thread.yield()` 尝试让出 CPU，直到成功更新并打印或者条件满足。
+
+这种机制确保了每个数字（从 1 到 9）只会被成功设置并打印一次，并且是按顺序进行的。
-需要注意的是，在调用`compareAndSwapInt`方法后，会直接返回`true`或`false`的修改结果，因此需要我们在代码中手动添加自旋的逻辑。在`AtomicInteger`类的设计中，也是采用了将`compareAndSwapInt`的结果作为循环条件，直至修改成功才退出死循环的方式来实现的原子性的自增操作。
+需要注意的是：
+
+1. **自旋逻辑：** `compareAndSwapInt` 方法本身只执行一次比较和交换操作，并立即返回结果。因此，为了确保操作最终成功（在值符合预期的情况下），我们需要在代码中显式地实现自旋逻辑（如 `while(true)` 循环），不断尝试直到 CAS 操作成功。
+2. **`AtomicInteger` 的实现：** JDK 中的 `java.util.concurrent.atomic.AtomicInteger` 类内部正是利用了类似的 CAS 操作和自旋逻辑来实现其原子性的 `getAndIncrement()`, `compareAndSet()` 等方法。直接使用 `AtomicInteger` 通常是更安全、更推荐的做法，因为它封装了底层的复杂性。
+3. **ABA 问题：** CAS 操作本身存在 ABA 问题（一个值从 A 变为 B，再变回 A，CAS 检查时会认为值没有变过）。在某些场景下，如果值的变化历史很重要，可能需要使用 `AtomicStampedReference` 来解决。但在本例的简单递增场景中，ABA 问题通常不构成影响。
+4. **CPU 消耗：** 长时间的自旋会消耗 CPU 资源。在竞争激烈或条件长时间不满足的情况下，可以考虑加入更复杂的退避策略（如 `Thread.sleep()` 或 `LockSupport.parkNanos()`）来优化。
### 线程调度
diff --git a/docs/java/basis/why-there-only-value-passing-in-java.md b/docs/java/basis/why-there-only-value-passing-in-java.md
index 296a6ec9c60..dc329cd32b6 100644
--- a/docs/java/basis/why-there-only-value-passing-in-java.md
+++ b/docs/java/basis/why-there-only-value-passing-in-java.md
@@ -34,7 +34,7 @@ void sayHello(String str) {
- **值传递**：方法接收的是实参值的拷贝，会创建副本。
- **引用传递**：方法接收的直接是实参所引用的对象在堆中的地址，不会创建副本，对形参的修改将影响到实参。
-很多程序设计语言（比如 C++、 Pascal )提供了两种参数传递的方式，不过，在 Java 中只有值传递。
+很多程序设计语言（比如 C++、 Pascal）提供了两种参数传递的方式，不过，在 Java 中只有值传递。
## 为什么 Java 只有值传递？
diff --git a/docs/java/collection/arrayblockingqueue-source-code.md b/docs/java/collection/arrayblockingqueue-source-code.md
index 2eb9eb78455..4c923ef0d29 100644
--- a/docs/java/collection/arrayblockingqueue-source-code.md
+++ b/docs/java/collection/arrayblockingqueue-source-code.md
@@ -11,7 +11,7 @@ tag:
Java 阻塞队列的历史可以追溯到 JDK1.5 版本，当时 Java 平台增加了 `java.util.concurrent`，即我们常说的 JUC 包，其中包含了各种并发流程控制工具、并发容器、原子类等。这其中自然也包含了我们这篇文章所讨论的阻塞队列。
-为了解决高并发场景下多线程之间数据共享的问题，JDK1.5 版本中出现了 `ArrayBlockingQueue` 和 `LinkedBlockingQueue`，它们是带有生产者-消费者模式实现的并发容器。其中，`ArrayBlockingQueue` 是有界队列，即添加的元素达到上限之后，再次添加就会被阻塞或者抛出异常。而 `LinkedBlockingQueue` 则由链表构成的队列，正是因为链表的特性，所以 `LinkedBlockingQueue` 在添加元素上并不会向 `ArrayBlockingQueue` 那样有着较多的约束，所以 `LinkedBlockingQueue` 设置队列是否有界是可选的(注意这里的无界并不是指可以添加任务数量的元素，而是说队列的大小默认为 `Integer.MAX_VALUE`，近乎于无限大)。
+为了解决高并发场景下多线程之间数据共享的问题，JDK1.5 版本中出现了 `ArrayBlockingQueue` 和 `LinkedBlockingQueue`，它们是带有生产者-消费者模式实现的并发容器。其中，`ArrayBlockingQueue` 是有界队列，即添加的元素达到上限之后，再次添加就会被阻塞或者抛出异常。而 `LinkedBlockingQueue` 则由链表构成的队列，正是因为链表的特性，所以 `LinkedBlockingQueue` 在添加元素上并不会向 `ArrayBlockingQueue` 那样有着较多的约束，所以 `LinkedBlockingQueue` 设置队列是否有界是可选的(注意这里的无界并不是指可以添加任意数量的元素，而是说队列的大小默认为 `Integer.MAX_VALUE`，近乎于无限大)。
随着 Java 的不断发展，JDK 后续的几个版本又对阻塞队列进行了不少的更新和完善:
@@ -119,8 +119,8 @@ public class ProducerConsumerExample {
生产者添加元素：2
消费者取出元素：1
消费者取出元素：2
-消费者取出元素：3
生产者添加元素：3
+消费者取出元素：3
生产者添加元素：4
生产者添加元素：5
消费者取出元素：4
diff --git a/docs/java/collection/arraylist-source-code.md b/docs/java/collection/arraylist-source-code.md
index 762d64b2cec..5c71801b699 100644
--- a/docs/java/collection/arraylist-source-code.md
+++ b/docs/java/collection/arraylist-source-code.md
@@ -159,19 +159,22 @@ public class ArrayList extends AbstractList
* @param minCapacity 所需的最小容量
*/
public void ensureCapacity(int minCapacity) {
- //如果是true，minExpand的值为0，如果是false,minExpand的值为10
+ // 如果不是默认空数组，则minExpand的值为0；
+ // 如果是默认空数组，则minExpand的值为10
int minExpand = (elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA)
- // any size if not default element table
+ // 如果不是默认元素表，则可以使用任意大小
? 0
- // larger than default for default empty table. It's already
- // supposed to be at default size.
+ // 如果是默认空数组，它应该已经是默认大小
: DEFAULT_CAPACITY;
- //如果最小容量大于已有的最大容量
+
+ // 如果最小容量大于已有的最大容量
if (minCapacity > minExpand) {
+ // 根据需要的最小容量，确保容量足够
ensureExplicitCapacity(minCapacity);
}
}
+
// 根据给定的最小容量和当前数组元素来计算所需容量。
private static int calculateCapacity(Object[] elementData, int minCapacity) {
// 如果当前数组元素为空数组（初始情况），返回默认容量和最小容量中的较大值作为所需容量
@@ -305,8 +308,11 @@ public class ArrayList extends AbstractList
/**
* 以正确的顺序（从第一个到最后一个元素）返回一个包含此列表中所有元素的数组。
- * 返回的数组将是“安全的”，因为该列表不保留对它的引用。 （换句话说，这个方法必须分配一个新的数组）。
- * 因此，调用者可以自由地修改返回的数组。 此方法充当基于阵列和基于集合的API之间的桥梁。
+ * 返回的数组将是“安全的”，因为该列表不保留对它的引用。
+ * （换句话说，这个方法必须分配一个新的数组）。
+ * 因此，调用者可以自由地修改返回的数组结构。
+ * 注意：如果元素是引用类型，修改元素的内容会影响到原列表中的对象。
+ * 此方法充当基于数组和基于集合的API之间的桥梁。
*/
public Object[] toArray() {
return Arrays.copyOf(elementData, size);
@@ -426,8 +432,7 @@ public class ArrayList extends AbstractList
}
/*
- * Private remove method that skips bounds checking and does not
- * return the value removed.
+ * 该方法为私有的移除方法，跳过了边界检查，并且不返回被移除的值。
*/
private void fastRemove(int index) {
modCount++;
@@ -435,7 +440,7 @@ public class ArrayList extends AbstractList
if (numMoved > 0)
System.arraycopy(elementData, index + 1, elementData, index,
numMoved);
- elementData[--size] = null; // clear to let GC do its work
+ elementData[--size] = null; // 在移除元素后，将该位置的元素设为 null，以便垃圾回收器（GC）能够回收该元素。
}
/**
@@ -729,7 +734,7 @@ private void grow(int minCapacity) {
**我们再来通过例子探究一下`grow()` 方法：**
- 当 `add` 第 1 个元素时，`oldCapacity` 为 0，经比较后第一个 if 判断成立，`newCapacity = minCapacity`(为 10)。但是第二个 if 判断不会成立，即 `newCapacity` 不比 `MAX_ARRAY_SIZE` 大，则不会进入 `hugeCapacity` 方法。数组容量为 10，`add` 方法中 return true,size 增为 1。
-- 当 `add` 第 11 个元素进入 `grow` 方法时，`newCapacity` 为 15，比 `minCapacity`（为 11）大，第一个 if 判断不成立。新容量没有大于数组最大 size，不会进入 huge`C`apacity 方法。数组容量扩为 15，add 方法中 return true,size 增为 11。
+- 当 `add` 第 11 个元素进入 `grow` 方法时，`newCapacity` 为 15，比 `minCapacity`（为 11）大，第一个 if 判断不成立。新容量没有大于数组最大 size，不会进入 `hugeCapacity` 方法。数组容量扩为 15，add 方法中 return true,size 增为 11。
- 以此类推······
**这里补充一点比较重要，但是容易被忽视掉的知识点：**
diff --git a/docs/java/collection/concurrent-hash-map-source-code.md b/docs/java/collection/concurrent-hash-map-source-code.md
index 2422b36c8fe..d0d210aacdf 100644
--- a/docs/java/collection/concurrent-hash-map-source-code.md
+++ b/docs/java/collection/concurrent-hash-map-source-code.md
@@ -328,7 +328,7 @@ private void rehash(HashEntry node) {
HashEntry e = oldTable[i];
if (e != null) {
HashEntry next = e.next;
- // 计算新的位置，新的位置只可能是不便或者是老的位置+老的容量。
+ // 计算新的位置，新的位置只可能是不变或者是老的位置+老的容量。
int idx = e.hash & sizeMask;
if (next == null) // Single node on list
// 如果当前位置还不是链表，只是一个元素，直接赋值
@@ -337,7 +337,7 @@ private void rehash(HashEntry node) {
// 如果是链表了
HashEntry lastRun = e;
int lastIdx = idx;
- // 新的位置只可能是不便或者是老的位置+老的容量。
+ // 新的位置只可能是不变或者是老的位置+老的容量。
// 遍历结束后，lastRun 后面的元素位置都是相同的
for (HashEntry last = next; last != null; last = last.next) {
int k = last.hash & sizeMask;
@@ -368,7 +368,19 @@ private void rehash(HashEntry node) {
}
```
-有些同学可能会对最后的两个 for 循环有疑惑，这里第一个 for 是为了寻找这样一个节点，这个节点后面的所有 next 节点的新位置都是相同的。然后把这个作为一个链表赋值到新位置。第二个 for 循环是为了把剩余的元素通过头插法插入到指定位置链表。这样实现的原因可能是基于概率统计，有深入研究的同学可以发表下意见。
+有些同学可能会对最后的两个 for 循环有疑惑，这里第一个 for 是为了寻找这样一个节点，这个节点后面的所有 next 节点的新位置都是相同的。然后把这个作为一个链表赋值到新位置。第二个 for 循环是为了把剩余的元素通过头插法插入到指定位置链表。~~这样实现的原因可能是基于概率统计，有深入研究的同学可以发表下意见。~~
+
+内部第二个 `for` 循环中使用了 `new HashEntry(h, p.key, v, n)` 创建了一个新的 `HashEntry`，而不是复用之前的，是因为如果复用之前的，那么会导致正在遍历（如正在执行 `get` 方法）的线程由于指针的修改无法遍历下去。正如注释中所说的：
+
+> 当它们不再被可能正在并发遍历表的任何读取线程引用时，被替换的节点将被垃圾回收。
+>
+> The nodes they replace will be garbage collectable as soon as they are no longer referenced by any reader thread that may be in the midst of concurrently traversing table
+
+为什么需要再使用一个 `for` 循环找到 `lastRun` ，其实是为了减少对象创建的次数，正如注解中所说的：
+
+> 从统计上看，在默认的阈值下，当表容量加倍时，只有大约六分之一的节点需要被克隆。
+>
+> Statistically, at the default threshold, only about one-sixth of them need cloning when a table doubles.
### 5. get
diff --git a/docs/java/collection/hashmap-source-code.md b/docs/java/collection/hashmap-source-code.md
index a4f92b8a38e..0e9342f0edf 100644
--- a/docs/java/collection/hashmap-source-code.md
+++ b/docs/java/collection/hashmap-source-code.md
@@ -90,7 +90,7 @@ public class HashMap extends AbstractMap implements Map, Cloneabl
static final int MIN_TREEIFY_CAPACITY = 64;
// 存储元素的数组，总是2的幂次倍
transient Node[] table;
- // 存放具体元素的集
+ // 一个包含了映射中所有键值对的集合视图
transient Set> entrySet;
// 存放元素的个数，注意这个不等于数组的长度。
transient int size;
diff --git a/docs/java/collection/java-collection-precautions-for-use.md b/docs/java/collection/java-collection-precautions-for-use.md
index e636ff5a77a..9bd3a4084d5 100644
--- a/docs/java/collection/java-collection-precautions-for-use.md
+++ b/docs/java/collection/java-collection-precautions-for-use.md
@@ -15,35 +15,58 @@ tag:
> **判断所有集合内部的元素是否为空，使用 `isEmpty()` 方法，而不是 `size()==0` 的方式。**
-这是因为 `isEmpty()` 方法的可读性更好，并且时间复杂度为 O(1)。
+这是因为 `isEmpty()` 方法的可读性更好，并且时间复杂度为 `O(1)`。
-绝大部分我们使用的集合的 `size()` 方法的时间复杂度也是 O(1)，不过，也有很多复杂度不是 O(1) 的，比如 `java.util.concurrent` 包下的某些集合（`ConcurrentLinkedQueue`、`ConcurrentHashMap`...）。
+绝大部分我们使用的集合的 `size()` 方法的时间复杂度也是 `O(1)`，不过，也有很多复杂度不是 `O(1)` 的，比如 `java.util.concurrent` 包下的 `ConcurrentLinkedQueue`。`ConcurrentLinkedQueue` 的 `isEmpty()` 方法通过 `first()` 方法进行判断，其中 `first()` 方法返回的是队列中第一个值不为 `null` 的节点（节点值为`null`的原因是在迭代器中使用的逻辑删除）
-下面是 `ConcurrentHashMap` 的 `size()` 方法和 `isEmpty()` 方法的源码。
+```java
+public boolean isEmpty() { return first() == null; }
+
+Node first() {
+ restartFromHead:
+ for (;;) {
+ for (Node h = head, p = h, q;;) {
+ boolean hasItem = (p.item != null);
+ if (hasItem || (q = p.next) == null) { // 当前节点值不为空 或 到达队尾
+ updateHead(h, p); // 将head设置为p
+ return hasItem ? p : null;
+ }
+ else if (p == q) continue restartFromHead;
+ else p = q; // p = p.next
+ }
+ }
+}
+```
+
+由于在插入与删除元素时，都会执行`updateHead(h, p)`方法，所以该方法的执行的时间复杂度可以近似为`O(1)`。而 `size()` 方法需要遍历整个链表，时间复杂度为`O(n)`
```java
public int size() {
- long n = sumCount();
- return ((n < 0L) ? 0 :
- (n > (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE :
- (int)n);
+ int count = 0;
+ for (Node p = first(); p != null; p = succ(p))
+ if (p.item != null)
+ if (++count == Integer.MAX_VALUE)
+ break;
+ return count;
}
+```
+
+此外，在`ConcurrentHashMap` 1.7 中 `size()` 方法和 `isEmpty()` 方法的时间复杂度也不太一样。`ConcurrentHashMap` 1.7 将元素数量存储在每个`Segment` 中，`size()` 方法需要统计每个 `Segment` 的数量，而 `isEmpty()` 只需要找到第一个不为空的 `Segment` 即可。但是在`ConcurrentHashMap` 1.8 中的 `size()` 方法和 `isEmpty()` 都需要调用 `sumCount()` 方法，其时间复杂度与 `Node` 数组的大小有关。下面是 `sumCount()` 方法的源码：
+
+```java
final long sumCount() {
CounterCell[] as = counterCells; CounterCell a;
long sum = baseCount;
- if (as != null) {
- for (int i = 0; i < as.length; ++i) {
+ if (as != null)
+ for (int i = 0; i < as.length; ++i)
if ((a = as[i]) != null)
sum += a.value;
- }
- }
return sum;
}
-public boolean isEmpty() {
- return sumCount() <= 0L; // ignore transient negative values
-}
```
+这是因为在并发的环境下，`ConcurrentHashMap` 将每个 `Node` 中节点的数量存储在 `CounterCell[]` 数组中。在 `ConcurrentHashMap` 1.7 中，将元素数量存储在每个`Segment` 中，`size()` 方法需要统计每个 `Segment` 的数量，而 `isEmpty()` 只需要找到第一个不为空的 `Segment` 即可。
+
## 集合转 Map
《阿里巴巴 Java 开发手册》的描述如下：
@@ -111,6 +134,7 @@ public static T requireNonNull(T obj) {
return obj;
}
```
+> `Collectors`也提供了无需mergeFunction的`toMap()`方法，但此时若出现key冲突，则会抛出`duplicateKeyException`异常，因此强烈建议使用`toMap()`方法必填mergeFunction。
## 集合遍历
diff --git a/docs/java/collection/java-collection-questions-01.md b/docs/java/collection/java-collection-questions-01.md
index aedc4d35d12..417a2d10f53 100644
--- a/docs/java/collection/java-collection-questions-01.md
+++ b/docs/java/collection/java-collection-questions-01.md
@@ -14,11 +14,13 @@ head:
+
+
## 集合概述
### Java 集合概览
-Java 集合，也叫作容器，主要是由两大接口派生而来：一个是 `Collection`接口，主要用于存放单一元素；另一个是 `Map` 接口，主要用于存放键值对。对于`Collection` 接口，下面又有三个主要的子接口：`List`、`Set` 、 `Queue`、`Map`。
+Java 集合，也叫作容器，主要是由两大接口派生而来：一个是 `Collection`接口，主要用于存放单一元素；另一个是 `Map` 接口，主要用于存放键值对。对于`Collection` 接口，下面又有三个主要的子接口：`List`、`Set` 、 `Queue`。
Java 集合框架如下图所示：
@@ -190,7 +192,7 @@ System.out.println(listOfStrings);
- 头部插入/删除：只需要修改头结点的指针即可完成插入/删除操作，因此时间复杂度为 O(1)。
- 尾部插入/删除：只需要修改尾结点的指针即可完成插入/删除操作，因此时间复杂度为 O(1)。
-- 指定位置插入/删除：需要先移动到指定位置，再修改指定节点的指针完成插入/删除，因此需要移动平均 n/2 个元素，时间复杂度为 O(n)。
+- 指定位置插入/删除：需要先移动到指定位置，再修改指定节点的指针完成插入/删除，不过由于有头尾指针，可以从较近的指针出发，因此需要遍历平均 n/4 个元素，时间复杂度为 O(n)。
这里简单列举一个例子：假如我们要删除节点 9 的话，需要先遍历链表找到该节点。然后，再执行相应节点指针指向的更改，具体的源码可以参考：[LinkedList 源码分析](./linkedlist-source-code.md) 。
@@ -253,6 +255,102 @@ public interface RandomAccess {
详见笔主的这篇文章: [ArrayList 扩容机制分析](https://javaguide.cn/java/collection/arraylist-source-code.html#_3-1-%E5%85%88%E4%BB%8E-arraylist-%E7%9A%84%E6%9E%84%E9%80%A0%E5%87%BD%E6%95%B0%E8%AF%B4%E8%B5%B7)。
+### 说说集合中的 fail-fast 和 fail-safe 是什么
+
+关于`fail-fast`引用`medium`中一篇文章关于`fail-fast`和`fail-safe`的说法：
+
+> Fail-fast systems are designed to immediately stop functioning upon encountering an unexpected condition. This immediate failure helps to catch errors early, making debugging more straightforward.
+
+快速失败的思想即针对可能发生的异常进行提前表明故障并停止运行，通过尽早的发现和停止错误，降低故障系统级联的风险。
+
+在`java.util`包下的大部分集合是不支持线程安全的，为了能够提前发现并发操作导致线程安全风险，提出通过维护一个`modCount`记录修改的次数，迭代期间通过比对预期修改次数`expectedModCount`和`modCount`是否一致来判断是否存在并发操作，从而实现快速失败，由此保证在避免在异常时执行非必要的复杂代码。
+
+对应的我们给出下面这样一段在示例，我们首先插入`100`个操作元素，一个线程迭代元素，一个线程删除元素，最终输出结果如愿抛出`ConcurrentModificationException`：
+
+```java
+// 使用线程安全的 CopyOnWriteArrayList 避免 ConcurrentModificationException
+List list = new CopyOnWriteArrayList<>();
+CountDownLatch countDownLatch = new CountDownLatch(2);
+
+// 添加元素
+for (int i = 0; i < 100; i++) {
+ list.add(i);
+}
+
+Thread t1 = new Thread(() -> {
+ // 迭代元素 (注意：Integer 是不可变的，这里的 i++ 不会修改 list 中的值)
+ for (Integer i : list) {
+ i++; // 这行代码实际上没有修改list中的元素
+ }
+ countDownLatch.countDown();
+});
+
+Thread t2 = new Thread(() -> {
+ System.out.println("删除元素1");
+ list.remove(Integer.valueOf(1)); // 使用 Integer.valueOf(1) 删除指定值的对象
+ countDownLatch.countDown();
+});
+
+t1.start();
+t2.start();
+countDownLatch.await();
+```
+
+我们在初始化时插入了`100`个元素，此时对应的修改`modCount`次数为`100`，随后线程 2 在线程 1 迭代期间进行元素删除操作，此时对应的`modCount`就变为`101`。
+线程 1 在随后`foreach`第 2 轮循环发现`modCount` 为`101`，与预期的`expectedModCount(值为100因为初始化插入了元素100个)`不等，判定为并发操作异常，于是便快速失败，抛出`ConcurrentModificationException`：
+
+
+
+对此我们也给出`for`循环底层迭代器获取下一个元素时的`next`方法，可以看到其内部的`checkForComodification`具有针对修改次数比对的逻辑：
+
+```java
+ public E next() {
+ //检查是否存在并发修改
+ checkForComodification();
+ //......
+ //返回下一个元素
+ return (E) elementData[lastRet = i];
+ }
+
+final void checkForComodification() {
+ //当前循环遍历次数和预期修改次数不一致时，就会抛出ConcurrentModificationException
+ if (modCount != expectedModCount)
+ throw new ConcurrentModificationException();
+ }
+
+```
+
+而`fail-safe`也就是安全失败的含义，它旨在即使面对意外情况也能恢复并继续运行，这使得它特别适用于不确定或者不稳定的环境：
+
+> Fail-safe systems take a different approach, aiming to recover and continue even in the face of unexpected conditions. This makes them particularly suited for uncertain or volatile environments.
+
+该思想常运用于并发容器，最经典的实现就是`CopyOnWriteArrayList`的实现，通过写时复制的思想保证在进行修改操作时复制出一份快照，基于这份快照完成添加或者删除操作后，将`CopyOnWriteArrayList`底层的数组引用指向这个新的数组空间，由此避免迭代时被并发修改所干扰所导致并发操作安全问题，当然这种做法也存缺点即进行遍历操作时无法获得实时结果：
+
+
+
+对应我们也给出`CopyOnWriteArrayList`实现`fail-safe`的核心代码，可以看到它的实现就是通过`getArray`获取数组引用然后通过`Arrays.copyOf`得到一个数组的快照，基于这个快照完成添加操作后，修改底层`array`变量指向的引用地址由此完成写时复制：
+
+```java
+public boolean add(E e) {
+ final ReentrantLock lock = this.lock;
+ lock.lock();
+ try {
+ //获取原有数组
+ Object[] elements = getArray();
+ int len = elements.length;
+ //基于原有数组复制出一份内存快照
+ Object[] newElements = Arrays.copyOf(elements, len + 1);
+ //进行添加操作
+ newElements[len] = e;
+ //array指向新的数组
+ setArray(newElements);
+ return true;
+ } finally {
+ lock.unlock();
+ }
+ }
+```
+
## Set
### Comparable 和 Comparator 的区别
diff --git a/docs/java/collection/java-collection-questions-02.md b/docs/java/collection/java-collection-questions-02.md
index 3dba082aee5..94eafcf9825 100644
--- a/docs/java/collection/java-collection-questions-02.md
+++ b/docs/java/collection/java-collection-questions-02.md
@@ -23,6 +23,7 @@ head:
- **对 Null key 和 Null value 的支持：** `HashMap` 可以存储 null 的 key 和 value，但 null 作为键只能有一个，null 作为值可以有多个；Hashtable 不允许有 null 键和 null 值，否则会抛出 `NullPointerException`。
- **初始容量大小和每次扩充容量大小的不同：** ① 创建时如果不指定容量初始值，`Hashtable` 默认的初始大小为 11，之后每次扩充，容量变为原来的 2n+1。`HashMap` 默认的初始化大小为 16。之后每次扩充，容量变为原来的 2 倍。② 创建时如果给定了容量初始值，那么 `Hashtable` 会直接使用你给定的大小，而 `HashMap` 会将其扩充为 2 的幂次方大小（`HashMap` 中的`tableSizeFor()`方法保证，下面给出了源代码）。也就是说 `HashMap` 总是使用 2 的幂作为哈希表的大小,后面会介绍到为什么是 2 的幂次方。
- **底层数据结构：** JDK1.8 以后的 `HashMap` 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）时，将链表转化为红黑树（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树），以减少搜索时间（后文中我会结合源码对这一过程进行分析）。`Hashtable` 没有这样的机制。
+- **哈希函数的实现**：`HashMap` 对哈希值进行了高位和低位的混合扰动处理以减少冲突，而 `Hashtable` 直接使用键的 `hashCode()` 值。
**`HashMap` 中带有初始容量的构造函数：**
@@ -47,18 +48,18 @@ head:
下面这个方法保证了 `HashMap` 总是使用 2 的幂作为哈希表的大小。
```java
- /**
- * Returns a power of two size for the given target capacity.
- */
- static final int tableSizeFor(int cap) {
- int n = cap - 1;
- n |= n >>> 1;
- n |= n >>> 2;
- n |= n >>> 4;
- n |= n >>> 8;
- n |= n >>> 16;
- return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
- }
+/**
+ * Returns a power of two size for the given target capacity.
+ */
+static final int tableSizeFor(int cap) {
+ int n = cap - 1;
+ n |= n >>> 1;
+ n |= n >>> 2;
+ n |= n >>> 4;
+ n |= n >>> 8;
+ n |= n >>> 16;
+ return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
+}
```
### HashMap 和 HashSet 区别
@@ -82,7 +83,7 @@ head:
`NavigableMap` 接口提供了丰富的方法来探索和操作键值对:
-1. **定向搜索**: `ceilingEntry()`, `floorEntry()`, `higherEntry()`和 `lowerEntry()` 等方法可以用于定位大于、小于、大于等于、小于等于给定键的最接近的键值对。
+1. **定向搜索**: `ceilingEntry()`, `floorEntry()`, `higherEntry()`和 `lowerEntry()` 等方法可以用于定位大于等于、小于等于、严格大于、严格小于给定键的最接近的键值对。
2. **子集操作**: `subMap()`, `headMap()`和 `tailMap()` 方法可以高效地创建原集合的子集视图，而无需复制整个集合。
3. **逆序视图**:`descendingMap()` 方法返回一个逆序的 `NavigableMap` 视图，使得可以反向迭代整个 `TreeMap`。
4. **边界操作**: `firstEntry()`, `lastEntry()`, `pollFirstEntry()`和 `pollLastEntry()` 等方法可以方便地访问和移除元素。
@@ -184,7 +185,7 @@ final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
JDK1.8 之前 `HashMap` 底层是 **数组和链表** 结合在一起使用也就是 **链表散列**。HashMap 通过 key 的 `hashcode` 经过扰动函数处理过后得到 hash 值，然后通过 `(n - 1) & hash` 判断当前元素存放的位置（这里的 n 指的是数组的长度），如果当前位置存在元素的话，就判断该元素与要存入的元素的 hash 值以及 key 是否相同，如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。
-所谓扰动函数指的就是 HashMap 的 `hash` 方法。使用 `hash` 方法也就是扰动函数是为了防止一些实现比较差的 `hashCode()` 方法 换句话说使用扰动函数之后可以减少碰撞。
+`HashMap` 中的扰动函数（`hash` 方法）是用来优化哈希值的分布。通过对原始的 `hashCode()` 进行额外处理，扰动函数可以减小由于糟糕的 `hashCode()` 实现导致的碰撞，从而提高数据的分布均匀性。
**JDK 1.8 HashMap 的 hash 方法源码:**
@@ -221,10 +222,23 @@ static int hash(int h) {
#### JDK1.8 之后
-相比于之前的版本， JDK1.8 之后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。
+相比于之前的版本， JDK1.8 之后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树。
+
+这样做的目的是减少搜索时间：链表的查询效率为 O(n)（n 是链表的长度），红黑树是一种自平衡二叉搜索树，其查询效率为 O(log n)。当链表较短时，O(n) 和 O(log n) 的性能差异不明显。但当链表变长时，查询性能会显著下降。
+**为什么优先扩容而非直接转为红黑树？**
+
+数组扩容能减少哈希冲突的发生概率（即将元素重新分散到新的、更大的数组中），这在多数情况下比直接转换为红黑树更高效。
+
+红黑树需要保持自平衡，维护成本较高。并且，过早引入红黑树反而会增加复杂度。
+
+**为什么选择阈值 8 和 64？**
+
+1. 泊松分布表明，链表长度达到 8 的概率极低（小于千万分之一）。在绝大多数情况下，链表长度都不会超过 8。阈值设置为 8，可以保证性能和空间效率的平衡。
+2. 数组长度阈值 64 同样是经过实践验证的经验值。在小数组中扩容成本低，优先扩容可以避免过早引入红黑树。数组大小达到 64 时，冲突概率较高，此时红黑树的性能优势开始显现。
+
> TreeMap、TreeSet 以及 JDK1.8 之后的 HashMap 底层都用到了红黑树。红黑树就是为了解决二叉查找树的缺陷，因为二叉查找树在某些情况下会退化成一个线性结构。
我们来结合源码分析一下 `HashMap` 链表到红黑树的转换。
@@ -239,7 +253,7 @@ for (int binCount = 0; ; ++binCount) {
// 遍历到链表最后一个节点
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null);
- // 如果链表元素个数大于等于TREEIFY_THRESHOLD（8）
+ // 如果链表元素个数大于TREEIFY_THRESHOLD（8）
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
// 红黑树转换（并不会直接转换成红黑树）
treeifyBin(tab, hash);
@@ -285,11 +299,55 @@ final void treeifyBin(Node[] tab, int hash) {
### HashMap 的长度为什么是 2 的幂次方
-为了能让 HashMap 存取高效，尽量较少碰撞，也就是要尽量把数据分配均匀。我们上面也讲到了过了，Hash 值的范围值-2147483648 到 2147483647，前后加起来大概 40 亿的映射空间，只要哈希函数映射得比较均匀松散，一般应用是很难出现碰撞的。但问题是一个 40 亿长度的数组，内存是放不下的。所以这个散列值是不能直接拿来用的。用之前还要先做对数组的长度取模运算，得到的余数才能用来要存放的位置也就是对应的数组下标。这个数组下标的计算方法是“ `(n - 1) & hash`”。（n 代表数组长度）。这也就解释了 HashMap 的长度为什么是 2 的幂次方。
+为了让 `HashMap` 存取高效并减少碰撞，我们需要确保数据尽量均匀分布。哈希值在 Java 中通常使用 `int` 表示，其范围是 `-2147483648 ~ 2147483647`前后加起来大概 40 亿的映射空间，只要哈希函数映射得比较均匀松散，一般应用是很难出现碰撞的。但是，问题是一个 40 亿长度的数组，内存是放不下的。所以，这个散列值是不能直接拿来用的。用之前还要先做对数组的长度取模运算，得到的余数才能用来要存放的位置也就是对应的数组下标。
**这个算法应该如何设计呢？**
-我们首先可能会想到采用%取余的操作来实现。但是，重点来了：**“取余(%)操作中如果除数是 2 的幂次则等价于与其除数减一的与(&)操作（也就是说 hash%length==hash&(length-1)的前提是 length 是 2 的 n 次方；）。”** 并且 **采用二进制位操作 &，相对于%能够提高运算效率，这就解释了 HashMap 的长度为什么是 2 的幂次方。**
+我们首先可能会想到采用 % 取余的操作来实现。但是，重点来了：“**取余(%)操作中如果除数是 2 的幂次则等价于与其除数减一的与(&)操作**（也就是说 `hash%length==hash&(length-1)` 的前提是 length 是 2 的 n 次方）。” 并且，**采用二进制位操作 & 相对于 % 能够提高运算效率**。
+
+除了上面所说的位运算比取余效率高之外，我觉得更重要的一个原因是：**长度是 2 的幂次方，可以让 `HashMap` 在扩容的时候更均匀**。例如:
+
+- length = 8 时，length - 1 = 7 的二进制位`0111`
+- length = 16 时，length - 1 = 15 的二进制位`1111`
+
+这时候原本存在 `HashMap` 中的元素计算新的数组位置时 `hash&(length-1)`，取决 hash 的第四个二进制位（从右数），会出现两种情况：
+
+1. 第四个二进制位为 0，数组位置不变，也就是说当前元素在新数组和旧数组的位置相同。
+2. 第四个二进制位为 1，数组位置在新数组扩容之后的那一部分。
+
+这里列举一个例子：
+
+```plain
+假设有一个元素的哈希值为 10101100
+
+旧数组元素位置计算：
+hash = 10101100
+length - 1 = 00000111
+& -----------------
+index = 00000100 (4)
+
+新数组元素位置计算：
+hash = 10101100
+length - 1 = 00001111
+& -----------------
+index = 00001100 (12)
+
+看第四位（从右数）：
+1.高位为 0：位置不变。
+2.高位为 1：移动到新位置（原索引位置+原容量）。
+```
+
+⚠️注意：这里列举的场景看的是第四个二进制位，更准确点来说看的是高位（从右数），例如 `length = 32` 时，`length - 1 = 31`，二进制为 `11111`，这里看的就是第五个二进制位。
+
+也就是说扩容之后，在旧数组元素 hash 值比较均匀（至于 hash 值均不均匀，取决于前面讲的对象的 `hashcode()` 方法和扰动函数）的情况下，新数组元素也会被分配的比较均匀，最好的情况是会有一半在新数组的前半部分，一半在新数组后半部分。
+
+这样也使得扩容机制变得简单和高效，扩容后只需检查哈希值高位的变化来决定元素的新位置，要么位置不变（高位为 0），要么就是移动到新位置（高位为 1，原索引位置+原容量）。
+
+最后，简单总结一下 `HashMap` 的长度是 2 的幂次方的原因：
+
+1. 位运算效率更高：位运算(&)比取余运算(%)更高效。当长度为 2 的幂次方时，`hash % length` 等价于 `hash & (length - 1)`。
+2. 可以更好地保证哈希值的均匀分布：扩容之后，在旧数组元素 hash 值比较均匀的情况下，新数组元素也会被分配的比较均匀，最好的情况是会有一半在新数组的前半部分，一半在新数组后半部分。
+3. 扩容机制变得简单和高效：扩容后只需检查哈希值高位的变化来决定元素的新位置，要么位置不变（高位为 0），要么就是移动到新位置（高位为 1，原索引位置+原容量）。
### HashMap 多线程操作导致死循环问题
diff --git a/docs/java/collection/linkedhashmap-source-code.md b/docs/java/collection/linkedhashmap-source-code.md
index 47904004114..08c9a2bcb28 100644
--- a/docs/java/collection/linkedhashmap-source-code.md
+++ b/docs/java/collection/linkedhashmap-source-code.md
@@ -258,7 +258,7 @@ public V get(Object key) {
```java
void afterNodeAccess(Node < K, V > e) { // move node to last
LinkedHashMap.Entry < K, V > last;
- //如果accessOrder 且当前节点不未链表尾节点
+ //如果accessOrder 且当前节点不为链表尾节点
if (accessOrder && (last = tail) != e) {
//获取当前节点、以及前驱节点和后继节点
@@ -272,7 +272,7 @@ void afterNodeAccess(Node < K, V > e) { // move node to last
if (b == null)
head = a;
else
- //如果后继节点不为空，则让前驱节点指向后继节点
+ //如果前驱节点不为空，则让前驱节点指向后继节点
b.after = a;
//如果后继节点不为空，则让后继节点指向前驱节点
@@ -372,10 +372,10 @@ void afterNodeRemoval(Node e) { // unlink
从源码可以看出， `afterNodeRemoval` 方法的整体操作就是让当前节点 p 和前驱节点、后继节点断开联系，等待 gc 回收，整体步骤为:
-1. 获取当前节点 p、以及 e 的前驱节点 b 和后继节点 a。
+1. 获取当前节点 p、以及 p 的前驱节点 b 和后继节点 a。
2. 让当前节点 p 和其前驱、后继节点断开联系。
3. 尝试让前驱节点 b 指向后继节点 a，若 b 为空则说明当前节点 p 在链表首部，我们直接将 head 指向后继节点 a 即可。
-4. 尝试让后继节点 a 指向前驱节点 b，若 a 为空则说明当前节点 p 在链表末端，所以直接让 tail 指针指向前驱节点 a 即可。
+4. 尝试让后继节点 a 指向前驱节点 b，若 a 为空则说明当前节点 p 在链表末端，所以直接让 tail 指针指向前驱节点 b 即可。
可以结合这张图理解，展示了 key 为 13 的元素被删除，也就是从链表中移除了这个元素。
@@ -454,7 +454,7 @@ void afterNodeInsertion(boolean evict) { // possibly remove eldest
## LinkedHashMap 和 HashMap 遍历性能比较
-`LinkedHashMap` 维护了一个双向链表来记录数据插入的顺序，因此在迭代遍历生成的迭代器的时候，是按照双向链表的路径进行遍历的。这一点相比于 `HashMap` 那种遍历整个 bucket 的方式来说，高效需多。
+`LinkedHashMap` 维护了一个双向链表来记录数据插入的顺序，因此在迭代遍历生成的迭代器的时候，是按照双向链表的路径进行遍历的。这一点相比于 `HashMap` 那种遍历整个 bucket 的方式来说，高效许多。
这一点我们可以从两者的迭代器中得以印证，先来看看 `HashMap` 的迭代器，可以看到 `HashMap` 迭代键值对时会用到一个 `nextNode` 方法，该方法会返回 next 指向的下一个元素，并会从 next 开始遍历 bucket 找到下一个 bucket 中不为空的元素 Node。
@@ -484,7 +484,7 @@ void afterNodeInsertion(boolean evict) { // possibly remove eldest
}
```
-相比之下 `LinkedHashMap` 的迭代器则是直接使用通过 `after` 指针快速定位到当前节点的后继节点，简洁高效需多。
+相比之下 `LinkedHashMap` 的迭代器则是直接使用通过 `after` 指针快速定位到当前节点的后继节点，简洁高效许多。
```java
final class LinkedEntryIterator extends LinkedHashIterator
@@ -550,7 +550,7 @@ System.out.println("linkedHashMap get time: " + (end - start));
System.out.println(num);
```
-从输出结果来看，因为 `LinkedHashMap` 需要维护双向链表的缘故，插入元素相较于 `HashMap` 会更耗时，但是有了双向链表明确的前后节点关系，迭代效率相对于前者高效了需多。不过，总体来说却别不大，毕竟数据量这么庞大。
+从输出结果来看，因为 `LinkedHashMap` 需要维护双向链表的缘故，插入元素相较于 `HashMap` 会更耗时，但是有了双向链表明确的前后节点关系，迭代效率相对于前者高效了许多。不过，总体来说却别不大，毕竟数据量这么庞大。
```bash
map time putVal: 5880
diff --git a/docs/java/collection/linkedlist-source-code.md b/docs/java/collection/linkedlist-source-code.md
index 92fee67251d..810ee25cd70 100644
--- a/docs/java/collection/linkedlist-source-code.md
+++ b/docs/java/collection/linkedlist-source-code.md
@@ -23,7 +23,7 @@ tag:
- 头部插入/删除：只需要修改头结点的指针即可完成插入/删除操作，因此时间复杂度为 O(1)。
- 尾部插入/删除：只需要修改尾结点的指针即可完成插入/删除操作，因此时间复杂度为 O(1)。
-- 指定位置插入/删除：需要先移动到指定位置，再修改指定节点的指针完成插入/删除，因此需要移动平均 n/2 个元素，时间复杂度为 O(n)。
+- 指定位置插入/删除：需要先移动到指定位置，再修改指定节点的指针完成插入/删除，不过由于有头尾指针，可以从较近的指针出发，因此需要遍历平均 n/4 个元素，时间复杂度为 O(n)。
### LinkedList 为什么不能实现 RandomAccess 接口？
@@ -99,7 +99,7 @@ public LinkedList(Collection c) {
`add()` 方法有两个版本：
- `add(E e)`：用于在 `LinkedList` 的尾部插入元素，即将新元素作为链表的最后一个元素，时间复杂度为 O(1)。
-- `add(int index, E element)`:用于在指定位置插入元素。这种插入方式需要先移动到指定位置，再修改指定节点的指针完成插入/删除，因此需要移动平均 n/2 个元素，时间复杂度为 O(n)。
+- `add(int index, E element)`:用于在指定位置插入元素。这种插入方式需要先移动到指定位置，再修改指定节点的指针完成插入/删除，因此需要移动平均 n/4 个元素，时间复杂度为 O(n)。
```java
// 在链表尾部插入元素
@@ -151,8 +151,9 @@ void linkBefore(E e, Node succ) {
final Node newNode = new Node<>(pred, e, succ);
// 将 succ 节点前驱引用 prev 指向新节点
succ.prev = newNode;
- // 判断尾节点是否为空，为空表示当前链表还没有节点
+ // 判断前驱节点是否为空，为空表示 succ 是第一个节点
if (pred == null)
+ // 新节点成为第一个节点
first = newNode;
else
// succ 节点前驱的后继引用指向新节点
diff --git a/docs/java/concurrent/aqs.md b/docs/java/concurrent/aqs.md
index d95388f0e02..c8e079d1a51 100644
--- a/docs/java/concurrent/aqs.md
+++ b/docs/java/concurrent/aqs.md
@@ -5,6 +5,8 @@ tag:
- Java并发
---
+
+
## AQS 介绍
AQS 的全称为 `AbstractQueuedSynchronizer` ，翻译过来的意思就是抽象队列同步器。这个类在 `java.util.concurrent.locks` 包下面。
@@ -18,31 +20,88 @@ public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchron
}
```
-AQS 为构建锁和同步器提供了一些通用功能的实现，因此，使用 AQS 能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的 `ReentrantLock`，`Semaphore`，其他的诸如 `ReentrantReadWriteLock`，`SynchronousQueue`等等皆是基于 AQS 的。
+AQS 为构建锁和同步器提供了一些通用功能的实现。因此，使用 AQS 能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的 `ReentrantLock`，`Semaphore`，其他的诸如 `ReentrantReadWriteLock`，`SynchronousQueue`等等皆是基于 AQS 的。
## AQS 原理
在面试中被问到并发知识的时候，大多都会被问到“请你说一下自己对于 AQS 原理的理解”。下面给大家一个示例供大家参考，面试不是背题，大家一定要加入自己的思想，即使加入不了自己的思想也要保证自己能够通俗的讲出来而不是背出来。
+### AQS 快速了解
+
+在真正讲解 AQS 源码之前，需要对 AQS 有一个整体层面的认识。这里会先通过几个问题，从整体层面上认识 AQS，了解 AQS 在整个 Java 并发中所位于的层面，之后在学习 AQS 源码的过程中，才能更加了解同步器和 AQS 之间的关系。
+
+#### AQS 的作用是什么？
+
+AQS 解决了开发者在实现同步器时的复杂性问题。它提供了一个通用框架，用于实现各种同步器，例如 **可重入锁**（`ReentrantLock`）、**信号量**（`Semaphore`）和 **倒计时器**（`CountDownLatch`）。通过封装底层的线程同步机制，AQS 将复杂的线程管理逻辑隐藏起来，使开发者只需专注于具体的同步逻辑。
+
+简单来说，AQS 是一个抽象类，为同步器提供了通用的 **执行框架**。它定义了 **资源获取和释放的通用流程**，而具体的资源获取逻辑则由具体同步器通过重写模板方法来实现。 因此，可以将 AQS 看作是同步器的 **基础“底座”**，而同步器则是基于 AQS 实现的 **具体“应用”**。
+
+#### AQS 为什么使用 CLH 锁队列的变体？
+
+CLH 锁是一种基于 **自旋锁** 的优化实现。
+
+先说一下自旋锁存在的问题：自旋锁通过线程不断对一个原子变量执行 `compareAndSet`（简称 `CAS`）操作来尝试获取锁。在高并发场景下，多个线程会同时竞争同一个原子变量，容易造成某个线程的 `CAS` 操作长时间失败，从而导致 **“饥饿”问题**（某些线程可能永远无法获取锁）。
+
+CLH 锁通过引入一个队列来组织并发竞争的线程，对自旋锁进行了改进：
+
+- 每个线程会作为一个节点加入到队列中，并通过自旋监控前一个线程节点的状态，而不是直接竞争共享变量。
+- 线程按顺序排队，确保公平性，从而避免了 “饥饿” 问题。
+
+AQS（AbstractQueuedSynchronizer）在 CLH 锁的基础上进一步优化，形成了其内部的 **CLH 队列变体**。主要改进点有以下两方面：
+
+1. **自旋 + 阻塞**： CLH 锁使用纯自旋方式等待锁的释放，但大量的自旋操作会占用过多的 CPU 资源。AQS 引入了 **自旋 + 阻塞** 的混合机制：
+ - 如果线程获取锁失败，会先短暂自旋尝试获取锁；
+ - 如果仍然失败，则线程会进入阻塞状态，等待被唤醒，从而减少 CPU 的浪费。
+2. **单向队列改为双向队列**：CLH 锁使用单向队列，节点只知道前驱节点的状态，而当某个节点释放锁时，需要通过队列唤醒后续节点。AQS 将队列改为 **双向队列**，新增了 `next` 指针，使得节点不仅知道前驱节点，也可以直接唤醒后继节点，从而简化了队列操作，提高了唤醒效率。
+
+#### AQS 的性能比较好，原因是什么？
+
+因为 AQS 内部大量使用了 `CAS` 操作。
+
+AQS 内部通过队列来存储等待的线程节点。由于队列是共享资源，在多线程场景下，需要保证队列的同步访问。
+
+AQS 内部通过 `CAS` 操作来控制队列的同步访问，`CAS` 操作主要用于控制 `队列初始化` 、 `线程节点入队` 两个操作的并发安全。虽然利用 `CAS` 控制并发安全可以保证比较好的性能，但同时会带来比较高的 **编码复杂度** 。
+
+#### AQS 中为什么 Node 节点需要不同的状态？
+
+AQS 中的 `waitStatus` 状态类似于 **状态机** ，通过不同状态来表明 Node 节点的不同含义，并且根据不同操作，来控制状态之间的流转。
+
+- 状态 `0` ：新节点加入队列之后，初始状态为 `0` 。
+
+- 状态 `SIGNAL` ：当有新的节点加入队列，此时新节点的前继节点状态就会由 `0` 更新为 `SIGNAL` ，表示前继节点释放锁之后，需要对新节点进行唤醒操作。如果唤醒 `SIGNAL` 状态节点的后续节点，就会将 `SIGNAL` 状态更新为 `0` 。即通过清除 `SIGNAL` 状态，表示已经执行了唤醒操作。
+
+- 状态 `CANCELLED` ：如果一个节点在队列中等待获取锁锁时，因为某种原因失败了，该节点的状态就会变为 `CANCELLED` ，表明取消获取锁，这种状态的节点是异常的，无法被唤醒，也无法唤醒后继节点。
+
### AQS 核心思想
-AQS 核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是基于 **CLH 锁** （Craig, Landin, and Hagersten locks） 实现的。
+AQS 核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是基于 **CLH 锁** （Craig, Landin, and Hagersten locks） 进一步优化实现的。
+
+**CLH 锁** 对自旋锁进行了改进，是基于单链表的自旋锁。在多线程场景下，会将请求获取锁的线程组织成一个单向队列，每个等待的线程会通过自旋访问前一个线程节点的状态，前一个节点释放锁之后，当前节点才可以获取锁。**CLH 锁** 的队列结构如下图所示。
+
+
+
+AQS 中使用的 **等待队列** 是 CLH 锁队列的变体（接下来简称为 CLH 变体队列）。
+
+AQS 的 CLH 变体队列是一个双向队列，会暂时获取不到锁的线程将被加入到该队列中，CLH 变体队列和原本的 CLH 锁队列的区别主要有两点：
-CLH 锁是对自旋锁的一种改进，是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系），暂时获取不到锁的线程将被加入到该队列中。AQS 将每条请求共享资源的线程封装成一个 CLH 队列锁的一个结点（Node）来实现锁的分配。在 CLH 队列锁中，一个节点表示一个线程，它保存着线程的引用（thread）、 当前节点在队列中的状态（waitStatus）、前驱节点（prev）、后继节点（next）。
+- 由 **自旋** 优化为 **自旋 + 阻塞** ：自旋操作的性能很高，但大量的自旋操作比较占用 CPU 资源，因此在 CLH 变体队列中会先通过自旋尝试获取锁，如果失败再进行阻塞等待。
+- 由 **单向队列** 优化为 **双向队列** ：在 CLH 变体队列中，会对等待的线程进行阻塞操作，当队列前边的线程释放锁之后，需要对后边的线程进行唤醒，因此增加了 `next` 指针，成为了双向队列。
-CLH 队列结构如下图所示：
+AQS 将每条请求共享资源的线程封装成一个 CLH 变体队列的一个结点（Node）来实现锁的分配。在 CLH 变体队列中，一个节点表示一个线程，它保存着线程的引用（thread）、 当前节点在队列中的状态（waitStatus）、前驱节点（prev）、后继节点（next）。
-
+AQS 中的 CLH 变体队列结构如下图所示：
+
+
关于 AQS 核心数据结构-CLH 锁的详细解读，强烈推荐阅读 [Java AQS 核心数据结构-CLH 锁 - Qunar 技术沙龙](https://mp.weixin.qq.com/s/jEx-4XhNGOFdCo4Nou5tqg) 这篇文章。
AQS(`AbstractQueuedSynchronizer`)的核心原理图：
-
+
AQS 使用 **int 成员变量 `state` 表示同步状态**，通过内置的 **FIFO 线程等待/等待队列** 来完成获取资源线程的排队工作。
-`state` 变量由 `volatile` 修饰，用于展示当前临界资源的获锁情况。
+`state` 变量由 `volatile` 修饰，用于展示当前临界资源的获取情况。
```java
// 共享变量，使用volatile修饰保证线程可见性
@@ -66,7 +125,7 @@ protected final boolean compareAndSetState(int expect, int update) {
}
```
-以可重入的互斥锁 `ReentrantLock` 为例，它的内部维护了一个 `state` 变量，用来表示锁的占用状态。`state` 的初始值为 0，表示锁处于未锁定状态。当线程 A 调用 `lock()` 方法时，会尝试通过 `tryAcquire()` 方法独占该锁，并让 `state` 的值加 1。如果成功了，那么线程 A 就获取到了锁。如果失败了，那么线程 A 就会被加入到一个等待队列（CLH 队列）中，直到其他线程释放该锁。假设线程 A 获取锁成功了，释放锁之前，A 线程自己是可以重复获取此锁的（`state` 会累加）。这就是可重入性的体现：一个线程可以多次获取同一个锁而不会被阻塞。但是，这也意味着，一个线程必须释放与获取的次数相同的锁，才能让 `state` 的值回到 0，也就是让锁恢复到未锁定状态。只有这样，其他等待的线程才能有机会获取该锁。
+以可重入的互斥锁 `ReentrantLock` 为例，它的内部维护了一个 `state` 变量，用来表示锁的占用状态。`state` 的初始值为 0，表示锁处于未锁定状态。当线程 A 调用 `lock()` 方法时，会尝试通过 `tryAcquire()` 方法独占该锁，并让 `state` 的值加 1。如果成功了，那么线程 A 就获取到了锁。如果失败了，那么线程 A 就会被加入到一个等待队列（CLH 变体队列）中，直到其他线程释放该锁。假设线程 A 获取锁成功了，释放锁之前，A 线程自己是可以重复获取此锁的（`state` 会累加）。这就是可重入性的体现：一个线程可以多次获取同一个锁而不会被阻塞。但是，这也意味着，一个线程必须释放与获取的次数相同的锁，才能让 `state` 的值回到 0，也就是让锁恢复到未锁定状态。只有这样，其他等待的线程才能有机会获取该锁。
线程 A 尝试获取锁的过程如下图所示（图源[从 ReentrantLock 的实现看 AQS 的原理及应用 - 美团技术团队](./reentrantlock.md)）：
@@ -74,20 +133,39 @@ protected final boolean compareAndSetState(int expect, int update) {
再以倒计时器 `CountDownLatch` 以例，任务分为 N 个子线程去执行，`state` 也初始化为 N（注意 N 要与线程个数一致）。这 N 个子线程开始执行任务，每执行完一个子线程，就调用一次 `countDown()` 方法。该方法会尝试使用 CAS(Compare and Swap) 操作，让 `state` 的值减少 1。当所有的子线程都执行完毕后（即 `state` 的值变为 0），`CountDownLatch` 会调用 `unpark()` 方法，唤醒主线程。这时，主线程就可以从 `await()` 方法（`CountDownLatch` 中的`await()` 方法而非 AQS 中的）返回，继续执行后续的操作。
-### AQS 资源共享方式
+### Node 节点 waitStatus 状态含义
-AQS 定义两种资源共享方式：`Exclusive`（独占，只有一个线程能执行，如`ReentrantLock`）和`Share`（共享，多个线程可同时执行，如`Semaphore`/`CountDownLatch`）。
+AQS 中的 `waitStatus` 状态类似于 **状态机** ，通过不同状态来表明 Node 节点的不同含义，并且根据不同操作，来控制状态之间的流转。
-一般来说，自定义同步器的共享方式要么是独占，要么是共享，他们也只需实现`tryAcquire-tryRelease`、`tryAcquireShared-tryReleaseShared`中的一种即可。但 AQS 也支持自定义同步器同时实现独占和共享两种方式，如`ReentrantReadWriteLock`。
+| Node 节点状态 | 值 | 含义 |
+| ------------- | --- | ------------------------------------------------------------------------------------------------------------------------- |
+| `CANCELLED` | 1 | 表示线程已经取消获取锁。线程在等待获取资源时被中断、等待资源超时会更新为该状态。 |
+| `SIGNAL` | -1 | 表示后继节点需要当前节点唤醒。在当前线程节点释放锁之后，需要对后继节点进行唤醒。 |
+| `CONDITION` | -2 | 表示节点在等待 Condition。当其他线程调用了 Condition 的 `signal()` 方法后，节点会从等待队列转移到同步队列中等待获取资源。 |
+| `PROPAGATE` | -3 | 用于共享模式。在共享模式下，可能会出现线程在队列中无法被唤醒的情况，因此引入了 `PROPAGATE` 状态来解决这个问题。 |
+| | 0 | 加入队列的新节点的初始状态。 |
-### 自定义同步器
+在 AQS 的源码中，经常使用 `> 0` 、 `< 0` 来对 `waitStatus` 进行判断。
-同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）：
+如果 `waitStatus > 0` ，表明节点的状态已经取消等待获取资源。
-1. 使用者继承 `AbstractQueuedSynchronizer` 并重写指定的方法。
-2. 将 AQS 组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。
+如果 `waitStatus < 0` ，表明节点的状态处于正常的状态，即没有取消等待。
-这和我们以往通过实现接口的方式有很大区别，这是模板方法模式很经典的一个运用。
+其中 `SIGNAL` 状态是最重要的，节点状态流转以及对应操作如下：
+
+| 状态流转 | 对应操作 |
+| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `0` | 新节点入队时，初始状态为 `0` 。 |
+| `0 -> SIGNAL` | 新节点入队时，它的前继节点状态会由 `0` 更新为 `SIGNAL` 。`SIGNAL` 状态表明该节点的后续节点需要被唤醒。 |
+| `SIGNAL -> 0` | 在唤醒后继节点时，需要清除当前节点的状态。通常发生在 `head` 节点，比如 `head` 节点的状态由 `SIGNAL` 更新为 `0` ，表示已经对 `head` 节点的后继节点唤醒了。 |
+| `0 -> PROPAGATE` | AQS 内部引入了 `PROPAGATE` 状态，为了解决并发场景下，可能造成的线程节点无法唤醒的情况。（在 AQS 共享模式获取资源的源码分析会讲到） |
+
+### 自定义同步器
+
+基于 AQS 可以实现自定义的同步器， AQS 提供了 5 个模板方法（模板方法模式）。如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）：
+
+1. 自定义的同步器继承 `AbstractQueuedSynchronizer` 。
+2. 重写 AQS 暴露的模板方法。
**AQS 使用了模板方法模式，自定义同步器时需要重写下面几个 AQS 提供的钩子方法：**
@@ -110,6 +188,742 @@ protected boolean isHeldExclusively()
除了上面提到的钩子方法之外，AQS 类中的其他方法都是 `final` ，所以无法被其他类重写。
+### AQS 资源共享方式
+
+AQS 定义两种资源共享方式：`Exclusive`（独占，只有一个线程能执行，如`ReentrantLock`）和`Share`（共享，多个线程可同时执行，如`Semaphore`/`CountDownLatch`）。
+
+一般来说，自定义同步器的共享方式要么是独占，要么是共享，他们也只需实现`tryAcquire-tryRelease`、`tryAcquireShared-tryReleaseShared`中的一种即可。但 AQS 也支持自定义同步器同时实现独占和共享两种方式，如`ReentrantReadWriteLock`。
+
+### AQS 资源获取源码分析（独占模式）
+
+AQS 中以独占模式获取资源的入口方法是 `acquire()` ，如下：
+
+```JAVA
+// AQS
+public final void acquire(int arg) {
+ if (!tryAcquire(arg) &&
+ acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
+ selfInterrupt();
+}
+```
+
+在 `acquire()` 中，线程会先尝试获取共享资源；如果获取失败，会将线程封装为 Node 节点加入到 AQS 的等待队列中；加入队列之后，会让等待队列中的线程尝试获取资源，并且会对线程进行阻塞操作。分别对应以下三个方法：
+
+- `tryAcquire()` ：尝试获取锁（模板方法），`AQS` 不提供具体实现，由子类实现。
+- `addWaiter()` ：如果获取锁失败，会将当前线程封装为 Node 节点加入到 AQS 的 CLH 变体队列中等待获取锁。
+- `acquireQueued()` ：对线程进行阻塞，并调用 `tryAcquire()` 方法让队列中的线程尝试获取锁。
+
+#### `tryAcquire()` 分析
+
+AQS 中对应的 `tryAcquire()` 模板方法如下：
+
+```JAVA
+// AQS
+protected boolean tryAcquire(int arg) {
+ throw new UnsupportedOperationException();
+}
+```
+
+`tryAcquire()` 方法是 AQS 提供的模板方法，不提供默认实现。
+
+因此，这里分析 `tryAcquire()` 方法时，以 `ReentrantLock` 的非公平锁（独占锁）为例进行分析，`ReentrantLock` 内部实现的 `tryAcquire()` 会调用到下边的 `nonfairTryAcquire()` ：
+
+```JAVA
+// ReentrantLock
+final boolean nonfairTryAcquire(int acquires) {
+ final Thread current = Thread.currentThread();
+ // 1、获取 AQS 中的 state 状态
+ int c = getState();
+ // 2、如果 state 为 0，证明锁没有被其他线程占用
+ if (c == 0) {
+ // 2.1、通过 CAS 对 state 进行更新
+ if (compareAndSetState(0, acquires)) {
+ // 2.2、如果 CAS 更新成功，就将锁的持有者设置为当前线程
+ setExclusiveOwnerThread(current);
+ return true;
+ }
+ }
+ // 3、如果当前线程和锁的持有线程相同，说明发生了「锁的重入」
+ else if (current == getExclusiveOwnerThread()) {
+ int nextc = c + acquires;
+ if (nextc < 0) // overflow
+ throw new Error("Maximum lock count exceeded");
+ // 3.1、将锁的重入次数加 1
+ setState(nextc);
+ return true;
+ }
+ // 4、如果锁被其他线程占用，就返回 false，表示获取锁失败
+ return false;
+}
+```
+
+在 `nonfairTryAcquire()` 方法内部，主要通过两个核心操作去完成资源的获取：
+
+- 通过 `CAS` 更新 `state` 变量。`state == 0` 表示资源没有被占用。`state > 0` 表示资源被占用，此时 `state` 表示重入次数。
+- 通过 `setExclusiveOwnerThread()` 设置持有资源的线程。
+
+如果线程更新 `state` 变量成功，就表明获取到了资源， 因此将持有资源的线程设置为当前线程即可。
+
+#### `addWaiter()` 分析
+
+在通过 `tryAcquire()` 方法尝试获取资源失败之后，会调用 `addWaiter()` 方法将当前线程封装为 Node 节点加入 `AQS` 内部的队列中。`addWaite()` 代码如下：
+
+```JAVA
+// AQS
+private Node addWaiter(Node mode) {
+ // 1、将当前线程封装为 Node 节点。
+ Node node = new Node(Thread.currentThread(), mode);
+ Node pred = tail;
+ // 2、如果 pred ！= null，则证明 tail 节点已经被初始化，直接将 Node 节点加入队列即可。
+ if (pred != null) {
+ node.prev = pred;
+ // 2.1、通过 CAS 控制并发安全。
+ if (compareAndSetTail(pred, node)) {
+ pred.next = node;
+ return node;
+ }
+ }
+ // 3、初始化队列，并将新创建的 Node 节点加入队列。
+ enq(node);
+ return node;
+}
+```
+
+**节点入队的并发安全：**
+
+在 `addWaiter()` 方法中，需要执行 Node 节点 **入队** 的操作。由于是在多线程环境下，因此需要通过 `CAS` 操作保证并发安全。
+
+通过 `CAS` 操作去更新 `tail` 指针指向新入队的 Node 节点，`CAS` 可以保证只有一个线程会成功修改 `tail` 指针，以此来保证 Node 节点入队时的并发安全。
+
+**AQS 内部队列的初始化：**
+
+在执行 `addWaiter()` 时，如果发现 `pred == null` ，即 `tail` 指针为 null，则证明队列没有初始化，需要调用 `enq()` 方法初始化队列，并将 `Node` 节点加入到初始化后的队列中，代码如下：
+
+```JAVA
+// AQS
+private Node enq(final Node node) {
+ for (;;) {
+ Node t = tail;
+ if (t == null) {
+ // 1、通过 CAS 操作保证队列初始化的并发安全
+ if (compareAndSetHead(new Node()))
+ tail = head;
+ } else {
+ // 2、与 addWaiter() 方法中节点入队的操作相同
+ node.prev = t;
+ if (compareAndSetTail(t, node)) {
+ t.next = node;
+ return t;
+ }
+ }
+ }
+}
+```
+
+在 `enq()` 方法中初始化队列，在初始化过程中，也需要通过 `CAS` 来保证并发安全。
+
+初始化队列总共包含两个步骤：初始化 `head` 节点、`tail` 指向 `head` 节点。
+
+**初始化后的队列如下图所示：**
+
+
+
+#### `acquireQueued()` 分析
+
+为了方便阅读，这里再贴一下 `AQS` 中 `acquire()` 获取资源的代码：
+
+```JAVA
+// AQS
+public final void acquire(int arg) {
+ if (!tryAcquire(arg) &&
+ acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
+ selfInterrupt();
+}
+```
+
+在 `acquire()` 方法中，通过 `addWaiter()` 方法将 `Node` 节点加入队列之后，就会调用 `acquireQueued()` 方法。代码如下：
+
+```JAVA
+// AQS：令队列中的节点尝试获取锁，并且对线程进行阻塞。
+final boolean acquireQueued(final Node node, int arg) {
+ boolean failed = true;
+ try {
+ boolean interrupted = false;
+ for (;;) {
+ // 1、尝试获取锁。
+ final Node p = node.predecessor();
+ if (p == head && tryAcquire(arg)) {
+ setHead(node);
+ p.next = null; // help GC
+ failed = false;
+ return interrupted;
+ }
+ // 2、判断线程是否可以阻塞，如果可以，则阻塞当前线程。
+ if (shouldParkAfterFailedAcquire(p, node) &&
+ parkAndCheckInterrupt())
+ interrupted = true;
+ }
+ } finally {
+ // 3、如果获取锁失败，就会取消获取锁，将节点状态更新为 CANCELLED。
+ if (failed)
+ cancelAcquire(node);
+ }
+}
+```
+
+在 `acquireQueued()` 方法中，主要做两件事情：
+
+- **尝试获取资源：** 当前线程加入队列之后，如果发现前继节点是 `head` 节点，说明当前线程是队列中第一个等待的节点，于是调用 `tryAcquire()` 尝试获取资源。
+
+- **阻塞当前线程** ：如果尝试获取资源失败，就需要阻塞当前线程，等待被唤醒之后获取资源。
+
+**1、尝试获取资源**
+
+在 `acquireQueued()` 方法中，尝试获取资源总共有 2 个步骤：
+
+- `p == head` ：表明当前节点的前继节点为 `head` 节点。此时当前节点为 AQS 队列中的第一个等待节点。
+- `tryAcquire(arg) == true` ：表明当前线程尝试获取资源成功。
+
+在成功获取资源之后，就需要将当前线程的节点 **从等待队列中移除** 。移除操作为：将当前等待的线程节点设置为 `head` 节点（`head` 节点是虚拟节点，并不参与排队获取资源）。
+
+**2、阻塞当前线程**
+
+在 `AQS` 中，当前节点的唤醒需要依赖于上一个节点。如果上一个节点取消获取锁，它的状态就会变为 `CANCELLED` ，`CANCELLED` 状态的节点没有获取到锁，也就无法执行解锁操作对当前节点进行唤醒。因此在阻塞当前线程之前，需要跳过 `CANCELLED` 状态的节点。
+
+通过 `shouldParkAfterFailedAcquire()` 方法来判断当前线程节点是否可以阻塞，如下：
+
+```JAVA
+// AQS：判断当前线程节点是否可以阻塞。
+private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
+ int ws = pred.waitStatus;
+ // 1、前继节点状态正常，直接返回 true 即可。
+ if (ws == Node.SIGNAL)
+ return true;
+ // 2、ws > 0 表示前继节点的状态异常，即为 CANCELLED 状态，需要跳过异常状态的节点。
+ if (ws > 0) {
+ do {
+ node.prev = pred = pred.prev;
+ } while (pred.waitStatus > 0);
+ pred.next = node;
+ } else {
+ // 3、如果前继节点的状态不是 SIGNAL，也不是 CANCELLED，就将状态设置为 SIGNAL。
+ compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
+ }
+ return false;
+}
+```
+
+`shouldParkAfterFailedAcquire()` 方法中的判断逻辑：
+
+- 如果发现前继节点的状态是 `SIGNAL` ，则可以阻塞当前线程。
+- 如果发现前继节点的状态是 `CANCELLED` ，则需要跳过 `CANCELLED` 状态的节点。
+- 如果发现前继节点的状态不是 `SIGNAL` 和 `CANCELLED` ，表明前继节点的状态处于正常等待资源的状态，因此将前继节点的状态设置为 `SIGNAL` ，表明该前继节点需要对后续节点进行唤醒。
+
+当判断当前线程可以阻塞之后，通过调用 `parkAndCheckInterrupt()` 方法来阻塞当前线程。内部使用了 `LockSupport` 来实现阻塞。`LockSupoprt` 底层是基于 `Unsafe` 类来阻塞线程，代码如下：
+
+```JAVA
+// AQS
+private final boolean parkAndCheckInterrupt() {
+ // 1、线程阻塞到这里
+ LockSupport.park(this);
+ // 2、线程被唤醒之后，返回线程中断状态
+ return Thread.interrupted();
+}
+```
+
+**为什么在线程被唤醒之后，要返回线程的中断状态呢？**
+
+在 `parkAndCheckInterrupt()` 方法中，当执行完 `LockSupport.park(this)` ，线程会被阻塞，代码如下：
+
+```JAVA
+// AQS
+private final boolean parkAndCheckInterrupt() {
+ LockSupport.park(this);
+ // 线程被唤醒之后，需要返回线程中断状态
+ return Thread.interrupted();
+}
+```
+
+当线程被唤醒之后，需要执行 `Thread.interrupted()` 来返回线程的中断状态，这是为什么呢？
+
+这个和线程的中断协作机制有关系，线程被唤醒之后，并不确定是被中断唤醒，还是被 `LockSupport.unpark()` 唤醒，因此需要通过线程的中断状态来判断。
+
+**在 `acquire()` 方法中，为什么需要调用 `selfInterrupt()` ？**
+
+`acquire()` 方法代码如下：
+
+```JAVA
+// AQS
+public final void acquire(int arg) {
+ if (!tryAcquire(arg) &&
+ acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
+ selfInterrupt();
+}
+```
+
+在 `acquire()` 方法中，当 `if` 语句的条件返回 `true` 后，就会调用 `selfInterrupt()` ，该方法会中断当前线程，为什么需要中断当前线程呢？
+
+当 `if` 判断为 `true` 时，需要 `tryAcquire()` 返回 `false` ，并且 `acquireQueued()` 返回 `true` 。
+
+其中 `acquireQueued()` 方法返回的是线程被唤醒之后的 **中断状态** ，通过执行 `Thread.interrupted()` 来返回。该方法在返回中断状态的同时，会清除线程的中断状态。
+
+因此如果 `if` 判断为 `true` ，表明线程的中断状态为 `true` ，但是调用 `Thread.interrupted()` 之后，线程的中断状态被清除为 `false` ，因此需要重新执行 `selfInterrupt()` 来重新设置线程的中断状态。
+
+### AQS 资源释放源码分析（独占模式）
+
+AQS 中以独占模式释放资源的入口方法是 `release()` ，代码如下：
+
+```JAVA
+// AQS
+public final boolean release(int arg) {
+ // 1、尝试释放锁
+ if (tryRelease(arg)) {
+ Node h = head;
+ // 2、唤醒后继节点
+ if (h != null && h.waitStatus != 0)
+ unparkSuccessor(h);
+ return true;
+ }
+ return false;
+}
+```
+
+在 `release()` 方法中，主要做两件事：尝试释放锁和唤醒后继节点。对应方法如下：
+
+**1、尝试释放锁**
+
+通过 `tryRelease()` 方法尝试释放锁，该方法为模板方法，由自定义同步器实现，因此这里仍然以 `ReentrantLock` 为例来讲解。
+
+`ReentrantLock` 中实现的 `tryRelease()` 方法如下：
+
+```JAVA
+// ReentrantLock
+protected final boolean tryRelease(int releases) {
+ int c = getState() - releases;
+ // 1、判断持有锁的线程是否为当前线程
+ if (Thread.currentThread() != getExclusiveOwnerThread())
+ throw new IllegalMonitorStateException();
+ boolean free = false;
+ // 2、如果 state 为 0，则表明当前线程已经没有重入次数。因此将 free 更新为 true，表明该线程会释放锁。
+ if (c == 0) {
+ free = true;
+ // 3、更新持有资源的线程为 null
+ setExclusiveOwnerThread(null);
+ }
+ // 4、更新 state 值
+ setState(c);
+ return free;
+}
+```
+
+在 `tryRelease()` 方法中，会先计算释放锁之后的 `state` 值，判断 `state` 值是否为 0。
+
+- 如果 `state == 0` ，表明该线程没有重入次数了，更新 `free = true` ，并修改持有资源的线程为 null，表明该线程完全释放这把锁。
+- 如果 `state != 0` ，表明该线程还存在重入次数，因此不更新 `free` 值，`free` 值为 `false` 表明该线程没有完全释放这把锁。
+
+之后更新 `state` 值，并返回 `free` 值，`free` 值表明线程是否完全释放锁。
+
+**2、唤醒后继节点**
+
+如果 `tryRelease()` 返回 `true` ，表明线程已经没有重入次数了，锁已经被完全释放，因此需要唤醒后继节点。
+
+在唤醒后继节点之前，需要判断是否可以唤醒后继节点，判断条件为： `h != null && h.waitStatus != 0` 。这里解释一下为什么要这样判断：
+
+- `h == null` ：表明 `head` 节点还没有被初始化，也就是 AQS 中的队列没有被初始化，因此无法唤醒队列中的线程节点。
+- `h != null && h.waitStatus == 0` ：表明头节点刚刚初始化完毕（节点的初始化状态为 0），后继节点线程还没有成功入队，因此不需要对后续节点进行唤醒。（当后继节点入队之后，会将前继节点的状态修改为 `SIGNAL` ，表明需要对后继节点进行唤醒）
+- `h != null && h.waitStatus != 0` ：其中 `waitStatus` 有可能大于 0，也有可能小于 0。其中 `> 0` 表明节点已经取消等待获取资源，`< 0` 表明节点处于正常等待状态。
+
+接下来进入 `unparkSuccessor()` 方法查看如何唤醒后继节点：
+
+```JAVA
+// AQS：这里的入参 node 为队列的头节点（虚拟头节点）
+private void unparkSuccessor(Node node) {
+ int ws = node.waitStatus;
+ // 1、将头节点的状态进行清除，为后续的唤醒做准备。
+ if (ws < 0)
+ compareAndSetWaitStatus(node, ws, 0);
+
+ Node s = node.next;
+ // 2、如果后继节点异常，则需要从 tail 向前遍历，找到正常状态的节点进行唤醒。
+ if (s == null || s.waitStatus > 0) {
+ s = null;
+ for (Node t = tail; t != null && t != node; t = t.prev)
+ if (t.waitStatus <= 0)
+ s = t;
+ }
+ if (s != null)
+ // 3、唤醒后继节点
+ LockSupport.unpark(s.thread);
+}
+```
+
+在 `unparkSuccessor()` 中，如果头节点的状态 `< 0` （在正常情况下，只要有后继节点，头节点的状态应该为 `SIGNAL` ，即 -1），表示需要对后继节点进行唤醒，因此这里提前清除头节点的状态标识，将状态修改为 0，表示已经执行了对后续节点唤醒的操作。
+
+如果 `s == null` 或者 `s.waitStatus > 0` ，表明后继节点异常，此时不能唤醒异常节点，而是要找到正常状态的节点进行唤醒。
+
+因此需要从 `tail` 指针向前遍历，来找到第一个状态正常（`waitStatus <= 0`）的节点进行唤醒。
+
+**为什么要从 `tail` 指针向前遍历，而不是从 `head` 指针向后遍历，寻找正常状态的节点呢？**
+
+遍历的方向和 **节点的入队操作** 有关。入队方法如下：
+
+```JAVA
+// AQS：节点入队方法
+private Node addWaiter(Node mode) {
+ Node node = new Node(Thread.currentThread(), mode);
+ Node pred = tail;
+ if (pred != null) {
+ // 1、先修改 prev 指针。
+ node.prev = pred;
+ if (compareAndSetTail(pred, node)) {
+ // 2、再修改 next 指针。
+ pred.next = node;
+ return node;
+ }
+ }
+ enq(node);
+ return node;
+}
+```
+
+在 `addWaiter()` 方法中，`node` 节点入队需要修改 `node.prev` 和 `pred.next` 两个指针，但是这两个操作并不是 **原子操作** ，先修改了 `node.prev` 指针，之后才修改 `pred.next` 指针。
+
+在极端情况下，可能会出现 `head` 节点的下一个节点状态为 `CANCELLED` ，此时新入队的节点仅更新了 `node.prev` 指针，还未更新 `pred.next` 指针，如下图：
+
+
+
+这样如果从 `head` 指针向后遍历，无法找到新入队的节点，因此需要从 `tail` 指针向前遍历找到新入队的节点。
+
+### 图解 AQS 工作原理（独占模式）
+
+至此，AQS 中以独占模式获取资源、释放资源的源码就讲完了。为了对 AQS 的工作原理、节点状态变化有一个更加清晰的认识，接下来会通过画图的方式来了解整个 AQS 的工作原理。
+
+由于 AQS 是底层同步工具，获取和释放资源的方法并没有提供具体实现，因此这里基于 `ReentrantLock` 来画图进行讲解。
+
+假设总共有 3 个线程尝试获取锁，线程分别为 `T1` 、 `T2` 和 `T3` 。
+
+此时，假设线程 `T1` 先获取到锁，线程 `T2` 排队等待获取锁。在线程 `T2` 进入队列之前，需要对 AQS 内部队列进行初始化。`head` 节点在初始化后状态为 `0` 。AQS 内部初始化后的队列如下图：
+
+
+
+此时，线程 `T2` 尝试获取锁。由于线程 `T1` 持有锁，因此线程 `T2` 会进入队列中等待获取锁。同时会将前继节点（ `head` 节点）的状态由 `0` 更新为 `SIGNAL` ，表示需要对 `head` 节点的后继节点进行唤醒。此时，AQS 内部队列如下图所示：
+
+
+
+此时，线程 `T3` 尝试获取锁。由于线程 `T1` 持有锁，因此线程 `T3` 会进入队列中等待获取锁。同时会将前继节点（线程 `T2` 节点）的状态由 `0` 更新为 `SIGNAL` ，表示线程 `T2` 节点需要对后继节点进行唤醒。此时，AQS 内部队列如下图所示：
+
+
+
+此时，假设线程 `T1` 释放锁，会唤醒后继节点 `T2` 。线程 `T2` 被唤醒后获取到锁，并且会从等待队列中退出。
+
+这里线程 `T2` 节点退出等待队列并不是直接从队列移除，而是令线程 `T2` 节点成为新的 `head` 节点，以此来退出资源获取的等待。此时 AQS 内部队列如下所示：
+
+
+
+此时，假设线程 `T2` 释放锁，会唤醒后继节点 `T3` 。线程 `T3` 获取到锁之后，同样也退出等待队列，即将线程 `T3` 节点变为 `head` 节点来退出资源获取的等待。此时 AQS 内部队列如下所示：
+
+
+
+### AQS 资源获取源码分析（共享模式）
+
+AQS 中以独占模式获取资源的入口方法是 `acquireShared()` ，如下：
+
+```JAVA
+// AQS
+public final void acquireShared(int arg) {
+ if (tryAcquireShared(arg) < 0)
+ doAcquireShared(arg);
+}
+```
+
+在 `acquireShared()` 方法中，会先尝试获取共享锁，如果获取失败，则将当前线程加入到队列中阻塞，等待唤醒后尝试获取共享锁，分别对应一下两个方法：`tryAcquireShared()` 和 `doAcquireShared()` 。
+
+其中 `tryAcquireShared()` 方法是 AQS 提供的模板方法，由同步器来实现具体逻辑。因此这里以 `Semaphore` 为例，来分析共享模式下，如何获取资源。
+
+#### `tryAcquireShared()` 分析
+
+`Semaphore` 中实现了公平锁和非公平锁，接下来以非公平锁为例来分析 `tryAcquireShared()` 源码。
+
+`Semaphore` 中重写的 `tryAcquireShared()` 方法会调用下边的 `nonfairTryAcquireShared()` 方法：
+
+```JAVA
+// Semaphore 重写 AQS 的模板方法
+protected int tryAcquireShared(int acquires) {
+ return nonfairTryAcquireShared(acquires);
+}
+
+// Semaphore
+final int nonfairTryAcquireShared(int acquires) {
+ for (;;) {
+ // 1、获取可用资源数量。
+ int available = getState();
+ // 2、计算剩余资源数量。
+ int remaining = available - acquires;
+ // 3、如果剩余资源数量 < 0，则说明资源不足，直接返回；如果 CAS 更新 state 成功，则说明当前线程获取到了共享资源，直接返回。
+ if (remaining < 0 ||
+ compareAndSetState(available, remaining))
+ return remaining;
+ }
+}
+```
+
+在共享模式下，AQS 中的 `state` 值表示共享资源的数量。
+
+在 `nonfairTryAcquireShared()` 方法中，会在死循环中不断尝试获取资源，如果 「剩余资源数不足」 或者 「当前线程成功获取资源」 ，就退出死循环。方法返回 **剩余的资源数量** ，根据返回值的不同，分为 3 种情况：
+
+- **剩余资源数量 > 0** ：表示成功获取资源，并且后续的线程也可以成功获取资源。
+- **剩余资源数量 = 0** ：表示成功获取资源，但是后续的线程无法成功获取资源。
+- **剩余资源数量 < 0** ：表示获取资源失败。
+
+#### `doAcquireShared()` 分析
+
+为了方便阅读，这里再贴一下获取资源的入口方法 `acquireShared()` ：
+
+```JAVA
+// AQS
+public final void acquireShared(int arg) {
+ if (tryAcquireShared(arg) < 0)
+ doAcquireShared(arg);
+}
+```
+
+在 `acquireShared()` 方法中，会先通过 `tryAcquireShared()` 尝试获取资源。
+
+如果发现方法的返回值 `< 0` ，即剩余的资源数小于 0，则表明当前线程获取资源失败。因此会进入 `doAcquireShared()` 方法，将当前线程加入到 AQS 队列进行等待。如下：
+
+```JAVA
+// AQS
+private void doAcquireShared(int arg) {
+ // 1、将当前线程加入到队列中等待。
+ final Node node = addWaiter(Node.SHARED);
+ boolean failed = true;
+ try {
+ boolean interrupted = false;
+ for (;;) {
+ final Node p = node.predecessor();
+ if (p == head) {
+ // 2、如果当前线程是等待队列的第一个节点，则尝试获取资源。
+ int r = tryAcquireShared(arg);
+ if (r >= 0) {
+ // 3、将当前线程节点移出等待队列，并唤醒后续线程节点。
+ setHeadAndPropagate(node, r);
+ p.next = null; // help GC
+ if (interrupted)
+ selfInterrupt();
+ failed = false;
+ return;
+ }
+ }
+ if (shouldParkAfterFailedAcquire(p, node) &&
+ parkAndCheckInterrupt())
+ interrupted = true;
+ }
+ } finally {
+ // 3、如果获取资源失败，就会取消获取资源，将节点状态更新为 CANCELLED。
+ if (failed)
+ cancelAcquire(node);
+ }
+}
+```
+
+由于当前线程已经尝试获取资源失败了，因此在 `doAcquireShared()` 方法中，需要将当前线程封装为 Node 节点，加入到队列中进行等待。
+
+以 **共享模式** 获取资源和 **独占模式** 获取资源最大的不同之处在于：共享模式下，资源的数量可能会大于 1，即可以多个线程同时持有资源。
+
+因此在共享模式下，当线程线程被唤醒之后，获取到了资源，如果发现还存在剩余资源，就会尝试唤醒后边的线程去尝试获取资源。对应的 `setHeadAndPropagate()` 方法如下：
+
+```JAVA
+// AQS
+private void setHeadAndPropagate(Node node, int propagate) {
+ Node h = head;
+ // 1、将当前线程节点移出等待队列。
+ setHead(node);
+ // 2、唤醒后续等待节点。
+ if (propagate > 0 || h == null || h.waitStatus < 0 ||
+ (h = head) == null || h.waitStatus < 0) {
+ Node s = node.next;
+ if (s == null || s.isShared())
+ doReleaseShared();
+ }
+}
+```
+
+在 `setHeadAndPropagate()` 方法中，唤醒后续节点需要满足一定的条件，主要需要满足 2 个条件：
+
+- `propagate > 0` ：`propagate` 代表获取资源之后剩余的资源数量，如果 `> 0` ，则可以唤醒后续线程去获取资源。
+- `h.waitStatus < 0` ：这里的 `h` 节点是执行 `setHead()` 之前的 `head` 节点。判断 `head.waitStatus` 时使用 `< 0` ，主要为了确定 `head` 节点的状态为 `SIGNAL` 或 `PROPAGATE` 。如果 `head` 节点为 `SIGNAL` ，则可以唤醒后续节点；如果 `head` 节点状态为 `PROPAGATE` ，也可以唤醒后续节点（这是为了解决并发场景下出现的问题，后续会细讲）。
+
+代码中关于 **唤醒后续等待节点** 的 `if` 判断稍微复杂一些，这里来讲一下为什么这样写：
+
+```JAVA
+if (propagate > 0 || h == null || h.waitStatus < 0 ||
+ (h = head) == null || h.waitStatus < 0)
+```
+
+- `h == null || h.waitStatus < 0` ： `h == null` 用于防止空指针异常。正常情况下 h 不会为 `null` ，因为执行到这里之前，当前节点已经加入到队列中了，队列不可能还没有初始化。
+
+ `h.waitStatus < 0` 主要判断 `head` 节点的状态是否为 `SIGNAL` 或者 `PROPAGATE` ，直接使用 `< 0` 来判断比较方便。
+
+- `(h = head) == null || h.waitStatus < 0` ：如果到这里说明之前判断的 `h.waitStatus < 0` ，说明存在并发。
+
+ 同时存在其他线程在唤醒后续节点，已经将 `head` 节点的值由 `SIGNAL` 修改为 `0` 了。因此，这里重新获取新的 `head` 节点，这次获取的 `head` 节点为通过 `setHead()` 设置的当前线程节点，之后再次判断 `waitStatus` 状态。
+
+如果 `if` 条件判断通过，就会走到 `doReleaseShared()` 方法唤醒后续等待节点，如下：
+
+```JAVA
+private void doReleaseShared() {
+ for (;;) {
+ Node h = head;
+ // 1、队列中至少需要一个等待的线程节点。
+ if (h != null && h != tail) {
+ int ws = h.waitStatus;
+ // 2、如果 head 节点的状态为 SIGNAL，则可以唤醒后继节点。
+ if (ws == Node.SIGNAL) {
+ // 2.1 清除 head 节点的 SIGNAL 状态，更新为 0。表示已经唤醒该节点的后继节点了。
+ if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
+ continue;
+ // 2.2 唤醒后继节点
+ unparkSuccessor(h);
+ }
+ // 3、如果 head 节点的状态为 0，则更新为 PROPAGATE。这是为了解决并发场景下存在的问题，接下来会细讲。
+ else if (ws == 0 &&
+ !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
+ continue;
+ }
+ if (h == head)
+ break;
+ }
+}
+```
+
+在 `doReleaseShared()` 方法中，会判断 `head` 节点的 `waitStatus` 状态来决定接下来的操作，有两种情况：
+
+- `head` 节点的状态为 `SIGNAL` ：表明 `head` 节点存在后继节点需要唤醒，因此通过 `CAS` 操作将 `head` 节点的 `SIGNAL` 状态更新为 `0` 。通过清除 `SIGNAL` 状态来表示已经对 `head` 节点的后继节点进行唤醒操作了。
+- `head` 节点的状态为 `0` ：表明存在并发情况，需要将 `0` 修改为 `PROPAGATE` 来保证在并发场景下可以正常唤醒线程。
+
+#### 为什么需要 `PROPAGATE` 状态？
+
+在 `doReleaseShared()` 释放资源时，第 3 步不太容易理解，即如果发现 `head` 节点的状态是 `0` ，就将 `head` 节点的状态由 `0` 更新为 `PROPAGATE` 。
+
+AQS 中，Node 节点的 `PROPAGATE` 就是为了处理并发场景下可能出现的无法唤醒线程节点的问题。`PROPAGATE` 只在 `doReleaseShared()` 方法中用到一次。
+
+**接下来通过案例分析，为什么需要 `PROPAGATE` 状态？**
+
+在共享模式下，线程获取和释放资源的方法调用链如下：
+
+- 线程获取资源的方法调用链为： `acquireShared() -> tryAcquireShared() -> 线程阻塞等待唤醒 -> tryAcquireShared() -> setHeadAndPropagate() -> if (剩余资源数 > 0) || (head.waitStatus < 0) 则唤醒后续节点` 。
+
+- 线程释放资源的方法调用链为： `releaseShared() -> tryReleaseShared() -> doReleaseShared()` 。
+
+**如果在释放资源时，没有将 `head` 节点的状态由 `0` 改为 `PROPAGATE` ：**
+
+假设总共有 4 个线程尝试以共享模式获取资源，总共有 2 个资源。初始 `T3` 和 `T4` 线程获取到了资源，`T1` 和 `T2` 线程没有获取到，因此在队列中排队等候。
+
+- 在时刻 1 时，线程 `T1` 和 `T2` 在等待队列中，`T3` 和 `T4` 持有资源。此时等待队列内节点以及对应状态为（括号内为节点的 `waitStatus` 状态）：
+
+ `head(-1) -> T1(-1) -> T2(0)` 。
+
+- 在时刻 2 时，线程 `T3` 释放资源，通过 `doReleaseShared()` 方法将 `head` 节点的状态由 `SIGNAL` 更新为 `0` ，并唤醒线程 `T1` ，之后线程 `T3` 退出。
+
+ 线程 `T1` 被唤醒之后，通过 `tryAcquireShared()` 获取到资源，但是此时还未来得及执行 `setHeadAndPropagate()` 将自己设置为 `head` 节点。此时等待队列内节点状态为：
+
+ `head(0) -> T1(-1) -> T2(0)` 。
+
+- 在时刻 3 时，线程 `T4` 释放资源， 由于此时 `head` 节点的状态为 `0` ，因此在 `doReleaseShared()` 方法中无法唤醒 `head` 的后继节点， 之后线程 `T4` 退出。
+
+- 在时刻 4 时，线程 `T1` 继续执行 `setHeadAndPropagate()` 方法将自己设置为 `head` 节点。
+
+ 但是此时由于线程 `T1` 执行 `tryAcquireShared()` 方法返回的剩余资源数为 `0` ，并且 `head` 节点的状态为 `0` ，因此线程 `T1` 并不会在 `setHeadAndPropagate()` 方法中唤醒后续节点。此时等待队列内节点状态为：
+
+ `head(-1，线程 T1 节点) -> T2(0)` 。
+
+此时，就导致线程 `T2` 节点在等待队列中，无法被唤醒。对应时刻表如下：
+
+| 时刻 | 线程 T1 | 线程 T2 | 线程 T3 | 线程 T4 | 等待队列 |
+| ------ | -------------------------------------------------------------- | -------- | ---------------- | ------------------------------------------------------------- | --------------------------------- |
+| 时刻 1 | 等待队列 | 等待队列 | 持有资源 | 持有资源 | `head(-1) -> T1(-1) -> T2(0)` |
+| 时刻 2 | （执行）被唤醒后，获取资源，但未来得及将自己设置为 `head` 节点 | 等待队列 | （执行）释放资源 | 持有资源 | `head(0) -> T1(-1) -> T2(0)` |
+| 时刻 3 | | 等待队列 | 已退出 | （执行）释放资源。但 `head` 节点状态为 `0` ，无法唤醒后继节点 | `head(0) -> T1(-1) -> T2(0)` |
+| 时刻 4 | （执行）将自己设置为 `head` 节点 | 等待队列 | 已退出 | 已退出 | `head(-1，线程 T1 节点) -> T2(0)` |
+
+**如果在线程释放资源时，将 `head` 节点的状态由 `0` 改为 `PROPAGATE` ，则可以解决上边出现的并发问题，如下：**
+
+- 在时刻 1 时，线程 `T1` 和 `T2` 在等待队列中，`T3` 和 `T4` 持有资源。此时等待队列内节点以及对应状态为：
+
+ `head(-1) -> T1(-1) -> T2(0)` 。
+
+- 在时刻 2 时，线程 `T3` 释放资源，通过 `doReleaseShared()` 方法将 `head` 节点的状态由 `SIGNAL` 更新为 `0` ，并唤醒线程 `T1` ，之后线程 `T3` 退出。
+
+ 线程 `T1` 被唤醒之后，通过 `tryAcquireShared()` 获取到资源，但是此时还未来得及执行 `setHeadAndPropagate()` 将自己设置为 `head` 节点。此时等待队列内节点状态为：
+
+ `head(0) -> T1(-1) -> T2(0)` 。
+
+- 在时刻 3 时，线程 `T4` 释放资源， 由于此时 `head` 节点的状态为 `0` ，因此在 `doReleaseShared()` 方法中会将 `head` 节点的状态由 `0` 更新为 `PROPAGATE` ， 之后线程 `T4` 退出。此时等待队列内节点状态为：
+
+ `head(PROPAGATE) -> T1(-1) -> T2(0)` 。
+
+- 在时刻 4 时，线程 `T1` 继续执行 `setHeadAndPropagate()` 方法将自己设置为 `head` 节点。此时等待队列内节点状态为：
+
+ `head(-1，线程 T1 节点) -> T2(0)` 。
+
+- 在时刻 5 时，虽然此时由于线程 `T1` 执行 `tryAcquireShared()` 方法返回的剩余资源数为 `0` ，但是 `head` 节点状态为 `PROPAGATE < 0` （这里的 `head` 节点是老的 `head` 节点，而不是刚成为 `head` 节点的线程 `T1` 节点）。
+
+ 因此线程 `T1` 会在 `setHeadAndPropagate()` 方法中唤醒后续 `T2` 节点，并将 `head` 节点的状态由 `SIGNAL` 更新为 `0`。此时等待队列内节点状态为：
+
+ `head(0，线程 T1 节点) -> T2(0)` 。
+
+- 在时刻 6 时，线程 `T2` 被唤醒后，获取到资源，并将自己设置为 `head` 节点。此时等待队列内节点状态为：
+
+ `head(0，线程 T2 节点)` 。
+
+有了 `PROPAGATE` 状态，就可以避免线程 `T2` 无法被唤醒的情况。对应时刻表如下：
+
+| 时刻 | 线程 T1 | 线程 T2 | 线程 T3 | 线程 T4 | 等待队列 |
+| ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | ---------------- | ------------------------------------------------------------------- | ------------------------------------ |
+| 时刻 1 | 等待队列 | 等待队列 | 持有资源 | 持有资源 | `head(-1) -> T1(-1) -> T2(0)` |
+| 时刻 2 | （执行）被唤醒后，获取资源，但未来得及将自己设置为 `head` 节点 | 等待队列 | （执行）释放资源 | 持有资源 | `head(0) -> T1(-1) -> T2(0)` |
+| 时刻 3 | 未继续向下执行 | 等待队列 | 已退出 | （执行）释放资源。此时会将 `head` 节点状态由 `0` 更新为 `PROPAGATE` | `head(PROPAGATE) -> T1(-1) -> T2(0)` |
+| 时刻 4 | （执行）将自己设置为 `head` 节点 | 等待队列 | 已退出 | 已退出 | `head(-1，线程 T1 节点) -> T2(0)` |
+| 时刻 5 | （执行）由于 `head` 节点状态为 `PROPAGATE < 0` ，因此会在 `setHeadAndPropagate()` 方法中唤醒后续节点，此时将新的 `head` 节点的状态由 `SIGNAL` 更新为 `0` ，并唤醒线程 `T2` | 等待队列 | 已退出 | 已退出 | `head(0，线程 T1 节点) -> T2(0)` |
+| 时刻 6 | 已退出 | （执行）线程 `T2` 被唤醒后，获取到资源，并将自己设置为 `head` 节点 | 已退出 | 已退出 | `head(0，线程 T2 节点)` |
+
+### AQS 资源释放源码分析（共享模式）
+
+AQS 中以共享模式释放资源的入口方法是 `releaseShared()` ，代码如下：
+
+```JAVA
+// AQS
+public final boolean releaseShared(int arg) {
+ if (tryReleaseShared(arg)) {
+ doReleaseShared();
+ return true;
+ }
+ return false;
+}
+```
+
+其中 `tryReleaseShared()` 方法是 AQS 提供的模板方法，这里同样以 `Semaphore` 来讲解，如下：
+
+```JAVA
+// Semaphore
+protected final boolean tryReleaseShared(int releases) {
+ for (;;) {
+ int current = getState();
+ int next = current + releases;
+ if (next < current) // overflow
+ throw new Error("Maximum permit count exceeded");
+ if (compareAndSetState(current, next))
+ return true;
+ }
+}
+```
+
+在 `Semaphore` 实现的 `tryReleaseShared()` 方法中，会在死循环内不断尝试释放资源，即通过 `CAS` 操作来更新 `state` 值。
+
+如果更新成功，则证明资源释放成功，会进入到 `doReleaseShared()` 方法。
+
+`doReleaseShared()` 方法在前文获取资源（共享模式）的部分已进行了详细的源码分析，此处不再重复。
+
## 常见同步工具类
下面介绍几个基于 AQS 的常见同步工具类。
@@ -331,8 +1145,7 @@ semaphore.release(5);// 释放5个许可
[issue645 补充内容](https://github.com/Snailclimb/JavaGuide/issues/645)：
-> `Semaphore` 与 `CountDownLatch` 一样，也是共享锁的一种实现。它默认构造 AQS 的 `state` 为 `permits`。当执行任务的线程数量超出 `permits`，那么多余的线程将会被放入等待队列 `Park`,并自旋判断 `state` 是否大于 0。只有当 `state` 大于 0 的时候，阻塞的线程才能继续执行,此时先前执行任务的线程继续执行 `release()` 方法，`release()` 方法使得 state 的变量会加 1，那么自旋的线程便会判断成功。
-> 如此，每次只有最多不超过 `permits` 数量的线程能自旋成功，便限制了执行任务线程的数量。
+> `Semaphore` 基于 AQS 实现，用于控制并发访问的线程数量，但它与共享锁的概念有所不同。`Semaphore` 的构造函数使用 `permits` 参数初始化 AQS 的 `state` 变量，该变量表示可用的许可数量。当线程调用 `acquire()` 方法尝试获取许可时，`state` 会原子性地减 1。如果 `state` 减 1 后大于等于 0，则 `acquire()` 成功返回，线程可以继续执行。如果 `state` 减 1 后小于 0，表示当前并发访问的线程数量已达到 `permits` 的限制，该线程会被放入 AQS 的等待队列并阻塞，**而不是自旋等待**。当其他线程完成任务并调用 `release()` 方法时，`state` 会原子性地加 1。`release()` 操作会唤醒 AQS 等待队列中的一个或多个阻塞线程。这些被唤醒的线程将再次尝试 `acquire()` 操作，竞争获取可用的许可。因此，`Semaphore` 通过控制许可数量来限制并发访问的线程数量，而不是通过自旋和共享锁机制。
### CountDownLatch （倒计时器）
@@ -406,7 +1219,7 @@ protected boolean tryReleaseShared(int releases) {
}
```
-以无参 `await`方法为例，当调用 `await()` 的时候，如果 `state` 不为 0，那就证明任务还没有执行完毕，`await()` 就会一直阻塞，也就是说 `await()` 之后的语句不会被执行（`main` 线程被加入到等待队列也就是 CLH 队列中了）。然后，`CountDownLatch` 会自旋 CAS 判断 `state == 0`，如果 `state == 0` 的话，就会释放所有等待的线程，`await()` 方法之后的语句得到执行。
+以无参 `await`方法为例，当调用 `await()` 的时候，如果 `state` 不为 0，那就证明任务还没有执行完毕，`await()` 就会一直阻塞，也就是说 `await()` 之后的语句不会被执行（`main` 线程被加入到等待队列也就是 变体 CLH 队列中了）。然后，`CountDownLatch` 会自旋 CAS 判断 `state == 0`，如果 `state == 0` 的话，就会释放所有等待的线程，`await()` 方法之后的语句得到执行。
```java
// 等待（也可以叫做加锁）
@@ -511,7 +1324,7 @@ for (int i = 0; i < threadCount-1; i++) {
`CyclicBarrier` 和 `CountDownLatch` 非常类似，它也可以实现线程间的技术等待，但是它的功能比 `CountDownLatch` 更加复杂和强大。主要应用场景和 `CountDownLatch` 类似。
-> `CountDownLatch` 的实现是基于 AQS 的，而 `CycliBarrier` 是基于 `ReentrantLock`(`ReentrantLock` 也属于 AQS 同步器)和 `Condition` 的。
+> `CountDownLatch` 的实现是基于 AQS 的，而 `CyclicBarrier` 是基于 `ReentrantLock`(`ReentrantLock` 也属于 AQS 同步器)和 `Condition` 的。
`CyclicBarrier` 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是：让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。
diff --git a/docs/java/concurrent/atomic-classes.md b/docs/java/concurrent/atomic-classes.md
index 95591d60612..ec47ba6f66f 100644
--- a/docs/java/concurrent/atomic-classes.md
+++ b/docs/java/concurrent/atomic-classes.md
@@ -7,17 +7,21 @@ tag:
## Atomic 原子类介绍
-Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是构成一般物质的最小单位，在化学反应中是不可分割的。在我们这里 Atomic 是指一个操作是不可中断的。即使是在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程干扰。
+`Atomic` 翻译成中文是“原子”的意思。在化学上，原子是构成物质的最小单位，在化学反应中不可分割。在编程中，`Atomic` 指的是一个操作具有原子性，即该操作不可分割、不可中断。即使在多个线程同时执行时，该操作要么全部执行完成，要么不执行，不会被其他线程看到部分完成的状态。
-所以，所谓原子类说简单点就是具有原子/原子操作特征的类。
+原子类简单来说就是具有原子性操作特征的类。
-并发包 `java.util.concurrent` 的原子类都存放在`java.util.concurrent.atomic`下,如下图所示。
+`java.util.concurrent.atomic` 包中的 `Atomic` 原子类提供了一种线程安全的方式来操作单个变量。
+
+`Atomic` 类依赖于 CAS（Compare-And-Swap，比较并交换）乐观锁来保证其方法的原子性，而不需要使用传统的锁机制（如 `synchronized` 块或 `ReentrantLock`）。
+
+这篇文章我们只介绍 Atomic 原子类的概念，具体实现原理可以阅读笔者写的这篇文章：[CAS 详解](./cas.md)。
-根据操作的数据类型，可以将 JUC 包中的原子类分为 4 类
+根据操作的数据类型，可以将 JUC 包中的原子类分为 4 类：
-**基本类型**
+**1、基本类型**
使用原子的方式更新基本类型
@@ -25,7 +29,7 @@ Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是
- `AtomicLong`：长整型原子类
- `AtomicBoolean`：布尔型原子类
-**数组类型**
+**2、数组类型**
使用原子的方式更新数组里的某个元素
@@ -33,7 +37,7 @@ Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是
- `AtomicLongArray`：长整型数组原子类
- `AtomicReferenceArray`：引用类型数组原子类
-**引用类型**
+**3、引用类型**
- `AtomicReference`：引用类型原子类
- `AtomicMarkableReference`：原子更新带有标记的引用类型。该类将 boolean 标记与引用关联起来，~~也可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题~~。
@@ -41,7 +45,7 @@ Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是
**🐛 修正（参见：[issue#626](https://github.com/Snailclimb/JavaGuide/issues/626)）** : `AtomicMarkableReference` 不能解决 ABA 问题。
-**对象的属性修改类型**
+**4、对象的属性修改类型**
- `AtomicIntegerFieldUpdater`:原子更新整型字段的更新器
- `AtomicLongFieldUpdater`：原子更新长整型字段的更新器
@@ -57,7 +61,7 @@ Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是
上面三个类提供的方法几乎相同，所以我们这里以 `AtomicInteger` 为例子来介绍。
-**AtomicInteger 类常用方法**
+**`AtomicInteger` 类常用方法** ：
```java
public final int get() //获取当前的值
@@ -66,90 +70,51 @@ public final int getAndIncrement()//获取当前的值，并自增
public final int getAndDecrement() //获取当前的值，并自减
public final int getAndAdd(int delta) //获取当前的值，并加上预期的值
boolean compareAndSet(int expect, int update) //如果输入的数值等于预期值，则以原子方式将该值设置为输入值（update）
-public final void lazySet(int newValue)//最终设置为newValue,使用 lazySet 设置之后可能导致其他线程在之后的一小段时间内还是可以读到旧的值。
+public final void lazySet(int newValue)//最终设置为newValue, lazySet 提供了一种比 set 方法更弱的语义，可能导致其他线程在之后的一小段时间内还是可以读到旧的值，但可能更高效。
```
**`AtomicInteger` 类使用示例** :
```java
-import java.util.concurrent.atomic.AtomicInteger;
-
-public class AtomicIntegerTest {
-
- public static void main(String[] args) {
- int temvalue = 0;
- AtomicInteger i = new AtomicInteger(0);
- temvalue = i.getAndSet(3);
- System.out.println("temvalue:" + temvalue + "; i:" + i); //temvalue:0; i:3
- temvalue = i.getAndIncrement();
- System.out.println("temvalue:" + temvalue + "; i:" + i); //temvalue:3; i:4
- temvalue = i.getAndAdd(5);
- System.out.println("temvalue:" + temvalue + "; i:" + i); //temvalue:4; i:9
- }
-
-}
-```
-
-### 基本数据类型原子类的优势
+// 初始化 AtomicInteger 对象，初始值为 0
+AtomicInteger atomicInt = new AtomicInteger(0);
-通过一个简单例子带大家看一下基本数据类型原子类的优势
+// 使用 getAndSet 方法获取当前值，并设置新值为 3
+int tempValue = atomicInt.getAndSet(3);
+System.out.println("tempValue: " + tempValue + "; atomicInt: " + atomicInt);
-**1、多线程环境不使用原子类保证线程安全（基本数据类型）**
+// 使用 getAndIncrement 方法获取当前值，并自增 1
+tempValue = atomicInt.getAndIncrement();
+System.out.println("tempValue: " + tempValue + "; atomicInt: " + atomicInt);
-```java
-class Test {
- private volatile int count = 0;
- //若要线程安全执行执行count++，需要加锁
- public synchronized void increment() {
- count++;
- }
-
- public int getCount() {
- return count;
- }
-}
-```
+// 使用 getAndAdd 方法获取当前值，并增加指定值 5
+tempValue = atomicInt.getAndAdd(5);
+System.out.println("tempValue: " + tempValue + "; atomicInt: " + atomicInt);
-**2、多线程环境使用原子类保证线程安全（基本数据类型）**
+// 使用 compareAndSet 方法进行原子性条件更新，期望值为 9，更新值为 10
+boolean updateSuccess = atomicInt.compareAndSet(9, 10);
+System.out.println("Update Success: " + updateSuccess + "; atomicInt: " + atomicInt);
-```java
-class Test2 {
- private AtomicInteger count = new AtomicInteger();
-
- public void increment() {
- count.incrementAndGet();
- }
- //使用AtomicInteger之后，不需要加锁，也可以实现线程安全。
- public int getCount() {
- return count.get();
- }
-}
+// 获取当前值
+int currentValue = atomicInt.get();
+System.out.println("Current value: " + currentValue);
+// 使用 lazySet 方法设置新值为 15
+atomicInt.lazySet(15);
+System.out.println("After lazySet, atomicInt: " + atomicInt);
```
-### AtomicInteger 线程安全原理简单分析
-
-`AtomicInteger` 类的部分源码：
+输出：
```java
- // setup to use Unsafe.compareAndSwapInt for updates（更新操作时提供“比较并替换”的作用）
- private static final Unsafe unsafe = Unsafe.getUnsafe();
- private static final long valueOffset;
-
- static {
- try {
- valueOffset = unsafe.objectFieldOffset
- (AtomicInteger.class.getDeclaredField("value"));
- } catch (Exception ex) { throw new Error(ex); }
- }
-
- private volatile int value;
+tempValue: 0; atomicInt: 3
+tempValue: 3; atomicInt: 4
+tempValue: 4; atomicInt: 9
+Update Success: true; atomicInt: 10
+Current value: 10
+After lazySet, atomicInt: 15
```
-`AtomicInteger` 类主要利用 CAS (compare and swap) + volatile 和 native 方法来保证原子操作，从而避免 synchronized 的高开销，执行效率大为提升。
-
-CAS 的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值。UnSafe 类的 `objectFieldOffset()` 方法是一个本地方法，这个方法是用来拿到“原来的值”的内存地址。另外 value 是一个 volatile 变量，在内存中可见，因此 JVM 可以保证任何时刻任何线程总能拿到该变量的最新值。
-
## 数组类型原子类
使用原子的方式更新数组里的某个元素
@@ -175,28 +140,57 @@ public final void lazySet(int i, int newValue)//最终 将index=i 位置的元
**`AtomicIntegerArray` 类使用示例** :
```java
-import java.util.concurrent.atomic.AtomicIntegerArray;
-
-public class AtomicIntegerArrayTest {
-
- public static void main(String[] args) {
- int temvalue = 0;
- int[] nums = { 1, 2, 3, 4, 5, 6 };
- AtomicIntegerArray i = new AtomicIntegerArray(nums);
- for (int j = 0; j < nums.length; j++) {
- System.out.println(i.get(j));
- }
- temvalue = i.getAndSet(0, 2);
- System.out.println("temvalue:" + temvalue + "; i:" + i);
- temvalue = i.getAndIncrement(0);
- System.out.println("temvalue:" + temvalue + "; i:" + i);
- temvalue = i.getAndAdd(0, 5);
- System.out.println("temvalue:" + temvalue + "; i:" + i);
- }
+int[] nums = {1, 2, 3, 4, 5, 6};
+// 创建 AtomicIntegerArray
+AtomicIntegerArray atomicArray = new AtomicIntegerArray(nums);
+
+// 打印 AtomicIntegerArray 中的初始值
+System.out.println("Initial values in AtomicIntegerArray:");
+for (int j = 0; j < nums.length; j++) {
+ System.out.print("Index " + j + ": " + atomicArray.get(j) + " ");
+}
+
+// 使用 getAndSet 方法将索引 0 处的值设置为 2，并返回旧值
+int tempValue = atomicArray.getAndSet(0, 2);
+System.out.println("\nAfter getAndSet(0, 2):");
+System.out.println("Returned value: " + tempValue);
+for (int j = 0; j < atomicArray.length(); j++) {
+ System.out.print("Index " + j + ": " + atomicArray.get(j) + " ");
+}
+
+// 使用 getAndIncrement 方法将索引 0 处的值加 1，并返回旧值
+tempValue = atomicArray.getAndIncrement(0);
+System.out.println("\nAfter getAndIncrement(0):");
+System.out.println("Returned value: " + tempValue);
+for (int j = 0; j < atomicArray.length(); j++) {
+ System.out.print("Index " + j + ": " + atomicArray.get(j) + " ");
+}
+// 使用 getAndAdd 方法将索引 0 处的值增加 5，并返回旧值
+tempValue = atomicArray.getAndAdd(0, 5);
+System.out.println("\nAfter getAndAdd(0, 5):");
+System.out.println("Returned value: " + tempValue);
+for (int j = 0; j < atomicArray.length(); j++) {
+ System.out.print("Index " + j + ": " + atomicArray.get(j) + " ");
}
```
+输出：
+
+```plain
+Initial values in AtomicIntegerArray:
+Index 0: 1 Index 1: 2 Index 2: 3 Index 3: 4 Index 4: 5 Index 5: 6
+After getAndSet(0, 2):
+Returned value: 1
+Index 0: 2 Index 1: 2 Index 2: 3 Index 3: 4 Index 4: 5 Index 5: 6
+After getAndIncrement(0):
+Returned value: 2
+Index 0: 3 Index 1: 2 Index 2: 3 Index 3: 4 Index 4: 5 Index 5: 6
+After getAndAdd(0, 5):
+Returned value: 3
+Index 0: 8 Index 1: 2 Index 2: 3 Index 3: 4 Index 4: 5 Index 5: 6
+```
+
## 引用类型原子类
基本类型原子类只能更新一个变量，如果需要原子更新多个变量，需要使用 引用类型原子类。
@@ -210,174 +204,133 @@ public class AtomicIntegerArrayTest {
**`AtomicReference` 类使用示例** :
```java
-import java.util.concurrent.atomic.AtomicReference;
-
-public class AtomicReferenceTest {
-
- public static void main(String[] args) {
- AtomicReference < Person > ar = new AtomicReference < Person > ();
- Person person = new Person("SnailClimb", 22);
- ar.set(person);
- Person updatePerson = new Person("Daisy", 20);
- ar.compareAndSet(person, updatePerson);
-
- System.out.println(ar.get().getName());
- System.out.println(ar.get().getAge());
- }
-}
-
+// Person 类
class Person {
private String name;
private int age;
+ //省略getter/setter和toString
+}
- public Person(String name, int age) {
- super();
- this.name = name;
- this.age = age;
- }
- public String getName() {
- return name;
- }
+// 创建 AtomicReference 对象并设置初始值
+AtomicReference ar = new AtomicReference<>(new Person("SnailClimb", 22));
- public void setName(String name) {
- this.name = name;
- }
+// 打印初始值
+System.out.println("Initial Person: " + ar.get().toString());
- public int getAge() {
- return age;
- }
+// 更新值
+Person updatePerson = new Person("Daisy", 20);
+ar.compareAndSet(ar.get(), updatePerson);
- public void setAge(int age) {
- this.age = age;
- }
+// 打印更新后的值
+System.out.println("Updated Person: " + ar.get().toString());
-}
+// 尝试再次更新
+Person anotherUpdatePerson = new Person("John", 30);
+boolean isUpdated = ar.compareAndSet(updatePerson, anotherUpdatePerson);
+
+// 打印是否更新成功及最终值
+System.out.println("Second Update Success: " + isUpdated);
+System.out.println("Final Person: " + ar.get().toString());
```
-上述代码首先创建了一个 `Person` 对象，然后把 `Person` 对象设置进 `AtomicReference` 对象中，然后调用 `compareAndSet` 方法，该方法就是通过 CAS 操作设置 ar。如果 ar 的值为 `person` 的话，则将其设置为 `updatePerson`。实现原理与 `AtomicInteger` 类中的 `compareAndSet` 方法相同。运行上面的代码后的输出结果如下：
+输出：
```plain
-Daisy
-20
+Initial Person: Person{name='SnailClimb', age=22}
+Updated Person: Person{name='Daisy', age=20}
+Second Update Success: true
+Final Person: Person{name='John', age=30}
```
**`AtomicStampedReference` 类使用示例** :
```java
-import java.util.concurrent.atomic.AtomicStampedReference;
-
-public class AtomicStampedReferenceDemo {
- public static void main(String[] args) {
- // 实例化、取当前值和 stamp 值
- final Integer initialRef = 0, initialStamp = 0;
- final AtomicStampedReference asr = new AtomicStampedReference<>(initialRef, initialStamp);
- System.out.println("currentValue=" + asr.getReference() + ", currentStamp=" + asr.getStamp());
-
- // compare and set
- final Integer newReference = 666, newStamp = 999;
- final boolean casResult = asr.compareAndSet(initialRef, newReference, initialStamp, newStamp);
- System.out.println("currentValue=" + asr.getReference()
- + ", currentStamp=" + asr.getStamp()
- + ", casResult=" + casResult);
-
- // 获取当前的值和当前的 stamp 值
- int[] arr = new int[1];
- final Integer currentValue = asr.get(arr);
- final int currentStamp = arr[0];
- System.out.println("currentValue=" + currentValue + ", currentStamp=" + currentStamp);
-
- // 单独设置 stamp 值
- final boolean attemptStampResult = asr.attemptStamp(newReference, 88);
- System.out.println("currentValue=" + asr.getReference()
- + ", currentStamp=" + asr.getStamp()
- + ", attemptStampResult=" + attemptStampResult);
-
- // 重新设置当前值和 stamp 值
- asr.set(initialRef, initialStamp);
- System.out.println("currentValue=" + asr.getReference() + ", currentStamp=" + asr.getStamp());
-
- // [不推荐使用，除非搞清楚注释的意思了] weak compare and set
- // 困惑！weakCompareAndSet 这个方法最终还是调用 compareAndSet 方法。[版本: jdk-8u191]
- // 但是注释上写着 "May fail spuriously and does not provide ordering guarantees,
- // so is only rarely an appropriate alternative to compareAndSet."
- // todo 感觉有可能是 jvm 通过方法名在 native 方法里面做了转发
- final boolean wCasResult = asr.weakCompareAndSet(initialRef, newReference, initialStamp, newStamp);
- System.out.println("currentValue=" + asr.getReference()
- + ", currentStamp=" + asr.getStamp()
- + ", wCasResult=" + wCasResult);
- }
-}
+// 创建一个 AtomicStampedReference 对象，初始值为 "SnailClimb"，初始版本号为 1
+AtomicStampedReference asr = new AtomicStampedReference<>("SnailClimb", 1);
+
+// 打印初始值和版本号
+int[] initialStamp = new int[1];
+String initialRef = asr.get(initialStamp);
+System.out.println("Initial Reference: " + initialRef + ", Initial Stamp: " + initialStamp[0]);
+
+// 更新值和版本号
+int oldStamp = initialStamp[0];
+String oldRef = initialRef;
+String newRef = "Daisy";
+int newStamp = oldStamp + 1;
+
+boolean isUpdated = asr.compareAndSet(oldRef, newRef, oldStamp, newStamp);
+System.out.println("Update Success: " + isUpdated);
+
+// 打印更新后的值和版本号
+int[] updatedStamp = new int[1];
+String updatedRef = asr.get(updatedStamp);
+System.out.println("Updated Reference: " + updatedRef + ", Updated Stamp: " + updatedStamp[0]);
+
+// 尝试用错误的版本号更新
+boolean isUpdatedWithWrongStamp = asr.compareAndSet(newRef, "John", oldStamp, newStamp + 1);
+System.out.println("Update with Wrong Stamp Success: " + isUpdatedWithWrongStamp);
+
+// 打印最终的值和版本号
+int[] finalStamp = new int[1];
+String finalRef = asr.get(finalStamp);
+System.out.println("Final Reference: " + finalRef + ", Final Stamp: " + finalStamp[0]);
```
输出结果如下：
```plain
-currentValue=0, currentStamp=0
-currentValue=666, currentStamp=999, casResult=true
-currentValue=666, currentStamp=999
-currentValue=666, currentStamp=88, attemptStampResult=true
-currentValue=0, currentStamp=0
-currentValue=666, currentStamp=999, wCasResult=true
+Initial Reference: SnailClimb, Initial Stamp: 1
+Update Success: true
+Updated Reference: Daisy, Updated Stamp: 2
+Update with Wrong Stamp Success: false
+Final Reference: Daisy, Final Stamp: 2
```
**`AtomicMarkableReference` 类使用示例** :
```java
-import java.util.concurrent.atomic.AtomicMarkableReference;
-
-public class AtomicMarkableReferenceDemo {
- public static void main(String[] args) {
- // 实例化、取当前值和 mark 值
- final Boolean initialRef = null, initialMark = false;
- final AtomicMarkableReference amr = new AtomicMarkableReference<>(initialRef, initialMark);
- System.out.println("currentValue=" + amr.getReference() + ", currentMark=" + amr.isMarked());
-
- // compare and set
- final Boolean newReference1 = true, newMark1 = true;
- final boolean casResult = amr.compareAndSet(initialRef, newReference1, initialMark, newMark1);
- System.out.println("currentValue=" + amr.getReference()
- + ", currentMark=" + amr.isMarked()
- + ", casResult=" + casResult);
-
- // 获取当前的值和当前的 mark 值
- boolean[] arr = new boolean[1];
- final Boolean currentValue = amr.get(arr);
- final boolean currentMark = arr[0];
- System.out.println("currentValue=" + currentValue + ", currentMark=" + currentMark);
-
- // 单独设置 mark 值
- final boolean attemptMarkResult = amr.attemptMark(newReference1, false);
- System.out.println("currentValue=" + amr.getReference()
- + ", currentMark=" + amr.isMarked()
- + ", attemptMarkResult=" + attemptMarkResult);
-
- // 重新设置当前值和 mark 值
- amr.set(initialRef, initialMark);
- System.out.println("currentValue=" + amr.getReference() + ", currentMark=" + amr.isMarked());
-
- // [不推荐使用，除非搞清楚注释的意思了] weak compare and set
- // 困惑！weakCompareAndSet 这个方法最终还是调用 compareAndSet 方法。[版本: jdk-8u191]
- // 但是注释上写着 "May fail spuriously and does not provide ordering guarantees,
- // so is only rarely an appropriate alternative to compareAndSet."
- // todo 感觉有可能是 jvm 通过方法名在 native 方法里面做了转发
- final boolean wCasResult = amr.weakCompareAndSet(initialRef, newReference1, initialMark, newMark1);
- System.out.println("currentValue=" + amr.getReference()
- + ", currentMark=" + amr.isMarked()
- + ", wCasResult=" + wCasResult);
- }
-}
+// 创建一个 AtomicMarkableReference 对象，初始值为 "SnailClimb"，初始标记为 false
+AtomicMarkableReference amr = new AtomicMarkableReference<>("SnailClimb", false);
+
+// 打印初始值和标记
+boolean[] initialMark = new boolean[1];
+String initialRef = amr.get(initialMark);
+System.out.println("Initial Reference: " + initialRef + ", Initial Mark: " + initialMark[0]);
+
+// 更新值和标记
+String oldRef = initialRef;
+String newRef = "Daisy";
+boolean oldMark = initialMark[0];
+boolean newMark = true;
+
+boolean isUpdated = amr.compareAndSet(oldRef, newRef, oldMark, newMark);
+System.out.println("Update Success: " + isUpdated);
+
+// 打印更新后的值和标记
+boolean[] updatedMark = new boolean[1];
+String updatedRef = amr.get(updatedMark);
+System.out.println("Updated Reference: " + updatedRef + ", Updated Mark: " + updatedMark[0]);
+
+// 尝试用错误的标记更新
+boolean isUpdatedWithWrongMark = amr.compareAndSet(newRef, "John", oldMark, !newMark);
+System.out.println("Update with Wrong Mark Success: " + isUpdatedWithWrongMark);
+
+// 打印最终的值和标记
+boolean[] finalMark = new boolean[1];
+String finalRef = amr.get(finalMark);
+System.out.println("Final Reference: " + finalRef + ", Final Mark: " + finalMark[0]);
```
输出结果如下：
```plain
-currentValue=null, currentMark=false
-currentValue=true, currentMark=true, casResult=true
-currentValue=true, currentMark=true
-currentValue=true, currentMark=false, attemptMarkResult=true
-currentValue=null, currentMark=false
-currentValue=true, currentMark=true, wCasResult=true
+Initial Reference: SnailClimb, Initial Mark: false
+Update Success: true
+Updated Reference: Daisy, Updated Mark: true
+Update with Wrong Mark Success: false
+Final Reference: Daisy, Final Mark: true
```
## 对象的属性修改类型原子类
@@ -388,59 +341,55 @@ currentValue=true, currentMark=true, wCasResult=true
- `AtomicLongFieldUpdater`：原子更新长整形字段的更新器
- `AtomicReferenceFieldUpdater`：原子更新引用类型里的字段的更新器
-要想原子地更新对象的属性需要两步。第一步，因为对象的属性修改类型原子类都是抽象类，所以每次使用都必须使用静态方法 newUpdater()创建一个更新器，并且需要设置想要更新的类和属性。第二步，更新的对象属性必须使用 public volatile 修饰符。
+要想原子地更新对象的属性需要两步。第一步，因为对象的属性修改类型原子类都是抽象类，所以每次使用都必须使用静态方法 newUpdater()创建一个更新器，并且需要设置想要更新的类和属性。第二步，更新的对象属性必须使用 volatile int 修饰符。
上面三个类提供的方法几乎相同，所以我们这里以 `AtomicIntegerFieldUpdater`为例子来介绍。
**`AtomicIntegerFieldUpdater` 类使用示例** :
```java
-import java.util.concurrent.atomic.AtomicIntegerFieldUpdater;
-
-public class AtomicIntegerFieldUpdaterTest {
- public static void main(String[] args) {
- AtomicIntegerFieldUpdater a = AtomicIntegerFieldUpdater.newUpdater(User.class, "age");
-
- User user = new User("Java", 22);
- System.out.println(a.getAndIncrement(user));// 22
- System.out.println(a.get(user));// 23
- }
+// Person 类
+class Person {
+ private String name;
+ // 要使用 AtomicIntegerFieldUpdater，字段必须是 volatile int
+ volatile int age;
+ //省略getter/setter和toString
}
-class User {
- private String name;
- public volatile int age;
+// 创建 AtomicIntegerFieldUpdater 对象
+AtomicIntegerFieldUpdater ageUpdater = AtomicIntegerFieldUpdater.newUpdater(Person.class, "age");
- public User(String name, int age) {
- super();
- this.name = name;
- this.age = age;
- }
+// 创建 Person 对象
+Person person = new Person("SnailClimb", 22);
- public String getName() {
- return name;
- }
+// 打印初始值
+System.out.println("Initial Person: " + person);
- public void setName(String name) {
- this.name = name;
- }
+// 更新 age 字段
+ageUpdater.incrementAndGet(person); // 自增
+System.out.println("After Increment: " + person);
- public int getAge() {
- return age;
- }
+ageUpdater.addAndGet(person, 5); // 增加 5
+System.out.println("After Adding 5: " + person);
- public void setAge(int age) {
- this.age = age;
- }
+ageUpdater.compareAndSet(person, 28, 30); // 如果当前值是 28，则设置为 30
+System.out.println("After Compare and Set (28 to 30): " + person);
-}
+// 尝试使用错误的比较值进行更新
+boolean isUpdated = ageUpdater.compareAndSet(person, 28, 35); // 这次应该失败
+System.out.println("Compare and Set (28 to 35) Success: " + isUpdated);
+System.out.println("Final Person: " + person);
```
输出结果：
```plain
-22
-23
+Initial Person: Name: SnailClimb, Age: 22
+After Increment: Name: SnailClimb, Age: 23
+After Adding 5: Name: SnailClimb, Age: 28
+After Compare and Set (28 to 30): Name: SnailClimb, Age: 30
+Compare and Set (28 to 35) Success: false
+Final Person: Name: SnailClimb, Age: 30
```
## 参考
diff --git a/docs/java/concurrent/cas.md b/docs/java/concurrent/cas.md
new file mode 100644
index 00000000000..af97f28d0c8
--- /dev/null
+++ b/docs/java/concurrent/cas.md
@@ -0,0 +1,162 @@
+---
+title: CAS 详解
+category: Java
+tag:
+ - Java并发
+---
+
+乐观锁和悲观锁的介绍以及乐观锁常见实现方式可以阅读笔者写的这篇文章：[乐观锁和悲观锁详解](https://javaguide.cn/java/concurrent/optimistic-lock-and-pessimistic-lock.html)。
+
+这篇文章主要介绍 ：Java 中 CAS 的实现以及 CAS 存在的一些问题。
+
+## Java 中 CAS 是如何实现的？
+
+在 Java 中，实现 CAS（Compare-And-Swap, 比较并交换）操作的一个关键类是`Unsafe`。
+
+`Unsafe`类位于`sun.misc`包下，是一个提供低级别、不安全操作的类。由于其强大的功能和潜在的危险性，它通常用于 JVM 内部或一些需要极高性能和底层访问的库中，而不推荐普通开发者在应用程序中使用。关于 `Unsafe`类的详细介绍，可以阅读这篇文章：📌[Java 魔法类 Unsafe 详解](https://javaguide.cn/java/basis/unsafe.html)。
+
+`sun.misc`包下的`Unsafe`类提供了`compareAndSwapObject`、`compareAndSwapInt`、`compareAndSwapLong`方法来实现的对`Object`、`int`、`long`类型的 CAS 操作：
+
+```java
+/**
+ * 以原子方式更新对象字段的值。
+ *
+ * @param o 要操作的对象
+ * @param offset 对象字段的内存偏移量
+ * @param expected 期望的旧值
+ * @param x 要设置的新值
+ * @return 如果值被成功更新，则返回 true；否则返回 false
+ */
+boolean compareAndSwapObject(Object o, long offset, Object expected, Object x);
+
+/**
+ * 以原子方式更新 int 类型的对象字段的值。
+ */
+boolean compareAndSwapInt(Object o, long offset, int expected, int x);
+
+/**
+ * 以原子方式更新 long 类型的对象字段的值。
+ */
+boolean compareAndSwapLong(Object o, long offset, long expected, long x);
+```
+
+`Unsafe`类中的 CAS 方法是`native`方法。`native`关键字表明这些方法是用本地代码（通常是 C 或 C++）实现的，而不是用 Java 实现的。这些方法直接调用底层的硬件指令来实现原子操作。也就是说，Java 语言并没有直接用 Java 实现 CAS。
+
+更准确点来说，Java 中 CAS 是 C++ 内联汇编的形式实现的，通过 JNI（Java Native Interface） 调用。因此，CAS 的具体实现与操作系统以及 CPU 密切相关。
+
+`java.util.concurrent.atomic` 包提供了一些用于原子操作的类。
+
+
+
+关于这些 Atomic 原子类的介绍和使用，可以阅读这篇文章：[Atomic 原子类总结](https://javaguide.cn/java/concurrent/atomic-classes.html)。
+
+Atomic 类依赖于 CAS 乐观锁来保证其方法的原子性，而不需要使用传统的锁机制（如 `synchronized` 块或 `ReentrantLock`）。
+
+`AtomicInteger`是 Java 的原子类之一，主要用于对 `int` 类型的变量进行原子操作，它利用`Unsafe`类提供的低级别原子操作方法实现无锁的线程安全性。
+
+下面，我们通过解读`AtomicInteger`的核心源码（JDK1.8），来说明 Java 如何使用`Unsafe`类的方法来实现原子操作。
+
+`AtomicInteger`核心源码如下：
+
+```java
+// 获取 Unsafe 实例
+private static final Unsafe unsafe = Unsafe.getUnsafe();
+private static final long valueOffset;
+
+static {
+ try {
+ // 获取“value”字段在AtomicInteger类中的内存偏移量
+ valueOffset = unsafe.objectFieldOffset
+ (AtomicInteger.class.getDeclaredField("value"));
+ } catch (Exception ex) { throw new Error(ex); }
+}
+// 确保“value”字段的可见性
+private volatile int value;
+
+// 如果当前值等于预期值，则原子地将值设置为newValue
+// 使用 Unsafe#compareAndSwapInt 方法进行CAS操作
+public final boolean compareAndSet(int expect, int update) {
+ return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
+}
+
+// 原子地将当前值加 delta 并返回旧值
+public final int getAndAdd(int delta) {
+ return unsafe.getAndAddInt(this, valueOffset, delta);
+}
+
+// 原子地将当前值加 1 并返回加之前的值（旧值）
+// 使用 Unsafe#getAndAddInt 方法进行CAS操作。
+public final int getAndIncrement() {
+ return unsafe.getAndAddInt(this, valueOffset, 1);
+}
+
+// 原子地将当前值减 1 并返回减之前的值（旧值）
+public final int getAndDecrement() {
+ return unsafe.getAndAddInt(this, valueOffset, -1);
+}
+```
+
+`Unsafe#getAndAddInt`源码：
+
+```java
+// 原子地获取并增加整数值
+public final int getAndAddInt(Object o, long offset, int delta) {
+ int v;
+ do {
+ // 以 volatile 方式获取对象 o 在内存偏移量 offset 处的整数值
+ v = getIntVolatile(o, offset);
+ } while (!compareAndSwapInt(o, offset, v, v + delta));
+ // 返回旧值
+ return v;
+}
+```
+
+可以看到，`getAndAddInt` 使用了 `do-while` 循环：在`compareAndSwapInt`操作失败时，会不断重试直到成功。也就是说，`getAndAddInt`方法会通过 `compareAndSwapInt` 方法来尝试更新 `value` 的值，如果更新失败（当前值在此期间被其他线程修改），它会重新获取当前值并再次尝试更新，直到操作成功。
+
+由于 CAS 操作可能会因为并发冲突而失败，因此通常会与`while`循环搭配使用，在失败后不断重试，直到操作成功。这就是 **自旋锁机制** 。
+
+## CAS 算法存在哪些问题？
+
+ABA 问题是 CAS 算法最常见的问题。
+
+### ABA 问题
+
+如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 **"ABA"问题。**
+
+ABA 问题的解决思路是在变量前面追加上**版本号或者时间戳**。JDK 1.5 以后的 `AtomicStampedReference` 类就是用来解决 ABA 问题的，其中的 `compareAndSet()` 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
+
+```java
+public boolean compareAndSet(V expectedReference,
+ V newReference,
+ int expectedStamp,
+ int newStamp) {
+ Pair current = pair;
+ return
+ expectedReference == current.reference &&
+ expectedStamp == current.stamp &&
+ ((newReference == current.reference &&
+ newStamp == current.stamp) ||
+ casPair(current, Pair.of(newReference, newStamp)));
+}
+```
+
+### 循环时间长开销大
+
+CAS 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。
+
+如果 JVM 能够支持处理器提供的`pause`指令，那么自旋操作的效率将有所提升。`pause`指令有两个重要作用：
+
+1. **延迟流水线执行指令**：`pause`指令可以延迟指令的执行，从而减少 CPU 的资源消耗。具体的延迟时间取决于处理器的实现版本，在某些处理器上，延迟时间可能为零。
+2. **避免内存顺序冲突**：在退出循环时，`pause`指令可以避免由于内存顺序冲突而导致的 CPU 流水线被清空，从而提高 CPU 的执行效率。
+
+### 只能保证一个共享变量的原子操作
+
+CAS 操作仅能对单个共享变量有效。当需要操作多个共享变量时，CAS 就显得无能为力。不过，从 JDK 1.5 开始，Java 提供了`AtomicReference`类，这使得我们能够保证引用对象之间的原子性。通过将多个变量封装在一个对象中，我们可以使用`AtomicReference`来执行 CAS 操作。
+
+除了 `AtomicReference` 这种方式之外，还可以利用加锁来保证。
+
+## 总结
+
+在 Java 中，CAS 通过 `Unsafe` 类中的 `native` 方法实现，这些方法调用底层的硬件指令来完成原子操作。由于其实现依赖于 C++ 内联汇编和 JNI 调用，因此 CAS 的具体实现与操作系统以及 CPU 密切相关。
+
+CAS 虽然具有高效的无锁特性，但也需要注意 ABA 、循环时间长开销大等问题。
diff --git a/docs/java/concurrent/completablefuture-intro.md b/docs/java/concurrent/completablefuture-intro.md
index 701d1420c59..be21c70e1c7 100644
--- a/docs/java/concurrent/completablefuture-intro.md
+++ b/docs/java/concurrent/completablefuture-intro.md
@@ -5,19 +5,25 @@ tag:
- Java并发
---
-一个接口可能需要调用 N 个其他服务的接口，这在项目开发中还是挺常见的。举个例子：用户请求获取订单信息，可能需要调用用户信息、商品详情、物流信息、商品推荐等接口，最后再汇总数据统一返回。
+实际项目中，一个接口可能需要同时获取多种不同的数据，然后再汇总返回，这种场景还是挺常见的。举个例子：用户请求获取订单信息，可能需要同时获取用户信息、商品详情、物流信息、商品推荐等数据。
-如果是串行（按顺序依次执行每个任务）执行的话，接口的响应速度会非常慢。考虑到这些接口之间有大部分都是 **无前后顺序关联** 的，可以 **并行执行** ，就比如说调用获取商品详情的时候，可以同时调用获取物流信息。通过并行执行多个任务的方式，接口的响应速度会得到大幅优化。
+如果是串行（按顺序依次执行每个任务）执行的话，接口的响应速度会非常慢。考虑到这些任务之间有大部分都是 **无前后顺序关联** 的，可以 **并行执行** ，就比如说调用获取商品详情的时候，可以同时调用获取物流信息。通过并行执行多个任务的方式，接口的响应速度会得到大幅优化。
-
+
-对于存在前后顺序关系的接口调用，可以进行编排，如下图所示。
+对于存在前后调用顺序关系的任务，可以进行任务编排。
1. 获取用户信息之后，才能调用商品详情和物流信息接口。
2. 成功获取商品详情和物流信息之后，才能调用商品推荐接口。
+可能会用到多线程异步任务编排的场景（这里只是举例，数据不一定是一次返回，可能会对接口进行拆分）：
+
+1. 首页：例如技术社区的首页可能需要同时获取文章推荐列表、广告栏、文章排行榜、热门话题等信息。
+2. 详情页：例如技术社区的文章详情页可能需要同时获取作者信息、文章详情、文章评论等信息。
+3. 统计模块：例如技术社区的后台统计模块可能需要同时获取粉丝数汇总、文章数据（阅读量、评论量、收藏量）汇总等信息。
+
对于 Java 程序来说，Java 8 才被引入的 `CompletableFuture` 可以帮助我们来做多个任务的编排，功能非常强大。
这篇文章是 `CompletableFuture` 的简单入门，带大家看看 `CompletableFuture` 常用的 API。
@@ -59,7 +65,7 @@ public interface Future {
## CompletableFuture 介绍
-`Future` 在实际使用过程中存在一些局限性比如不支持异步任务的编排组合、获取计算结果的 `get()` 方法为阻塞调用。
+`Future` 在实际使用过程中存在一些局限性，比如不支持异步任务的编排组合、获取计算结果的 `get()` 方法为阻塞调用。
Java 8 才被引入`CompletableFuture` 类可以解决`Future` 的这些缺陷。`CompletableFuture` 除了提供了更为好用和强大的 `Future` 特性之外，还提供了函数式编程、异步任务编排组合（可以将多个异步任务串联起来，组成一个完整的链式调用）等能力。
@@ -647,7 +653,15 @@ abc
我们上面的代码示例中，为了方便，都没有选择自定义线程池。实际项目中，这是不可取的。
-`CompletableFuture` 默认使用`ForkJoinPool.commonPool()` 作为执行器，这个线程池是全局共享的，可能会被其他任务占用，导致性能下降或者饥饿。因此，建议使用自定义的线程池来执行 `CompletableFuture` 的异步任务，可以提高并发度和灵活性。
+`CompletableFuture` 默认使用全局共享的 `ForkJoinPool.commonPool()` 作为执行器，所有未指定执行器的异步任务都会使用该线程池。这意味着应用程序、多个库或框架（如 Spring、第三方库）若都依赖 `CompletableFuture`，默认情况下它们都会共享同一个线程池。
+
+虽然 `ForkJoinPool` 效率很高，但当同时提交大量任务时，可能会导致资源竞争和线程饥饿，进而影响系统性能。
+
+为避免这些问题，建议为 `CompletableFuture` 提供自定义线程池，带来以下优势：
+
+- **隔离性**：为不同任务分配独立的线程池，避免全局线程池资源争夺。
+- **资源控制**：根据任务特性调整线程池大小和队列类型，优化性能表现。
+- **异常处理**：通过自定义 `ThreadFactory` 更好地处理线程中的异常情况。
```java
private ThreadPoolExecutor executor = new ThreadPoolExecutor(10, 10,
diff --git "a/docs/java/concurrent/images/java-thread-pool-summary/threadpoolexecutor\346\236\204\351\200\240\345\207\275\346\225\260.png" "b/docs/java/concurrent/images/java-thread-pool-summary/threadpoolexecutor\346\236\204\351\200\240\345\207\275\346\225\260.png"
deleted file mode 100644
index 6e3c7082eed..00000000000
Binary files "a/docs/java/concurrent/images/java-thread-pool-summary/threadpoolexecutor\346\236\204\351\200\240\345\207\275\346\225\260.png" and /dev/null differ
diff --git a/docs/java/concurrent/java-concurrent-collections.md b/docs/java/concurrent/java-concurrent-collections.md
index 9a669d900e0..45aa258818a 100644
--- a/docs/java/concurrent/java-concurrent-collections.md
+++ b/docs/java/concurrent/java-concurrent-collections.md
@@ -15,13 +15,19 @@ JDK 提供的这些容器大部分在 `java.util.concurrent` 包中。
## ConcurrentHashMap
-我们知道 `HashMap` 不是线程安全的，在并发场景下如果要保证一种可行的方式是使用 `Collections.synchronizedMap()` 方法来包装我们的 `HashMap`。但这是通过使用一个全局的锁来同步不同线程间的并发访问，因此会带来不可忽视的性能问题。
+我们知道，`HashMap` 是线程不安全的，如果在并发场景下使用，一种常见的解决方式是通过 `Collections.synchronizedMap()` 方法对 `HashMap` 进行包装，使其变为线程安全。不过，这种方式是通过一个全局锁来同步不同线程间的并发访问，会导致严重的性能瓶颈，尤其是在高并发场景下。
-所以就有了 `HashMap` 的线程安全版本—— `ConcurrentHashMap` 的诞生。
+为了解决这一问题，`ConcurrentHashMap` 应运而生，作为 `HashMap` 的线程安全版本，它提供了更高效的并发处理能力。
在 JDK1.7 的时候，`ConcurrentHashMap` 对整个桶数组进行了分割分段(`Segment`，分段锁)，每一把锁只锁容器其中一部分数据（下面有示意图），多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。
-到了 JDK1.8 的时候，`ConcurrentHashMap` 已经摒弃了 `Segment` 的概念，而是直接用 `Node` 数组+链表+红黑树的数据结构来实现，并发控制使用 `synchronized` 和 CAS 来操作。（JDK1.6 以后 `synchronized` 锁做了很多优化） 整个看起来就像是优化过且线程安全的 `HashMap`，虽然在 JDK1.8 中还能看到 `Segment` 的数据结构，但是已经简化了属性，只是为了兼容旧版本。
+
+
+到了 JDK1.8 的时候，`ConcurrentHashMap` 取消了 `Segment` 分段锁，采用 `Node + CAS + synchronized` 来保证并发安全。数据结构跟 `HashMap` 1.8 的结构类似，数组+链表/红黑二叉树。Java 8 在链表长度超过一定阈值（8）时将链表（寻址时间复杂度为 O(N)）转换为红黑树（寻址时间复杂度为 O(log(N))）。
+
+Java 8 中，锁粒度更细，`synchronized` 只锁定当前链表或红黑二叉树的首节点，这样只要 hash 不冲突，就不会产生并发，就不会影响其他 Node 的读写，效率大幅提升。
+
+
关于 `ConcurrentHashMap` 的详细介绍，请看我写的这篇文章：[`ConcurrentHashMap` 源码分析](./../collection/concurrent-hash-map-source-code.md)。
diff --git a/docs/java/concurrent/java-concurrent-questions-01.md b/docs/java/concurrent/java-concurrent-questions-01.md
index 64ac6d523b1..e1768d04d45 100644
--- a/docs/java/concurrent/java-concurrent-questions-01.md
+++ b/docs/java/concurrent/java-concurrent-questions-01.md
@@ -14,9 +14,11 @@ head:
-## 什么是线程和进程?
+## 线程
-### 何为进程?
+### ⭐️什么是线程和进程?
+
+#### 何为进程?
进程是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。系统运行一个程序即是一个进程从创建，运行到消亡的过程。
@@ -26,7 +28,7 @@ head:
-### 何为线程?
+#### 何为线程?
线程与进程相似，但线程是一个比进程更小的执行单位。一个进程在其执行的过程中可以产生多个线程。与进程不同的是同类的多个线程共享进程的**堆**和**方法区**资源，但每个线程有自己的**程序计数器**、**虚拟机栈**和**本地方法栈**，所以系统在产生一个线程，或是在各个线程之间做切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。
@@ -59,7 +61,7 @@ public class MultiThread {
从上面的输出内容可以看出：**一个 Java 程序的运行是 main 线程和多个其他线程同时运行**。
-## Java 线程和操作系统的线程有啥区别？
+### Java 线程和操作系统的线程有啥区别？
JDK 1.2 之前，Java 线程是基于绿色线程（Green Threads）实现的，这是一种用户级线程（用户线程），也就是说 JVM 自己模拟了多线程的运行，而不依赖于操作系统。由于绿色线程和原生线程比起来在使用时有一些限制（比如绿色线程不能直接使用操作系统提供的功能如异步 I/O、只能在一个内核线程上运行无法利用多核），在 JDK 1.2 及以后，Java 线程改为基于原生线程（Native Threads）实现，也就是说 JVM 直接使用操作系统原生的内核级线程（内核线程）来实现 Java 线程，由操作系统内核进行线程的调度和管理。
@@ -82,13 +84,7 @@ JDK 1.2 之前，Java 线程是基于绿色线程（Green Threads）实现的，
在 Windows 和 Linux 等主流操作系统中，Java 线程采用的是一对一的线程模型，也就是一个 Java 线程对应一个系统内核线程。Solaris 系统是一个特例（Solaris 系统本身就支持多对多的线程模型），HotSpot VM 在 Solaris 上支持多对多和一对一。具体可以参考 R 大的回答: [JVM 中的线程模型是用户级的么？](https://www.zhihu.com/question/23096638/answer/29617153)。
-虚拟线程在 JDK 21 顺利转正，关于虚拟线程、平台线程（也就是我们上面提到的 Java 线程）和内核线程三者的关系可以阅读我写的这篇文章：[Java 20 新特性概览](../new-features/java20.md)。
-
-## 请简要描述线程与进程的关系,区别及优缺点？
-
-从 JVM 角度说进程和线程之间的关系。
-
-### 图解进程和线程的关系
+### ⭐️请简要描述线程与进程的关系,区别及优缺点？
下图是 Java 内存区域，通过下图我们从 JVM 的角度来说一下线程和进程之间的关系。
@@ -102,7 +98,7 @@ JDK 1.2 之前，Java 线程是基于绿色线程（Green Threads）实现的，
下面来思考这样一个问题：为什么**程序计数器**、**虚拟机栈**和**本地方法栈**是线程私有的呢？为什么堆和方法区是线程共享的呢？
-### 程序计数器为什么是私有的?
+#### 程序计数器为什么是私有的?
程序计数器主要有下面两个作用：
@@ -113,61 +109,18 @@ JDK 1.2 之前，Java 线程是基于绿色线程（Green Threads）实现的，
所以，程序计数器私有主要是为了**线程切换后能恢复到正确的执行位置**。
-### 虚拟机栈和本地方法栈为什么是私有的?
+#### 虚拟机栈和本地方法栈为什么是私有的?
- **虚拟机栈：** 每个 Java 方法在执行之前会创建一个栈帧用于存储局部变量表、操作数栈、常量池引用等信息。从方法调用直至执行完成的过程，就对应着一个栈帧在 Java 虚拟机栈中入栈和出栈的过程。
- **本地方法栈：** 和虚拟机栈所发挥的作用非常相似，区别是：**虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。** 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。
所以，为了**保证线程中的局部变量不被别的线程访问到**，虚拟机栈和本地方法栈是线程私有的。
-### 一句话简单了解堆和方法区
+#### 一句话简单了解堆和方法区
堆和方法区是所有线程共享的资源，其中堆是进程中最大的一块内存，主要用于存放新创建的对象 (几乎所有对象都在这里分配内存)，方法区主要用于存放已被加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
-## 并发与并行的区别
-
-- **并发**：两个及两个以上的作业在同一 **时间段** 内执行。
-- **并行**：两个及两个以上的作业在同一 **时刻** 执行。
-
-最关键的点是：是否是 **同时** 执行。
-
-## 同步和异步的区别
-
-- **同步**：发出一个调用之后，在没有得到结果之前， 该调用就不可以返回，一直等待。
-- **异步**：调用在发出之后，不用等待返回结果，该调用直接返回。
-
-## 为什么要使用多线程?
-
-先从总体上来说：
-
-- **从计算机底层来说：** 线程可以比作是轻量级的进程，是程序执行的最小单位,线程间的切换和调度的成本远远小于进程。另外，多核 CPU 时代意味着多个线程可以同时运行，这减少了线程上下文切换的开销。
-- **从当代互联网发展趋势来说：** 现在的系统动不动就要求百万级甚至千万级的并发量，而多线程并发编程正是开发高并发系统的基础，利用好多线程机制可以大大提高系统整体的并发能力以及性能。
-
-再深入到计算机底层来探讨：
-
-- **单核时代**：在单核时代多线程主要是为了提高单进程利用 CPU 和 IO 系统的效率。 假设只运行了一个 Java 进程的情况，当我们请求 IO 的时候，如果 Java 进程中只有一个线程，此线程被 IO 阻塞则整个进程被阻塞。CPU 和 IO 设备只有一个在运行，那么可以简单地说系统整体效率只有 50%。当使用多线程的时候，一个线程被 IO 阻塞，其他线程还可以继续使用 CPU。从而提高了 Java 进程利用系统资源的整体效率。
-- **多核时代**: 多核时代多线程主要是为了提高进程利用多核 CPU 的能力。举个例子：假如我们要计算一个复杂的任务，我们只用一个线程的话，不论系统有几个 CPU 核心，都只会有一个 CPU 核心被利用到。而创建多个线程，这些线程可以被映射到底层多个 CPU 上执行，在任务中的多个线程没有资源竞争的情况下，任务执行的效率会有显著性的提高，约等于（单核时执行时间/CPU 核心数）。
-
-## 使用多线程可能带来什么问题?
-
-并发编程的目的就是为了能提高程序的执行效率进而提高程序的运行速度，但是并发编程并不总是能提高程序运行速度的，而且并发编程可能会遇到很多问题，比如：内存泄漏、死锁、线程不安全等等。
-
-## 如何理解线程安全和不安全？
-
-线程安全和不安全是在多线程环境下对于同一份数据的访问是否能够保证其正确性和一致性的描述。
-
-- 线程安全指的是在多线程环境下，对于同一份数据，不管有多少个线程同时访问，都能保证这份数据的正确性和一致性。
-- 线程不安全则表示在多线程环境下，对于同一份数据，多个线程同时访问时可能会导致数据混乱、错误或者丢失。
-
-## 单核 CPU 上运行多个线程效率一定会高吗？
-
-单核 CPU 同时运行多个线程的效率是否会高，取决于线程的类型和任务的性质。一般来说，有两种类型的线程：CPU 密集型和 IO 密集型。CPU 密集型的线程主要进行计算和逻辑处理，需要占用大量的 CPU 资源。IO 密集型的线程主要进行输入输出操作，如读写文件、网络通信等，需要等待 IO 设备的响应，而不占用太多的 CPU 资源。
-
-在单核 CPU 上，同一时刻只能有一个线程在运行，其他线程需要等待 CPU 的时间片分配。如果线程是 CPU 密集型的，那么多个线程同时运行会导致频繁的线程切换，增加了系统的开销，降低了效率。如果线程是 IO 密集型的，那么多个线程同时运行可以利用 CPU 在等待 IO 时的空闲时间，提高了效率。
-
-因此，对于单核 CPU 来说，如果任务是 CPU 密集型的，那么开很多线程会影响效率；如果任务是 IO 密集型的，那么开很多线程会提高效率。当然，这里的“很多”也要适度，不能超过系统能够承受的上限。
-
-## 如何创建线程？
+### 如何创建线程？
一般来说，创建线程有很多种方式，例如继承`Thread`类、实现`Runnable`接口、实现`Callable`接口、使用线程池、使用`CompletableFuture`类等等。
@@ -177,7 +130,7 @@ JDK 1.2 之前，Java 线程是基于绿色线程（Green Threads）实现的，
关于这个问题的详细分析可以查看这篇文章：[大家都说 Java 有三种创建线程的方式！并发编程中的惊天骗局！](https://mp.weixin.qq.com/s/NspUsyhEmKnJ-4OprRFp9g)。
-## 说说线程的生命周期和状态?
+### ⭐️说说线程的生命周期和状态?
Java 线程在运行的生命周期中的指定时刻只可能处于下面 6 种不同状态的其中一个状态：
@@ -209,7 +162,7 @@ Java 线程状态变迁图(图源：[挑错 |《Java 并发编程的艺术》中
相关阅读：[线程的几种状态你真的了解么？](https://mp.weixin.qq.com/s/R5MrTsWvk9McFSQ7bS0W2w) 。
-## 什么是线程上下文切换?
+### 什么是线程上下文切换?
线程在执行过程中会有自己的运行条件和状态（也称上下文），比如上文所说到过的程序计数器，栈信息等。当出现如下情况的时候，线程会从占用 CPU 状态中退出。
@@ -222,9 +175,97 @@ Java 线程状态变迁图(图源：[挑错 |《Java 并发编程的艺术》中
上下文切换是现代操作系统的基本功能，因其每次需要保存信息恢复信息，这将会占用 CPU，内存等系统资源进行处理，也就意味着效率会有一定损耗，如果频繁切换就会造成整体效率低下。
-## 什么是线程死锁?如何避免死锁?
+### Thread#sleep() 方法和 Object#wait() 方法对比
+
+**共同点**：两者都可以暂停线程的执行。
+
+**区别**：
+
+- **`sleep()` 方法没有释放锁，而 `wait()` 方法释放了锁** 。
+- `wait()` 通常被用于线程间交互/通信，`sleep()`通常被用于暂停执行。
+- `wait()` 方法被调用后，线程不会自动苏醒，需要别的线程调用同一个对象上的 `notify()`或者 `notifyAll()` 方法。`sleep()`方法执行完成后，线程会自动苏醒，或者也可以使用 `wait(long timeout)` 超时后线程会自动苏醒。
+- `sleep()` 是 `Thread` 类的静态本地方法，`wait()` 则是 `Object` 类的本地方法。为什么这样设计呢？下一个问题就会聊到。
+
+### 为什么 wait() 方法不定义在 Thread 中？
+
+`wait()` 是让获得对象锁的线程实现等待，会自动释放当前线程占有的对象锁。每个对象（`Object`）都拥有对象锁，既然要释放当前线程占有的对象锁并让其进入 WAITING 状态，自然是要操作对应的对象（`Object`）而非当前的线程（`Thread`）。
+
+类似的问题：**为什么 `sleep()` 方法定义在 `Thread` 中？**
+
+因为 `sleep()` 是让当前线程暂停执行，不涉及到对象类，也不需要获得对象锁。
+
+### 可以直接调用 Thread 类的 run 方法吗？
+
+这是另一个非常经典的 Java 多线程面试问题，而且在面试中会经常被问到。很简单，但是很多人都会答不上来！
+
+new 一个 `Thread`，线程进入了新建状态。调用 `start()`方法，会启动一个线程并使线程进入了就绪状态，当分配到时间片后就可以开始运行了。 `start()` 会执行线程的相应准备工作，然后自动执行 `run()` 方法的内容，这是真正的多线程工作。 但是，直接执行 `run()` 方法，会把 `run()` 方法当成一个 main 线程下的普通方法去执行，并不会在某个线程中执行它，所以这并不是多线程工作。
+
+**总结：调用 `start()` 方法方可启动线程并使线程进入就绪状态，直接执行 `run()` 方法的话不会以多线程的方式执行。**
+
+## 多线程
+
+### 并发与并行的区别
+
+- **并发**：两个及两个以上的作业在同一 **时间段** 内执行。
+- **并行**：两个及两个以上的作业在同一 **时刻** 执行。
+
+最关键的点是：是否是 **同时** 执行。
+
+### 同步和异步的区别
+
+- **同步**：发出一个调用之后，在没有得到结果之前， 该调用就不可以返回，一直等待。
+- **异步**：调用在发出之后，不用等待返回结果，该调用直接返回。
+
+### ⭐️为什么要使用多线程?
+
+先从总体上来说：
+
+- **从计算机底层来说：** 线程可以比作是轻量级的进程，是程序执行的最小单位，线程间的切换和调度的成本远远小于进程。另外，多核 CPU 时代意味着多个线程可以同时运行，这减少了线程上下文切换的开销。
+- **从当代互联网发展趋势来说：** 现在的系统动不动就要求百万级甚至千万级的并发量，而多线程并发编程正是开发高并发系统的基础，利用好多线程机制可以大大提高系统整体的并发能力以及性能。
+
+再深入到计算机底层来探讨：
+
+- **单核时代**：在单核时代多线程主要是为了提高单进程利用 CPU 和 IO 系统的效率。 假设只运行了一个 Java 进程的情况，当我们请求 IO 的时候，如果 Java 进程中只有一个线程，此线程被 IO 阻塞则整个进程被阻塞。CPU 和 IO 设备只有一个在运行，那么可以简单地说系统整体效率只有 50%。当使用多线程的时候，一个线程被 IO 阻塞，其他线程还可以继续使用 CPU。从而提高了 Java 进程利用系统资源的整体效率。
+- **多核时代**: 多核时代多线程主要是为了提高进程利用多核 CPU 的能力。举个例子：假如我们要计算一个复杂的任务，我们只用一个线程的话，不论系统有几个 CPU 核心，都只会有一个 CPU 核心被利用到。而创建多个线程，这些线程可以被映射到底层多个 CPU 核心上执行，在任务中的多个线程没有资源竞争的情况下，任务执行的效率会有显著性的提高，约等于（单核时执行时间/CPU 核心数）。
+
+### ⭐️单核 CPU 支持 Java 多线程吗？
+
+单核 CPU 是支持 Java 多线程的。操作系统通过时间片轮转的方式，将 CPU 的时间分配给不同的线程。尽管单核 CPU 一次只能执行一个任务，但通过快速在多个线程之间切换，可以让用户感觉多个任务是同时进行的。
+
+这里顺带提一下 Java 使用的线程调度方式。
+
+操作系统主要通过两种线程调度方式来管理多线程的执行：
+
+- **抢占式调度（Preemptive Scheduling）**：操作系统决定何时暂停当前正在运行的线程，并切换到另一个线程执行。这种切换通常是由系统时钟中断（时间片轮转）或其他高优先级事件（如 I/O 操作完成）触发的。这种方式存在上下文切换开销，但公平性和 CPU 资源利用率较好，不易阻塞。
+- **协同式调度（Cooperative Scheduling）**：线程执行完毕后，主动通知系统切换到另一个线程。这种方式可以减少上下文切换带来的性能开销，但公平性较差，容易阻塞。
+
+Java 使用的线程调度是抢占式的。也就是说，JVM 本身不负责线程的调度，而是将线程的调度委托给操作系统。操作系统通常会基于线程优先级和时间片来调度线程的执行，高优先级的线程通常获得 CPU 时间片的机会更多。
+
+### ⭐️单核 CPU 上运行多个线程效率一定会高吗？
+
+单核 CPU 同时运行多个线程的效率是否会高，取决于线程的类型和任务的性质。一般来说，有两种类型的线程：
+
+1. **CPU 密集型**：CPU 密集型的线程主要进行计算和逻辑处理，需要占用大量的 CPU 资源。
+2. **IO 密集型**：IO 密集型的线程主要进行输入输出操作，如读写文件、网络通信等，需要等待 IO 设备的响应，而不占用太多的 CPU 资源。
+
+在单核 CPU 上，同一时刻只能有一个线程在运行，其他线程需要等待 CPU 的时间片分配。如果线程是 CPU 密集型的，那么多个线程同时运行会导致频繁的线程切换，增加了系统的开销，降低了效率。如果线程是 IO 密集型的，那么多个线程同时运行可以利用 CPU 在等待 IO 时的空闲时间，提高了效率。
+
+因此，对于单核 CPU 来说，如果任务是 CPU 密集型的，那么开很多线程会影响效率；如果任务是 IO 密集型的，那么开很多线程会提高效率。当然，这里的“很多”也要适度，不能超过系统能够承受的上限。
+
+### 使用多线程可能带来什么问题?
+
+并发编程的目的就是为了能提高程序的执行效率进而提高程序的运行速度，但是并发编程并不总是能提高程序运行速度的，而且并发编程可能会遇到很多问题，比如：内存泄漏、死锁、线程不安全等等。
+
+### 如何理解线程安全和不安全？
+
+线程安全和不安全是在多线程环境下对于同一份数据的访问是否能够保证其正确性和一致性的描述。
+
+- 线程安全指的是在多线程环境下，对于同一份数据，不管有多少个线程同时访问，都能保证这份数据的正确性和一致性。
+- 线程不安全则表示在多线程环境下，对于同一份数据，多个线程同时访问时可能会导致数据混乱、错误或者丢失。
+
+## ⭐️死锁
-### 认识线程死锁
+### 什么是线程死锁？
线程死锁描述的是这样一种情况：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。
@@ -282,14 +323,37 @@ Thread[线程 1,5,main]waiting get resource2
Thread[线程 2,5,main]waiting get resource1
```
-线程 A 通过 `synchronized (resource1)` 获得 `resource1` 的监视器锁，然后通过`Thread.sleep(1000);`让线程 A 休眠 1s 为的是让线程 B 得到执行然后获取到 resource2 的监视器锁。线程 A 和线程 B 休眠结束了都开始企图请求获取对方的资源，然后这两个线程就会陷入互相等待的状态，这也就产生了死锁。
+线程 A 通过 `synchronized (resource1)` 获得 `resource1` 的监视器锁，然后通过 `Thread.sleep(1000);` 让线程 A 休眠 1s，为的是让线程 B 得到执行然后获取到 resource2 的监视器锁。线程 A 和线程 B 休眠结束了都开始企图请求获取对方的资源，然后这两个线程就会陷入互相等待的状态，这也就产生了死锁。
上面的例子符合产生死锁的四个必要条件：
-1. 互斥条件：该资源任意一个时刻只由一个线程占用。
-2. 请求与保持条件：一个线程因请求资源而阻塞时，对已获得的资源保持不放。
-3. 不剥夺条件:线程已获得的资源在未使用完之前不能被其他线程强行剥夺，只有自己使用完毕后才释放资源。
-4. 循环等待条件:若干线程之间形成一种头尾相接的循环等待资源关系。
+1. **互斥条件**：该资源任意一个时刻只由一个线程占用。
+2. **请求与保持条件**：一个线程因请求资源而阻塞时，对已获得的资源保持不放。
+3. **不剥夺条件**：线程已获得的资源在未使用完之前不能被其他线程强行剥夺，只有自己使用完毕后才释放资源。
+4. **循环等待条件**：若干线程之间形成一种头尾相接的循环等待资源关系。
+
+### 如何检测死锁？
+
+- 使用`jmap`、`jstack`等命令查看 JVM 线程栈和堆内存的情况。如果有死锁，`jstack` 的输出中通常会有 `Found one Java-level deadlock:`的字样，后面会跟着死锁相关的线程信息。另外，实际项目中还可以搭配使用`top`、`df`、`free`等命令查看操作系统的基本情况，出现死锁可能会导致 CPU、内存等资源消耗过高。
+- 采用 VisualVM、JConsole 等工具进行排查。
+
+这里以 JConsole 工具为例进行演示。
+
+首先，我们要找到 JDK 的 bin 目录，找到 jconsole 并双击打开。
+
+
+
+对于 MAC 用户来说，可以通过 `/usr/libexec/java_home -V`查看 JDK 安装目录，找到后通过 `open . + 文件夹地址`打开即可。例如，我本地的某个 JDK 的路径是：
+
+```bash
+ open . /Users/guide/Library/Java/JavaVirtualMachines/corretto-1.8.0_252/Contents/Home
+```
+
+打开 jconsole 后，连接对应的程序，然后进入线程界面选择检测死锁即可！
+
+
+
+
### 如何预防和避免线程死锁?
@@ -339,33 +403,16 @@ Process finished with exit code 0
我们分析一下上面的代码为什么避免了死锁的发生?
-线程 1 首先获得到 resource1 的监视器锁,这时候线程 2 就获取不到了。然后线程 1 再去获取 resource2 的监视器锁，可以获取到。然后线程 1 释放了对 resource1、resource2 的监视器锁的占用，线程 2 获取到就可以执行了。这样就破坏了破坏循环等待条件，因此避免了死锁。
-
-## sleep() 方法和 wait() 方法对比
-
-**共同点**：两者都可以暂停线程的执行。
-
-**区别**：
+线程 1 首先获得到 resource1 的监视器锁,这时候线程 2 就获取不到了。然后线程 1 再去获取 resource2 的监视器锁，可以获取到。然后线程 1 释放了对 resource1、resource2 的监视器锁的占用，线程 2 获取到就可以执行了。这样就破坏了循环等待条件，因此避免了死锁。
-- **`sleep()` 方法没有释放锁，而 `wait()` 方法释放了锁** 。
-- `wait()` 通常被用于线程间交互/通信，`sleep()`通常被用于暂停执行。
-- `wait()` 方法被调用后，线程不会自动苏醒，需要别的线程调用同一个对象上的 `notify()`或者 `notifyAll()` 方法。`sleep()`方法执行完成后，线程会自动苏醒，或者也可以使用 `wait(long timeout)` 超时后线程会自动苏醒。
-- `sleep()` 是 `Thread` 类的静态本地方法，`wait()` 则是 `Object` 类的本地方法。为什么这样设计呢？下一个问题就会聊到。
+## 虚拟线程
-## 为什么 wait() 方法不定义在 Thread 中？
-
-`wait()` 是让获得对象锁的线程实现等待，会自动释放当前线程占有的对象锁。每个对象（`Object`）都拥有对象锁，既然要释放当前线程占有的对象锁并让其进入 WAITING 状态，自然是要操作对应的对象（`Object`）而非当前的线程（`Thread`）。
-
-类似的问题：**为什么 `sleep()` 方法定义在 `Thread` 中？**
+虚拟线程在 Java 21 正式发布，这是一项重量级的更新。我写了一篇文章来总结虚拟线程常见的问题：[虚拟线程常见问题总结](./virtual-thread.md)，包含下面这些问题：
-因为 `sleep()` 是让当前线程暂停执行，不涉及到对象类，也不需要获得对象锁。
-
-## 可以直接调用 Thread 类的 run 方法吗？
-
-这是另一个非常经典的 Java 多线程面试问题，而且在面试中会经常被问到。很简单，但是很多人都会答不上来！
-
-new 一个 `Thread`，线程进入了新建状态。调用 `start()`方法，会启动一个线程并使线程进入了就绪状态，当分配到时间片后就可以开始运行了。 `start()` 会执行线程的相应准备工作，然后自动执行 `run()` 方法的内容，这是真正的多线程工作。 但是，直接执行 `run()` 方法，会把 `run()` 方法当成一个 main 线程下的普通方法去执行，并不会在某个线程中执行它，所以这并不是多线程工作。
-
-**总结：调用 `start()` 方法方可启动线程并使线程进入就绪状态，直接执行 `run()` 方法的话不会以多线程的方式执行。**
+1. 什么是虚拟线程？
+2. 虚拟线程和平台线程有什么关系？
+3. 虚拟线程有什么优点和缺点？
+4. 如何创建虚拟线程？
+5. 虚拟线程的底层原理是什么？
diff --git a/docs/java/concurrent/java-concurrent-questions-02.md b/docs/java/concurrent/java-concurrent-questions-02.md
index 9fe955a4028..40c1b140434 100644
--- a/docs/java/concurrent/java-concurrent-questions-02.md
+++ b/docs/java/concurrent/java-concurrent-questions-02.md
@@ -14,11 +14,11 @@ head:
-## JMM(Java 内存模型)
+## ⭐️JMM(Java 内存模型)
JMM（Java 内存模型）相关的问题比较多，也比较重要，于是我单独抽了一篇文章来总结 JMM 相关的知识点和问题：[JMM（Java 内存模型）详解](./jmm.md) 。
-## volatile 关键字
+## ⭐️volatile 关键字
### 如何保证变量的可见性？
@@ -60,7 +60,7 @@ public class Singleton {
private Singleton() {
}
- public static Singleton getUniqueInstance() {
+ public static Singleton getUniqueInstance() {
//先判断对象是否已经实例过，没有实例化过才进入加锁代码
if (uniqueInstance == null) {
//类对象加锁
@@ -174,7 +174,7 @@ public void increase() {
}
```
-## 乐观锁和悲观锁
+## ⭐️乐观锁和悲观锁
### 什么是悲观锁？
@@ -285,6 +285,108 @@ public final native boolean compareAndSwapLong(Object o, long offset, long expec
关于 `Unsafe` 类的详细介绍可以看这篇文章：[Java 魔法类 Unsafe 详解 - JavaGuide - 2022](https://javaguide.cn/java/basis/unsafe.html) 。
+### Java 中 CAS 是如何实现的？
+
+在 Java 中，实现 CAS（Compare-And-Swap, 比较并交换）操作的一个关键类是`Unsafe`。
+
+`Unsafe`类位于`sun.misc`包下，是一个提供低级别、不安全操作的类。由于其强大的功能和潜在的危险性，它通常用于 JVM 内部或一些需要极高性能和底层访问的库中，而不推荐普通开发者在应用程序中使用。关于 `Unsafe`类的详细介绍，可以阅读这篇文章：📌[Java 魔法类 Unsafe 详解](https://javaguide.cn/java/basis/unsafe.html)。
+
+`sun.misc`包下的`Unsafe`类提供了`compareAndSwapObject`、`compareAndSwapInt`、`compareAndSwapLong`方法来实现的对`Object`、`int`、`long`类型的 CAS 操作：
+
+```java
+/**
+ * 以原子方式更新对象字段的值。
+ *
+ * @param o 要操作的对象
+ * @param offset 对象字段的内存偏移量
+ * @param expected 期望的旧值
+ * @param x 要设置的新值
+ * @return 如果值被成功更新，则返回 true；否则返回 false
+ */
+boolean compareAndSwapObject(Object o, long offset, Object expected, Object x);
+
+/**
+ * 以原子方式更新 int 类型的对象字段的值。
+ */
+boolean compareAndSwapInt(Object o, long offset, int expected, int x);
+
+/**
+ * 以原子方式更新 long 类型的对象字段的值。
+ */
+boolean compareAndSwapLong(Object o, long offset, long expected, long x);
+```
+
+`Unsafe`类中的 CAS 方法是`native`方法。`native`关键字表明这些方法是用本地代码（通常是 C 或 C++）实现的，而不是用 Java 实现的。这些方法直接调用底层的硬件指令来实现原子操作。也就是说，Java 语言并没有直接用 Java 实现 CAS，而是通过 C++ 内联汇编的形式实现的（通过 JNI 调用）。因此，CAS 的具体实现与操作系统以及 CPU 密切相关。
+
+`java.util.concurrent.atomic` 包提供了一些用于原子操作的类。这些类利用底层的原子指令，确保在多线程环境下的操作是线程安全的。
+
+
+
+关于这些 Atomic 原子类的介绍和使用，可以阅读这篇文章：[Atomic 原子类总结](https://javaguide.cn/java/concurrent/atomic-classes.html)。
+
+`AtomicInteger`是 Java 的原子类之一，主要用于对 `int` 类型的变量进行原子操作，它利用`Unsafe`类提供的低级别原子操作方法实现无锁的线程安全性。
+
+下面，我们通过解读`AtomicInteger`的核心源码（JDK1.8），来说明 Java 如何使用`Unsafe`类的方法来实现原子操作。
+
+`AtomicInteger`核心源码如下：
+
+```java
+// 获取 Unsafe 实例
+private static final Unsafe unsafe = Unsafe.getUnsafe();
+private static final long valueOffset;
+
+static {
+ try {
+ // 获取“value”字段在AtomicInteger类中的内存偏移量
+ valueOffset = unsafe.objectFieldOffset
+ (AtomicInteger.class.getDeclaredField("value"));
+ } catch (Exception ex) { throw new Error(ex); }
+}
+// 确保“value”字段的可见性
+private volatile int value;
+
+// 如果当前值等于预期值，则原子地将值设置为newValue
+// 使用 Unsafe#compareAndSwapInt 方法进行CAS操作
+public final boolean compareAndSet(int expect, int update) {
+ return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
+}
+
+// 原子地将当前值加 delta 并返回旧值
+public final int getAndAdd(int delta) {
+ return unsafe.getAndAddInt(this, valueOffset, delta);
+}
+
+// 原子地将当前值加 1 并返回加之前的值（旧值）
+// 使用 Unsafe#getAndAddInt 方法进行CAS操作。
+public final int getAndIncrement() {
+ return unsafe.getAndAddInt(this, valueOffset, 1);
+}
+
+// 原子地将当前值减 1 并返回减之前的值（旧值）
+public final int getAndDecrement() {
+ return unsafe.getAndAddInt(this, valueOffset, -1);
+}
+```
+
+`Unsafe#getAndAddInt`源码：
+
+```java
+// 原子地获取并增加整数值
+public final int getAndAddInt(Object o, long offset, int delta) {
+ int v;
+ do {
+ // 以 volatile 方式获取对象 o 在内存偏移量 offset 处的整数值
+ v = getIntVolatile(o, offset);
+ } while (!compareAndSwapInt(o, offset, v, v + delta));
+ // 返回旧值
+ return v;
+}
+```
+
+可以看到，`getAndAddInt` 使用了 `do-while` 循环：在`compareAndSwapInt`操作失败时，会不断重试直到成功。也就是说，`getAndAddInt`方法会通过 `compareAndSwapInt` 方法来尝试更新 `value` 的值，如果更新失败（当前值在此期间被其他线程修改），它会重新获取当前值并再次尝试更新，直到操作成功。
+
+由于 CAS 操作可能会因为并发冲突而失败，因此通常会与`while`循环搭配使用，在失败后不断重试，直到操作成功。这就是 **自旋锁机制** 。
+
### CAS 算法存在哪些问题？
ABA 问题是 CAS 算法最常见的问题。
@@ -314,14 +416,16 @@ public boolean compareAndSet(V expectedReference,
CAS 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。
-如果 JVM 能支持处理器提供的 pause 指令那么效率会有一定的提升，pause 指令有两个作用：
+如果 JVM 能够支持处理器提供的`pause`指令，那么自旋操作的效率将有所提升。`pause`指令有两个重要作用：
-1. 可以延迟流水线执行指令，使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。
-2. 可以避免在退出循环的时候因内存顺序冲突而引起 CPU 流水线被清空，从而提高 CPU 的执行效率。
+1. **延迟流水线执行指令**：`pause`指令可以延迟指令的执行，从而减少 CPU 的资源消耗。具体的延迟时间取决于处理器的实现版本，在某些处理器上，延迟时间可能为零。
+2. **避免内存顺序冲突**：在退出循环时，`pause`指令可以避免由于内存顺序冲突而导致的 CPU 流水线被清空，从而提高 CPU 的执行效率。
#### 只能保证一个共享变量的原子操作
-CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5 开始，提供了`AtomicReference`类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用`AtomicReference`类把多个共享变量合并成一个共享变量来操作。
+CAS 操作仅能对单个共享变量有效。当需要操作多个共享变量时，CAS 就显得无能为力。不过，从 JDK 1.5 开始，Java 提供了`AtomicReference`类，这使得我们能够保证引用对象之间的原子性。通过将多个变量封装在一个对象中，我们可以使用`AtomicReference`来执行 CAS 操作。
+
+除了 `AtomicReference` 这种方式之外，还可以利用加锁来保证。
## synchronized 关键字
@@ -371,8 +475,8 @@ synchronized static void method() {
对括号里指定的对象/类加锁：
-- `synchronized(object)` 表示进入同步代码库前要获得 **给定对象的锁**。
-- `synchronized(类.class)` 表示进入同步代码前要获得 **给定 Class 的锁**
+- `synchronized(object)` 表示进入同步代码块前要获得 **给定对象的锁**。
+- `synchronized(类.class)` 表示进入同步代码块前要获得 **给定 Class 的锁**
```java
synchronized(this) {
@@ -388,11 +492,11 @@ synchronized(this) {
### 构造方法可以用 synchronized 修饰么？
-先说结论：**构造方法不能使用 synchronized 关键字修饰。**
+构造方法不能使用 synchronized 关键字修饰。不过，可以在构造方法内部使用 synchronized 代码块。
-构造方法本身就属于线程安全的，不存在同步的构造方法一说。
+另外，构造方法本身是线程安全的，但如果在构造方法中涉及到共享资源的操作，就需要采取适当的同步措施来保证整个构造过程的线程安全。
-### synchronized 底层原理了解吗？
+### ⭐️synchronized 底层原理了解吗？
synchronized 关键字底层原理属于 JVM 层面的东西。
@@ -426,13 +530,13 @@ public class SynchronizedDemo {
-对象锁的的拥有者线程才可以执行 `monitorexit` 指令来释放锁。在执行 `monitorexit` 指令后，将锁计数器设为 0，表明锁被释放，其他线程可以尝试获取锁。
+对象锁的拥有者线程才可以执行 `monitorexit` 指令来释放锁。在执行 `monitorexit` 指令后，将锁计数器设为 0，表明锁被释放，其他线程可以尝试获取锁。
如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。
-#### synchronized 修饰方法的的情况
+#### synchronized 修饰方法的情况
```java
public class SynchronizedDemo2 {
@@ -445,7 +549,7 @@ public class SynchronizedDemo2 {
-`synchronized` 修饰的方法并没有 `monitorenter` 指令和 `monitorexit` 指令，取得代之的确实是 `ACC_SYNCHRONIZED` 标识，该标识指明了该方法是一个同步方法。JVM 通过该 `ACC_SYNCHRONIZED` 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。
+`synchronized` 修饰的方法并没有 `monitorenter` 指令和 `monitorexit` 指令，取而代之的是 `ACC_SYNCHRONIZED` 标识，该标识指明了该方法是一个同步方法。JVM 通过该 `ACC_SYNCHRONIZED` 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。
如果是实例方法，JVM 会尝试获取实例对象的锁。如果是静态方法，JVM 会尝试获取当前 class 的锁。
@@ -453,9 +557,9 @@ public class SynchronizedDemo2 {
`synchronized` 同步语句块的实现使用的是 `monitorenter` 和 `monitorexit` 指令，其中 `monitorenter` 指令指向同步代码块的开始位置，`monitorexit` 指令则指明同步代码块的结束位置。
-`synchronized` 修饰的方法并没有 `monitorenter` 指令和 `monitorexit` 指令，取得代之的确实是 `ACC_SYNCHRONIZED` 标识，该标识指明了该方法是一个同步方法。
+`synchronized` 修饰的方法并没有 `monitorenter` 指令和 `monitorexit` 指令，取而代之的是 `ACC_SYNCHRONIZED` 标识，该标识指明了该方法是一个同步方法。
-**不过两者的本质都是对对象监视器 monitor 的获取。**
+**不过，两者的本质都是对对象监视器 monitor 的获取。**
相关推荐：[Java 锁与线程的那些事 - 有赞技术团队](https://tech.youzan.com/javasuo-yu-xian-cheng-de-na-xie-shi/) 。
@@ -469,7 +573,31 @@ public class SynchronizedDemo2 {
`synchronized` 锁升级是一个比较复杂的过程，面试也很少问到，如果你想要详细了解的话，可以看看这篇文章：[浅析 synchronized 锁升级的原理与实现](https://www.cnblogs.com/star95/p/17542850.html)。
-### synchronized 和 volatile 有什么区别？
+### synchronized 的偏向锁为什么被废弃了？
+
+Open JDK 官方声明：[JEP 374: Deprecate and Disable Biased Locking](https://openjdk.org/jeps/374)
+
+在 JDK15 中，偏向锁被默认关闭（仍然可以使用 `-XX:+UseBiasedLocking` 启用偏向锁），在 JDK18 中，偏向锁已经被彻底废弃（无法通过命令行打开）。
+
+在官方声明中，主要原因有两个方面：
+
+- **性能收益不明显：**
+
+偏向锁是 HotSpot 虚拟机的一项优化技术，可以提升单线程对同步代码块的访问性能。
+
+受益于偏向锁的应用程序通常使用了早期的 Java 集合 API，例如 HashTable、Vector，在这些集合类中通过 synchronized 来控制同步，这样在单线程频繁访问时，通过偏向锁会减少同步开销。
+
+随着 JDK 的发展，出现了 ConcurrentHashMap 高性能的集合类，在集合类内部进行了许多性能优化，此时偏向锁带来的性能收益就不明显了。
+
+偏向锁仅仅在单线程访问同步代码块的场景中可以获得性能收益。
+
+如果存在多线程竞争，就需要 **撤销偏向锁** ，这个操作的性能开销是比较昂贵的。偏向锁的撤销需要等待进入到全局安全点（safe point），该状态下所有线程都是暂停的，此时去检查线程状态并进行偏向锁的撤销。
+
+- **JVM 内部代码维护成本太高：**
+
+偏向锁将许多复杂代码引入到同步子系统，并且对其他的 HotSpot 组件也具有侵入性。这种复杂性为理解代码、系统重构带来了困难，因此， OpenJDK 官方希望禁用、废弃并删除偏向锁。
+
+### ⭐️synchronized 和 volatile 有什么区别？
`synchronized` 关键字和 `volatile` 关键字是两个互补的存在，而不是对立的存在！
@@ -507,7 +635,7 @@ public ReentrantLock(boolean fair) {
- **公平锁** : 锁被释放之后，先申请的线程先得到锁。性能较差一些，因为公平锁为了保证时间上的绝对顺序，上下文切换更频繁。
- **非公平锁**：锁被释放之后，后申请的线程可能会先获取到锁，是随机或者按照其他优先级排序的。性能更好，但可能会导致某些线程永远无法获取到锁。
-### synchronized 和 ReentrantLock 有什么区别？
+### ⭐️synchronized 和 ReentrantLock 有什么区别？
#### 两者都是可重入锁
@@ -542,9 +670,10 @@ public class SynchronizedDemo {
相比`synchronized`，`ReentrantLock`增加了一些高级功能。主要来说主要有三点：
-- **等待可中断** : `ReentrantLock`提供了一种能够中断等待锁的线程的机制，通过 `lock.lockInterruptibly()` 来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
+- **等待可中断** : `ReentrantLock`提供了一种能够中断等待锁的线程的机制，通过 `lock.lockInterruptibly()` 来实现这个机制。也就是说当前线程在等待获取锁的过程中，如果其他线程中断当前线程「 `interrupt()` 」，当前线程就会抛出 `InterruptedException` 异常，可以捕捉该异常进行相应处理。
- **可实现公平锁** : `ReentrantLock`可以指定是公平锁还是非公平锁。而`synchronized`只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。`ReentrantLock`默认情况是非公平的，可以通过 `ReentrantLock`类的`ReentrantLock(boolean fair)`构造方法来指定是否是公平的。
- **可实现选择性通知（锁可以绑定多个条件）**: `synchronized`关键字与`wait()`和`notify()`/`notifyAll()`方法相结合可以实现等待/通知机制。`ReentrantLock`类当然也可以实现，但是需要借助于`Condition`接口与`newCondition()`方法。
+- **支持超时** ：`ReentrantLock` 提供了 `tryLock(timeout)` 的方法，可以指定等待获取锁的最长等待时间，如果超过了等待时间，就会获取锁失败，不会一直等待。
如果你想使用上述功能，那么选择 `ReentrantLock` 是一个不错的选择。
@@ -552,6 +681,85 @@ public class SynchronizedDemo {
> `Condition`是 JDK1.5 之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个`Lock`对象中可以创建多个`Condition`实例（即对象监视器），**线程对象可以注册在指定的`Condition`中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。 在使用`notify()/notifyAll()`方法进行通知时，被通知的线程是由 JVM 选择的，用`ReentrantLock`类结合`Condition`实例可以实现“选择性通知”** ，这个功能非常重要，而且是 `Condition` 接口默认提供的。而`synchronized`关键字就相当于整个 `Lock` 对象中只有一个`Condition`实例，所有的线程都注册在它一个身上。如果执行`notifyAll()`方法的话就会通知所有处于等待状态的线程，这样会造成很大的效率问题。而`Condition`实例的`signalAll()`方法，只会唤醒注册在该`Condition`实例中的所有等待线程。
+关于 **等待可中断** 的补充：
+
+> `lockInterruptibly()` 会让获取锁的线程在阻塞等待的过程中可以响应中断，即当前线程在获取锁的时候，发现锁被其他线程持有，就会阻塞等待。
+>
+> 在阻塞等待的过程中，如果其他线程中断当前线程 `interrupt()` ，就会抛出 `InterruptedException` 异常，可以捕获该异常，做一些处理操作。
+>
+> 为了更好理解这个方法，借用 Stack Overflow 上的一个案例，可以更好地理解 `lockInterruptibly()` 可以响应中断：
+>
+> ```JAVA
+> public class MyRentrantlock {
+> Thread t = new Thread() {
+> @Override
+> public void run() {
+> ReentrantLock r = new ReentrantLock();
+> // 1.1、第一次尝试获取锁，可以获取成功
+> r.lock();
+>
+> // 1.2、此时锁的重入次数为 1
+> System.out.println("lock() : lock count :" + r.getHoldCount());
+>
+> // 2、中断当前线程，通过 Thread.currentThread().isInterrupted() 可以看到当前线程的中断状态为 true
+> interrupt();
+> System.out.println("Current thread is intrupted");
+>
+> // 3.1、尝试获取锁，可以成功获取
+> r.tryLock();
+> // 3.2、此时锁的重入次数为 2
+> System.out.println("tryLock() on intrupted thread lock count :" + r.getHoldCount());
+> try {
+> // 4、打印线程的中断状态为 true，那么调用 lockInterruptibly() 方法就会抛出 InterruptedException 异常
+> System.out.println("Current Thread isInterrupted:" + Thread.currentThread().isInterrupted());
+> r.lockInterruptibly();
+> System.out.println("lockInterruptibly() --NOt executable statement" + r.getHoldCount());
+> } catch (InterruptedException e) {
+> r.lock();
+> System.out.println("Error");
+> } finally {
+> r.unlock();
+> }
+>
+> // 5、打印锁的重入次数，可以发现 lockInterruptibly() 方法并没有成功获取到锁
+> System.out.println("lockInterruptibly() not able to Acqurie lock: lock count :" + r.getHoldCount());
+>
+> r.unlock();
+> System.out.println("lock count :" + r.getHoldCount());
+> r.unlock();
+> System.out.println("lock count :" + r.getHoldCount());
+> }
+> };
+> public static void main(String str[]) {
+> MyRentrantlock m = new MyRentrantlock();
+> m.t.start();
+> }
+> }
+> ```
+>
+> 输出：
+>
+> ```BASH
+> lock() : lock count :1
+> Current thread is intrupted
+> tryLock() on intrupted thread lock count :2
+> Current Thread isInterrupted:true
+> Error
+> lockInterruptibly() not able to Acqurie lock: lock count :2
+> lock count :1
+> lock count :0
+> ```
+
+关于 **支持超时** 的补充：
+
+> **为什么需要 `tryLock(timeout)` 这个功能呢？**
+>
+> `tryLock(timeout)` 方法尝试在指定的超时时间内获取锁。如果成功获取锁，则返回 `true`；如果在锁可用之前超时，则返回 `false`。此功能在以下几种场景中非常有用：
+>
+> - **防止死锁：** 在复杂的锁场景中，`tryLock(timeout)` 可以通过允许线程在合理的时间内放弃并重试来帮助防止死锁。
+> - **提高响应速度：** 防止线程无限期阻塞。
+> - **处理时间敏感的操作：** 对于具有严格时间限制的操作，`tryLock(timeout)` 允许线程在无法及时获取锁时继续执行替代操作。
+
### 可中断锁和不可中断锁有什么区别？
- **可中断锁**：获取锁的过程中可以被中断，不需要一直等到获取锁之后 才能进行其他逻辑处理。`ReentrantLock` 就属于是可中断锁。
diff --git a/docs/java/concurrent/java-concurrent-questions-03.md b/docs/java/concurrent/java-concurrent-questions-03.md
index 03055ed184c..84d58459d09 100644
--- a/docs/java/concurrent/java-concurrent-questions-03.md
+++ b/docs/java/concurrent/java-concurrent-questions-03.md
@@ -18,93 +18,36 @@ head:
### ThreadLocal 有什么用？
-通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。**如果想实现每一个线程都有自己的专属本地变量该如何解决呢？**
+通常情况下，我们创建的变量可以被任何一个线程访问和修改。这在多线程环境中可能导致数据竞争和线程安全问题。那么，**如果想让每个线程都有自己的专属本地变量，该如何实现呢？**
-JDK 中自带的`ThreadLocal`类正是为了解决这样的问题。 **`ThreadLocal`类主要解决的就是让每个线程绑定自己的值，可以将`ThreadLocal`类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。**
+JDK 中提供的 `ThreadLocal` 类正是为了解决这个问题。**`ThreadLocal` 类允许每个线程绑定自己的值**，可以将其形象地比喻为一个“存放数据的盒子”。每个线程都有自己独立的盒子，用于存储私有数据，确保不同线程之间的数据互不干扰。
-如果你创建了一个`ThreadLocal`变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是`ThreadLocal`变量名的由来。他们可以使用 `get()` 和 `set()` 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。
+当你创建一个 `ThreadLocal` 变量时，每个访问该变量的线程都会拥有一个独立的副本。这也是 `ThreadLocal` 名称的由来。线程可以通过 `get()` 方法获取自己线程的本地副本，或通过 `set()` 方法修改该副本的值，从而避免了线程安全问题。
-再举个简单的例子：两个人去宝屋收集宝物，这两个共用一个袋子的话肯定会产生争执，但是给他们两个人每个人分配一个袋子的话就不会出现这样的问题。如果把这两个人比作线程的话，那么 ThreadLocal 就是用来避免这两个线程竞争的。
-
-### 如何使用 ThreadLocal？
-
-相信看了上面的解释，大家已经搞懂 `ThreadLocal` 类是个什么东西了。下面简单演示一下如何在项目中实际使用 `ThreadLocal` 。
+举个简单的例子：假设有两个人去宝屋收集宝物。如果他们共用一个袋子，必然会产生争执；但如果每个人都有一个独立的袋子，就不会有这个问题。如果将这两个人比作线程，那么 `ThreadLocal` 就是用来避免这两个线程竞争同一个资源的方法。
```java
-import java.text.SimpleDateFormat;
-import java.util.Random;
-
-public class ThreadLocalExample implements Runnable{
-
- // SimpleDateFormat 不是线程安全的，所以每个线程都要有自己独立的副本
- private static final ThreadLocal formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm"));
-
- public static void main(String[] args) throws InterruptedException {
- ThreadLocalExample obj = new ThreadLocalExample();
- for(int i=0 ; i<10; i++){
- Thread t = new Thread(obj, ""+i);
- Thread.sleep(new Random().nextInt(1000));
- t.start();
- }
- }
-
- @Override
- public void run() {
- System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern());
- try {
- Thread.sleep(new Random().nextInt(1000));
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- //formatter pattern is changed here by thread, but it won't reflect to other threads
- formatter.set(new SimpleDateFormat());
-
- System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern());
+public class ThreadLocalExample {
+ private static ThreadLocal threadLocal = ThreadLocal.withInitial(() -> 0);
+
+ public static void main(String[] args) {
+ Runnable task = () -> {
+ int value = threadLocal.get();
+ value += 1;
+ threadLocal.set(value);
+ System.out.println(Thread.currentThread().getName() + " Value: " + threadLocal.get());
+ };
+
+ Thread thread1 = new Thread(task, "Thread-1");
+ Thread thread2 = new Thread(task, "Thread-2");
+
+ thread1.start(); // 输出: Thread-1 Value: 1
+ thread2.start(); // 输出: Thread-2 Value: 1
}
-
}
-
-```
-
-输出结果 :
-
-```plain
-Thread Name= 0 default Formatter = yyyyMMdd HHmm
-Thread Name= 0 formatter = yy-M-d ah:mm
-Thread Name= 1 default Formatter = yyyyMMdd HHmm
-Thread Name= 2 default Formatter = yyyyMMdd HHmm
-Thread Name= 1 formatter = yy-M-d ah:mm
-Thread Name= 3 default Formatter = yyyyMMdd HHmm
-Thread Name= 2 formatter = yy-M-d ah:mm
-Thread Name= 4 default Formatter = yyyyMMdd HHmm
-Thread Name= 3 formatter = yy-M-d ah:mm
-Thread Name= 4 formatter = yy-M-d ah:mm
-Thread Name= 5 default Formatter = yyyyMMdd HHmm
-Thread Name= 5 formatter = yy-M-d ah:mm
-Thread Name= 6 default Formatter = yyyyMMdd HHmm
-Thread Name= 6 formatter = yy-M-d ah:mm
-Thread Name= 7 default Formatter = yyyyMMdd HHmm
-Thread Name= 7 formatter = yy-M-d ah:mm
-Thread Name= 8 default Formatter = yyyyMMdd HHmm
-Thread Name= 9 default Formatter = yyyyMMdd HHmm
-Thread Name= 8 formatter = yy-M-d ah:mm
-Thread Name= 9 formatter = yy-M-d ah:mm
-```
-
-从输出中可以看出，虽然 `Thread-0` 已经改变了 `formatter` 的值，但 `Thread-1` 默认格式化值与初始化值相同，其他线程也一样。
-
-上面有一段代码用到了创建 `ThreadLocal` 变量的那段代码用到了 Java8 的知识，它等于下面这段代码，如果你写了下面这段代码的话，IDEA 会提示你转换为 Java8 的格式(IDEA 真的不错！)。因为 ThreadLocal 类在 Java 8 中扩展，使用一个新的方法`withInitial()`，将 Supplier 功能接口作为参数。
-
-```java
-private static final ThreadLocal formatter = new ThreadLocal(){
- @Override
- protected SimpleDateFormat initialValue(){
- return new SimpleDateFormat("yyyyMMdd HHmm");
- }
-};
```
-### ThreadLocal 原理了解吗？
+### ⭐️ThreadLocal 原理了解吗？
从 `Thread`类源代码入手。
@@ -161,15 +104,36 @@ ThreadLocalMap(ThreadLocal firstKey, Object firstValue) {
-### ThreadLocal 内存泄露问题是怎么导致的？
+### ⭐️ThreadLocal 内存泄露问题是怎么导致的？
-`ThreadLocalMap` 中使用的 key 为 `ThreadLocal` 的弱引用，而 value 是强引用。所以，如果 `ThreadLocal` 没有被外部强引用的情况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。
+`ThreadLocal` 内存泄漏的根本原因在于其内部实现机制。
-这样一来，`ThreadLocalMap` 中就会出现 key 为 null 的 Entry。假如我们不做任何措施的话，value 永远无法被 GC 回收，这个时候就可能会产生内存泄露。`ThreadLocalMap` 实现中已经考虑了这种情况，在调用 `set()`、`get()`、`remove()` 方法的时候，会清理掉 key 为 null 的记录。使用完 `ThreadLocal`方法后最好手动调用`remove()`方法
+通过上面的内容我们已经知道：每个线程维护一个名为 `ThreadLocalMap` 的 map。 当你使用 `ThreadLocal` 存储值时，实际上是将值存储在当前线程的 `ThreadLocalMap` 中，其中 `ThreadLocal` 实例本身作为 key，而你要存储的值作为 value。
+
+`ThreadLocal` 的 `set()` 方法源码如下：
+
+```java
+public void set(T value) {
+ Thread t = Thread.currentThread(); // 获取当前线程
+ ThreadLocalMap map = getMap(t); // 获取当前线程的 ThreadLocalMap
+ if (map != null) {
+ map.set(this, value); // 设置值
+ } else {
+ createMap(t, value); // 创建新的 ThreadLocalMap
+ }
+}
+```
+
+`ThreadLocalMap` 的 `set()` 和 `createMap()` 方法中，并没有直接存储 `ThreadLocal` 对象本身，而是使用 `ThreadLocal` 的哈希值计算数组索引，最终存储于类型为`static class Entry extends WeakReference>`的数组中。
+
+```java
+int i = key.threadLocalHashCode & (len-1);
+```
+
+`ThreadLocalMap` 的 `Entry` 定义如下：
```java
static class Entry extends WeakReference> {
- /** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal k, Object v) {
@@ -179,11 +143,91 @@ static class Entry extends WeakReference> {
}
```
-**弱引用介绍：**
+`ThreadLocalMap` 的 `key` 和 `value` 引用机制：
-> 如果一个对象只具有弱引用，那就类似于**可有可无的生活用品**。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。
->
-> 弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。
+- **key 是弱引用**：`ThreadLocalMap` 中的 key 是 `ThreadLocal` 的弱引用 (`WeakReference>`)。 这意味着，如果 `ThreadLocal` 实例不再被任何强引用指向，垃圾回收器会在下次 GC 时回收该实例，导致 `ThreadLocalMap` 中对应的 key 变为 `null`。
+- **value 是强引用**：即使 `key` 被 GC 回收，`value` 仍然被 `ThreadLocalMap.Entry` 强引用存在，无法被 GC 回收。
+
+当 `ThreadLocal` 实例失去强引用后，其对应的 value 仍然存在于 `ThreadLocalMap` 中，因为 `Entry` 对象强引用了它。如果线程持续存活（例如线程池中的线程），`ThreadLocalMap` 也会一直存在，导致 key 为 `null` 的 entry 无法被垃圾回收，即会造成内存泄漏。
+
+也就是说，内存泄漏的发生需要同时满足两个条件：
+
+1. `ThreadLocal` 实例不再被强引用；
+2. 线程持续存活，导致 `ThreadLocalMap` 长期存在。
+
+虽然 `ThreadLocalMap` 在 `get()`, `set()` 和 `remove()` 操作时会尝试清理 key 为 null 的 entry，但这种清理机制是被动的，并不完全可靠。
+
+**如何避免内存泄漏的发生？**
+
+1. 在使用完 `ThreadLocal` 后，务必调用 `remove()` 方法。 这是最安全和最推荐的做法。 `remove()` 方法会从 `ThreadLocalMap` 中显式地移除对应的 entry，彻底解决内存泄漏的风险。 即使将 `ThreadLocal` 定义为 `static final`，也强烈建议在每次使用后调用 `remove()`。
+2. 在线程池等线程复用的场景下，使用 `try-finally` 块可以确保即使发生异常，`remove()` 方法也一定会被执行。
+
+### ⭐️如何跨线程传递 ThreadLocal 的值？
+
+由于 `ThreadLocal` 的变量值存放在 `Thread` 里，而父子线程属于不同的 `Thread` 的。因此在异步场景下，父子线程的 `ThreadLocal` 值无法进行传递。
+
+如果想要在异步场景下传递 `ThreadLocal` 值，有两种解决方案：
+
+- `InheritableThreadLocal` ：`InheritableThreadLocal` 是 JDK1.2 提供的工具，继承自 `ThreadLocal` 。使用 `InheritableThreadLocal` 时，会在创建子线程时，令子线程继承父线程中的 `ThreadLocal` 值，但是无法支持线程池场景下的 `ThreadLocal` 值传递。
+- `TransmittableThreadLocal` ： `TransmittableThreadLocal` （简称 TTL） 是阿里巴巴开源的工具类，继承并加强了`InheritableThreadLocal`类，可以在线程池的场景下支持 `ThreadLocal` 值传递。项目地址：。
+
+#### InheritableThreadLocal 原理
+
+`InheritableThreadLocal` 实现了创建异步线程时，继承父线程 `ThreadLocal` 值的功能。该类是 JDK 团队提供的，通过改造 JDK 源码包中的 `Thread` 类来实现创建线程时，`ThreadLocal` 值的传递。
+
+**`InheritableThreadLocal` 的值存储在哪里？**
+
+在 `Thread` 类中添加了一个新的 `ThreadLocalMap` ，命名为 `inheritableThreadLocals` ，该变量用于存储需要跨线程传递的 `ThreadLocal` 值。如下：
+
+```JAVA
+class Thread implements Runnable {
+ ThreadLocal.ThreadLocalMap threadLocals = null;
+ ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
+}
+```
+
+**如何完成 `ThreadLocal` 值的传递？**
+
+通过改造 `Thread` 类的构造方法来实现，在创建 `Thread` 线程时，拿到父线程的 `inheritableThreadLocals` 变量赋值给子线程即可。相关代码如下：
+
+```JAVA
+// Thread 的构造方法会调用 init() 方法
+private void init(/* ... */) {
+ // 1、获取父线程
+ Thread parent = currentThread();
+ // 2、将父线程的 inheritableThreadLocals 赋值给子线程
+ if (inheritThreadLocals && parent.inheritableThreadLocals != null)
+ this.inheritableThreadLocals =
+ ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
+}
+```
+
+#### TransmittableThreadLocal 原理
+
+JDK 默认没有支持线程池场景下 `ThreadLocal` 值传递的功能，因此阿里巴巴开源了一套工具 `TransmittableThreadLocal` 来实现该功能。
+
+阿里巴巴无法改动 JDK 的源码，因此他内部通过 **装饰器模式** 在原有的功能上做增强，以此来实现线程池场景下的 `ThreadLocal` 值传递。
+
+TTL 改造的地方有两处：
+
+- 实现自定义的 `Thread` ，在 `run()` 方法内部做 `ThreadLocal` 变量的赋值操作。
+
+- 基于 **线程池** 进行装饰，在 `execute()` 方法中，不提交 JDK 内部的 `Thread` ，而是提交自定义的 `Thread` 。
+
+如果想要查看相关源码，可以引入 Maven 依赖进行下载。
+
+```XML
+
+ com.alibaba
+ transmittable-thread-local
+ 2.12.0
+
+```
+
+#### 应用场景
+
+1. **压测流量标记**： 在压测场景中，使用 `ThreadLocal` 存储压测标记，用于区分压测流量和真实流量。如果标记丢失，可能导致压测流量被错误地当成线上流量处理。
+2. **上下文传递**：在分布式系统中，传递链路追踪信息（如 Trace ID）或用户上下文信息。
## 线程池
@@ -191,25 +235,27 @@ static class Entry extends WeakReference> {
顾名思义，线程池就是管理一系列线程的资源池。当有任务要处理时，直接从线程池中获取线程来处理，处理完之后线程并不会立即被销毁，而是等待下一个任务。
-### 为什么要用线程池？
+### ⭐️为什么要用线程池？
池化技术想必大家已经屡见不鲜了，线程池、数据库连接池、HTTP 连接池等等都是对这个思想的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。
-**线程池**提供了一种限制和管理资源（包括执行一个任务）的方式。 每个**线程池**还维护一些基本统计信息，例如已完成任务的数量。
-
-这里借用《Java 并发编程的艺术》提到的来说一下**使用线程池的好处**：
+线程池提供了一种限制和管理资源（包括执行一个任务）的方式。 每个线程池还维护一些基本统计信息，例如已完成任务的数量。使用线程池主要带来以下几个好处：
-- **降低资源消耗**。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
-- **提高响应速度**。当任务到达时，任务可以不需要等到线程创建就能立即执行。
-- **提高线程的可管理性**。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。
+1. **降低资源消耗**：线程池里的线程是可以重复利用的。一旦线程完成了某个任务，它不会立即销毁，而是回到池子里等待下一个任务。这就避免了频繁创建和销毁线程带来的开销。
+2. **提高响应速度**：因为线程池里通常会维护一定数量的核心线程（或者说“常驻工人”），任务来了之后，可以直接交给这些已经存在的、空闲的线程去执行，省去了创建线程的时间，任务能够更快地得到处理。
+3. **提高线程的可管理性**：线程池允许我们统一管理池中的线程。我们可以配置线程池的大小（核心线程数、最大线程数）、任务队列的类型和大小、拒绝策略等。这样就能控制并发线程的总量，防止资源耗尽，保证系统的稳定性。同时，线程池通常也提供了监控接口，方便我们了解线程池的运行状态（比如有多少活跃线程、多少任务在排队等），便于调优。
### 如何创建线程池？
-**方式一：通过`ThreadPoolExecutor`构造函数来创建（推荐）。**
+在 Java 中，创建线程池主要有两种方式：
-
+**方式一：通过 `ThreadPoolExecutor` 构造函数直接创建 (推荐)**
-**方式二：通过 `Executor` 框架的工具类 `Executors` 来创建。**
+
+
+这是最推荐的方式，因为它允许开发者明确指定线程池的核心参数，对线程池的运行行为有更精细的控制，从而避免资源耗尽的风险。
+
+**方式二：通过 `Executors` 工具类创建 (不推荐用于生产环境)**
`Executors`工具类提供的创建线程池的方法如下图所示：
@@ -222,7 +268,7 @@ static class Entry extends WeakReference> {
- `CachedThreadPool`： 可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用。
- `ScheduledThreadPool`：给定的延迟后运行任务或者定期执行任务的线程池。
-### 为什么不推荐使用内置线程池？
+### ⭐️为什么不推荐使用内置线程池？
在《阿里巴巴 Java 开发手册》“并发处理”这一章节，明确指出线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。
@@ -232,23 +278,21 @@ static class Entry extends WeakReference> {
另外，《阿里巴巴 Java 开发手册》中强制线程池不允许使用 `Executors` 去创建，而是通过 `ThreadPoolExecutor` 构造函数的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险
-`Executors` 返回线程池对象的弊端如下：
+`Executors` 返回线程池对象的弊端如下(后文会详细介绍到)：
-- `FixedThreadPool` 和 `SingleThreadExecutor`:使用的是无界的 `LinkedBlockingQueue`，任务队列最大长度为 `Integer.MAX_VALUE`,可能堆积大量的请求，从而导致 OOM。
+- `FixedThreadPool` 和 `SingleThreadExecutor`:使用的是阻塞队列 `LinkedBlockingQueue`，任务队列最大长度为 `Integer.MAX_VALUE`，可以看作是无界的，可能堆积大量的请求，从而导致 OOM。
- `CachedThreadPool`:使用的是同步队列 `SynchronousQueue`, 允许创建的线程数量为 `Integer.MAX_VALUE` ，如果任务数量过多且执行速度较慢，可能会创建大量的线程，从而导致 OOM。
- `ScheduledThreadPool` 和 `SingleThreadScheduledExecutor`:使用的无界的延迟阻塞队列`DelayedWorkQueue`，任务队列最大长度为 `Integer.MAX_VALUE`,可能堆积大量的请求，从而导致 OOM。
```java
-// 无界队列 LinkedBlockingQueue
public static ExecutorService newFixedThreadPool(int nThreads) {
-
+ // LinkedBlockingQueue 的默认长度为 Integer.MAX_VALUE，可以看作是无界的
return new ThreadPoolExecutor(nThreads, nThreads,0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue());
}
-// 无界队列 LinkedBlockingQueue
public static ExecutorService newSingleThreadExecutor() {
-
+ // LinkedBlockingQueue 的默认长度为 Integer.MAX_VALUE，可以看作是无界的
return new FinalizableDelegatedExecutorService (new ThreadPoolExecutor(1, 1,0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue()));
}
@@ -270,7 +314,7 @@ public ScheduledThreadPoolExecutor(int corePoolSize) {
}
```
-### 线程池常见参数有哪些？如何解释？
+### ⭐️线程池常见参数有哪些？如何解释？
```java
/**
@@ -308,25 +352,103 @@ public ScheduledThreadPoolExecutor(int corePoolSize) {
`ThreadPoolExecutor`其他常见参数 :
-- `keepAliveTime`:线程池中的线程数量大于 `corePoolSize` 的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了 `keepAliveTime`才会被回收销毁。
+- `keepAliveTime`:当线程池中的线程数量大于 `corePoolSize` ，即有非核心线程（线程池中核心线程以外的线程）时，这些非核心线程空闲后不会立即销毁，而是会等待，直到等待的时间超过了 `keepAliveTime`才会被回收销毁。
- `unit` : `keepAliveTime` 参数的时间单位。
- `threadFactory` :executor 创建新线程的时候会用到。
-- `handler` :饱和策略（后面会单独详细介绍一下）。
+- `handler` :拒绝策略（后面会单独详细介绍一下）。
下面这张图可以加深你对线程池中各个参数的相互关系的理解（图片来源：《Java 性能调优实战》）：
-### 线程池的饱和策略有哪些？
+### 线程池的核心线程会被回收吗？
+
+`ThreadPoolExecutor` 默认不会回收核心线程，即使它们已经空闲了。这是为了减少创建线程的开销，因为核心线程通常是要长期保持活跃的。但是，如果线程池是被用于周期性使用的场景，且频率不高（周期之间有明显的空闲时间），可以考虑将 `allowCoreThreadTimeOut(boolean value)` 方法的参数设置为 `true`，这样就会回收空闲（时间间隔由 `keepAliveTime` 指定）的核心线程了。
+
+```java
+public void allowCoreThreadTimeOut(boolean value) {
+ // 核心线程的 keepAliveTime 必须大于 0 才能启用超时机制
+ if (value && keepAliveTime <= 0) {
+ throw new IllegalArgumentException("Core threads must have nonzero keep alive times");
+ }
+ // 设置 allowCoreThreadTimeOut 的值
+ if (value != allowCoreThreadTimeOut) {
+ allowCoreThreadTimeOut = value;
+ // 如果启用了超时机制，清理所有空闲的线程，包括核心线程
+ if (value) {
+ interruptIdleWorkers();
+ }
+ }
+}
+```
+
+### 核心线程空闲时处于什么状态？
+
+核心线程空闲时，其状态分为以下两种情况：
+
+- **设置了核心线程的存活时间** ：核心线程在空闲时，会处于 `WAITING` 状态，等待获取任务。如果阻塞等待的时间超过了核心线程存活时间，则该线程会退出工作，将该线程从线程池的工作线程集合中移除，线程状态变为 `TERMINATED` 状态。
+- **没有设置核心线程的存活时间** ：核心线程在空闲时，会一直处于 `WAITING` 状态，等待获取任务，核心线程会一直存活在线程池中。
+
+当队列中有可用任务时，会唤醒被阻塞的线程，线程的状态会由 `WAITING` 状态变为 `RUNNABLE` 状态，之后去执行对应任务。
+
+接下来通过相关源码，了解一下线程池内部是如何做的。
+
+线程在线程池内部被抽象为了 `Worker` ，当 `Worker` 被启动之后，会不断去任务队列中获取任务。
+
+在获取任务的时候，会根据 `timed` 值来决定从任务队列（ `BlockingQueue` ）获取任务的行为。
+
+如果「设置了核心线程的存活时间」或者「线程数量超过了核心线程数量」，则将 `timed` 标记为 `true` ，表明获取任务时需要使用 `poll()` 指定超时时间。
+
+- `timed == true` ：使用 `poll()` 来获取任务。使用 `poll()` 方法获取任务超时的话，则当前线程会退出执行（ `TERMINATED` ），该线程从线程池中被移除。
+- `timed == false` ：使用 `take()` 来获取任务。使用 `take()` 方法获取任务会让当前线程一直阻塞等待（`WAITING`）。
+
+源码如下：
+
+```JAVA
+// ThreadPoolExecutor
+private Runnable getTask() {
+ boolean timedOut = false;
+ for (;;) {
+ // ...
+
+ // 1、如果「设置了核心线程的存活时间」或者是「线程数量超过了核心线程数量」，则 timed 为 true。
+ boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;
+ // 2、扣减线程数量。
+ // wc > maximuimPoolSize：线程池中的线程数量超过最大线程数量。其中 wc 为线程池中的线程数量。
+ // timed && timeOut：timeOut 表示获取任务超时。
+ // 分为两种情况：核心线程设置了存活时间 && 获取任务超时，则扣减线程数量；线程数量超过了核心线程数量 && 获取任务超时，则扣减线程数量。
+ if ((wc > maximumPoolSize || (timed && timedOut))
+ && (wc > 1 || workQueue.isEmpty())) {
+ if (compareAndDecrementWorkerCount(c))
+ return null;
+ continue;
+ }
+ try {
+ // 3、如果 timed 为 true，则使用 poll() 获取任务；否则，使用 take() 获取任务。
+ Runnable r = timed ?
+ workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
+ workQueue.take();
+ // 4、获取任务之后返回。
+ if (r != null)
+ return r;
+ timedOut = true;
+ } catch (InterruptedException retry) {
+ timedOut = false;
+ }
+ }
+}
+```
+
+### ⭐️线程池的拒绝策略有哪些？
如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任务时，`ThreadPoolExecutor` 定义一些策略:
- `ThreadPoolExecutor.AbortPolicy`：抛出 `RejectedExecutionException`来拒绝新任务的处理。
-- `ThreadPoolExecutor.CallerRunsPolicy`：调用执行自己的线程运行任务，也就是直接在调用`execute`方法的线程中运行(`run`)被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。如果您的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话，你可以选择这个策略。
+- `ThreadPoolExecutor.CallerRunsPolicy`：调用执行者自己的线程运行任务，也就是直接在调用`execute`方法的线程中运行(`run`)被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。如果你的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话，你可以选择这个策略。
- `ThreadPoolExecutor.DiscardPolicy`：不处理新任务，直接丢弃掉。
- `ThreadPoolExecutor.DiscardOldestPolicy`：此策略将丢弃最早的未处理的任务请求。
-举个例子：Spring 通过 `ThreadPoolTaskExecutor` 或者我们直接通过 `ThreadPoolExecutor` 的构造函数创建线程池的时候，当我们不指定 `RejectedExecutionHandler` 饱和策略来配置线程池的时候，默认使用的是 `AbortPolicy`。在这种饱和策略下，如果队列满了，`ThreadPoolExecutor` 将抛出 `RejectedExecutionException` 异常来拒绝新来的任务 ，这代表你将丢失对这个任务的处理。如果不想丢弃任务的话，可以使用`CallerRunsPolicy`。`CallerRunsPolicy` 和其他的几个策略不同，它既不会抛弃任务，也不会抛出异常，而是将任务回退给调用者，使用调用者的线程来执行任务
+举个例子：Spring 通过 `ThreadPoolTaskExecutor` 或者我们直接通过 `ThreadPoolExecutor` 的构造函数创建线程池的时候，当我们不指定 `RejectedExecutionHandler` 拒绝策略来配置线程池的时候，默认使用的是 `AbortPolicy`。在这种拒绝策略下，如果队列满了，`ThreadPoolExecutor` 将抛出 `RejectedExecutionException` 异常来拒绝新来的任务 ，这代表你将丢失对这个任务的处理。如果不想丢弃任务的话，可以使用`CallerRunsPolicy`。`CallerRunsPolicy` 和其他的几个策略不同，它既不会抛弃任务，也不会抛出异常，而是将任务回退给调用者，使用调用者的线程来执行任务。
```java
public static class CallerRunsPolicy implements RejectedExecutionHandler {
@@ -342,26 +464,203 @@ public static class CallerRunsPolicy implements RejectedExecutionHandler {
}
```
+### 如果不允许丢弃任务，应该选择哪个拒绝策略？
+
+根据上面对线程池拒绝策略的介绍，相信大家很容易能够得出答案是：`CallerRunsPolicy` 。
+
+这里我们再来结合`CallerRunsPolicy` 的源码来看看：
+
+```java
+public static class CallerRunsPolicy implements RejectedExecutionHandler {
+
+ public CallerRunsPolicy() { }
+
+
+ public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
+ //只要当前程序没有关闭，就用执行execute方法的线程执行该任务
+ if (!e.isShutdown()) {
+
+ r.run();
+ }
+ }
+ }
+```
+
+从源码可以看出，只要当前程序不关闭就会使用执行`execute`方法的线程执行该任务。
+
+### CallerRunsPolicy 拒绝策略有什么风险？如何解决？
+
+我们上面也提到了：如果想要保证任何一个任务请求都要被执行的话，那选择 `CallerRunsPolicy` 拒绝策略更合适一些。
+
+不过，如果走到`CallerRunsPolicy`的任务是个非常耗时的任务，且处理提交任务的线程是主线程，可能会导致主线程阻塞，影响程序的正常运行。
+
+这里简单举一个例子，该线程池限定了最大线程数为 2，阻塞队列大小为 1(这意味着第 4 个任务就会走到拒绝策略)，`ThreadUtil`为 Hutool 提供的工具类：
+
+```java
+public class ThreadPoolTest {
+
+ private static final Logger log = LoggerFactory.getLogger(ThreadPoolTest.class);
+
+ public static void main(String[] args) {
+ // 创建一个线程池，核心线程数为1，最大线程数为2
+ // 当线程数大于核心线程数时，多余的空闲线程存活的最长时间为60秒，
+ // 任务队列为容量为1的ArrayBlockingQueue，饱和策略为CallerRunsPolicy。
+ ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(1,
+ 2,
+ 60,
+ TimeUnit.SECONDS,
+ new ArrayBlockingQueue<>(1),
+ new ThreadPoolExecutor.CallerRunsPolicy());
+
+ // 提交第一个任务，由核心线程执行
+ threadPoolExecutor.execute(() -> {
+ log.info("核心线程执行第一个任务");
+ ThreadUtil.sleep(1, TimeUnit.MINUTES);
+ });
+
+ // 提交第二个任务，由于核心线程被占用，任务将进入队列等待
+ threadPoolExecutor.execute(() -> {
+ log.info("非核心线程处理入队的第二个任务");
+ ThreadUtil.sleep(1, TimeUnit.MINUTES);
+ });
+
+ // 提交第三个任务，由于核心线程被占用且队列已满，创建非核心线程处理
+ threadPoolExecutor.execute(() -> {
+ log.info("非核心线程处理第三个任务");
+ ThreadUtil.sleep(1, TimeUnit.MINUTES);
+ });
+
+ // 提交第四个任务，由于核心线程和非核心线程都被占用，队列也满了，根据CallerRunsPolicy策略，任务将由提交任务的线程（即主线程）来执行
+ threadPoolExecutor.execute(() -> {
+ log.info("主线程处理第四个任务");
+ ThreadUtil.sleep(2, TimeUnit.MINUTES);
+ });
+
+ // 提交第五个任务，主线程被第四个任务卡住，该任务必须等到主线程执行完才能提交
+ threadPoolExecutor.execute(() -> {
+ log.info("核心线程执行第五个任务");
+ });
+
+ // 关闭线程池
+ threadPoolExecutor.shutdown();
+ }
+}
+
+```
+
+输出：
+
+```bash
+18:19:48.203 INFO [pool-1-thread-1] c.j.concurrent.ThreadPoolTest - 核心线程执行第一个任务
+18:19:48.203 INFO [pool-1-thread-2] c.j.concurrent.ThreadPoolTest - 非核心线程处理第三个任务
+18:19:48.203 INFO [main] c.j.concurrent.ThreadPoolTest - 主线程处理第四个任务
+18:20:48.212 INFO [pool-1-thread-2] c.j.concurrent.ThreadPoolTest - 非核心线程处理入队的第二个任务
+18:21:48.219 INFO [pool-1-thread-2] c.j.concurrent.ThreadPoolTest - 核心线程执行第五个任务
+```
+
+从输出结果可以看出，因为`CallerRunsPolicy`这个拒绝策略，导致耗时的任务用了主线程执行，导致线程池阻塞，进而导致后续任务无法及时执行，严重的情况下很可能导致 OOM。
+
+我们从问题的本质入手，调用者采用`CallerRunsPolicy`是希望所有的任务都能够被执行，暂时无法处理的任务又被保存在阻塞队列`BlockingQueue`中。这样的话，在内存允许的情况下，我们可以增加阻塞队列`BlockingQueue`的大小并调整堆内存以容纳更多的任务，确保任务能够被准确执行。
+
+为了充分利用 CPU，我们还可以调整线程池的`maximumPoolSize` （最大线程数）参数，这样可以提高任务处理速度，避免累计在 `BlockingQueue`的任务过多导致内存用完。
+
+
+
+如果服务器资源以达到可利用的极限，这就意味我们要在设计策略上改变线程池的调度了，我们都知道，导致主线程卡死的本质就是因为我们不希望任何一个任务被丢弃。换个思路，有没有办法既能保证任务不被丢弃且在服务器有余力时及时处理呢？
+
+这里提供的一种**任务持久化**的思路，这里所谓的任务持久化，包括但不限于:
+
+1. 设计一张任务表将任务存储到 MySQL 数据库中。
+2. Redis 缓存任务。
+3. 将任务提交到消息队列中。
+
+这里以方案一为例，简单介绍一下实现逻辑：
+
+1. 实现`RejectedExecutionHandler`接口自定义拒绝策略，自定义拒绝策略负责将线程池暂时无法处理（此时阻塞队列已满）的任务入库（保存到 MySQL 中）。注意：线程池暂时无法处理的任务会先被放在阻塞队列中，阻塞队列满了才会触发拒绝策略。
+2. 继承`BlockingQueue`实现一个混合式阻塞队列，该队列包含 JDK 自带的`ArrayBlockingQueue`。另外，该混合式阻塞队列需要修改取任务处理的逻辑，也就是重写`take()`方法，取任务时优先从数据库中读取最早的任务，数据库中无任务时再从 `ArrayBlockingQueue`中去取任务。
+
+
+
+整个实现逻辑还是比较简单的，核心在于自定义拒绝策略和阻塞队列。如此一来，一旦我们的线程池中线程达到满载时，我们就可以通过拒绝策略将最新任务持久化到 MySQL 数据库中，等到线程池有了有余力处理所有任务时，让其优先处理数据库中的任务以避免"饥饿"问题。
+
+当然，对于这个问题，我们也可以参考其他主流框架的做法，以 Netty 为例，它的拒绝策略则是直接创建一个线程池以外的线程处理这些任务，为了保证任务的实时处理，这种做法可能需要良好的硬件设备且临时创建的线程无法做到准确的监控：
+
+```java
+private static final class NewThreadRunsPolicy implements RejectedExecutionHandler {
+ NewThreadRunsPolicy() {
+ super();
+ }
+ public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
+ try {
+ //创建一个临时线程处理任务
+ final Thread t = new Thread(r, "Temporary task executor");
+ t.start();
+ } catch (Throwable e) {
+ throw new RejectedExecutionException(
+ "Failed to start a new thread", e);
+ }
+ }
+}
+```
+
+ActiveMQ 则是尝试在指定的时效内尽可能的争取将任务入队，以保证最大交付：
+
+```java
+new RejectedExecutionHandler() {
+ @Override
+ public void rejectedExecution(final Runnable r, final ThreadPoolExecutor executor) {
+ try {
+ //限时阻塞等待，实现尽可能交付
+ executor.getQueue().offer(r, 60, TimeUnit.SECONDS);
+ } catch (InterruptedException e) {
+ throw new RejectedExecutionException("Interrupted waiting for BrokerService.worker");
+ }
+ throw new RejectedExecutionException("Timed Out while attempting to enqueue Task.");
+ }
+ });
+```
+
### 线程池常用的阻塞队列有哪些？
新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。
不同的线程池会选用不同的阻塞队列，我们可以结合内置线程池来分析。
-- 容量为 `Integer.MAX_VALUE` 的 `LinkedBlockingQueue`（无界队列）：`FixedThreadPool` 和 `SingleThreadExector` 。`FixedThreadPool`最多只能创建核心线程数的线程（核心线程数和最大线程数相等），`SingleThreadExector`只能创建一个线程（核心线程数和最大线程数都是 1），二者的任务队列永远不会被放满。
+- 容量为 `Integer.MAX_VALUE` 的 `LinkedBlockingQueue`（有界阻塞队列）：`FixedThreadPool` 和 `SingleThreadExecutor` 。`FixedThreadPool`最多只能创建核心线程数的线程（核心线程数和最大线程数相等），`SingleThreadExecutor`只能创建一个线程（核心线程数和最大线程数都是 1），二者的任务队列永远不会被放满。
- `SynchronousQueue`（同步队列）：`CachedThreadPool` 。`SynchronousQueue` 没有容量，不存储元素，目的是保证对于提交的任务，如果有空闲线程，则使用空闲线程来处理；否则新建一个线程来处理任务。也就是说，`CachedThreadPool` 的最大线程数是 `Integer.MAX_VALUE` ，可以理解为线程数是可以无限扩展的，可能会创建大量线程，从而导致 OOM。
-- `DelayedWorkQueue`（延迟阻塞队列）：`ScheduledThreadPool` 和 `SingleThreadScheduledExecutor` 。`DelayedWorkQueue` 的内部元素并不是按照放入的时间排序，而是会按照延迟的时间长短对任务进行排序，内部采用的是“堆”的数据结构，可以保证每次出队的任务都是当前队列中执行时间最靠前的。`DelayedWorkQueue` 添加元素满了之后会自动扩容原来容量的 1/2，即永远不会阻塞，最大扩容可达 `Integer.MAX_VALUE`，所以最多只能创建核心线程数的线程。
+- `DelayedWorkQueue`（延迟队列）：`ScheduledThreadPool` 和 `SingleThreadScheduledExecutor` 。`DelayedWorkQueue` 的内部元素并不是按照放入的时间排序，而是会按照延迟的时间长短对任务进行排序，内部采用的是“堆”的数据结构，可以保证每次出队的任务都是当前队列中执行时间最靠前的。`DelayedWorkQueue` 添加元素满了之后会自动扩容，增加原来容量的 50%，即永远不会阻塞，最大扩容可达 `Integer.MAX_VALUE`，所以最多只能创建核心线程数的线程。
+- `ArrayBlockingQueue`（有界阻塞队列）：底层由数组实现，容量一旦创建，就不能修改。
-### 线程池处理任务的流程了解吗？
+### ⭐️线程池处理任务的流程了解吗？
1. 如果当前运行的线程数小于核心线程数，那么就会新建一个线程来执行任务。
2. 如果当前运行的线程数等于或大于核心线程数，但是小于最大线程数，那么就把该任务放入到任务队列里等待执行。
3. 如果向任务队列投放任务失败（任务队列已经满了），但是当前运行的线程数是小于最大线程数的，就新建一个线程来执行任务。
-4. 如果当前运行的线程数已经等同于最大线程数了，新建线程将会使当前运行的线程超出最大线程数，那么当前任务会被拒绝，饱和策略会调用`RejectedExecutionHandler.rejectedExecution()`方法。
+4. 如果当前运行的线程数已经等同于最大线程数了，新建线程将会使当前运行的线程超出最大线程数，那么当前任务会被拒绝，拒绝策略会调用`RejectedExecutionHandler.rejectedExecution()`方法。
+
+再提一个有意思的小问题：**线程池在提交任务前，可以提前创建线程吗？**
+
+答案是可以的！`ThreadPoolExecutor` 提供了两个方法帮助我们在提交任务之前，完成核心线程的创建，从而实现线程池预热的效果：
-### 如何给线程池命名？
+- `prestartCoreThread()`:启动一个线程，等待任务，如果已达到核心线程数，这个方法返回 false，否则返回 true；
+- `prestartAllCoreThreads()`:启动所有的核心线程，并返回启动成功的核心线程数。
+
+### ⭐️线程池中线程异常后，销毁还是复用？
+
+直接说结论，需要分两种情况：
+
+- **使用`execute()`提交任务**：当任务通过`execute()`提交到线程池并在执行过程中抛出异常时，如果这个异常没有在任务内被捕获，那么该异常会导致当前线程终止，并且异常会被打印到控制台或日志文件中。线程池会检测到这种线程终止，并创建一个新线程来替换它，从而保持配置的线程数不变。
+- **使用`submit()`提交任务**：对于通过`submit()`提交的任务，如果在任务执行中发生异常，这个异常不会直接打印出来。相反，异常会被封装在由`submit()`返回的`Future`对象中。当调用`Future.get()`方法时，可以捕获到一个`ExecutionException`。在这种情况下，线程不会因为异常而终止，它会继续存在于线程池中，准备执行后续的任务。
+
+简单来说：使用`execute()`时，未捕获异常导致线程终止，线程池创建新线程替代；使用`submit()`时，异常被封装在`Future`中，线程继续复用。
+
+这种设计允许`submit()`提供更灵活的错误处理机制，因为它允许调用者决定如何处理异常，而`execute()`则适用于那些不需要关注执行结果的场景。
+
+具体的源码分析可以参考这篇：[线程池中线程异常后：销毁还是复用？ - 京东技术](https://mp.weixin.qq.com/s/9ODjdUU-EwQFF5PrnzOGfw)。
+
+### ⭐️如何给线程池命名？
初始化线程池的时候需要显示命名（设置线程池名称前缀），有利于定位问题。
@@ -420,7 +719,7 @@ public final class NamingThreadFactory implements ThreadFactory {
>
> Linux 相比与其他操作系统（包括其他类 Unix 系统）有很多的优点，其中有一项就是，其上下文切换和模式切换的时间消耗非常少。
-类比于实现世界中的人类通过合作做某件事情，我们可以肯定的一点是线程池大小设置过大或者过小都会有问题，合适的才是最好。
+类比于现实世界中的人类通过合作做某件事情，我们可以肯定的一点是线程池大小设置过大或者过小都会有问题，合适的才是最好。
- 如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的，CPU 根本没有得到充分利用。
- 如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。
@@ -448,7 +747,7 @@ CPU 密集型简单理解就是利用 CPU 计算能力的任务比如你在内
公式也只是参考，具体还是要根据项目实际线上运行情况来动态调整。我在后面介绍的美团的线程池参数动态配置这种方案就非常不错，很实用！
-### 如何动态修改线程池的参数？
+### ⭐️如何动态修改线程池的参数？
美团技术团队在[《Java 线程池实现原理及其在美团业务中的实践》](https://tech.meituan.com/2020/04/02/java-pooling-pratice-in-meituan.html)这篇文章中介绍到对线程池参数实现可自定义配置的思路和方法。
@@ -474,18 +773,20 @@ CPU 密集型简单理解就是利用 CPU 计算能力的任务比如你在内
-还没看够？推荐 why 神的[如何设置线程池参数？美团给出了一个让面试官虎躯一震的回答。](https://mp.weixin.qq.com/s/9HLuPcoWmTqAeFKa1kj-_A)这篇文章，深度剖析，很不错哦！
+还没看够？我在[《后端面试高频系统设计&场景题》](https://javaguide.cn/zhuanlan/back-end-interview-high-frequency-system-design-and-scenario-questions.html#%E4%BB%8B%E7%BB%8D)中详细介绍了如何设计一个动态线程池，这也是面试中常问的一道系统设计题。
+
+
如果我们的项目也想要实现这种效果的话，可以借助现成的开源项目：
- **[Hippo4j](https://github.com/opengoofy/hippo4j)**：异步线程池框架，支持线程池动态变更&监控&报警，无需修改代码轻松引入。支持多种使用模式，轻松引入，致力于提高系统运行保障能力。
- **[Dynamic TP](https://github.com/dromara/dynamic-tp)**：轻量级动态线程池，内置监控告警功能，集成三方中间件线程池管理，基于主流配置中心（已支持 Nacos、Apollo，Zookeeper、Consul、Etcd，可通过 SPI 自定义实现）。
-### 如何设计一个能够根据任务的优先级来执行的线程池？
+### ⭐️如何设计一个能够根据任务的优先级来执行的线程池？
这是一个常见的面试问题，本质其实还是在考察求职者对于线程池以及阻塞队列的掌握。
-我们上面也提到了，不同的线程池会选用不同的阻塞队列作为任务队列，比如`FixedThreadPool` 使用的是`LinkedBlockingQueue`（无界队列），由于队列永远不会被放满，因此`FixedThreadPool`最多只能创建核心线程数的线程。
+我们上面也提到了，不同的线程池会选用不同的阻塞队列作为任务队列，比如`FixedThreadPool` 使用的是`LinkedBlockingQueue`（有界队列），默认构造器初始的队列长度为 `Integer.MAX_VALUE` ，由于队列永远不会被放满，因此`FixedThreadPool`最多只能创建核心线程数的线程。
假如我们需要实现一个优先级任务线程池的话，那可以考虑使用 `PriorityBlockingQueue` （优先级阻塞队列）作为任务队列（`ThreadPoolExecutor` 的构造函数有一个 `workQueue` 参数可以传入任务队列）。
@@ -512,6 +813,10 @@ CPU 密集型简单理解就是利用 CPU 计算能力的任务比如你在内
## Future
+重点是要掌握 `CompletableFuture` 的使用以及常见面试题。
+
+除了下面的面试题之外，还推荐你看看我写的这篇文章： [CompletableFuture 详解](./completablefuture-intro.md)。
+
### Future 类有什么用？
`Future` 类是异步思想的典型运用，主要用在一些需要执行耗时任务的场景，避免程序一直原地等待耗时任务执行完成，执行效率太低。具体来说是这样的：当我们执行某一耗时的任务时，可以将这个耗时任务交给一个子线程去异步执行，同时我们可以干点其他事情，不用傻傻等待耗时任务执行完成。等我们的事情干完后，我们再通过 `Future` 类获取到耗时任务的执行结果。这样一来，程序的执行效率就明显提高了。
@@ -580,9 +885,11 @@ public FutureTask(Runnable runnable, V result) {
`FutureTask`相当于对`Callable` 进行了封装，管理着任务执行的情况，存储了 `Callable` 的 `call` 方法的任务执行结果。
+关于更多 `Future` 的源码细节，可以肝这篇万字解析，写的很清楚：[Java 是如何实现 Future 模式的？万字详解！](https://juejin.cn/post/6844904199625375757)。
+
### CompletableFuture 类有什么用？
-`Future` 在实际使用过程中存在一些局限性比如不支持异步任务的编排组合、获取计算结果的 `get()` 方法为阻塞调用。
+`Future` 在实际使用过程中存在一些局限性，比如不支持异步任务的编排组合、获取计算结果的 `get()` 方法为阻塞调用。
Java 8 才被引入`CompletableFuture` 类可以解决`Future` 的这些缺陷。`CompletableFuture` 除了提供了更为好用和强大的 `Future` 特性之外，还提供了函数式编程、异步任务编排组合（可以将多个异步任务串联起来，组成一个完整的链式调用）等能力。
@@ -603,36 +910,105 @@ public class CompletableFuture implements Future, CompletionStage {
-## AQS
+### ⭐️一个任务需要依赖另外两个任务执行完之后再执行，怎么设计？
-### AQS 是什么？
+这种任务编排场景非常适合通过`CompletableFuture`实现。这里假设要实现 T3 在 T2 和 T1 执行完后执行。
-AQS 的全称为 `AbstractQueuedSynchronizer` ，翻译过来的意思就是抽象队列同步器。这个类在 `java.util.concurrent.locks` 包下面。
+代码如下（这里为了简化代码，用到了 Hutool 的线程工具类 `ThreadUtil` 和日期时间工具类 `DateUtil`）：
-
+```java
+// T1
+CompletableFuture futureT1 = CompletableFuture.runAsync(() -> {
+ System.out.println("T1 is executing. Current time：" + DateUtil.now());
+ // 模拟耗时操作
+ ThreadUtil.sleep(1000);
+});
+// T2
+CompletableFuture futureT2 = CompletableFuture.runAsync(() -> {
+ System.out.println("T2 is executing. Current time：" + DateUtil.now());
+ ThreadUtil.sleep(1000);
+});
+
+// 使用allOf()方法合并T1和T2的CompletableFuture，等待它们都完成
+CompletableFuture bothCompleted = CompletableFuture.allOf(futureT1, futureT2);
+// 当T1和T2都完成后，执行T3
+bothCompleted.thenRunAsync(() -> System.out.println("T3 is executing after T1 and T2 have completed.Current time：" + DateUtil.now()));
+// 等待所有任务完成，验证效果
+ThreadUtil.sleep(3000);
+```
+
+通过 `CompletableFuture` 的 `allOf()` 这个静态方法来并行运行 T1 和 T2，当 T1 和 T2 都完成后，再执行 T3。
+
+### ⭐️使用 CompletableFuture，有一个任务失败，如何处理异常？
+
+使用 `CompletableFuture`的时候一定要以正确的方式进行异常处理，避免异常丢失或者出现不可控问题。
+
+下面是一些建议：
+
+- 使用 `whenComplete` 方法可以在任务完成时触发回调函数，并正确地处理异常，而不是让异常被吞噬或丢失。
+- 使用 `exceptionally` 方法可以处理异常并重新抛出，以便异常能够传播到后续阶段，而不是让异常被忽略或终止。
+- 使用 `handle` 方法可以处理正常的返回结果和异常，并返回一个新的结果，而不是让异常影响正常的业务逻辑。
+- 使用 `CompletableFuture.allOf` 方法可以组合多个 `CompletableFuture`，并统一处理所有任务的异常，而不是让异常处理过于冗长或重复。
+- ……
-AQS 就是一个抽象类，主要用来构建锁和同步器。
+### ⭐️在使用 CompletableFuture 的时候为什么要自定义线程池？
+
+`CompletableFuture` 默认使用全局共享的 `ForkJoinPool.commonPool()` 作为执行器，所有未指定执行器的异步任务都会使用该线程池。这意味着应用程序、多个库或框架（如 Spring、第三方库）若都依赖 `CompletableFuture`，默认情况下它们都会共享同一个线程池。
+
+虽然 `ForkJoinPool` 效率很高，但当同时提交大量任务时，可能会导致资源竞争和线程饥饿，进而影响系统性能。
+
+为避免这些问题，建议为 `CompletableFuture` 提供自定义线程池，带来以下优势：
+
+- 隔离性：为不同任务分配独立的线程池，避免全局线程池资源争夺。
+- 资源控制：根据任务特性调整线程池大小和队列类型，优化性能表现。
+- 异常处理：通过自定义 `ThreadFactory` 更好地处理线程中的异常情况。
```java
-public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable {
-}
+private ThreadPoolExecutor executor = new ThreadPoolExecutor(10, 10,
+ 0L, TimeUnit.MILLISECONDS,
+ new LinkedBlockingQueue());
+
+CompletableFuture.runAsync(() -> {
+ //...
+}, executor);
```
-AQS 为构建锁和同步器提供了一些通用功能的实现，因此，使用 AQS 能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的 `ReentrantLock`，`Semaphore`，其他的诸如 `ReentrantReadWriteLock`，`SynchronousQueue`等等皆是基于 AQS 的。
+## AQS
+
+关于 AQS 源码的详细分析，可以看看这一篇文章：[AQS 详解](./aqs.md)。
+
+### AQS 是什么？
+
+AQS （`AbstractQueuedSynchronizer` ，抽象队列同步器）是从 JDK1.5 开始提供的 Java 并发核心组件。
+
+AQS 解决了开发者在实现同步器时的复杂性问题。它提供了一个通用框架，用于实现各种同步器，例如 **可重入锁**（`ReentrantLock`）、**信号量**（`Semaphore`）和 **倒计时器**（`CountDownLatch`）。通过封装底层的线程同步机制，AQS 将复杂的线程管理逻辑隐藏起来，使开发者只需专注于具体的同步逻辑。
+
+简单来说，AQS 是一个抽象类，为同步器提供了通用的 **执行框架**。它定义了 **资源获取和释放的通用流程**，而具体的资源获取逻辑则由具体同步器通过重写模板方法来实现。 因此，可以将 AQS 看作是同步器的 **基础“底座”**，而同步器则是基于 AQS 实现的 **具体“应用”**。
+
+### ⭐️AQS 的原理是什么？
+
+AQS 核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是基于 **CLH 锁** （Craig, Landin, and Hagersten locks） 进一步优化实现的。
+
+**CLH 锁** 对自旋锁进行了改进，是基于单链表的自旋锁。在多线程场景下，会将请求获取锁的线程组织成一个单向队列，每个等待的线程会通过自旋访问前一个线程节点的状态，前一个节点释放锁之后，当前节点才可以获取锁。**CLH 锁** 的队列结构如下图所示。
+
+
+
+AQS 中使用的 **等待队列** 是 CLH 锁队列的变体（接下来简称为 CLH 变体队列）。
-### AQS 的原理是什么？
+AQS 的 CLH 变体队列是一个双向队列，会暂时获取不到锁的线程将被加入到该队列中，CLH 变体队列和原本的 CLH 锁队列的区别主要有两点：
-AQS 核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是用 **CLH 队列锁** 实现的，即将暂时获取不到锁的线程加入到队列中。
+- 由 **自旋** 优化为 **自旋 + 阻塞** ：自旋操作的性能很高，但大量的自旋操作比较占用 CPU 资源，因此在 CLH 变体队列中会先通过自旋尝试获取锁，如果失败再进行阻塞等待。
+- 由 **单向队列** 优化为 **双向队列** ：在 CLH 变体队列中，会对等待的线程进行阻塞操作，当队列前边的线程释放锁之后，需要对后边的线程进行唤醒，因此增加了 `next` 指针，成为了双向队列。
-CLH(Craig,Landin,and Hagersten) 队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS 是将每条请求共享资源的线程封装成一个 CLH 锁队列的一个结点（Node）来实现锁的分配。在 CLH 同步队列中，一个节点表示一个线程，它保存着线程的引用（thread）、 当前节点在队列中的状态（waitStatus）、前驱节点（prev）、后继节点（next）。
+AQS 将每条请求共享资源的线程封装成一个 CLH 变体队列的一个结点（Node）来实现锁的分配。在 CLH 变体队列中，一个节点表示一个线程，它保存着线程的引用（thread）、 当前节点在队列中的状态（waitStatus）、前驱节点（prev）、后继节点（next）。
-CLH 队列结构如下图所示：
+AQS 中的 CLH 变体队列结构如下图所示：
-
+
-AQS(`AbstractQueuedSynchronizer`)的核心原理图（图源[Java 并发之 AQS 详解](https://www.cnblogs.com/waterystone/p/4920797.html)）如下：
+AQS(`AbstractQueuedSynchronizer`)的核心原理图：
-
+
AQS 使用 **int 成员变量 `state` 表示同步状态**，通过内置的 **线程等待队列** 来完成获取资源线程的排队工作。
@@ -662,7 +1038,7 @@ protected final boolean compareAndSetState(int expect, int update) {
以 `ReentrantLock` 为例，`state` 初始值为 0，表示未锁定状态。A 线程 `lock()` 时，会调用 `tryAcquire()` 独占该锁并将 `state+1` 。此后，其他线程再 `tryAcquire()` 时就会失败，直到 A 线程 `unlock()` 到 `state=`0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己是可以重复获取此锁的（`state` 会累加），这就是可重入的概念。但要注意，获取多少次就要释放多少次，这样才能保证 state 是能回到零态的。
-再以 `CountDownLatch` 以例，任务分为 N 个子线程去执行，`state` 也初始化为 N（注意 N 要与线程个数一致）。这 N 个子线程是并行执行的，每个子线程执行完后`countDown()` 一次，state 会 CAS(Compare and Swap) 减 1。等到所有子线程都执行完后(即 `state=0` )，会 `unpark()` 主调用线程，然后主调用线程就会从 `await()` 函数返回，继续后余动作。
+再以 `CountDownLatch` 以例，任务分为 N 个子线程去执行，`state` 也初始化为 N（注意 N 要与线程个数一致）。这 N 个子线程是并行执行的，每个子线程执行完后`countDown()` 一次，state 会 CAS(Compare and Swap) 减 1。等到所有子线程都执行完后(即 `state=0` )，会 `unpark()` 主调用线程，然后主调用线程就会从 `await()` 函数返回，继续后续动作。
### Semaphore 有什么用？
@@ -843,7 +1219,7 @@ CompletableFuture allFutures = CompletableFuture.allOf(
`CyclicBarrier` 和 `CountDownLatch` 非常类似，它也可以实现线程间的技术等待，但是它的功能比 `CountDownLatch` 更加复杂和强大。主要应用场景和 `CountDownLatch` 类似。
-> `CountDownLatch` 的实现是基于 AQS 的，而 `CycliBarrier` 是基于 `ReentrantLock`(`ReentrantLock` 也属于 AQS 同步器)和 `Condition` 的。
+> `CountDownLatch` 的实现是基于 AQS 的，而 `CyclicBarrier` 是基于 `ReentrantLock`(`ReentrantLock` 也属于 AQS 同步器)和 `Condition` 的。
`CyclicBarrier` 的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是：让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。
@@ -981,6 +1357,7 @@ public int await() throws InterruptedException, BrokenBarrierException {
- 《深入理解 Java 虚拟机》
- 《实战 Java 高并发程序设计》
+- Java 线程池的实现原理及其在业务中的最佳实践:阿里云开发者：
- 带你了解下 SynchronousQueue（并发队列专题）：
- 阻塞队列 — DelayedWorkQueue 源码分析：
- Java 多线程（三）——FutureTask/CompletableFuture：
diff --git a/docs/java/concurrent/java-thread-pool-best-practices.md b/docs/java/concurrent/java-thread-pool-best-practices.md
index 62b2475e523..04154bfa378 100644
--- a/docs/java/concurrent/java-thread-pool-best-practices.md
+++ b/docs/java/concurrent/java-thread-pool-best-practices.md
@@ -13,9 +13,9 @@ tag:
`Executors` 返回线程池对象的弊端如下(后文会详细介绍到)：
-- **`FixedThreadPool` 和 `SingleThreadExecutor`**：使用的是无界的 `LinkedBlockingQueue`，任务队列最大长度为 `Integer.MAX_VALUE`,可能堆积大量的请求，从而导致 OOM。
-- **`CachedThreadPool`**：使用的是同步队列 `SynchronousQueue`, 允许创建的线程数量为 `Integer.MAX_VALUE` ，可能会创建大量线程，从而导致 OOM。
-- **`ScheduledThreadPool` 和 `SingleThreadScheduledExecutor`** : 使用的无界的延迟阻塞队列`DelayedWorkQueue`，任务队列最大长度为 `Integer.MAX_VALUE`,可能堆积大量的请求，从而导致 OOM。
+- **`FixedThreadPool` 和 `SingleThreadExecutor`**：使用的是阻塞队列 `LinkedBlockingQueue`，任务队列的默认长度和最大长度为 `Integer.MAX_VALUE`，可以看作是无界队列，可能堆积大量的请求，从而导致 OOM。
+- **`CachedThreadPool`**：使用的是同步队列 `SynchronousQueue`，允许创建的线程数量为 `Integer.MAX_VALUE` ，可能会创建大量线程，从而导致 OOM。
+- **`ScheduledThreadPool` 和 `SingleThreadScheduledExecutor`** : 使用的无界的延迟阻塞队列`DelayedWorkQueue`，任务队列最大长度为 `Integer.MAX_VALUE`，可能堆积大量的请求，从而导致 OOM。
说白了就是：**使用有界队列，控制线程创建数量。**
@@ -136,15 +136,20 @@ public final class NamingThreadFactory implements ThreadFactory {
>
> Linux 相比与其他操作系统（包括其他类 Unix 系统）有很多的优点，其中有一项就是，其上下文切换和模式切换的时间消耗非常少。
-类比于实现世界中的人类通过合作做某件事情，我们可以肯定的一点是线程池大小设置过大或者过小都会有问题，合适的才是最好。
+类比于现实世界中的人类通过合作做某件事情，我们可以肯定的一点是线程池大小设置过大或者过小都会有问题，合适的才是最好。
- 如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的，CPU 根本没有得到充分利用。
- 如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。
有一个简单并且适用面比较广的公式：
-- **CPU 密集型任务(N+1)：** 这种任务消耗的主要是 CPU 资源，可以将线程数设置为 N（CPU 核心数）+1。比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。
-- **I/O 密集型任务(2N)：** 这种任务应用起来，系统会用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是 2N。
+- **CPU 密集型任务 (N)：** 这种任务消耗的主要是 CPU 资源，线程数应设置为 N（CPU 核心数）。由于任务主要瓶颈在于 CPU 计算能力，与核心数相等的线程数能够最大化 CPU 利用率，过多线程反而会导致竞争和上下文切换开销。
+- **I/O 密集型任务(M \* N)：** 这类任务大部分时间处理 I/O 交互，线程在等待 I/O 时不占用 CPU。 为了充分利用 CPU 资源，线程数可以设置为 M \* N，其中 N 是 CPU 核心数，M 是一个大于 1 的倍数，建议默认设置为 2 ，具体取值取决于 I/O 等待时间和任务特点，需要通过测试和监控找到最佳平衡点。
+
+CPU 密集型任务不再推荐 N+1，原因如下：
+
+- "N+1" 的初衷是希望预留线程处理突发暂停，但实际上，处理缺页中断等情况仍然需要占用 CPU 核心。
+- CPU 密集场景下，CPU 始终是瓶颈，预留线程并不能凭空增加 CPU 处理能力，反而可能加剧竞争。
**如何判断是 CPU 密集任务还是 IO 密集任务？**
@@ -170,7 +175,7 @@ IO 密集型任务下，几乎全是线程等待时间，从理论上来说，
美团技术团队的思路是主要对线程池的核心参数实现自定义可配置。这三个核心参数是：
-- **`corePoolSize` :** 核心线程数线程数定义了最小可以同时运行的线程数量。
+- **`corePoolSize` :** 核心线程数定义了最小可以同时运行的线程数量。
- **`maximumPoolSize` :** 当队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。
- **`workQueue`:** 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。
@@ -227,7 +232,7 @@ try {
线程池本身的目的是为了提高任务执行效率，避免因频繁创建和销毁线程而带来的性能开销。如果将耗时任务提交到线程池中执行，可能会导致线程池中的线程被长时间占用，无法及时响应其他任务，甚至会导致线程池崩溃或者程序假死。
-因此，在使用线程池时，我们应该尽量避免将耗时任务提交到线程池中执行。对于一些比较耗时的操作，如网络请求、文件读写等，可以采用异步操作的方式来处理，以避免阻塞线程池中的线程。
+因此，在使用线程池时，我们应该尽量避免将耗时任务提交到线程池中执行。对于一些比较耗时的操作，如网络请求、文件读写等，可以采用 `CompletableFuture` 等其他异步操作的方式来处理，以避免阻塞线程池中的线程。
## 8、线程池使用的一些小坑
diff --git a/docs/java/concurrent/java-thread-pool-summary.md b/docs/java/concurrent/java-thread-pool-summary.md
index 9dff3a50147..47a1f916de2 100644
--- a/docs/java/concurrent/java-thread-pool-summary.md
+++ b/docs/java/concurrent/java-thread-pool-summary.md
@@ -5,6 +5,8 @@ tag:
- Java并发
---
+
+
池化技术想必大家已经屡见不鲜了，线程池、数据库连接池、HTTP 连接池等等都是对这个思想的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。
这篇文章我会详细介绍一下线程池的基本概念以及核心原理。
@@ -125,13 +127,13 @@ public class ScheduledThreadPoolExecutor
- `keepAliveTime`:线程池中的线程数量大于 `corePoolSize` 的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了 `keepAliveTime`才会被回收销毁。
- `unit` : `keepAliveTime` 参数的时间单位。
- `threadFactory` :executor 创建新线程的时候会用到。
-- `handler` :饱和策略（后面会单独详细介绍一下）。
+- `handler` :拒绝策略（后面会单独详细介绍一下）。
下面这张图可以加深你对线程池中各个参数的相互关系的理解（图片来源：《Java 性能调优实战》）：
-**`ThreadPoolExecutor` 饱和策略定义:**
+**`ThreadPoolExecutor` 拒绝策略定义:**
如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任务时，`ThreadPoolExecutor` 定义一些策略:
@@ -142,7 +144,7 @@ public class ScheduledThreadPoolExecutor
举个例子：
-举个例子：Spring 通过 `ThreadPoolTaskExecutor` 或者我们直接通过 `ThreadPoolExecutor` 的构造函数创建线程池的时候，当我们不指定 `RejectedExecutionHandler` 饱和策略来配置线程池的时候，默认使用的是 `AbortPolicy`。在这种饱和策略下，如果队列满了，`ThreadPoolExecutor` 将抛出 `RejectedExecutionException` 异常来拒绝新来的任务 ，这代表你将丢失对这个任务的处理。如果不想丢弃任务的话，可以使用`CallerRunsPolicy`。`CallerRunsPolicy` 和其他的几个策略不同，它既不会抛弃任务，也不会抛出异常，而是将任务回退给调用者，使用调用者的线程来执行任务
+举个例子：Spring 通过 `ThreadPoolTaskExecutor` 或者我们直接通过 `ThreadPoolExecutor` 的构造函数创建线程池的时候，当我们不指定 `RejectedExecutionHandler` 拒绝策略来配置线程池的时候，默认使用的是 `AbortPolicy`。在这种拒绝策略下，如果队列满了，`ThreadPoolExecutor` 将抛出 `RejectedExecutionException` 异常来拒绝新来的任务 ，这代表你将丢失对这个任务的处理。如果不想丢弃任务的话，可以使用`CallerRunsPolicy`。`CallerRunsPolicy` 和其他的几个策略不同，它既不会抛弃任务，也不会抛出异常，而是将任务回退给调用者，使用调用者的线程来执行任务
```java
public static class CallerRunsPolicy implements RejectedExecutionHandler {
@@ -160,11 +162,15 @@ public static class CallerRunsPolicy implements RejectedExecutionHandler {
### 线程池创建的两种方式
-**方式一：通过`ThreadPoolExecutor`构造函数来创建（推荐）。**
+在 Java 中，创建线程池主要有两种方式：
+
+**方式一：通过 `ThreadPoolExecutor` 构造函数直接创建 (推荐)**
+
+
-
+这是最推荐的方式，因为它允许开发者明确指定线程池的核心参数，对线程池的运行行为有更精细的控制，从而避免资源耗尽的风险。
-**方式二：通过 `Executor` 框架的工具类 `Executors` 来创建。**
+**方式二：通过 `Executors` 工具类创建 (不推荐用于生产环境)**
`Executors`工具类提供的创建线程池的方法如下图所示：
@@ -181,21 +187,19 @@ public static class CallerRunsPolicy implements RejectedExecutionHandler {
`Executors` 返回线程池对象的弊端如下(后文会详细介绍到)：
-- `FixedThreadPool` 和 `SingleThreadExecutor`:使用的是无界的 `LinkedBlockingQueue`，任务队列最大长度为 `Integer.MAX_VALUE`,可能堆积大量的请求，从而导致 OOM。
+- `FixedThreadPool` 和 `SingleThreadExecutor`:使用的是阻塞队列 `LinkedBlockingQueue`，任务队列最大长度为 `Integer.MAX_VALUE`，可以看作是无界的，可能堆积大量的请求，从而导致 OOM。
- `CachedThreadPool`:使用的是同步队列 `SynchronousQueue`, 允许创建的线程数量为 `Integer.MAX_VALUE` ，如果任务数量过多且执行速度较慢，可能会创建大量的线程，从而导致 OOM。
- `ScheduledThreadPool` 和 `SingleThreadScheduledExecutor`:使用的无界的延迟阻塞队列`DelayedWorkQueue`，任务队列最大长度为 `Integer.MAX_VALUE`,可能堆积大量的请求，从而导致 OOM。
```java
-// 无界队列 LinkedBlockingQueue
public static ExecutorService newFixedThreadPool(int nThreads) {
-
+ // LinkedBlockingQueue 的默认长度为 Integer.MAX_VALUE，可以看作是无界的
return new ThreadPoolExecutor(nThreads, nThreads,0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue());
}
-// 无界队列 LinkedBlockingQueue
public static ExecutorService newSingleThreadExecutor() {
-
+ // LinkedBlockingQueue 的默认长度为 Integer.MAX_VALUE，可以看作是无界的
return new FinalizableDelegatedExecutorService (new ThreadPoolExecutor(1, 1,0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue()));
}
@@ -325,7 +329,7 @@ public class ThreadPoolExecutorDemo {
- `keepAliveTime` : 等待时间为 1L。
- `unit`: 等待时间的单位为 TimeUnit.SECONDS。
- `workQueue`：任务队列为 `ArrayBlockingQueue`，并且容量为 100;
-- `handler`:饱和策略为 `CallerRunsPolicy`。
+- `handler`:拒绝策略为 `CallerRunsPolicy`。
**输出结构**：
@@ -413,7 +417,7 @@ Finished all threads // 任务全部执行完了才会跳出来，因为executo
1. 如果当前运行的线程数小于核心线程数，那么就会新建一个线程来执行任务。
2. 如果当前运行的线程数等于或大于核心线程数，但是小于最大线程数，那么就把该任务放入到任务队列里等待执行。
3. 如果向任务队列投放任务失败（任务队列已经满了），但是当前运行的线程数是小于最大线程数的，就新建一个线程来执行任务。
-4. 如果当前运行的线程数已经等同于最大线程数了，新建线程将会使当前运行的线程超出最大线程数，那么当前任务会被拒绝，饱和策略会调用`RejectedExecutionHandler.rejectedExecution()`方法。
+4. 如果当前运行的线程数已经等同于最大线程数了，新建线程将会使当前运行的线程超出最大线程数，那么当前任务会被拒绝，拒绝策略会调用`RejectedExecutionHandler.rejectedExecution()`方法。
@@ -534,7 +538,7 @@ Finished all threads // 任务全部执行完了才会跳出来，因为executo
#### `Runnable` vs `Callable`
-`Runnable`自 Java 1.0 以来一直存在，但`Callable`仅在 Java 1.5 中引入,目的就是为了来处理`Runnable`不支持的用例。**`Runnable` 接口**不会返回结果或抛出检查异常，但是 **`Callable` 接口**可以。所以，如果任务不需要返回结果或抛出异常推荐使用 **`Runnable` 接口**，这样代码看起来会更加简洁。
+`Runnable`自 Java 1.0 以来一直存在，但`Callable`仅在 Java 1.5 中引入,目的就是为了来处理`Runnable`不支持的用例。`Runnable` 接口不会返回结果或抛出检查异常，但是 `Callable` 接口可以。所以，如果任务不需要返回结果或抛出异常推荐使用 `Runnable` 接口，这样代码看起来会更加简洁。
工具类 `Executors` 可以实现将 `Runnable` 对象转换成 `Callable` 对象。（`Executors.callable(Runnable task)` 或 `Executors.callable(Runnable task, Object result)`）。
@@ -567,14 +571,15 @@ public interface Callable {
#### `execute()` vs `submit()`
-- `execute()`方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功与否；
-- `submit()`方法用于提交需要返回值的任务。线程池会返回一个 `Future` 类型的对象，通过这个 `Future` 对象可以判断任务是否执行成功，并且可以通过 `Future` 的 `get()`方法来获取返回值，`get()`方法会阻塞当前线程直到任务完成，而使用 `get（long timeout，TimeUnit unit）`方法的话，如果在 `timeout` 时间内任务还没有执行完，就会抛出 `java.util.concurrent.TimeoutException`。
+`execute()` 和 `submit()`是两种提交任务到线程池的方法，有一些区别：
-这里只是为了演示使用，推荐使用 `ThreadPoolExecutor` 构造方法来创建线程池。
+- **返回值**：`execute()` 方法用于提交不需要返回值的任务。通常用于执行 `Runnable` 任务，无法判断任务是否被线程池成功执行。`submit()` 方法用于提交需要返回值的任务。可以提交 `Runnable` 或 `Callable` 任务。`submit()` 方法返回一个 `Future` 对象，通过这个 `Future` 对象可以判断任务是否执行成功，并获取任务的返回值（`get()`方法会阻塞当前线程直到任务完成， `get（long timeout，TimeUnit unit）`多了一个超时时间，如果在 `timeout` 时间内任务还没有执行完，就会抛出 `java.util.concurrent.TimeoutException`）。
+- **异常处理**：在使用 `submit()` 方法时，可以通过 `Future` 对象处理任务执行过程中抛出的异常；而在使用 `execute()` 方法时，异常处理需要通过自定义的 `ThreadFactory` （在线程工厂创建线程的时候设置`UncaughtExceptionHandler`对象来 处理异常）或 `ThreadPoolExecutor` 的 `afterExecute()` 方法来处理
示例 1：使用 `get()`方法获取返回值。
```java
+// 这里只是为了演示使用，推荐使用 `ThreadPoolExecutor` 构造方法来创建线程池。
ExecutorService executorService = Executors.newFixedThreadPool(3);
Future submit = executorService.submit(() -> {
diff --git a/docs/java/concurrent/jmm.md b/docs/java/concurrent/jmm.md
index bdba79d816f..dbc36a351b9 100644
--- a/docs/java/concurrent/jmm.md
+++ b/docs/java/concurrent/jmm.md
@@ -61,9 +61,13 @@ Java 源代码会经历 **编译器优化重排 —> 指令并行重排 —> 内
**指令重排序可以保证串行语义一致，但是没有义务保证多线程间的语义也一致** ，所以在多线程下，指令重排序可能会导致一些问题。
-编译器和处理器的指令重排序的处理方式不一样。对于编译器，通过禁止特定类型的编译器重排序的方式来禁止重排序。对于处理器，通过插入内存屏障（Memory Barrier，或有时叫做内存栅栏，Memory Fence）的方式来禁止特定类型的处理器重排序。指令并行重排和内存系统重排都属于是处理器级别的指令重排序。
+对于编译器优化重排和处理器的指令重排序（指令并行重排和内存系统重排都属于是处理器级别的指令重排序），处理该问题的方式不一样。
-> 内存屏障（Memory Barrier，或有时叫做内存栅栏，Memory Fence）是一种 CPU 指令，用来禁止处理器指令发生重排序（像屏障一样），从而保障指令执行的有序性。另外，为了达到屏障的效果，它也会使处理器写入、读取值之前，将主内存的值写入高速缓存，清空无效队列，从而保障变量的可见性。
+- 对于编译器，通过禁止特定类型的编译器重排序的方式来禁止重排序。
+
+- 对于处理器，通过插入内存屏障（Memory Barrier，或有时叫做内存栅栏，Memory Fence）的方式来禁止特定类型的处理器重排序。
+
+> 内存屏障（Memory Barrier，或有时叫做内存栅栏，Memory Fence）是一种 CPU 指令，用来禁止处理器指令发生重排序（像屏障一样），从而保障指令执行的有序性。另外，为了达到屏障的效果，它会在处理器写入值时，强制将写缓冲区中的数据刷新到主内存；在读取值之前，使处理器本地缓存中的相关数据失效，强制从主内存中加载最新值，从而保障变量的可见性。
## JMM(Java Memory Model)
diff --git a/docs/java/concurrent/optimistic-lock-and-pessimistic-lock.md b/docs/java/concurrent/optimistic-lock-and-pessimistic-lock.md
index 5cb979865d9..ba370690a11 100644
--- a/docs/java/concurrent/optimistic-lock-and-pessimistic-lock.md
+++ b/docs/java/concurrent/optimistic-lock-and-pessimistic-lock.md
@@ -5,9 +5,7 @@ tag:
- Java并发
---
-如果将悲观锁（Pessimistic Lock）和乐观锁（PessimisticLock 或 OptimisticLock）对应到现实生活中来。悲观锁有点像是一位比较悲观（也可以说是未雨绸缪）的人，总是会假设最坏的情况，避免出现问题。乐观锁有点像是一位比较乐观的人，总是会假设最好的情况，在要出现问题之前快速解决问题。
-
-在程序世界中，乐观锁和悲观锁的最终目的都是为了保证线程安全，避免在并发场景下的资源竞争问题。但是，相比于乐观锁，悲观锁对性能的影响更大！
+如果将悲观锁（Pessimistic Lock）和乐观锁（Optimistic Lock）对应到现实生活中来。悲观锁有点像是一位比较悲观（也可以说是未雨绸缪）的人，总是会假设最坏的情况，避免出现问题。乐观锁有点像是一位比较乐观的人，总是会假设最好的情况，在要出现问题之前快速解决问题。
## 什么是悲观锁？
@@ -31,34 +29,30 @@ try {
}
```
-高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，悲观锁还可能会存在死锁问题，影响代码的正常运行。
+高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，悲观锁还可能会存在死锁问题（线程获得锁的顺序不当时），影响代码的正常运行。
## 什么是乐观锁？
乐观锁总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，无需加锁也无需等待，只是在提交修改的时候去验证对应的资源（也就是数据）是否被其它线程修改了（具体方法可以使用版本号机制或 CAS 算法）。
-像 Java 中`java.util.concurrent.atomic`包下面的原子变量类（比如`AtomicInteger`、`LongAdder`）就是使用了乐观锁的一种实现方式 **CAS** 实现的。
-
-
+在 Java 中`java.util.concurrent.atomic`包下面的原子变量类（比如`AtomicInteger`、`LongAdder`）就是使用了乐观锁的一种实现方式 **CAS** 实现的。
+
```java
// LongAdder 在高并发场景下会比 AtomicInteger 和 AtomicLong 的性能更好
// 代价就是会消耗更多的内存空间（空间换时间）
-LongAdder longAdder = new LongAdder();
-// 自增
-longAdder.increment();
-// 获取结果
-longAdder.sum();
+LongAdder sum = new LongAdder();
+sum.increment();
```
-高并发的场景下，乐观锁相比悲观锁来说，不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。但是，如果冲突频繁发生（写占比非常多的情况），会频繁失败和重试（悲观锁的开销是固定的），这样同样会非常影响性能，导致 CPU 飙升。
+高并发的场景下，乐观锁相比悲观锁来说，不存在锁竞争造成线程阻塞，也不会有死锁问题，在性能上往往会更胜一筹。但是，如果冲突频繁发生（写占比非常多的情况），会频繁失败并重试，这样同样会非常影响性能，导致 CPU 飙升。
不过，大量失败重试的问题也是可以解决的，像我们前面提到的 `LongAdder`以空间换时间的方式就解决了这个问题。
理论上来说：
-- 悲观锁通常多用于写比较多的情况下（多写场景，竞争激烈），这样可以避免频繁失败和重试影响性能，悲观锁的开销是固定的。不过，如果乐观锁解决了频繁失败和重试这个问题的话（比如`LongAdder`），也是可以考虑使用乐观锁的，要视实际情况而定。
-- 乐观锁通常多于写比较少的情况下（多读场景，竞争较少），这样可以避免频繁加锁影响性能。不过，乐观锁主要针对的对象是单个共享变量（参考`java.util.concurrent.atomic`包下面的原子变量类）。
+- 悲观锁通常多用于写比较多的情况（多写场景，竞争激烈），这样可以避免频繁失败和重试影响性能，悲观锁的开销是固定的。不过，如果乐观锁解决了频繁失败和重试这个问题的话（比如`LongAdder`），也是可以考虑使用乐观锁的，要视实际情况而定。
+- 乐观锁通常多用于写比较少的情况（多读场景，竞争较少），这样可以避免频繁加锁影响性能。不过，乐观锁主要针对的对象是单个共享变量（参考`java.util.concurrent.atomic`包下面的原子变量类）。
## 如何实现乐观锁？
@@ -100,77 +94,21 @@ CAS 涉及到三个操作数：
当多个线程同时使用 CAS 操作一个变量时，只有一个会胜出，并成功更新，其余均会失败，但失败的线程并不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。
-Java 语言并没有直接实现 CAS，CAS 相关的实现是通过 C++ 内联汇编的形式实现的（JNI 调用）。因此， CAS 的具体实现和操作系统以及 CPU 都有关系。
-
-`sun.misc`包下的`Unsafe`类提供了`compareAndSwapObject`、`compareAndSwapInt`、`compareAndSwapLong`方法来实现的对`Object`、`int`、`long`类型的 CAS 操作
-
-```java
-/**
- * CAS
- * @param o 包含要修改field的对象
- * @param offset 对象中某field的偏移量
- * @param expected 期望值
- * @param update 更新值
- * @return true | false
- */
-public final native boolean compareAndSwapObject(Object o, long offset, Object expected, Object update);
-
-public final native boolean compareAndSwapInt(Object o, long offset, int expected,int update);
-
-public final native boolean compareAndSwapLong(Object o, long offset, long expected, long update);
-```
-
-关于 `Unsafe` 类的详细介绍可以看这篇文章：[Java 魔法类 Unsafe 详解 - JavaGuide - 2022](https://javaguide.cn/java/basis/unsafe.html) 。
-
-## CAS 算法存在哪些问题？
-
-ABA 问题是 CAS 算法最常见的问题。
-
-### ABA 问题
-
-如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 **"ABA"问题。**
+关于 CAS 的进一步介绍，可以阅读读者写的这篇文章：[CAS 详解](./cas.md)，其中详细提到了 Java 中 CAS 的实现以及 CAS 存在的一些问题。
-ABA 问题的解决思路是在变量前面追加上**版本号或者时间戳**。JDK 1.5 以后的 `AtomicStampedReference` 类就是用来解决 ABA 问题的，其中的 `compareAndSet()` 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
-
-```java
-public boolean compareAndSet(V expectedReference,
- V newReference,
- int expectedStamp,
- int newStamp) {
- Pair current = pair;
- return
- expectedReference == current.reference &&
- expectedStamp == current.stamp &&
- ((newReference == current.reference &&
- newStamp == current.stamp) ||
- casPair(current, Pair.of(newReference, newStamp)));
-}
-```
-
-### 循环时间长开销大
-
-CAS 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。
-
-如果 JVM 能支持处理器提供的 pause 指令那么效率会有一定的提升，pause 指令有两个作用：
-
-1. 可以延迟流水线执行指令，使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。
-2. 可以避免在退出循环的时候因内存顺序冲突而引起 CPU 流水线被清空，从而提高 CPU 的执行效率。
-
-### 只能保证一个共享变量的原子操作
+## 总结
-CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5 开始，提供了`AtomicReference`类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用`AtomicReference`类把多个共享变量合并成一个共享变量来操作。
+本文详细介绍了乐观锁和悲观锁的概念以及乐观锁常见实现方式：
-## 总结
+- 悲观锁基于悲观的假设，认为共享资源在每次访问时都会发生冲突，因此在每次操作时都会加锁。这种锁机制会导致其他线程阻塞，直到锁被释放。Java 中的 `synchronized` 和 `ReentrantLock` 是悲观锁的典型实现方式。虽然悲观锁能有效避免数据竞争，但在高并发场景下会导致线程阻塞、上下文切换频繁，从而影响系统性能，并且还可能引发死锁问题。
+- 乐观锁基于乐观的假设，认为共享资源在每次访问时不会发生冲突，因此无须加锁，只需在提交修改时验证数据是否被其他线程修改。Java 中的 `AtomicInteger` 和 `LongAdder` 等类通过 CAS（Compare-And-Swap）算法实现了乐观锁。乐观锁避免了线程阻塞和死锁问题，在读多写少的场景中性能优越。但在写操作频繁的情况下，可能会导致大量重试和失败，从而影响性能。
+- 乐观锁主要通过版本号机制或 CAS 算法实现。版本号机制通过比较版本号确保数据一致性，而 CAS 通过硬件指令实现原子操作，直接比较和交换变量值。
-- 高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，悲观锁还可能会存在死锁问题，影响代码的正常运行。乐观锁相比悲观锁来说，不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。不过，如果冲突频繁发生（写占比非常多的情况），会频繁失败和重试，这样同样会非常影响性能，导致 CPU 飙升。
-- 乐观锁一般会使用版本号机制或 CAS 算法实现，CAS 算法相对来说更多一些，这里需要格外注意。
-- CAS 的全称是 **Compare And Swap（比较与交换）** ，用于实现乐观锁，被广泛应用于各大框架中。CAS 的思想很简单，就是用一个预期值和要更新的变量值进行比较，两值相等才会进行更新。
-- CAS 算法的问题：ABA 问题、循环时间长开销大、只能保证一个共享变量的原子操作。
+悲观锁和乐观锁各有优缺点，适用于不同的应用场景。在实际开发中，选择合适的锁机制能够有效提升系统的并发性能和稳定性。
## 参考
- 《Java 并发编程核心 78 讲》
- 通俗易懂 悲观锁、乐观锁、可重入锁、自旋锁、偏向锁、轻量/重量级锁、读写锁、各种锁及其 Java 实现！：
-- 一文彻底搞懂 CAS 实现原理 & 深入到 CPU 指令：
diff --git a/docs/java/concurrent/virtual-thread.md b/docs/java/concurrent/virtual-thread.md
index d5f6fe39fd1..f7f889fb81f 100644
--- a/docs/java/concurrent/virtual-thread.md
+++ b/docs/java/concurrent/virtual-thread.md
@@ -1,5 +1,5 @@
---
-title: 虚拟线程极简入门
+title: 虚拟线程常见问题总结
category: Java
tag:
- Java并发
@@ -27,26 +27,25 @@ tag:
### 优点
-- 非常轻量级：可以在单个线程中创建成百上千个虚拟线程而不会导致过多的线程创建和上下文切换。
-- 简化异步编程： 虚拟线程可以简化异步编程，使代码更易于理解和维护。它可以将异步代码编写得更像同步代码，避免了回调地狱（Callback Hell）。
-- 减少资源开销： 相比于操作系统线程，虚拟线程的资源开销更小。本质上是提高了线程的执行效率，从而减少线程资源的创建和上下文切换。
+- **非常轻量级**：可以在单个线程中创建成百上千个虚拟线程而不会导致过多的线程创建和上下文切换。
+- **简化异步编程**： 虚拟线程可以简化异步编程，使代码更易于理解和维护。它可以将异步代码编写得更像同步代码，避免了回调地狱（Callback Hell）。
+- **减少资源开销**： 由于虚拟线程是由 JVM 实现的，它能够更高效地利用底层资源，例如 CPU 和内存。虚拟线程的上下文切换比平台线程更轻量，因此能够更好地支持高并发场景。
### 缺点
-- 不适用于计算密集型任务： 虚拟线程适用于 I/O 密集型任务，但不适用于计算密集型任务，因为密集型计算始终需要 CPU 资源作为支持。
-- 依赖于语言或库的支持： 协程需要编程语言或库提供支持。不是所有编程语言都原生支持协程。比如 Java 实现的虚拟线程。
+- **不适用于计算密集型任务**： 虚拟线程适用于 I/O 密集型任务，但不适用于计算密集型任务，因为密集型计算始终需要 CPU 资源作为支持。
+- **与某些第三方库不兼容**： 虽然虚拟线程设计时考虑了与现有代码的兼容性，但某些依赖平台线程特性的第三方库可能不完全兼容虚拟线程。
-## 四种创建虚拟线程的方法
-
-Java 21 已经正式支持虚拟线程，大家可以在官网下载使用，在使用上官方为了降低使用门槛，尽量复用原有的 `Thread` 类，让大家可以更加平滑的使用。
+## 如何创建虚拟线程？
官方提供了以下四种方式创建虚拟线程：
1. 使用 `Thread.startVirtualThread()` 创建
2. 使用 `Thread.ofVirtual()` 创建
3. 使用 `ThreadFactory` 创建
+4. 使用 `Executors.newVirtualThreadPerTaskExecutor()`创建
-#### 使用 Thread.startVirtualThread()创建
+**1、使用 `Thread.startVirtualThread()` 创建**
```java
public class VirtualThreadTest {
@@ -64,7 +63,7 @@ static class CustomThread implements Runnable {
}
```
-#### 使用 Thread.ofVirtual()创建
+**2、使用 `Thread.ofVirtual()` 创建**
```java
public class VirtualThreadTest {
@@ -85,7 +84,7 @@ static class CustomThread implements Runnable {
}
```
-#### 使用 ThreadFactory 创建
+**3、使用 `ThreadFactory` 创建**
```java
public class VirtualThreadTest {
@@ -105,7 +104,7 @@ static class CustomThread implements Runnable {
}
```
-#### 使用 Executors.newVirtualThreadPerTaskExecutor()创建
+**4、使用`Executors.newVirtualThreadPerTaskExecutor()`创建**
```java
public class VirtualThreadTest {
@@ -227,6 +226,11 @@ totalMillis：2865ms
- 可以看到在密集 IO 的场景下，需要创建大量的平台线程异步处理才能达到虚拟线程的处理速度。
- 因此，在密集 IO 的场景，虚拟线程可以大幅提高线程的执行效率，减少线程资源的创建以及上下文切换。
-- 吐槽：虽然虚拟线程我很想用，但是我 Java8 有机会升级到 Java21 吗？呜呜
**注意**：有段时间 JDK 一直致力于 Reactor 响应式编程来提高 Java 性能，但响应式编程难以理解、调试、使用，最终又回到了同步编程，最终虚拟线程诞生。
+
+## 虚拟线程的底层原理是什么？
+
+如果你想要详细了解虚拟线程实现原理，推荐一篇文章：[虚拟线程 - VirtualThread 源码透视](https://www.cnblogs.com/throwable/p/16758997.html)。
+
+面试一般是不会问到这个问题的，仅供学有余力的同学进一步研究学习。
diff --git a/docs/java/io/io-basis.md b/docs/java/io/io-basis.md
index 0dd36b1c32d..1ea1bcd3f86 100755
--- a/docs/java/io/io-basis.md
+++ b/docs/java/io/io-basis.md
@@ -20,7 +20,7 @@ Java IO 流的 40 多个类都是从如下 4 个抽象类基类中派生出来
## 字节流
### InputStream（字节输入流）
-
+
`InputStream`用于从源头（通常是文件）读取数据（字节信息）到内存中，`java.io.InputStream`抽象类是所有字节输入流的父类。
`InputStream` 常用方法：
@@ -184,7 +184,9 @@ The content read from file:§å®¶å¥½
因此，I/O 流就干脆提供了一个直接操作字符的接口，方便我们平时对字符进行流操作。如果音频文件、图片等媒体文件用字节流比较好，如果涉及到字符的话使用字符流比较好。
-字符流默认采用的是 `Unicode` 编码，我们可以通过构造方法自定义编码。顺便分享一下之前遇到的笔试题：常用字符编码所占字节数？`utf8` :英文占 1 字节，中文占 3 字节，`unicode`：任何字符都占 2 个字节，`gbk`：英文占 1 字节，中文占 2 字节。
+字符流默认采用的是 `Unicode` 编码，我们可以通过构造方法自定义编码。
+
+Unicode 本身只是一种字符集，它为每个字符分配一个唯一的数字编号，并没有规定具体的存储方式。UTF-8、UTF-16、UTF-32 都是 Unicode 的编码方式，它们使用不同的字节数来表示 Unicode 字符。例如，UTF-8 :英文占 1 字节，中文占 3 字节。
### Reader（字符输入流）
@@ -428,7 +430,7 @@ class BufferedInputStream extends FilterInputStream {
### BufferedOutputStream（字节缓冲输出流）
-`BufferedOutputStream` 将数据（字节信息）写入到目的地（通常是文件）的过程中不会一个字节一个字节的写入，而是会先将要写入的字节存放在缓存区，并从内部缓冲区中单独写入字节。这样大幅减少了 IO 次数，提高了读取效率
+`BufferedOutputStream` 将数据（字节信息）写入到目的地（通常是文件）的过程中不会一个字节一个字节的写入，而是会先将要写入的字节存放在缓存区，并从内部缓冲区中单独写入字节。这样大幅减少了 IO 次数，提高了效率
```java
try (BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream("output.txt"))) {
diff --git a/docs/java/io/io-design-patterns.md b/docs/java/io/io-design-patterns.md
index 5408c06049b..f005a18ece4 100644
--- a/docs/java/io/io-design-patterns.md
+++ b/docs/java/io/io-design-patterns.md
@@ -118,8 +118,8 @@ BufferedReader bufferedReader = new BufferedReader(isr);
```java
public class InputStreamReader extends Reader {
- //用于解码的对象
- private final StreamDecoder sd;
+ //用于解码的对象
+ private final StreamDecoder sd;
public InputStreamReader(InputStream in) {
super(in);
try {
@@ -130,7 +130,7 @@ public class InputStreamReader extends Reader {
}
}
// 使用 StreamDecoder 对象做具体的读取工作
- public int read() throws IOException {
+ public int read() throws IOException {
return sd.read();
}
}
diff --git a/docs/java/io/io-model.md b/docs/java/io/io-model.md
index 39fe181850f..e6d48bc0439 100644
--- a/docs/java/io/io-model.md
+++ b/docs/java/io/io-model.md
@@ -18,7 +18,7 @@ I/O 一直是很多小伙伴难以理解的一个知识点，这篇文章我会
### 何为 I/O?
-I/O（**I**nput/**O**utpu） 即**输入／输出** 。
+I/O（**I**nput/**O**utput） 即**输入／输出** 。
**我们先从计算机结构的角度来解读一下 I/O。**
diff --git a/docs/java/io/nio-basis.md b/docs/java/io/nio-basis.md
index f8afc76fbbf..4cf9723ba37 100644
--- a/docs/java/io/nio-basis.md
+++ b/docs/java/io/nio-basis.md
@@ -342,7 +342,7 @@ public class NioSelectorExample {
零拷贝是提升 IO 操作性能的一个常用手段，像 ActiveMQ、Kafka 、RocketMQ、QMQ、Netty 等顶级开源项目都用到了零拷贝。
-零拷贝是指计算机执行 IO 操作时，CPU 不需要将数据从一个存储区域复制到另一个存储区域，从而可以减少上下文切换以及 CPU 的拷贝时间。也就是说，零拷贝主主要解决操作系统在处理 I/O 操作时频繁复制数据的问题。零拷贝的常见实现技术有： `mmap+write`、`sendfile`和 `sendfile + DMA gather copy` 。
+零拷贝是指计算机执行 IO 操作时，CPU 不需要将数据从一个存储区域复制到另一个存储区域，从而可以减少上下文切换以及 CPU 的拷贝时间。也就是说，零拷贝主要解决操作系统在处理 I/O 操作时频繁复制数据的问题。零拷贝的常见实现技术有： `mmap+write`、`sendfile`和 `sendfile + DMA gather copy` 。
下图展示了各种零拷贝技术的对比图：
diff --git a/docs/java/jvm/class-file-structure.md b/docs/java/jvm/class-file-structure.md
index 61a6c00dab9..31cc64e30fb 100644
--- a/docs/java/jvm/class-file-structure.md
+++ b/docs/java/jvm/class-file-structure.md
@@ -149,7 +149,7 @@ Java 类的继承关系由类索引、父类索引和接口索引集合三项确
类索引用于确定这个类的全限定名，父类索引用于确定这个类的父类的全限定名，由于 Java 语言的单继承，所以父类索引只有一个，除了 `java.lang.Object` 之外，所有的 Java 类都有父类，因此除了 `java.lang.Object` 外，所有 Java 类的父类索引都不为 0。
-接口索引集合用来描述这个类实现了那些接口，这些被实现的接口将按 `implements` (如果这个类本身是接口的话则是`extends`) 后的接口顺序从左到右排列在接口索引集合中。
+接口索引集合用来描述这个类实现了哪些接口，这些被实现的接口将按 `implements` (如果这个类本身是接口的话则是`extends`) 后的接口顺序从左到右排列在接口索引集合中。
### 字段表集合（Fields）
diff --git a/docs/java/jvm/class-loading-process.md b/docs/java/jvm/class-loading-process.md
index 5b10ec5911d..6d6bcd2ea54 100644
--- a/docs/java/jvm/class-loading-process.md
+++ b/docs/java/jvm/class-loading-process.md
@@ -7,7 +7,7 @@ tag:
## 类的生命周期
-类从被加载到虚拟机内存中开始到卸载出内存为止，它的整个生命周期可以简单概括为 7 个阶段：：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）。其中，验证、准备和解析这三个阶段可以统称为连接（Linking）。
+类从被加载到虚拟机内存中开始到卸载出内存为止，它的整个生命周期可以简单概括为 7 个阶段：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）。其中，验证、准备和解析这三个阶段可以统称为连接（Linking）。
这 7 个阶段的顺序如下图所示：
@@ -49,7 +49,7 @@ tag:
验证阶段这一步在整个类加载过程中耗费的资源还是相对较多的，但很有必要，可以有效防止恶意代码的执行。任何时候，程序安全都是第一位。
-不过，验证阶段也不是必须要执行的阶段。如果程序运行的全部代码(包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码)都已经被反复使用和验证过，在生产环境的实施阶段就可以考虑使用 `-Xverify:none` 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
+不过，验证阶段也不是必须要执行的阶段。如果程序运行的全部代码(包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码)都已经被反复使用和验证过，在生产环境的实施阶段就可以考虑使用 `-Xverify:none` 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。但是需要注意的是 `-Xverify:none` 和 `-noverify` 在 JDK 13 中被标记为 deprecated ，在未来版本的 JDK 中可能会被移除。
验证阶段主要由四个检验阶段组成：
@@ -83,7 +83,7 @@ tag:
2. 从概念上讲，类变量所使用的内存都应当在 **方法区** 中进行分配。不过有一点需要注意的是：JDK 7 之前，HotSpot 使用永久代来实现方法区的时候，实现是完全符合这种逻辑概念的。 而在 JDK 7 及之后，HotSpot 已经把原本放在永久代的字符串常量池、静态变量等移动到堆中，这个时候类变量则会随着 Class 对象一起存放在 Java 堆中。相关阅读：[《深入理解 Java 虚拟机（第 3 版）》勘误#75](https://github.com/fenixsoft/jvm_book/issues/75 "《深入理解Java虚拟机（第3版）》勘误#75")
3. 这里所设置的初始值"通常情况"下是数据类型默认的零值（如 0、0L、null、false 等），比如我们定义了`public static int value=111` ，那么 value 变量在准备阶段的初始值就是 0 而不是 111（初始化阶段才会赋值）。特殊情况：比如给 value 变量加上了 final 关键字`public static final int value=111` ，那么准备阶段 value 的值就被赋值为 111。
-**基本数据类型的零值**：(图片来自《深入理解 Java 虚拟机》第 3 版 7.33 )
+**基本数据类型的零值**：(图片来自《深入理解 Java 虚拟机》第 3 版 7.3.3 )
@@ -91,7 +91,7 @@ tag:
**解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。** 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符 7 类符号引用进行。
-《深入理解 Java 虚拟机》7.34 节第三版对符号引用和直接引用的解释如下：
+《深入理解 Java 虚拟机》7.3.4 节第三版对符号引用和直接引用的解释如下：
@@ -109,16 +109,14 @@ tag:
对于初始化阶段，虚拟机严格规范了有且只有 6 种情况下，必须对类进行初始化(只有主动去使用类才会初始化类)：
-1. 当遇到 `new`、 `getstatic`、`putstatic` 或 `invokestatic` 这 4 条字节码指令时，比如 `new` 一个类，读取一个静态字段(未被 final 修饰)、或调用一个类的静态方法时。
- - 当 jvm 执行 `new` 指令时会初始化类。即当程序创建一个类的实例对象。
- - 当 jvm 执行 `getstatic` 指令时会初始化类。即程序访问类的静态变量(不是静态常量，常量会被加载到运行时常量池)。
- - 当 jvm 执行 `putstatic` 指令时会初始化类。即程序给类的静态变量赋值。
- - 当 jvm 执行 `invokestatic` 指令时会初始化类。即程序调用类的静态方法。
+1. 遇到 `new`、`getstatic`、`putstatic` 或 `invokestatic` 这 4 条字节码指令时：
+ - `new`: 创建一个类的实例对象。
+ - `getstatic`、`putstatic`: 读取或设置一个类型的静态字段（被 `final` 修饰、已在编译期把结果放入常量池的静态字段除外）。
+ - `invokestatic`: 调用类的静态方法。
2. 使用 `java.lang.reflect` 包的方法对类进行反射调用时如 `Class.forName("...")`, `newInstance()` 等等。如果类没初始化，需要触发其初始化。
3. 初始化一个类，如果其父类还未初始化，则先触发该父类的初始化。
4. 当虚拟机启动时，用户需要定义一个要执行的主类 (包含 `main` 方法的那个类)，虚拟机会先初始化这个类。
-5. `MethodHandle` 和 `VarHandle` 可以看作是轻量级的反射调用机制，而要想使用这 2 个调用，
- 就必须先使用 `findStaticVarHandle` 来初始化要调用的类。
+5. `MethodHandle` 和 `VarHandle` 可以看作是轻量级的反射调用机制，而要想使用这 2 个调用，就必须先使用 `findStaticVarHandle` 来初始化要调用的类。
6. **「补充，来自[issue745](https://github.com/Snailclimb/JavaGuide/issues/745 "issue745")」** 当一个接口中定义了 JDK8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。
## 类卸载
diff --git a/docs/java/jvm/classloader.md b/docs/java/jvm/classloader.md
index 97e12e86d60..35a8bfd0eda 100644
--- a/docs/java/jvm/classloader.md
+++ b/docs/java/jvm/classloader.md
@@ -58,7 +58,7 @@ class Class {
}
```
-简单来说，**类加载器的主要作用就是加载 Java 类的字节码（ `.class` 文件）到 JVM 中（在内存中生成一个代表该类的 `Class` 对象）。** 字节码可以是 Java 源程序（`.java`文件）经过 `javac` 编译得来，也可以是通过工具动态生成或者通过网络下载得来。
+简单来说，**类加载器的主要作用就是动态加载 Java 类的字节码（ `.class` 文件）到 JVM 中（在内存中生成一个代表该类的 `Class` 对象）。** 字节码可以是 Java 源程序（`.java`文件）经过 `javac` 编译得来，也可以是通过工具动态生成或者通过网络下载得来。
其实除了加载类之外，类加载器还可以加载 Java 应用所需的资源如文本、图像、配置文件、视频等等文件资源。本文只讨论其核心功能：加载类。
@@ -281,9 +281,50 @@ protected Class loadClass(String name, boolean resolve)
### 双亲委派模型的好处
-双亲委派模型保证了 Java 程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类），也保证了 Java 的核心 API 不被篡改。
+双亲委派模型是 Java 类加载机制的重要组成部分，它通过委派父加载器优先加载类的方式，实现了两个关键的安全目标：避免类的重复加载和防止核心 API 被篡改。
-如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 `java.lang.Object` 类的话，那么程序运行的时候，系统就会出现两个不同的 `Object` 类。双亲委派模型可以保证加载的是 JRE 里的那个 `Object` 类，而不是你写的 `Object` 类。这是因为 `AppClassLoader` 在加载你的 `Object` 类时，会委托给 `ExtClassLoader` 去加载，而 `ExtClassLoader` 又会委托给 `BootstrapClassLoader`，`BootstrapClassLoader` 发现自己已经加载过了 `Object` 类，会直接返回，不会去加载你写的 `Object` 类。
+JVM 区分不同类的依据是类名加上加载该类的类加载器，即使类名相同，如果由不同的类加载器加载，也会被视为不同的类。 双亲委派模型确保核心类总是由 `BootstrapClassLoader` 加载，保证了核心类的唯一性。
+
+例如，当应用程序尝试加载 `java.lang.Object` 时，`AppClassLoader` 会首先将请求委派给 `ExtClassLoader`，`ExtClassLoader` 再委派给 `BootstrapClassLoader`。`BootstrapClassLoader` 会在 JRE 核心类库中找到并加载 `java.lang.Object`，从而保证应用程序使用的是 JRE 提供的标准版本。
+
+有很多小伙伴就要说了：“那我绕过双亲委派模型不就可以了么？”。
+
+然而，即使攻击者绕过了双亲委派模型，Java 仍然具备更底层的安全机制来保护核心类库。`ClassLoader` 的 `preDefineClass` 方法会在定义类之前进行类名校验。任何以 `"java."` 开头的类名都会触发 `SecurityException`，阻止恶意代码定义或加载伪造的核心类。
+
+JDK 8 中`ClassLoader#preDefineClass` 方法源码如下：
+
+```java
+private ProtectionDomain preDefineClass(String name,
+ ProtectionDomain pd)
+ {
+ // 检查类名是否合法
+ if (!checkName(name)) {
+ throw new NoClassDefFoundError("IllegalName: " + name);
+ }
+
+ // 防止在 "java.*" 包中定义类。
+ // 此检查对于安全性至关重要，因为它可以防止恶意代码替换核心 Java 类。
+ // JDK 9 利用平台类加载器增强了 preDefineClass 方法的安全性
+ if ((name != null) && name.startsWith("java.")) {
+ throw new SecurityException
+ ("禁止的包名: " +
+ name.substring(0, name.lastIndexOf('.')));
+ }
+
+ // 如果未指定 ProtectionDomain，则使用默认域（defaultDomain）。
+ if (pd == null) {
+ pd = defaultDomain;
+ }
+
+ if (name != null) {
+ checkCerts(name, pd.getCodeSource());
+ }
+
+ return pd;
+ }
+```
+
+JDK 9 中这部分逻辑有所改变，多了平台类加载器（`getPlatformClassLoader()` 方法获取），增强了 `preDefineClass` 方法的安全性。这里就不贴源码了，感兴趣的话，可以自己去看看。
### 打破双亲委派模型方法
@@ -326,7 +367,7 @@ Tomcat 这四个自定义的类加载器对应的目录如下：
拿 Spring 这个例子来说，当 Spring 需要加载业务类的时候，它不是用自己的类加载器，而是用当前线程的上下文类加载器。还记得我上面说的吗？每个 Web 应用都会创建一个单独的 `WebAppClassLoader`，并在启动 Web 应用的线程里设置线程线程上下文类加载器为 `WebAppClassLoader`。这样就可以让高层的类加载器（`SharedClassLoader`）借助子类加载器（ `WebAppClassLoader`）来加载业务类，破坏了 Java 的类加载委托机制，让应用逆向使用类加载器。
-线程线程上下文类加载器的原理是将一个类加载器保存在线程私有数据里，跟线程绑定，然后在需要的时候取出来使用。这个类加载器通常是由应用程序或者容器（如 Tomcat）设置的。
+线程上下文类加载器的原理是将一个类加载器保存在线程私有数据里，跟线程绑定，然后在需要的时候取出来使用。这个类加载器通常是由应用程序或者容器（如 Tomcat）设置的。
`Java.lang.Thread` 中的`getContextClassLoader()`和 `setContextClassLoader(ClassLoader cl)`分别用来获取和设置线程的上下文类加载器。如果没有通过`setContextClassLoader(ClassLoader cl)`进行设置的话，线程将继承其父线程的上下文类加载器。
diff --git a/docs/java/jvm/jdk-monitoring-and-troubleshooting-tools.md b/docs/java/jvm/jdk-monitoring-and-troubleshooting-tools.md
index 8c3acfb30a0..33fc2d8767b 100644
--- a/docs/java/jvm/jdk-monitoring-and-troubleshooting-tools.md
+++ b/docs/java/jvm/jdk-monitoring-and-troubleshooting-tools.md
@@ -13,7 +13,7 @@ tag:
- **`jstat`**（JVM Statistics Monitoring Tool）: 用于收集 HotSpot 虚拟机各方面的运行数据;
- **`jinfo`** (Configuration Info for Java) : Configuration Info for Java,显示虚拟机配置信息;
- **`jmap`** (Memory Map for Java) : 生成堆转储快照;
-- **`jhat`** (JVM Heap Dump Browser) : 用于分析 heapdump 文件，它会建立一个 HTTP/HTML 服务器，让用户可以在浏览器上查看分析结果;
+- **`jhat`** (JVM Heap Dump Browser) : 用于分析 heapdump 文件，它会建立一个 HTTP/HTML 服务器，让用户可以在浏览器上查看分析结果。JDK9 移除了 jhat；
- **`jstack`** (Stack Trace for Java) : 生成虚拟机当前时刻的线程快照，线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合。
### `jps`:查看所有 Java 进程
@@ -133,6 +133,8 @@ Server is ready.
访问
-
+### MAT：内存分析器工具
+
+MAT（Memory Analyzer Tool）是一款快速便捷且功能强大丰富的 JVM 堆内存离线分析工具。其通过展现 JVM 异常时所记录的运行时堆转储快照（Heap dump）状态（正常运行时也可以做堆转储分析），帮助定位内存泄漏问题或优化大内存消耗逻辑。
+
+在遇到 OOM 和 GC 问题的时候，我一般会首选使用 MAT 分析 dump 文件在，这也是该工具应用最多的一个场景。
+
+关于 MAT 的详细介绍推荐下面这两篇文章，写的很不错：
+
+- [JVM 内存分析工具 MAT 的深度讲解与实践—入门篇](https://juejin.cn/post/6908665391136899079)
+- [JVM 内存分析工具 MAT 的深度讲解与实践—进阶篇](https://juejin.cn/post/6911624328472133646)
+
diff --git a/docs/java/jvm/jvm-garbage-collection.md b/docs/java/jvm/jvm-garbage-collection.md
index 61e1451531a..970933ee5ce 100644
--- a/docs/java/jvm/jvm-garbage-collection.md
+++ b/docs/java/jvm/jvm-garbage-collection.md
@@ -253,29 +253,58 @@ public class ReferenceCountingGc {
JDK1.2 之前，Java 中引用的定义很传统：如果 reference 类型的数据存储的数值代表的是另一块内存的起始地址，就称这块内存代表一个引用。
-JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用四种（引用强度逐渐减弱）
+JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用四种（引用强度逐渐减弱），强引用就是 Java 中普通的对象，而软引用、弱引用、虚引用在 JDK 中定义的类分别是 `SoftReference`、`WeakReference`、`PhantomReference`。
**1．强引用（StrongReference）**
-以前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，那就类似于**必不可少的生活用品**，垃圾回收器绝不会回收它。当内存空间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。
+强引用实际上就是程序代码中普遍存在的引用赋值，这是使用最普遍的引用，其代码如下
+
+```java
+String strongReference = new String("abc");
+```
+
+如果一个对象具有强引用，那就类似于**必不可少的生活用品**，垃圾回收器绝不会回收它。当内存空间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。
**2．软引用（SoftReference）**
-如果一个对象只具有软引用，那就类似于**可有可无的生活用品**。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。
+如果一个对象只具有软引用，那就类似于**可有可无的生活用品**。软引用代码如下
+
+```java
+// 软引用
+String str = new String("abc");
+SoftReference softReference = new SoftReference(str);
+```
+
+如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。
软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，JAVA 虚拟机就会把这个软引用加入到与之关联的引用队列中。
**3．弱引用（WeakReference）**
-如果一个对象只具有弱引用，那就类似于**可有可无的生活用品**。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。
+如果一个对象只具有弱引用，那就类似于**可有可无的生活用品**。弱引用代码如下：
+
+```java
+String str = new String("abc");
+WeakReference weakReference = new WeakReference<>(str);
+str = null; //str变成软引用，可以被收集
+```
+
+弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。
弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。
**4．虚引用（PhantomReference）**
-"虚引用"顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。
+"虚引用"顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。虚引用代码如下：
+
+```java
+String str = new String("abc");
+ReferenceQueue queue = new ReferenceQueue();
+// 创建虚引用，要求必须与一个引用队列关联
+PhantomReference pr = new PhantomReference(str, queue);
+```
**虚引用主要用来跟踪对象被垃圾回收的活动**。
@@ -322,7 +351,7 @@ JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引
-关于具体是标记可回收对象还是不可回收对象，众说纷纭，两种说法其实都没问题，我个人更倾向于是前者。
+关于具体是标记可回收对象（不可达对象）还是不可回收对象（可达对象），众说纷纭，两种说法其实都没问题，我个人更倾向于是后者。
如果按照前者的理解，整个标记-清除过程大致是这样的：
@@ -353,7 +382,7 @@ JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引
当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 Java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
-比如在新生代中，每次收集都会有大量对象死去，所以可以选择”标记-复制“算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。
+比如在新生代中，每次收集都会有大量对象死去，所以可以选择“复制”算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。
**延伸面试问题：** HotSpot 为什么要分为新生代和老年代？
@@ -367,8 +396,8 @@ JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引
JDK 默认垃圾收集器（使用 `java -XX:+PrintCommandLineFlags -version` 命令查看）：
-- JDK 8：Parallel Scavenge（新生代）+ Parallel Old（老年代）
-- JDK 9 ~ JDK20: G1
+- JDK 8: Parallel Scavenge（新生代）+ Parallel Old（老年代）
+- JDK 9 ~ JDK22: G1
### Serial 收集器
@@ -451,7 +480,7 @@ JDK1.8 默认使用的是 Parallel Scavenge + Parallel Old，如果指定了-XX:
从名字中的**Mark Sweep**这两个词可以看出，CMS 收集器是一种 **“标记-清除”算法**实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：
-- **初始标记：** 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快 ；
+- **初始标记：** 短暂停顿，标记直接与 root 相连的对象（根对象）；
- **并发标记：** 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
- **重新标记：** 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
- **并发清除：** 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。
@@ -464,11 +493,11 @@ JDK1.8 默认使用的是 Parallel Scavenge + Parallel Old，如果指定了-XX:
- **无法处理浮动垃圾；**
- **它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。**
-**从 JDK9 开始，CMS 收集器已被弃用。**
+**CMS 垃圾回收器在 Java 9 中已经被标记为过时(deprecated)，并在 Java 14 中被移除。**
### G1 收集器
-**G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征.**
+**G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征。**
被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征。它具备以下特点：
@@ -479,10 +508,10 @@ JDK1.8 默认使用的是 Parallel Scavenge + Parallel Old，如果指定了-XX:
G1 收集器的运作大致分为以下几个步骤：
-- **初始标记**
-- **并发标记**
-- **最终标记**
-- **筛选回收**
+- **初始标记**： 短暂停顿（Stop-The-World，STW），标记从 GC Roots 可直接引用的对象，即标记所有直接可达的活跃对象
+- **并发标记**：与应用并发运行，标记所有可达对象。 这一阶段可能持续较长时间，取决于堆的大小和对象的数量。
+- **最终标记**： 短暂停顿（STW），处理并发标记阶段结束后残留的少量未处理的引用变更。
+- **筛选回收**：根据标记结果，选择回收价值高的区域，复制存活对象到新区域，回收旧区域内存。这一阶段包含一个或多个停顿（STW），具体取决于回收的复杂度。
@@ -512,7 +541,11 @@ java -XX:+UseZGC className
java -XX:+UseZGC -XX:+ZGenerational className
```
-关于 ZGC 收集器的详细介绍推荐阅读美团技术团队的 [新一代垃圾回收器 ZGC 的探索与实践](https://tech.meituan.com/2020/08/06/new-zgc-practice-in-meituan.html) 这篇文章。
+关于 ZGC 收集器的详细介绍推荐看看这几篇文章：
+
+- [从历代 GC 算法角度剖析 ZGC - 京东技术](https://mp.weixin.qq.com/s/ExkB40cq1_Z0ooDzXn7CVw)
+- [新一代垃圾回收器 ZGC 的探索与实践 - 美团技术团队](https://tech.meituan.com/2020/08/06/new-zgc-practice-in-meituan.html)
+- [极致八股文之 JVM 垃圾回收器 G1&ZGC 详解 - 阿里云开发者](https://mp.weixin.qq.com/s/Ywj3XMws0IIK-kiUllN87Q)
## 参考
diff --git a/docs/java/jvm/jvm-parameters-intro.md b/docs/java/jvm/jvm-parameters-intro.md
index 5ec3b92ceef..b97fc66d923 100644
--- a/docs/java/jvm/jvm-parameters-intro.md
+++ b/docs/java/jvm/jvm-parameters-intro.md
@@ -6,78 +6,78 @@ tag:
---
> 本文由 JavaGuide 翻译自 [https://www.baeldung.com/jvm-parameters](https://www.baeldung.com/jvm-parameters)，并对文章进行了大量的完善补充。
+> 文档参数 [https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html)
>
-> JDK 版本：1.8
+> JDK 版本：1.8 为主，也会补充新版本常用参数
-## 1.概述
+在本篇文章中，我们将一起掌握 Java 虚拟机（JVM）中最常用的一些参数配置，帮助你更好地理解和调优 Java 应用的运行环境。
-在本篇文章中，你将掌握最常用的 JVM 参数配置。
+## 堆内存相关
-## 2.堆内存相关
-
-> Java 虚拟机所管理的内存中最大的一块，Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。**此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。**
+> Java 堆（Java Heap）是 JVM 所管理的内存中最大的一块区域，**所有线程共享**，在虚拟机启动时创建。**此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都要在堆上分配内存。**
-### 2.1.显式指定堆内存`–Xms`和`-Xmx`
+### 设置堆内存大小 (-Xms 和 -Xmx)
+
+根据应用程序的实际需求设置初始和最大堆内存大小，是性能调优中最常见的实践之一。**推荐显式设置这两个参数，并且通常建议将它们设置为相同的值**，以避免运行时堆内存的动态调整带来的性能开销。
-与性能有关的最常见实践之一是根据应用程序要求初始化堆内存。如果我们需要指定最小和最大堆大小（推荐显示指定大小），以下参数可以帮助你实现：
+使用以下参数进行设置：
```bash
--Xms[unit]
--Xmx[unit]
+-Xms[unit] # 设置 JVM 初始堆大小
+-Xmx[unit] # 设置 JVM 最大堆大小
```
-- **heap size** 表示要初始化内存的具体大小。
-- **unit** 表示要初始化内存的单位。单位为 **_“ g”_** (GB)、**_“ m”_**（MB）、**_“ k”_**（KB）。
+- ``: 指定内存的具体数值。
+- `[unit]`: 指定内存的单位，如 g (GB)、m (MB)、k (KB)。
-举个栗子 🌰，如果我们要为 JVM 分配最小 2 GB 和最大 5 GB 的堆内存大小，我们的参数应该这样来写：
+**示例：** 将 JVM 的初始堆和最大堆都设置为 4GB：
```bash
--Xms2G -Xmx5G
+-Xms4G -Xmx4G
```
-### 2.2.显式新生代内存(Young Generation)
+### 设置新生代内存大小 (Young Generation)
-根据[Oracle 官方文档](https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/sizing.html)，在堆总可用内存配置完成之后，第二大影响因素是为 `Young Generation` 在堆内存所占的比例。默认情况下，YG 的最小大小为 1310 _MB_，最大大小为 _无限制_。
+根据[Oracle 官方文档](https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/sizing.html)，在堆总可用内存配置完成之后，第二大影响因素是为 `Young Generation` 在堆内存所占的比例。默认情况下，YG 的最小大小为 **1310 MB**，最大大小为 **无限制**。
-一共有两种指定 新生代内存(Young Generation)大小的方法：
+可以通过以下两种方式设置新生代内存大小：
**1.通过`-XX:NewSize`和`-XX:MaxNewSize`指定**
```bash
--XX:NewSize=[unit]
--XX:MaxNewSize=[unit]
+-XX:NewSize=[unit] # 设置新生代初始大小
+-XX:MaxNewSize=[unit] # 设置新生代最大大小
```
-举个栗子 🌰，如果我们要为 新生代分配 最小 256m 的内存，最大 1024m 的内存我们的参数应该这样来写：
+**示例：** 设置新生代最小 512MB，最大 1024MB：
```bash
--XX:NewSize=256m
--XX:MaxNewSize=1024m
+-XX:NewSize=512m -XX:MaxNewSize=1024m
```
**2.通过`-Xmn[unit]`指定**
-举个栗子 🌰，如果我们要为 新生代分配 256m 的内存（NewSize 与 MaxNewSize 设为一致），我们的参数应该这样来写：
+**示例：** 将新生代大小固定为 512MB：
```bash
--Xmn256m
+-Xmn512m
```
GC 调优策略中很重要的一条经验总结是这样说的：
-> 将新对象预留在新生代，由于 Full GC 的成本远高于 Minor GC，因此尽可能将对象分配在新生代是明智的做法，实际项目中根据 GC 日志分析新生代空间大小分配是否合理，适当通过“-Xmn”命令调节新生代大小，最大限度降低新对象直接进入老年代的情况。
+> 尽量让新创建的对象在新生代分配内存并被回收，因为 Minor GC 的成本通常远低于 Full GC。通过分析 GC 日志，判断新生代空间分配是否合理。如果大量新对象过早进入老年代（Promotion），可以适当通过 `-Xmn` 或 -`XX:NewSize/-XX:MaxNewSize` 调整新生代大小，目标是最大限度地减少对象直接进入老年代的情况。
-另外，你还可以通过 **`-XX:NewRatio=`** 来设置老年代与新生代内存的比值。
+另外，你还可以通过 **`-XX:NewRatio=`** 参数来设置**老年代与新生代（不含 Survivor 区）的内存大小比例**。
-比如下面的参数就是设置老年代与新生代内存的比值为 1。也就是说老年代和新生代所占比值为 1：1，新生代占整个堆栈的 1/2。
+例如，`-XX:NewRatio=2` （默认值）表示老年代 : 新生代 = 2 : 1。即新生代占整个堆大小的 1/3。
-```plain
--XX:NewRatio=1
+```bash
+-XX:NewRatio=2
```
-### 2.3.显式指定永久代/元空间的大小
+### 设置永久代/元空间大小 (PermGen/Metaspace)
**从 Java 8 开始，如果我们没有指定 Metaspace 的大小，随着更多类的创建，虚拟机会耗尽所有可用的系统内存（永久代并不会出现这种情况）。**
@@ -101,7 +101,7 @@ JDK 1.8 之前永久代还没被彻底移除的时候通常通过下面这些参
**🐛 修正（参见：[issue#1947](https://github.com/Snailclimb/JavaGuide/issues/1947)）**：
-1、Metaspace 的初始容量并不是 `-XX:MetaspaceSize` 设置，无论 `-XX:MetaspaceSize` 配置什么值，对于 64 位 JVM 来说，Metaspace 的初始容量都是 21807104（约 20.8m）。
+**1、`-XX:MetaspaceSize` 并非初始容量：** Metaspace 的初始容量并不是 `-XX:MetaspaceSize` 设置，无论 `-XX:MetaspaceSize` 配置什么值，对于 64 位 JVM，元空间的初始容量通常是一个固定的较小值（Oracle 文档提到约 12MB 到 20MB 之间，实际观察约 20.8MB）。
可以参考 Oracle 官方文档 [Other Considerations](https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/considerations.html) 中提到的：
@@ -111,11 +111,7 @@ JDK 1.8 之前永久代还没被彻底移除的时候通常通过下面这些参
另外，还可以看一下这个试验：[JVM 参数 MetaspaceSize 的误解](https://mp.weixin.qq.com/s/jqfppqqd98DfAJHZhFbmxA)。
-2、Metaspace 由于使用不断扩容到`-XX:MetaspaceSize`参数指定的量，就会发生 FGC，且之后每次 Metaspace 扩容都会发生 Full GC。
-
-也就是说，MetaspaceSize 表示 Metaspace 使用过程中触发 Full GC 的阈值，只对触发起作用。
-
-垃圾搜集器内部是根据变量 `_capacity_until_GC`来判断 Metaspace 区域是否达到阈值的，初始化代码如下所示：
+**2、扩容与 Full GC：** 当 Metaspace 的使用量增长并首次达到`-XX:MetaspaceSize` 指定的阈值时，会触发一次 Full GC。在此之后，JVM 会动态调整这个触发 GC 的阈值。如果元空间继续增长，每次达到新的阈值需要扩容时，仍然可能触发 Full GC（具体行为与垃圾收集器和版本有关）。垃圾搜集器内部是根据变量 `_capacity_until_GC`来判断 Metaspace 区域是否达到阈值的，初始化代码如下所示：
```c
void MetaspaceGC::initialize() {
@@ -125,111 +121,120 @@ void MetaspaceGC::initialize() {
}
```
-相关阅读：[issue 更正：MaxMetaspaceSize 如果不指定大小的话，不会耗尽内存 #1204](https://github.com/Snailclimb/JavaGuide/issues/1204) 。
-
-## 3.垃圾收集相关
+**3、`-XX:MaxMetaspaceSize` 的重要性：**如果不显式设置 -`XX:MaxMetaspaceSize`，元空间的最大大小理论上受限于可用的本地内存。在极端情况下（如类加载器泄漏导致不断加载类），这确实**可能耗尽大量本地内存**。因此，**强烈建议设置一个合理的 `-XX:MaxMetaspaceSize` 上限**，以防止对系统造成影响。
-### 3.1.垃圾回收器
+相关阅读：[issue 更正：MaxMetaspaceSize 如果不指定大小的话，不会耗尽内存 #1204](https://github.com/Snailclimb/JavaGuide/issues/1204) 。
-为了提高应用程序的稳定性，选择正确的[垃圾收集](http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html)算法至关重要。
+## 垃圾收集相关
-JVM 具有四种类型的 GC 实现：
+### 选择垃圾回收器
-- 串行垃圾收集器
-- 并行垃圾收集器
-- CMS 垃圾收集器
-- G1 垃圾收集器
+选择合适的垃圾收集器（Garbage Collector, GC）对于应用的吞吐量和响应延迟至关重要。关于垃圾收集算法和收集器的详细介绍，可以看笔者写的这篇：[JVM 垃圾回收详解（重点）](https://javaguide.cn/java/jvm/jvm-garbage-collection.html)。
-可以使用以下参数声明这些实现：
+JVM 提供了多种 GC 实现，适用于不同的场景：
-```bash
--XX:+UseSerialGC
--XX:+UseParallelGC
--XX:+UseParNewGC
--XX:+UseG1GC
-```
+- **Serial GC (串行垃圾收集器):** 单线程执行 GC，适用于客户端模式或单核 CPU 环境。参数：`-XX:+UseSerialGC`。
+- **Parallel GC (并行垃圾收集器):** 多线程执行新生代 GC (Minor GC)，以及可选的多线程执行老年代 GC (Full GC，通过 `-XX:+UseParallelOldGC`)。关注吞吐量，是 JDK 8 的默认 GC。参数：`-XX:+UseParallelGC`。
+- **CMS GC (Concurrent Mark Sweep 并发标记清除收集器):** 以获取最短回收停顿时间为目标，大部分 GC 阶段可与用户线程并发执行。适用于对响应时间要求高的应用。在 JDK 9 中被标记为弃用，JDK 14 中被移除。参数：`-XX:+UseConcMarkSweepGC`。
+- **G1 GC (Garbage-First Garbage Collector):** JDK 9 及之后版本的默认 GC。将堆划分为多个 Region，兼顾吞吐量和停顿时间，试图在可预测的停顿时间内完成 GC。参数：`-XX:+UseG1GC`。
+- **ZGC:** 更新的低延迟 GC，目标是将 GC 停顿时间控制在几毫秒甚至亚毫秒级别，需要较新版本的 JDK 支持。参数（具体参数可能随版本变化）：`-XX:+UseZGC`、`-XX:+UseShenandoahGC`。
-有关*垃圾回收*实施的更多详细信息，请参见[此处](https://github.com/Snailclimb/JavaGuide/blob/master/docs/java/jvm/JVM%E5%9E%83%E5%9C%BE%E5%9B%9E%E6%94%B6.md)。
+### GC 日志记录
-### 3.2.GC 日志记录
+在生产环境或进行 GC 问题排查时，**务必开启 GC 日志记录**。详细的 GC 日志是分析和解决 GC 问题的关键依据。
-生产环境上，或者其他要测试 GC 问题的环境上，一定会配置上打印 GC 日志的参数，便于分析 GC 相关的问题。
+以下是一些推荐配置的 GC 日志参数（适用于 JDK 8/11 等常见版本）：
```bash
-# 必选
-# 打印基本 GC 信息
+# --- 推荐的基础配置 ---
+# 打印详细 GC 信息
-XX:+PrintGCDetails
+# 打印 GC 发生的时间戳 (相对于 JVM 启动时间)
+# -XX:+PrintGCTimeStamps
+# 打印 GC 发生的日期和时间 (更常用)
-XX:+PrintGCDateStamps
-# 打印对象分布
+# 指定 GC 日志文件的输出路径，%t 可以输出日期时间戳
+-Xloggc:/path/to/gc-%t.log
+
+# --- 推荐的进阶配置 ---
+# 打印对象年龄分布 (有助于判断对象晋升老年代的情况)
-XX:+PrintTenuringDistribution
-# 打印堆数据
+# 在 GC 前后打印堆信息
-XX:+PrintHeapAtGC
-# 打印Reference处理信息
-# 强引用/弱引用/软引用/虚引用/finalize 相关的方法
+# 打印各种类型引用 (强/软/弱/虚) 的处理信息
-XX:+PrintReferenceGC
-# 打印STW时间
+# 打印应用暂停时间 (Stop-The-World, STW)
-XX:+PrintGCApplicationStoppedTime
-# 可选
-# 打印safepoint信息，进入 STW 阶段之前，需要要找到一个合适的 safepoint
--XX:+PrintSafepointStatistics
--XX:PrintSafepointStatisticsCount=1
-
-# GC日志输出的文件路径
--Xloggc:/path/to/gc-%t.log
-# 开启日志文件分割
+# --- GC 日志文件滚动配置 ---
+# 启用 GC 日志文件滚动
-XX:+UseGCLogFileRotation
-# 最多分割几个文件，超过之后从头文件开始写
+# 设置滚动日志文件的数量 (例如，保留最近 14 个)
-XX:NumberOfGCLogFiles=14
-# 每个文件上限大小，超过就触发分割
+# 设置每个日志文件的最大大小 (例如，50MB)
-XX:GCLogFileSize=50M
+
+# --- 可选的辅助诊断配置 ---
+# 打印安全点 (Safepoint) 统计信息 (有助于分析 STW 原因)
+# -XX:+PrintSafepointStatistics
+# -XX:PrintSafepointStatisticsCount=1
```
-## 4.处理 OOM
+**注意:** JDK 9 及之后版本引入了统一的 JVM 日志框架 (`-Xlog`)，配置方式有所不同，但上述 `-Xloggc` 和滚动参数通常仍然兼容或有对应的新参数。
+
+## 处理 OOM
对于大型应用程序来说，面对内存不足错误是非常常见的，这反过来会导致应用程序崩溃。这是一个非常关键的场景，很难通过复制来解决这个问题。
这就是为什么 JVM 提供了一些参数，这些参数将堆内存转储到一个物理文件中，以后可以用来查找泄漏:
```bash
+# 在发生 OOM 时生成堆转储文件
-XX:+HeapDumpOnOutOfMemoryError
--XX:HeapDumpPath=./java_pid.hprof
--XX:OnOutOfMemoryError="< cmd args >;< cmd args >"
+
+# 指定堆转储文件的输出路径。 会被替换为进程 ID
+-XX:HeapDumpPath=/path/to/heapdump/java_pid.hprof
+# 示例：-XX:HeapDumpPath=/data/dumps/
+
+# (可选) 在发生 OOM 时执行指定的命令或脚本
+# 例如，发送告警通知或尝试重启服务（需谨慎使用）
+# -XX:OnOutOfMemoryError=" "
+# 示例：-XX:OnOutOfMemoryError="sh /path/to/notify.sh"
+
+# (可选) 启用 GC 开销限制检查
+# 如果 GC 时间占总时间比例过高（默认 98%）且回收效果甚微（默认小于 2% 堆内存），
+# 会提前抛出 OOM，防止应用长时间卡死在 GC 中。
-XX:+UseGCOverheadLimit
```
-这里有几点需要注意:
-
-- **HeapDumpOnOutOfMemoryError** 指示 JVM 在遇到 **OutOfMemoryError** 错误时将 heap 转储到物理文件中。
-- **HeapDumpPath** 表示要写入文件的路径; 可以给出任何文件名; 但是，如果 JVM 在名称中找到一个 `` 标记，则当前进程的进程 id 将附加到文件名中，并使用`.hprof`格式
-- **OnOutOfMemoryError** 用于发出紧急命令，以便在内存不足的情况下执行; 应该在 `cmd args` 空间中使用适当的命令。例如，如果我们想在内存不足时重启服务器，我们可以设置参数: `-XX:OnOutOfMemoryError="shutdown -r"` 。
-- **UseGCOverheadLimit** 是一种策略，它限制在抛出 OutOfMemory 错误之前在 GC 中花费的 VM 时间的比例
-
-## 5.其他
-
-- `-server` : 启用“ Server Hotspot VM”; 此参数默认用于 64 位 JVM
-- `-XX:+UseStringDeduplication` : _Java 8u20_ 引入了这个 JVM 参数，通过创建太多相同 String 的实例来减少不必要的内存使用; 这通过将重复 String 值减少为单个全局 `char []` 数组来优化堆内存。
-- `-XX:+UseLWPSynchronization`: 设置基于 LWP (轻量级进程)的同步策略，而不是基于线程的同步。
-- `-XX:LargePageSizeInBytes`: 设置用于 Java 堆的较大页面大小; 它采用 GB/MB/KB 的参数; 页面大小越大，我们可以更好地利用虚拟内存硬件资源; 然而，这可能会导致 PermGen 的空间大小更大，这反过来又会迫使 Java 堆空间的大小减小。
-- `-XX:MaxHeapFreeRatio` : 设置 GC 后, 堆空闲的最大百分比，以避免收缩。
-- `-XX:SurvivorRatio` : eden/survivor 空间的比例, 例如`-XX:SurvivorRatio=6` 设置每个 survivor 和 eden 之间的比例为 1:6。
-- `-XX:+UseLargePages` : 如果系统支持，则使用大页面内存; 请注意，如果使用这个 JVM 参数，OpenJDK 7 可能会崩溃。
-- `-XX:+UseStringCache` : 启用 String 池中可用的常用分配字符串的缓存。
-- `-XX:+UseCompressedStrings` : 对 String 对象使用 `byte []` 类型，该类型可以用纯 ASCII 格式表示。
-- `-XX:+OptimizeStringConcat` : 它尽可能优化字符串串联操作。
-
-## 文章推荐
-
-这里推荐了非常多优质的 JVM 实践相关的文章，推荐阅读，尤其是 JVM 性能优化和问题排查相关的文章。
-
-- [JVM 参数配置说明 - 阿里云官方文档 - 2022](https://help.aliyun.com/document_detail/148851.html)
-- [JVM 内存配置最佳实践 - 阿里云官方文档 - 2022](https://help.aliyun.com/document_detail/383255.html)
-- [求你了，GC 日志打印别再瞎配置了 - 思否 - 2022](https://segmentfault.com/a/1190000039806436)
-- [一次大量 JVM Native 内存泄露的排查分析（64M 问题） - 掘金 - 2022](https://juejin.cn/post/7078624931826794503)
-- [一次线上 JVM 调优实践，FullGC40 次/天到 10 天一次的优化过程 - HeapDump - 2021](https://heapdump.cn/article/1859160)
-- [听说 JVM 性能优化很难？今天我小试了一把！ - 陈树义 - 2021](https://shuyi.tech/archives/have-a-try-in-jvm-combat)
-- [你们要的线上 GC 问题案例来啦 - 编了个程 - 2021](https://mp.weixin.qq.com/s/df1uxHWUXzhErxW1sZ6OvQ)
-- [Java 中 9 种常见的 CMS GC 问题分析与解决 - 美团技术团队 - 2020](https://tech.meituan.com/2020/11/12/java-9-cms-gc.html)
-- [从实际案例聊聊 Java 应用的 GC 优化-美团技术团队 - 美团技术团队 - 2017](https://tech.meituan.com/2017/12/29/jvm-optimize.html)
+## 其他常用参数
+
+- `-server`: 明确启用 Server 模式的 HotSpot VM。（在 64 位 JVM 上通常是默认值）。
+- `-XX:+UseStringDeduplication`: (JDK 8u20+) 尝试识别并共享底层 `char[]` 数组相同的 String 对象，以减少内存占用。适用于存在大量重复字符串的场景。
+- `-XX:SurvivorRatio=`: 设置 Eden 区与单个 Survivor 区的大小比例。例如 `-XX:SurvivorRatio=8` 表示 Eden:Survivor = 8:1。
+- `-XX:MaxTenuringThreshold=`: 设置对象从新生代晋升到老年代的最大年龄阈值（对象每经历一次 Minor GC 且存活，年龄加 1）。默认值通常是 15。
+- `-XX:+DisableExplicitGC`: 禁止代码中显式调用 `System.gc()`。推荐开启，避免人为触发不必要的 Full GC。
+- `-XX:+UseLargePages`: (需要操作系统支持) 尝试使用大内存页（如 2MB 而非 4KB），可能提升内存密集型应用的性能，但需谨慎测试。
+- -`XX:MinHeapFreeRatio= / -XX:MaxHeapFreeRatio=`: 控制 GC 后堆内存保持空闲的最小/最大百分比，用于动态调整堆大小（如果 `-Xms` 和 `-Xmx` 不相等）。通常建议将 `-Xms` 和 `-Xmx` 设为一致，避免调整开销。
+
+**注意：** 以下参数在现代 JVM 版本中可能已**弃用、移除或默认开启且无需手动设置**：
+
+- `-XX:+UseLWPSynchronization`: 较旧的同步策略选项，现代 JVM 通常有更优化的实现。
+- `-XX:LargePageSizeInBytes`: 通常由 `-XX:+UseLargePages` 自动确定或通过 OS 配置。
+- `-XX:+UseStringCache`: 已被移除。
+- `-XX:+UseCompressedStrings`: 已被 Java 9 及之后默认开启的 Compact Strings 特性取代。
+- `-XX:+OptimizeStringConcat`: 字符串连接优化（invokedynamic）在 Java 9 及之后是默认行为。
+
+## 总结
+
+本文为 Java 开发者提供了一份实用的 JVM 常用参数配置指南，旨在帮助读者理解和优化 Java 应用的性能与稳定性。文章重点强调了以下几个方面：
+
+1. **堆内存配置：** 建议显式设置初始与最大堆内存 (`-Xms`, -`Xmx`，通常设为一致) 和新生代大小 (`-Xmn` 或 `-XX:NewSize/-XX:MaxNewSize`)，这对 GC 性能至关重要。
+2. **元空间管理 (Java 8+)：** 澄清了 `-XX:MetaspaceSize` 的实际作用（首次触发 Full GC 的阈值，而非初始容量），并强烈建议设置 `-XX:MaxMetaspaceSize` 以防止潜在的本地内存耗尽。
+3. **垃圾收集器选择与日志：**介绍了不同 GC 算法的适用场景，并强调在生产和测试环境中开启详细 GC 日志 (`-Xloggc`, `-XX:+PrintGCDetails` 等) 对于问题排查的必要性。
+4. **OOM 故障排查：** 说明了如何通过 `-XX:+HeapDumpOnOutOfMemoryError` 等参数在发生 OOM 时自动生成堆转储文件，以便进行后续的内存泄漏分析。
+5. **其他参数：** 简要介绍了如字符串去重等其他有用参数，并指出了部分旧参数的现状。
+
+具体的问题排查和调优案例，可以参考笔者整理的这篇文章：[JVM 线上问题排查和性能调优案例](https://javaguide.cn/java/jvm/jvm-in-action.html)。
diff --git a/docs/java/jvm/memory-area.md b/docs/java/jvm/memory-area.md
index fb85672be56..c841024a452 100644
--- a/docs/java/jvm/memory-area.md
+++ b/docs/java/jvm/memory-area.md
@@ -88,12 +88,12 @@ Java 虚拟机规范对于运行时数据区域的规定是相当宽松的。以
Java 方法有两种返回方式，一种是 return 语句正常返回，一种是抛出异常。不管哪种返回方式，都会导致栈帧被弹出。也就是说， **栈帧随着方法调用而创建，随着方法结束而销毁。无论方法正常完成还是异常完成都算作方法结束。**
-除了 `StackOverFlowError` 错误之外，栈还可能会出现`OutOfMemoryError`错误，这是因为如果栈的内存大小可以动态扩展， 如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出`OutOfMemoryError`异常。
+除了 `StackOverFlowError` 错误之外，栈还可能会出现`OutOfMemoryError`错误，这是因为如果栈的内存大小可以动态扩展， 那么当虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出`OutOfMemoryError`异常。
简单总结一下程序运行中栈可能会出现两种错误：
-- **`StackOverFlowError`：** 若栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度的时候，就抛出 `StackOverFlowError` 错误。
-- **`OutOfMemoryError`：** 如果栈的内存大小可以动态扩展， 如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出`OutOfMemoryError`异常。
+- **`StackOverFlowError`：** 如果栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度的时候，就抛出 `StackOverFlowError` 错误。
+- **`OutOfMemoryError`：** 如果栈的内存大小可以动态扩展， 那么当虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出`OutOfMemoryError`异常。
@@ -125,7 +125,25 @@ Java 堆是垃圾收集器管理的主要区域，因此也被称作 **GC 堆（
**JDK 8 版本之后 PermGen(永久代) 已被 Metaspace(元空间) 取代，元空间使用的是本地内存。** （我会在方法区这部分内容详细介绍到）。
-大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 S0 或者 S1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 `-XX:MaxTenuringThreshold` 来设置。
+大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 S0 或者 S1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 `-XX:MaxTenuringThreshold` 来设置。不过，设置的值应该在 0-15，否则会爆出以下错误：
+
+```bash
+MaxTenuringThreshold of 20 is invalid; must be between 0 and 15
+```
+
+**为什么年龄只能是 0-15?**
+
+因为记录年龄的区域在对象头中，这个区域的大小通常是 4 位。这 4 位可以表示的最大二进制数字是 1111，即十进制的 15。因此，对象的年龄被限制为 0 到 15。
+
+这里我们简单结合对象布局来详细介绍一下。
+
+在 HotSpot 虚拟机中，对象在内存中存储的布局可以分为 3 块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。其中，对象头包括两部分：标记字段（Mark Word）和类型指针（Klass Word）。关于对象内存布局的详细介绍，后文会介绍到，这里就不重复提了。
+
+这个年龄信息就是在标记字段中存放的（标记字段还存放了对象自身的其他信息比如哈希码、锁状态信息等等）。`markOop.hpp`定义了标记字（mark word）的结构：
+
+
+
+可以看到对象年龄占用的大小确实是 4 位。
> **🐛 修正（参见：[issue552](https://github.com/Snailclimb/JavaGuide/issues/552)）**：“Hotspot 遍历所有对象时，按照年龄从小到大对其所占用的大小进行累加，当累加到某个年龄时，所累加的大小超过了 Survivor 区的一半，则取这个年龄和 `MaxTenuringThreshold` 中更小的一个值，作为新的晋升年龄阈值”。
>
@@ -134,7 +152,7 @@ Java 堆是垃圾收集器管理的主要区域，因此也被称作 **GC 堆（
> ```c++
> uint ageTable::compute_tenuring_threshold(size_t survivor_capacity) {
> //survivor_capacity是survivor空间的大小
-> size_t desired_survivor_size = (size_t)((((double) survivor_capacity)*TargetSurvivorRatio)/100);
+> size_t desired_survivor_size = (size_t)((((double) survivor_capacity)*TargetSurvivorRatio)/100);//TargetSurvivorRatio 为50
> size_t total = 0;
> uint age = 1;
> while (age < table_size) {
@@ -224,17 +242,17 @@ Class 文件中除了有类的版本、字段、方法、接口等描述信息
**字符串常量池** 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。
```java
-// 在堆中创建字符串对象”ab“
-// 将字符串对象”ab“的引用保存在字符串常量池中
+// 在字符串常量池中创建字符串对象 ”ab“
+// 将字符串对象 ”ab“ 的引用赋值给给 aa
String aa = "ab";
-// 直接返回字符串常量池中字符串对象”ab“的引用
+// 直接返回字符串常量池中字符串对象 ”ab“，赋值给引用 bb
String bb = "ab";
-System.out.println(aa==bb);// true
+System.out.println(aa==bb); // true
```
HotSpot 虚拟机中字符串常量池的实现是 `src/hotspot/share/classfile/stringTable.cpp` ,`StringTable` 可以简单理解为一个固定大小的`HashTable` ，容量为 `StringTableSize`（可以通过 `-XX:StringTableSize` 参数来设置），保存的是字符串（key）和 字符串对象的引用（value）的映射关系，字符串对象的引用指向堆中的字符串对象。
-JDK1.7 之前，字符串常量池存放在永久代。JDK1.7 字符串常量池和静态变量从永久代移动了 Java 堆中。
+JDK1.7 之前，字符串常量池存放在永久代。JDK1.7 字符串常量池和静态变量从永久代移动到了 Java 堆中。
@@ -314,9 +332,12 @@ Java 对象的创建过程我建议最好是能默写出来，并且要掌握每
### 对象的内存布局
-在 Hotspot 虚拟机中，对象在内存中的布局可以分为 3 块区域：**对象头**、**实例数据**和**对齐填充**。
+在 Hotspot 虚拟机中，对象在内存中的布局可以分为 3 块区域：**对象头（Header）**、**实例数据（Instance Data）**和**对齐填充（Padding）**。
+
+对象头包括两部分信息：
-**Hotspot 虚拟机的对象头包括两部分信息**，**第一部分用于存储对象自身的运行时数据**（哈希码、GC 分代年龄、锁状态标志等等），**另一部分是类型指针**，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
+1. 标记字段（Mark Word）：用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等。
+2. 类型指针（Klass pointer）：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
**实例数据部分是对象真正存储的有效信息**，也是在程序中所定义的各种类型的字段内容。
diff --git a/docs/java/new-features/java10.md b/docs/java/new-features/java10.md
index d52cac575b2..ee5fbb18187 100644
--- a/docs/java/new-features/java10.md
+++ b/docs/java/new-features/java10.md
@@ -53,7 +53,7 @@ var 并不会改变 Java 是一门静态类型语言的事实，编译器负责
## G1 并行 Full GC
-从 Java9 开始 G1 就了默认的垃圾回收器，G1 是以一种低延时的垃圾回收器来设计的，旨在避免进行 Full GC,但是 Java9 的 G1 的 FullGC 依然是使用单线程去完成标记清除算法,这可能会导致垃圾回收期在无法回收内存的时候触发 Full GC。
+从 Java9 开始 G1 就成了默认的垃圾回收器，G1 是以一种低延时的垃圾回收器来设计的，旨在避免进行 Full GC,但是 Java9 的 G1 的 FullGC 依然是使用单线程去完成标记清除算法,这可能会导致垃圾回收期在无法回收内存的时候触发 Full GC。
为了最大限度地减少 Full GC 造成的应用停顿的影响，从 Java10 开始，G1 的 FullGC 改为并行的标记清除算法，同时会使用与年轻代回收和混合回收相同的并行工作线程数量，从而减少了 Full GC 的发生，以带来更好的性能提升、更大的吞吐量。
diff --git a/docs/java/new-features/java11.md b/docs/java/new-features/java11.md
index f9d076c4b95..0f114047434 100644
--- a/docs/java/new-features/java11.md
+++ b/docs/java/new-features/java11.md
@@ -77,7 +77,7 @@ System.out.println(op.isEmpty());//判断指定的 Optional 对象是否为空
ZGC 主要为了满足如下目标进行设计：
- GC 停顿时间不超过 10ms
-- 即能处理几百 MB 的小堆，也能处理几个 TB 的大堆
+- 既能处理几百 MB 的小堆，也能处理几个 TB 的大堆
- 应用吞吐能力不会下降超过 15%（与 G1 回收算法相比）
- 方便在此基础上引入新的 GC 特性和利用 colored 针以及 Load barriers 优化奠定基础
- 当前只支持 Linux/x64 位平台
diff --git a/docs/java/new-features/java19.md b/docs/java/new-features/java19.md
index c1afe97f38c..a207bc6830a 100644
--- a/docs/java/new-features/java19.md
+++ b/docs/java/new-features/java19.md
@@ -36,7 +36,7 @@ Java 程序可以通过该 API 与 Java 运行时之外的代码和数据进行
Foreign Function & Memory API (FFM API) 定义了类和接口：
-- 分配外部内存：`MemorySegment`、、`MemoryAddress`和`SegmentAllocator`）；
+- 分配外部内存：`MemorySegment`、`MemoryAddress`和`SegmentAllocator`；
- 操作和访问结构化的外部内存：`MemoryLayout`, `VarHandle`；
- 控制外部内存的分配和释放：`MemorySession`；
- 调用外部函数：`Linker`、`FunctionDescriptor`和`SymbolLookup`。
diff --git a/docs/java/new-features/java21.md b/docs/java/new-features/java21.md
index f6c3874ce0c..5f145c23cc5 100644
--- a/docs/java/new-features/java21.md
+++ b/docs/java/new-features/java21.md
@@ -75,8 +75,8 @@ String message = STR."Greetings \{name}!";
Java 目前支持三种模板处理器：
- STR：自动执行字符串插值，即将模板中的每个嵌入式表达式替换为其值（转换为字符串）。
-- FMT：和 STR 类似，但是它还可以接受格式说明符，这些格式说明符出现在嵌入式表达式的左边，用来控制输出的样式
-- RAW：不会像 STR 和 FMT 模板处理器那样自动处理字符串模板，而是返回一个 `StringTemplate` 对象，这个对象包含了模板中的文本和表达式的信息
+- FMT：和 STR 类似，但是它还可以接受格式说明符，这些格式说明符出现在嵌入式表达式的左边，用来控制输出的样式。
+- RAW：不会像 STR 和 FMT 模板处理器那样自动处理字符串模板，而是返回一个 `StringTemplate` 对象，这个对象包含了模板中的文本和表达式的信息。
```java
String name = "Lokesh";
@@ -85,14 +85,14 @@ String name = "Lokesh";
String message = STR."Greetings \{name}.";
//FMT
-String message = STR."Greetings %-12s\{name}.";
+String message = FMT."Greetings %-12s\{name}.";
//RAW
StringTemplate st = RAW."Greetings \{name}.";
String message = STR.process(st);
```
-除了 JDK 自带的三种模板处理器外，你还可以实现 `StringTemplate.Processor` 接口来创建自己的模板处理器。
+除了 JDK 自带的三种模板处理器外，你还可以实现 `StringTemplate.Processor` 接口来创建自己的模板处理器，只需要继承 `StringTemplate.Processor`接口，然后实现 `process` 方法即可。
我们可以使用局部变量、静态/非静态字段甚至方法作为嵌入表达式：
@@ -198,7 +198,7 @@ Integer lastElement = linkedHashSet.getLast(); // 3
linkedHashSet.addFirst(0); //List contains: [0, 1, 2, 3]
linkedHashSet.addLast(4); //List contains: [0, 1, 2, 3, 4]
-System.out.println(linkedHashSet.reversed()); //Prints [5, 3, 2, 1, 0]
+System.out.println(linkedHashSet.reversed()); //Prints [4, 3, 2, 1, 0]
```
`SequencedMap` 接口继承了 `Map`接口， 提供了在集合两端访问、添加或删除键值对、获取包含 key 的 `SequencedSet`、包含 value 的 `SequencedCollection`、包含 entry（键值对） 的 `SequencedSet`以及获取集合的反向视图的方法。
@@ -297,7 +297,7 @@ static String formatterPatternSwitch(Object obj) {
}
```
-## JEP 442: 外部函数和内存 API（第三次预览）
+## JEP 442：外部函数和内存 API（第三次预览）
Java 程序可以通过该 API 与 Java 运行时之外的代码和数据进行互操作。通过高效地调用外部函数（即 JVM 之外的代码）和安全地访问外部内存（即不受 JVM 管理的内存），该 API 使 Java 程序能够调用本机库并处理本机数据，而不会像 JNI 那样危险和脆弱。
diff --git a/docs/java/new-features/java22-23.md b/docs/java/new-features/java22-23.md
new file mode 100644
index 00000000000..223c2b7a72c
--- /dev/null
+++ b/docs/java/new-features/java22-23.md
@@ -0,0 +1,429 @@
+---
+title: Java 22 & 23 新特性概览
+category: Java
+tag:
+ - Java新特性
+---
+
+JDK 23 和 JDK 22 一样，这也是一个非 LTS（长期支持）版本，Oracle 仅提供六个月的支持。下一个长期支持版是 JDK 25，预计明年 9 月份发布。
+
+下图是从 JDK8 到 JDK 24 每个版本的更新带来的新特性数量和更新时间：
+
+
+
+由于 JDK 22 和 JDK 23 重合的新特性较多，这里主要以 JDK 23 为主介绍，会补充 JDK 22 独有的一些特性。
+
+JDK 23 一共有 12 个新特性：
+
+- [JEP 455: 模式中的原始类型、instanceof 和 switch（预览）](https://openjdk.org/jeps/455)
+- [JEP 456: 类文件 API（第二次预览）](https://openjdk.org/jeps/466)
+- [JEP 467：Markdown 文档注释](https://openjdk.org/jeps/467)
+- [JEP 469：向量 API（第八次孵化）](https://openjdk.org/jeps/469)
+- [JEP 473：流收集器（第二次预览）](https://openjdk.org/jeps/473)
+- [JEP 471：弃用 sun.misc.Unsafe 中的内存访问方法](https://openjdk.org/jeps/471)
+- [JEP 474：ZGC：默认的分代模式](https://openjdk.org/jeps/474)
+- [JEP 476：模块导入声明 (预览)](https://openjdk.org/jeps/476)
+- [JEP 477：未命名类和实例 main 方法 （第三次预览）](https://openjdk.org/jeps/477)
+- [JEP 480：结构化并发 （第三次预览）](https://openjdk.org/jeps/480)
+- [JEP 481： 作用域值 （第三次预览）](https://openjdk.org/jeps/481)
+- [JEP 482：灵活的构造函数体（第二次预览）](https://openjdk.org/jeps/482)
+
+JDK 22 的新特性如下：
+
+
+
+其中，下面这 3 条新特性我会单独拎出来详细介绍一下：
+
+- [JEP 423：G1 垃圾收集器区域固定](https://openjdk.org/jeps/423)
+- [JEP 454：外部函数与内存 API](https://openjdk.org/jeps/454)
+- [JEP 456：未命名模式和变量](https://openjdk.org/jeps/456)
+- [JEP 458：启动多文件源代码程序](https://openjdk.org/jeps/458)
+
+## JDK 23
+
+### JEP 455: 模式中的原始类型、instanceof 和 switch（预览）
+
+在 JEP 455 之前， `instanceof` 只支持引用类型，`switch` 表达式和语句的 `case` 标签只能使用整数字面量、枚举常量和字符串字面量。
+
+JEP 455 的预览特性中，`instanceof` 和 `switch` 全面支持所有原始类型，包括 `byte`, `short`, `char`, `int`, `long`, `float`, `double`, `boolean`。
+
+```java
+// 传统写法
+if (i >= -128 && i <= 127) {
+ byte b = (byte)i;
+ ... b ...
+}
+
+// 使用 instanceof 改进
+if (i instanceof byte b) {
+ ... b ...
+}
+
+long v = ...;
+// 传统写法
+if (v == 1L) {
+ // ...
+} else if (v == 2L) {
+ // ...
+} else if (v == 10_000_000_000L) {
+ // ...
+}
+
+// 使用 long 类型的 case 标签
+switch (v) {
+ case 1L:
+ // ...
+ break;
+ case 2L:
+ // ...
+ break;
+ case 10_000_000_000L:
+ // ...
+ break;
+ default:
+ // ...
+}
+```
+
+### JEP 456: 类文件 API（第二次预览）
+
+类文件 API 在 JDK 22 进行了第一次预览，由 [JEP 457](https://openjdk.org/jeps/457) 提出。
+
+类文件 API 的目标是提供一套标准化的 API，用于解析、生成和转换 Java 类文件，取代过去对第三方库（如 ASM）在类文件处理上的依赖。
+
+```java
+// 创建一个 ClassFile 对象，这是操作类文件的入口。
+ClassFile cf = ClassFile.of();
+// 解析字节数组为 ClassModel
+ClassModel classModel = cf.parse(bytes);
+
+// 构建新的类文件，移除以 "debug" 开头的所有方法
+byte[] newBytes = cf.build(classModel.thisClass().asSymbol(),
+ classBuilder -> {
+ // 遍历所有类元素
+ for (ClassElement ce : classModel) {
+ // 判断是否为方法 且 方法名以 "debug" 开头
+ if (!(ce instanceof MethodModel mm
+ && mm.methodName().stringValue().startsWith("debug"))) {
+ // 添加到新的类文件中
+ classBuilder.with(ce);
+ }
+ }
+ });
+```
+
+### JEP 467：Markdown 文档注释
+
+在 JavaDoc 文档注释中可以使用 Markdown 语法，取代原本只能使用 HTML 和 JavaDoc 标签的方式。
+
+Markdown 更简洁易读，减少了手动编写 HTML 的繁琐，同时保留了对 HTML 元素和 JavaDoc 标签的支持。这个增强旨在让 API 文档注释的编写和阅读变得更加轻松，同时不会影响现有注释的解释。Markdown 提供了对常见文档元素（如段落、列表、链接等）的简化表达方式，提升了文档注释的可维护性和开发者体验。
+
+
+
+### JEP 469：向量 API（第八次孵化）
+
+向量计算由对向量的一系列操作组成。向量 API 用来表达向量计算，该计算可以在运行时可靠地编译为支持的 CPU 架构上的最佳向量指令，从而实现优于等效标量计算的性能。
+
+向量 API 的目标是为用户提供简洁易用且与平台无关的表达范围广泛的向量计算。
+
+这是对数组元素的简单标量计算：
+
+```java
+void scalarComputation(float[] a, float[] b, float[] c) {
+ for (int i = 0; i < a.length; i++) {
+ c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
+ }
+}
+```
+
+这是使用 Vector API 进行的等效向量计算：
+
+```java
+static final VectorSpecies SPECIES = FloatVector.SPECIES_PREFERRED;
+
+void vectorComputation(float[] a, float[] b, float[] c) {
+ int i = 0;
+ int upperBound = SPECIES.loopBound(a.length);
+ for (; i < upperBound; i += SPECIES.length()) {
+ // FloatVector va, vb, vc;
+ var va = FloatVector.fromArray(SPECIES, a, i);
+ var vb = FloatVector.fromArray(SPECIES, b, i);
+ var vc = va.mul(va)
+ .add(vb.mul(vb))
+ .neg();
+ vc.intoArray(c, i);
+ }
+ for (; i < a.length; i++) {
+ c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
+ }
+}
+```
+
+### JEP 473：流收集器（第二次预览）
+
+流收集器在 JDK 22 进行了第一次预览，由 [JEP 461](https://openjdk.org/jeps/457) 提出。
+
+这个改进使得 Stream API 可以支持自定义中间操作。
+
+```java
+source.gather(a).gather(b).gather(c).collect(...)
+```
+
+### JEP 471：弃用 sun.misc.Unsafe 中的内存访问方法
+
+JEP 471 提议弃用 `sun.misc.Unsafe` 中的内存访问方法，这些方法将来的版本中会被移除。
+
+这些不安全的方法已有安全高效的替代方案：
+
+- `java.lang.invoke.VarHandle` ：JDK 9 (JEP 193) 中引入，提供了一种安全有效地操作堆内存的方法，包括对象的字段、类的静态字段以及数组元素。
+- `java.lang.foreign.MemorySegment` ：JDK 22 (JEP 454) 中引入，提供了一种安全有效地访问堆外内存的方法，有时会与 `VarHandle` 协同工作。
+
+这两个类是 Foreign Function & Memory API（外部函数和内存 API） 的核心组件，分别用于管理和操作堆外内存。Foreign Function & Memory API 在 JDK 22 中正式转正，成为标准特性。
+
+```java
+import jdk.incubator.foreign.*;
+import java.lang.invoke.VarHandle;
+
+// 管理堆外整数数组的类
+class OffHeapIntBuffer {
+
+ // 用于访问整数元素的VarHandle
+ private static final VarHandle ELEM_VH = ValueLayout.JAVA_INT.arrayElementVarHandle();
+
+ // 内存管理器
+ private final Arena arena;
+
+ // 堆外内存段
+ private final MemorySegment buffer;
+
+ // 构造函数，分配指定数量的整数空间
+ public OffHeapIntBuffer(long size) {
+ this.arena = Arena.ofShared();
+ this.buffer = arena.allocate(ValueLayout.JAVA_INT, size);
+ }
+
+ // 释放内存
+ public void deallocate() {
+ arena.close();
+ }
+
+ // 以volatile方式设置指定索引的值
+ public void setVolatile(long index, int value) {
+ ELEM_VH.setVolatile(buffer, 0L, index, value);
+ }
+
+ // 初始化指定范围的元素为0
+ public void initialize(long start, long n) {
+ buffer.asSlice(ValueLayout.JAVA_INT.byteSize() * start,
+ ValueLayout.JAVA_INT.byteSize() * n)
+ .fill((byte) 0);
+ }
+
+ // 将指定范围的元素复制到新数组
+ public int[] copyToNewArray(long start, int n) {
+ return buffer.asSlice(ValueLayout.JAVA_INT.byteSize() * start,
+ ValueLayout.JAVA_INT.byteSize() * n)
+ .toArray(ValueLayout.JAVA_INT);
+ }
+}
+```
+
+### JEP 474：ZGC：默认的分代模式
+
+Z 垃圾回收器 (ZGC) 的默认模式切换为分代模式，并弃用非分代模式，计划在未来版本中移除。这是因为分代 ZGC 是大多数场景下的更优选择。
+
+### JEP 476：模块导入声明 (预览)
+
+模块导入声明允许在 Java 代码中简洁地导入整个模块的所有导出包，而无需逐个声明包的导入。这一特性简化了模块化库的重用，特别是在使用多个模块时，避免了大量的包导入声明，使得开发者可以更方便地访问第三方库和 Java 基本类。
+
+此特性对初学者和原型开发尤为有用，因为它无需开发者将自己的代码模块化，同时保留了对传统导入方式的兼容性，提升了开发效率和代码可读性。
+
+```java
+// 导入整个 java.base 模块，开发者可以直接访问 List、Map、Stream 等类，而无需每次手动导入相关包
+import module java.base;
+
+public class Example {
+ public static void main(String[] args) {
+ String[] fruits = { "apple", "berry", "citrus" };
+ Map fruitMap = Stream.of(fruits)
+ .collect(Collectors.toMap(
+ s -> s.toUpperCase().substring(0, 1),
+ Function.identity()));
+
+ System.out.println(fruitMap);
+ }
+}
+```
+
+### JEP 477：未命名类和实例 main 方法 （第三次预览）
+
+这个特性主要简化了 `main` 方法的的声明。对于 Java 初学者来说，这个 `main` 方法的声明引入了太多的 Java 语法概念，不利于初学者快速上手。
+
+没有使用该特性之前定义一个 `main` 方法：
+
+```java
+public class HelloWorld {
+ public static void main(String[] args) {
+ System.out.println("Hello, World!");
+ }
+}
+```
+
+使用该新特性之后定义一个 `main` 方法：
+
+```java
+class HelloWorld {
+ void main() {
+ System.out.println("Hello, World!");
+ }
+}
+```
+
+进一步简化（未命名的类允许我们省略类名）
+
+```java
+void main() {
+ System.out.println("Hello, World!");
+}
+```
+
+### JEP 480：结构化并发 （第三次预览）
+
+Java 19 引入了结构化并发，一种多线程编程方法，目的是为了通过结构化并发 API 来简化多线程编程，并不是为了取代`java.util.concurrent`，目前处于孵化器阶段。
+
+结构化并发将不同线程中运行的多个任务视为单个工作单元，从而简化错误处理、提高可靠性并增强可观察性。也就是说，结构化并发保留了单线程代码的可读性、可维护性和可观察性。
+
+结构化并发的基本 API 是[`StructuredTaskScope`](https://download.java.net/java/early_access/loom/docs/api/jdk.incubator.concurrent/jdk/incubator/concurrent/StructuredTaskScope.html)。`StructuredTaskScope` 支持将任务拆分为多个并发子任务，在它们自己的线程中执行，并且子任务必须在主任务继续之前完成。
+
+`StructuredTaskScope` 的基本用法如下：
+
+```java
+ try (var scope = new StructuredTaskScope()) {
+ // 使用fork方法派生线程来执行子任务
+ Future future1 = scope.fork(task1);
+ Future future2 = scope.fork(task2);
+ // 等待线程完成
+ scope.join();
+ // 结果的处理可能包括处理或重新抛出异常
+ ... process results/exceptions ...
+ } // close
+```
+
+结构化并发非常适合虚拟线程，虚拟线程是 JDK 实现的轻量级线程。许多虚拟线程共享同一个操作系统线程，从而允许非常多的虚拟线程。
+
+### JEP 481：作用域值 （第三次预览）
+
+作用域值（Scoped Values）可以在线程内和线程间共享不可变的数据，优于线程局部变量，尤其是在使用大量虚拟线程时。
+
+```java
+final static ScopedValue<...> V = new ScopedValue<>();
+
+// In some method
+ScopedValue.where(V, )
+ .run(() -> { ... V.get() ... call methods ... });
+
+// In a method called directly or indirectly from the lambda expression
+... V.get() ...
+```
+
+作用域值允许在大型程序中的组件之间安全有效地共享数据，而无需求助于方法参数。
+
+### JEP 482：灵活的构造函数体（第二次预览）
+
+这个特性最初在 JDK 22 由 [JEP 447: Statements before super(...) (Preview)](https://openjdk.org/jeps/447)提出。
+
+Java 要求在构造函数中，`super(...)` 或 `this(...)` 调用必须作为第一条语句出现。这意味着我们无法在调用父类构造函数之前在子类构造函数中直接初始化字段。
+
+灵活的构造函数体解决了这一问题，它允许在构造函数体内，在调用 `super(..)` 或 `this(..)` 之前编写语句，这些语句可以初始化字段，但不能引用正在构造的实例。这样可以防止在父类构造函数中调用子类方法时，子类的字段未被正确初始化，增强了类构造的可靠性。
+
+这一特性解决了之前 Java 语法限制了构造函数代码组织的问题，让开发者能够更自由、更自然地表达构造函数的行为，例如在构造函数中直接进行参数验证、准备和共享，而无需依赖辅助方法或构造函数，提高了代码的可读性和可维护性。
+
+```java
+class Person {
+ private final String name;
+ private int age;
+
+ public Person(String name, int age) {
+ if (age < 0) {
+ throw new IllegalArgumentException("Age cannot be negative.");
+ }
+ this.name = name; // 在调用父类构造函数之前初始化字段
+ this.age = age;
+ // ... 其他初始化代码
+ }
+}
+
+class Employee extends Person {
+ private final int employeeId;
+
+ public Employee(String name, int age, int employeeId) {
+ this.employeeId = employeeId; // 在调用父类构造函数之前初始化字段
+ super(name, age); // 调用父类构造函数
+ // ... 其他初始化代码
+ }
+}
+```
+
+## JDK 22
+
+### JEP 423：G1 垃圾收集器区域固定
+
+JEP 423 提出在 G1 垃圾收集器中实现区域固定（Region Pinning）功能，旨在减少由于 Java Native Interface (JNI) 关键区域导致的延迟问题。
+
+JNI 关键区域内的对象不能在垃圾收集时被移动，因此 G1 以往通过禁用垃圾收集解决该问题，导致线程阻塞及严重的延迟。通过在 G1 的老年代和年轻代中引入区域固定机制，允许在关键区域内固定对象所在的内存区域，同时继续回收未固定的区域，避免了禁用垃圾回收的需求。这种改进有助于显著降低延迟，提升系统在与 JNI 交互时的吞吐量和稳定性。
+
+### JEP 454：外部函数和内存 API
+
+Java 程序可以通过该 API 与 Java 运行时之外的代码和数据进行互操作。通过高效地调用外部函数（即 JVM 之外的代码）和安全地访问外部内存（即不受 JVM 管理的内存），该 API 使 Java 程序能够调用本机库并处理本机数据，而不会像 JNI 那样危险和脆弱。
+
+外部函数和内存 API 在 Java 17 中进行了第一轮孵化，由 [JEP 412](https://openjdk.java.net/jeps/412) 提出。Java 18 中进行了第二次孵化，由[JEP 419](https://openjdk.org/jeps/419) 提出。Java 19 中是第一次预览，由 [JEP 424](https://openjdk.org/jeps/424) 提出。JDK 20 中是第二次预览，由 [JEP 434](https://openjdk.org/jeps/434) 提出。JDK 21 中是第三次预览，由 [JEP 442](https://openjdk.org/jeps/442) 提出。
+
+最终，该特性在 JDK 22 中顺利转正。
+
+在 [Java 19 新特性概览](./java19.md) 中，我有详细介绍到外部函数和内存 API，这里就不再做额外的介绍了。
+
+### JEP 456：未命名模式和变量
+
+未命名模式和变量在 JDK 21 中由 [JEP 443](https://openjdk.org/jeps/443)提出预览，JDK 22 中就已经转正。
+
+关于这个新特性的详细介绍，可以看看[Java 21 新特性概览(重要)](./java21.md)这篇文章中的介绍。
+
+### JEP 458：启动多文件源代码程序
+
+Java 11 引入了 [JEP 330：启动单文件源代码程序](https://openjdk.org/jeps/330)，增强了 `java` 启动器的功能，使其能够直接运行单个 Java 源文件。通过命令 `java HelloWorld.java`，Java 可以在内存中隐式编译源代码并立即执行，而不需要在磁盘上生成 `.class` 文件。这简化了开发者在编写小型工具程序或学习 Java 时的工作流程，避免了手动编译的额外步骤。
+
+假设文件`Prog.java`声明了两个类：
+
+```java
+class Prog {
+ public static void main(String[] args) { Helper.run(); }
+}
+
+class Helper {
+ static void run() { System.out.println("Hello!"); }
+}
+```
+
+`java Prog.java`命令会在内存中编译两个类并执行`main`该文件中声明的第一个类的方法。
+
+这种方式有一个限制，程序的所有源代码必须放在一个`.java`文件中。
+
+[JEP 458：启动多文件源代码程序](https://openjdk.org/jeps/458) 是对 JEP 330 功能的扩展，允许直接运行由多个 Java 源文件组成的程序，而无需显式的编译步骤。
+
+假设一个目录中有两个 Java 源文件 `Prog.java` 和 `Helper.java`，每个文件各自声明了一个类：
+
+```java
+// Prog.java
+class Prog {
+ public static void main(String[] args) { Helper.run(); }
+}
+
+// Helper.java
+class Helper {
+ static void run() { System.out.println("Hello!"); }
+}
+```
+
+当你运行命令 `java Prog.java` 时，Java 启动器会在内存中编译并执行 `Prog` 类的 `main` 方法。由于 `Prog` 类中的代码引用了 `Helper` 类，启动器会自动在文件系统中找到 `Helper.java` 文件，编译其中的 `Helper` 类，并在内存中执行它。这个过程是自动的，开发者无需显式调用 `javac` 来编译所有源文件。
+
+这一特性使得从小型项目到大型项目的过渡更加平滑，开发者可以自由选择何时引入构建工具，避免在快速迭代时被迫设置复杂的项目结构。该特性消除了单文件的限制，进一步简化了从单一文件到多文件程序的开发过程，特别适合原型开发、快速实验以及早期项目的探索阶段。
diff --git a/docs/java/new-features/java24.md b/docs/java/new-features/java24.md
new file mode 100644
index 00000000000..4b8df7e2317
--- /dev/null
+++ b/docs/java/new-features/java24.md
@@ -0,0 +1,255 @@
+---
+title: Java 24 新特性概览
+category: Java
+tag:
+ - Java新特性
+---
+
+[JDK 24](https://openjdk.org/projects/jdk/24/) 是自 JDK 21 以来的第三个非长期支持版本，和 [JDK 22](https://javaguide.cn/java/new-features/java22-23.html)、[JDK 23](https://javaguide.cn/java/new-features/java22-23.html)一样。下一个长期支持版是 **JDK 25**，预计今年 9 月份发布。
+
+JDK 24 带来的新特性还是蛮多的，一共 24 个。JDK 22 和 JDK 23 都只有 12 个，JDK 24 的新特性相当于这两次的总和了。因此，这个版本还是非常有必要了解一下的。
+
+JDK 24 新特性概览：
+
+
+
+下图是从 JDK 8 到 JDK 24 每个版本的更新带来的新特性数量和更新时间：
+
+
+
+## JEP 478: 密钥派生函数 API（预览）
+
+密钥派生函数 API 是一种用于从初始密钥和其他数据派生额外密钥的加密算法。它的核心作用是为不同的加密目的（如加密、认证等）生成多个不同的密钥，避免密钥重复使用带来的安全隐患。 这在现代加密中是一个重要的里程碑，为后续新兴的量子计算环境打下了基础
+
+通过该 API，开发者可以使用最新的密钥派生算法（如 HKDF 和未来的 Argon2）：
+
+```java
+// 创建一个 KDF 对象，使用 HKDF-SHA256 算法
+KDF hkdf = KDF.getInstance("HKDF-SHA256");
+
+// 创建 Extract 和 Expand 参数规范
+AlgorithmParameterSpec params =
+ HKDFParameterSpec.ofExtract()
+ .addIKM(initialKeyMaterial) // 设置初始密钥材料
+ .addSalt(salt) // 设置盐值
+ .thenExpand(info, 32); // 设置扩展信息和目标长度
+
+// 派生一个 32 字节的 AES 密钥
+SecretKey key = hkdf.deriveKey("AES", params);
+
+// 可以使用相同的 KDF 对象进行其他密钥派生操作
+```
+
+## JEP 483: 提前类加载和链接
+
+在传统 JVM 中，应用在每次启动时需要动态加载和链接类。这种机制对启动时间敏感的应用（如微服务或无服务器函数）带来了显著的性能瓶颈。该特性通过缓存已加载和链接的类，显著减少了重复工作的开销，显著减少 Java 应用程序的启动时间。测试表明，对大型应用（如基于 Spring 的服务器应用），启动时间可减少 40% 以上。
+
+这个优化是零侵入性的，对应用程序、库或框架的代码无需任何更改，启动也方式保持一致，仅需添加相关 JVM 参数（如 `-XX:+ClassDataSharing`）。
+
+## JEP 484: 类文件 API
+
+类文件 API 在 JDK 22 进行了第一次预览（[JEP 457](https://openjdk.org/jeps/457)），在 JDK 23 进行了第二次预览并进一步完善（[JEP 466](https://openjdk.org/jeps/466)）。最终，该特性在 JDK 24 中顺利转正。
+
+类文件 API 的目标是提供一套标准化的 API，用于解析、生成和转换 Java 类文件，取代过去对第三方库（如 ASM）在类文件处理上的依赖。
+
+```java
+// 创建一个 ClassFile 对象，这是操作类文件的入口。
+ClassFile cf = ClassFile.of();
+// 解析字节数组为 ClassModel
+ClassModel classModel = cf.parse(bytes);
+
+// 构建新的类文件，移除以 "debug" 开头的所有方法
+byte[] newBytes = cf.build(classModel.thisClass().asSymbol(),
+ classBuilder -> {
+ // 遍历所有类元素
+ for (ClassElement ce : classModel) {
+ // 判断是否为方法 且 方法名以 "debug" 开头
+ if (!(ce instanceof MethodModel mm
+ && mm.methodName().stringValue().startsWith("debug"))) {
+ // 添加到新的类文件中
+ classBuilder.with(ce);
+ }
+ }
+ });
+```
+
+## JEP 485: 流收集器
+
+流收集器 `Stream::gather(Gatherer)` 是一个强大的新特性，它允许开发者定义自定义的中间操作，从而实现更复杂、更灵活的数据转换。`Gatherer` 接口是该特性的核心，它定义了如何从流中收集元素，维护中间状态，并在处理过程中生成结果。
+
+与现有的 `filter`、`map` 或 `distinct` 等内置操作不同，`Stream::gather` 使得开发者能够实现那些难以用标准 Stream 操作完成的任务。例如，可以使用 `Stream::gather` 实现滑动窗口、自定义规则的去重、或者更复杂的状态转换和聚合。 这种灵活性极大地扩展了 Stream API 的应用范围，使开发者能够应对更复杂的数据处理场景。
+
+基于 `Stream::gather(Gatherer)` 实现字符串长度的去重逻辑：
+
+```java
+var result = Stream.of("foo", "bar", "baz", "quux")
+ .gather(Gatherer.ofSequential(
+ HashSet::new, // 初始化状态为 HashSet,用于保存已经遇到过的字符串长度
+ (set, str, downstream) -> {
+ if (set.add(str.length())) {
+ return downstream.push(str);
+ }
+ return true; // 继续处理流
+ }
+ ))
+ .toList();// 转换为列表
+
+// 输出结果 ==> [foo, quux]
+```
+
+## JEP 486: 永久禁用安全管理器
+
+JDK 24 不再允许启用 `Security Manager`，即使通过 `java -Djava.security.manager`命令也无法启用，这是逐步移除该功能的关键一步。虽然 `Security Manager` 曾经是 Java 中限制代码权限（如访问文件系统或网络、读取或写入敏感文件、执行系统命令）的重要工具，但由于复杂性高、使用率低且维护成本大，Java 社区决定最终移除它。
+
+## JEP 487: 作用域值 （第四次预览）
+
+作用域值（Scoped Values）可以在线程内和线程间共享不可变的数据，优于线程局部变量，尤其是在使用大量虚拟线程时。
+
+```java
+final static ScopedValue<...> V = new ScopedValue<>();
+
+// In some method
+ScopedValue.where(V, )
+ .run(() -> { ... V.get() ... call methods ... });
+
+// In a method called directly or indirectly from the lambda expression
+... V.get() ...
+```
+
+作用域值允许在大型程序中的组件之间安全有效地共享数据，而无需求助于方法参数。
+
+## JEP 491: 虚拟线程的同步而不固定平台线程
+
+优化了虚拟线程与 `synchronized` 的工作机制。 虚拟线程在 `synchronized` 方法和代码块中阻塞时，通常能够释放其占用的操作系统线程（平台线程），避免了对平台线程的长时间占用，从而提升应用程序的并发能力。 这种机制避免了“固定 (Pinning)”——即虚拟线程长时间占用平台线程，阻止其服务于其他虚拟线程的情况。
+
+现有的使用 `synchronized` 的 Java 代码无需修改即可受益于虚拟线程的扩展能力。 例如，一个 I/O 密集型的应用程序，如果使用传统的平台线程，可能会因为线程阻塞而导致并发能力下降。 而使用虚拟线程，即使在 `synchronized` 块中发生阻塞，也不会固定平台线程，从而允许平台线程继续服务于其他虚拟线程，提高整体的并发性能。
+
+## JEP 493：在没有 JMOD 文件的情况下链接运行时镜像
+
+默认情况下，JDK 同时包含运行时镜像（运行时所需的模块）和 JMOD 文件。这个特性使得 jlink 工具无需使用 JDK 的 JMOD 文件就可以创建自定义运行时镜像，减少了 JDK 的安装体积（约 25%）。
+
+说明：
+
+- Jlink 是随 Java 9 一起发布的新命令行工具。它允许开发人员为基于模块的 Java 应用程序创建自己的轻量级、定制的 JRE。
+- JMOD 文件是 Java 模块的描述文件，包含了模块的元数据和资源。
+
+## JEP 495: 简化的源文件和实例主方法（第四次预览）
+
+这个特性主要简化了 `main` 方法的的声明。对于 Java 初学者来说，这个 `main` 方法的声明引入了太多的 Java 语法概念，不利于初学者快速上手。
+
+没有使用该特性之前定义一个 `main` 方法：
+
+```java
+public class HelloWorld {
+ public static void main(String[] args) {
+ System.out.println("Hello, World!");
+ }
+}
+```
+
+使用该新特性之后定义一个 `main` 方法：
+
+```java
+class HelloWorld {
+ void main() {
+ System.out.println("Hello, World!");
+ }
+}
+```
+
+进一步简化（未命名的类允许我们省略类名）
+
+```java
+void main() {
+ System.out.println("Hello, World!");
+}
+```
+
+## JEP 497: 量子抗性数字签名算法 (ML-DSA)
+
+JDK 24 引入了支持实施抗量子的基于模块晶格的数字签名算法 （Module-Lattice-Based Digital Signature Algorithm, **ML-DSA**），为抵御未来量子计算机可能带来的威胁做准备。
+
+ML-DSA 是美国国家标准与技术研究院（NIST）在 FIPS 204 中标准化的量子抗性算法，用于数字签名和身份验证。
+
+## JEP 498: 使用 `sun.misc.Unsafe` 内存访问方法时发出警告
+
+JDK 23([JEP 471](https://openjdk.org/jeps/471)) 提议弃用 `sun.misc.Unsafe` 中的内存访问方法，这些方法将来的版本中会被移除。在 JDK 24 中，当首次调用 `sun.misc.Unsafe` 的任何内存访问方法时，运行时会发出警告。
+
+这些不安全的方法已有安全高效的替代方案：
+
+- `java.lang.invoke.VarHandle` ：JDK 9 (JEP 193) 中引入，提供了一种安全有效地操作堆内存的方法，包括对象的字段、类的静态字段以及数组元素。
+- `java.lang.foreign.MemorySegment` ：JDK 22 (JEP 454) 中引入，提供了一种安全有效地访问堆外内存的方法，有时会与 `VarHandle` 协同工作。
+
+这两个类是 Foreign Function & Memory API（外部函数和内存 API） 的核心组件，分别用于管理和操作堆外内存。Foreign Function & Memory API 在 JDK 22 中正式转正，成为标准特性。
+
+```java
+import jdk.incubator.foreign.*;
+import java.lang.invoke.VarHandle;
+
+// 管理堆外整数数组的类
+class OffHeapIntBuffer {
+
+ // 用于访问整数元素的VarHandle
+ private static final VarHandle ELEM_VH = ValueLayout.JAVA_INT.arrayElementVarHandle();
+
+ // 内存管理器
+ private final Arena arena;
+
+ // 堆外内存段
+ private final MemorySegment buffer;
+
+ // 构造函数，分配指定数量的整数空间
+ public OffHeapIntBuffer(long size) {
+ this.arena = Arena.ofShared();
+ this.buffer = arena.allocate(ValueLayout.JAVA_INT, size);
+ }
+
+ // 释放内存
+ public void deallocate() {
+ arena.close();
+ }
+
+ // 以volatile方式设置指定索引的值
+ public void setVolatile(long index, int value) {
+ ELEM_VH.setVolatile(buffer, 0L, index, value);
+ }
+
+ // 初始化指定范围的元素为0
+ public void initialize(long start, long n) {
+ buffer.asSlice(ValueLayout.JAVA_INT.byteSize() * start,
+ ValueLayout.JAVA_INT.byteSize() * n)
+ .fill((byte) 0);
+ }
+
+ // 将指定范围的元素复制到新数组
+ public int[] copyToNewArray(long start, int n) {
+ return buffer.asSlice(ValueLayout.JAVA_INT.byteSize() * start,
+ ValueLayout.JAVA_INT.byteSize() * n)
+ .toArray(ValueLayout.JAVA_INT);
+ }
+}
+```
+
+## JEP 499: 结构化并发（第四次预览）
+
+JDK 19 引入了结构化并发，一种多线程编程方法，目的是为了通过结构化并发 API 来简化多线程编程，并不是为了取代`java.util.concurrent`，目前处于孵化器阶段。
+
+结构化并发将不同线程中运行的多个任务视为单个工作单元，从而简化错误处理、提高可靠性并增强可观察性。也就是说，结构化并发保留了单线程代码的可读性、可维护性和可观察性。
+
+结构化并发的基本 API 是`StructuredTaskScope`，它支持将任务拆分为多个并发子任务，在它们自己的线程中执行，并且子任务必须在主任务继续之前完成。
+
+`StructuredTaskScope` 的基本用法如下：
+
+```java
+ try (var scope = new StructuredTaskScope()) {
+ // 使用fork方法派生线程来执行子任务
+ Future future1 = scope.fork(task1);
+ Future future2 = scope.fork(task2);
+ // 等待线程完成
+ scope.join();
+ // 结果的处理可能包括处理或重新抛出异常
+ ... process results/exceptions ...
+ } // close
+```
+
+结构化并发非常适合虚拟线程，虚拟线程是 JDK 实现的轻量级线程。许多虚拟线程共享同一个操作系统线程，从而允许非常多的虚拟线程。
diff --git a/docs/java/new-features/java8-common-new-features.md b/docs/java/new-features/java8-common-new-features.md
index 04267d56af4..e402ba5a882 100644
--- a/docs/java/new-features/java8-common-new-features.md
+++ b/docs/java/new-features/java8-common-new-features.md
@@ -7,6 +7,8 @@ tag:
> 本文来自[cowbi](https://github.com/cowbi)的投稿~
+
+
Oracle 于 2014 发布了 Java8（jdk1.8），诸多原因使它成为目前市场上使用最多的 jdk 版本。虽然发布距今已将近 7 年，但很多程序员对其新特性还是不够了解，尤其是用惯了 Java8 之前版本的老程序员，比如我。
为了不脱离队伍太远，还是有必要对这些新特性做一些总结梳理。它较 jdk.7 有很多变化或者说是优化，比如 interface 里可以有静态方法，并且可以有方法体，这一点就颠覆了之前的认知；`java.util.HashMap` 数据结构里增加了红黑树；还有众所周知的 Lambda 表达式等等。本文不能把所有的新特性都给大家一一分享，只列出比较常用的新特性给大家做详细讲解。更多相关内容请看[官网关于 Java8 的新特性的介绍](https://www.oracle.com/java/technologies/javase/8-whats-new.html)。
@@ -93,9 +95,7 @@ public class InterfaceNewImpl implements InterfaceNew , InterfaceNew1{
在 java 8 中专门有一个包放函数式接口`java.util.function`，该包下的所有接口都有 `@FunctionalInterface` 注解，提供函数式编程。
-在其他包中也有函数式接口，其中一些没有`@FunctionalInterface` 注解，但是只要符合函数式接口的定义就是函数式接口，与是否有
-
-`@FunctionalInterface`注解无关，注解只是在编译时起到强制规范定义的作用。其在 Lambda 表达式中有广泛的应用。
+在其他包中也有函数式接口，其中一些没有`@FunctionalInterface` 注解，但是只要符合函数式接口的定义就是函数式接口，与是否有`@FunctionalInterface`注解无关，注解只是在编译时起到强制规范定义的作用。其在 Lambda 表达式中有广泛的应用。
## Lambda 表达式
diff --git a/docs/java/new-features/java8-tutorial-translate.md b/docs/java/new-features/java8-tutorial-translate.md
index 42e2146eb74..9e0fd04ec70 100644
--- a/docs/java/new-features/java8-tutorial-translate.md
+++ b/docs/java/new-features/java8-tutorial-translate.md
@@ -595,7 +595,7 @@ System.out.println(String.format("parallel sort took: %d ms", millis));
```java
1000000
-parallel sort took: 475 ms//串行排序所用的时间
+parallel sort took: 475 ms//并行排序所用的时间
```
上面两个代码几乎是一样的，但是并行版的快了 50% 左右，唯一需要做的改动就是将 `stream()` 改为`parallelStream()`。
diff --git a/docs/javaguide/contribution-guideline.md b/docs/javaguide/contribution-guideline.md
index ea0079b53d0..0c9e8df0ef1 100644
--- a/docs/javaguide/contribution-guideline.md
+++ b/docs/javaguide/contribution-guideline.md
@@ -8,9 +8,11 @@ icon: guide
你可以从下面几个方向来做贡献：
-- 笔记内容大多是手敲，所以难免会有笔误，你可以帮我找错别字。
-- 很多知识点我可能没有涉及到，所以你可以对其他知识点进行补充。
-- 现有的知识点难免存在不完善或者错误，所以你可以对已有知识点进行修改/补充。
+- 修改错别字，毕竟内容基本都是手敲，难免会有笔误。
+- 对原有内容进行修改完善，例如对某个面试问题的答案进行完善、对某篇文章的内容进行完善。
+- 新增内容，例如新增面试常问的问题、添加重要知识点的详解。
+
+目前的贡献奖励也比较丰富和完善，对于多次贡献的用户，有耳机、键盘等实物奖励以及现金奖励！
一定一定一定要注意 **排版规范**：
@@ -18,6 +20,7 @@ icon: guide
- [写给大家看的中文排版指南 - 知乎](https://zhuanlan.zhihu.com/p/20506092)
- [中文文案排版细则 - Dawner](https://dawner.top/posts/chinese-copywriting-rules/)
- [中文技术文档写作风格指南](https://github.com/yikeke/zh-style-guide/)
+- [中文排版需求](https://www.w3.org/TR/clreq/)
如果要提 issue/question 的话，强烈推荐阅读下面这些资料：
@@ -25,3 +28,5 @@ icon: guide
- [《如何向开源社区提问题》](https://github.com/seajs/seajs/issues/545)
- [《如何有效地报告 Bug》](http://www.chiark.greenend.org.uk/~sgtatham/bugs-cn.html)
- [《如何向开源项目提交无法解答的问题》](https://zhuanlan.zhihu.com/p/25795393)。
+
+另外，你可以参考学习别人的文章，但一定一定一定不能复制粘贴别人的内容，努力比别人写的更容易理解，用自己的话讲出来，适当简化表达，突出重点！
diff --git a/docs/open-source-project/readme.md b/docs/open-source-project/README.md
similarity index 100%
rename from docs/open-source-project/readme.md
rename to docs/open-source-project/README.md
diff --git a/docs/open-source-project/machine-learning.md b/docs/open-source-project/machine-learning.md
index 9feaaf4a769..6ace75ac622 100644
--- a/docs/open-source-project/machine-learning.md
+++ b/docs/open-source-project/machine-learning.md
@@ -4,11 +4,18 @@ category: 开源项目
icon: a-MachineLearning
---
-由于 Java 在 AI 领域应用较少，因此相关的开源项目也非常少：
+由于 Java 在 AI 领域目前的应用较少，因此相关的开源项目也非常少。
+
+## 基础框架
- [Spring AI](https://github.com/spring-projects/spring-ai)：人工智能工程应用框架，为开发 AI 应用程序提供了 Spring 友好的 API 和抽象。
+- [Spring AI Alibaba](https://github.com/alibaba/spring-ai-alibaba)：一款 Java 语言实现的 AI 应用开发框架，旨在简化 Java AI 应用程序开发，让 Java 开发者像使用 Spring 开发普通应用一样开发 AI 应用。
+- [LangChain4j](https://github.com/langchain4j/langchain4j)：LangChiain 的 Java 版本，用于简化将 LLM（Large Language Model，大语言模型） 集成到 Java 应用程序的过程。
- [Deeplearning4j](https://github.com/eclipse/deeplearning4j)：Deeplearning4j 是第一个为 Java 和 Scala 编写的商业级，开源，分布式深度学习库。
- [Smile](https://github.com/haifengl/smile)：基于 Java 和 Scala 的机器学习库。
- [GdxAI](https://github.com/libgdx/gdx-ai)：完全用 Java 编写的人工智能框架，用于使用 libGDX 进行游戏开发。
-- [chatgpt-java](https://github.com/Grt1228/chatgpt-java)：ChatGPT Java SDK。
+
+## 实战
+
+- [springboot-openai-chatgpt](https://github.com/274056675/springboot-openai-chatgpt)：一个基于 SpringCloud 微服务架构，已对接 GPT-3.5、GPT-4.0、百度文心一言、Midjourney 绘图等等。
- [ai-beehive](https://github.com/hncboy/ai-beehive)：AI 蜂巢，基于 Java 使用 Spring Boot 3 和 JDK 17，支持的功能有 ChatGPT、OpenAi Image、Midjourney、NewBing、文心一言等等。
diff --git a/docs/open-source-project/practical-project.md b/docs/open-source-project/practical-project.md
index c96fd053f48..1c5e2d70dbb 100644
--- a/docs/open-source-project/practical-project.md
+++ b/docs/open-source-project/practical-project.md
@@ -27,8 +27,8 @@ icon: project
- [paicoding](https://github.com/itwanger/paicoding)：一款好用又强大的开源社区，基于 Spring Boot 系列主流技术栈，附详细的教程。
- [forest](https://github.com/rymcu/forest)：下一代的知识社区系统，可以自定义专题和作品集。后端基于 SpringBoot + Shrio + MyBatis + JWT + Redis，前端基于 Vue + NuxtJS + Element-UI。
-- [vhr](https://github.com/lenve/vhr "vhr")：微人事是一个前后端分离的人力资源管理系统，项目采用 SpringBoot+Vue 开发。
- [community](https://github.com/codedrinker/community)：开源论坛、问答系统，现有功能提问、回复、通知、最新、最热、消除零回复功能。功能持续更新中…… 技术栈 Spring、Spring Boot、MyBatis、MySQL/H2、Bootstrap。
+- [OneBlog](https://gitee.com/yadong.zhang/DBlog)：简洁美观、功能强大并且自适应的博客系统，支持广告位、SEO、实时通讯等功能。
- [VBlog](https://github.com/lenve/VBlog)：V 部落，Vue+SpringBoot 实现的多用户博客管理平台!
- [My-Blog](https://github.com/ZHENFENG13/My-Blog)： SpringBoot + Mybatis + Thymeleaf 等技术实现的 Java 博客系统，页面美观、功能齐全、部署简单及完善的代码，一定会给使用者无与伦比的体验。
@@ -49,6 +49,7 @@ icon: project
- [HOJ](https://gitee.com/himitzh0730/hoj)：分布式架构的在线测评平台 OJ ，功能非常全面，支持刷题、训练、比赛、评测等功能。
- [VOJ](https://github.com/simplefanC/voj)：基于微服务架构的高性能在线评测系统。拥有本地判题服务，同时支持其它知名 OJ (HDU、POJ...) 的远程判题。采用现阶段流行技术实现，采用 Docker 容器化部署。
- [OnlineJudge](https://github.com/SDUOJ/OnlineJudge)：基于微服务架构的在线评测系统，支持多种国际赛制支持（ICPC/OI/IOI），采用 Docker 容器化部署。
+- [sg-exam](https://gitee.com/wells2333/sg-exam)：方便易用、高颜值的教学管理平台，提供多租户、权限管理、考试、练习、在线学习等功能。
- [uexam](https://gitee.com/mindskip/uexam)：功能全面的在线考试系统，开发部署简单快捷、界面设计友好、代码结构清晰。相关阅读：[好一个 Spring Boot 开源在线考试系统！解决了我的燃眉之急](http://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzg2OTA0Njk0OA%3D%3D%26mid%3D2247491585%26idx%3D1%26sn%3D8d3c6768c22e72d6bfcbeee9624886a7%26chksm%3Dcea1afcaf9d626dc918760289c37025ad526f6255786bc198d2402203df64c873ad7934f58df%26scene%3D178%26cur_album_id%3D1345382825083895808%23rd) 。
- [PassJava-Platform](https://github.com/Jackson0714/PassJava-Platform)：基于微服务架构的面试刷题小程序！相关阅读：[一个基于 Spring Cloud 的面试刷题系统。面试、毕设、项目经验一网打尽](http://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzg2OTA0Njk0OA%3D%3D%26mid%3D2247497045%26idx%3D1%26sn%3D577175bfd6c040a0df5a494fce6f9758%26chksm%3Dcea1ba9ef9d633883a2e213c0fb9a88bdc87051347d4b3fad2c2befb65d8b16e1ea81d8146dd%26scene%3D178%26cur_album_id%3D1345382825083895808%23rd)。
diff --git a/docs/open-source-project/system-design.md b/docs/open-source-project/system-design.md
index b7bd363ea9b..5471f2d07b3 100644
--- a/docs/open-source-project/system-design.md
+++ b/docs/open-source-project/system-design.md
@@ -10,6 +10,7 @@ icon: "xitongsheji"
- [Spring Boot](https://github.com/spring-projects/spring-boot "spring-boot")：Spring Boot 可以轻松创建独立的生产级基于 Spring 的应用程序，内置 web 服务器让你可以像运行普通 Java 程序一样运行项 目。另外，大部分 Spring Boot 项目只需要少量的配置即可，这有别于 Spring 的重配置。
- [SOFABoot](https://github.com/sofastack/sofa-boot)：SOFABoot 基于 Spring Boot ，不过在其基础上增加了 Readiness Check，类隔离，日志空间隔离等等能力。 配套提供的还有：SOFARPC（RPC 框架）、SOFABolt（基于 Netty 的远程通信框架）、SOFARegistry（注册中心）...详情请参考：[SOFAStack](https://github.com/sofastack) 。
+- [Solon](https://gitee.com/opensolon/solon)：国产面向全场景的 Java 企业级应用开发框架。
- [Javalin](https://github.com/tipsy/javalin)：一个轻量级的 Web 框架，同时支持 Java 和 Kotlin，被微软、红帽、Uber 等公司使用。
- [Play Framework](https://github.com/playframework/playframework)：面向 Java 和 Scala 的高速 Web 框架。
- [Blade](https://github.com/lets-blade/blade)：一款追求简约、高效的 Web 框架，基于 Java8 + Netty4。
@@ -18,6 +19,7 @@ icon: "xitongsheji"
- [Armeria](https://github.com/line/armeria)：适合任何情况的微服务框架。你可以用你喜欢的技术构建任何类型的微服务，包括[gRPC](https://grpc.io/)、 [Thrift](https://thrift.apache.org/)、[Kotlin](https://kotlinlang.org/)、 [Retrofit](https://square.github.io/retrofit/)、[Reactive Streams](https://www.reactive-streams.org/)、 [Spring Boot](https://spring.io/projects/spring-boot)和[Dropwizard](https://www.dropwizard.io/)
- [Quarkus](https://github.com/quarkusio/quarkus) : 用于编写 Java 应用程序的云原生和容器优先的框架。
+- [Helidon](https://github.com/helidon-io/helidon)：一组用于编写微服务的 Java 库，支持 Helidon MP 和 Helidon SE 两种编程模型。
### API 文档
@@ -59,7 +61,6 @@ icon: "xitongsheji"
- [Retrofit](https://github.com/square/retrofit)：适用于 Android 和 Java 的类型安全的 HTTP 客户端。Retrofit 的 HTTP 请求使用的是 [OkHttp](https://square.github.io/okhttp/) 库（一款被广泛使用网络框架）。
- [Forest](https://gitee.com/dromara/forest)：轻量级 HTTP 客户端 API 框架，让 Java 发送 HTTP/HTTPS 请求不再难。它比 OkHttp 和 HttpClient 更高层，是封装调用第三方 restful api client 接口的好帮手，是 retrofit 和 feign 之外另一个选择。
- [netty-websocket-spring-boot-starter](https://github.com/YeautyYE/netty-websocket-spring-boot-starter) :帮助你在 Spring Boot 中使用 Netty 来开发 WebSocket 服务器，并像 spring-websocket 的注解开发一样简单。
-- [SMS4J](https://github.com/dromara/SMS4J)：短信聚合框架，解决接入多个短信 SDK 的繁琐流程。
## 数据库
@@ -72,7 +73,8 @@ icon: "xitongsheji"
- [MyBatis-Plus](https://github.com/baomidou/mybatis-plus) : [MyBatis](http://www.mybatis.org/mybatis-3/) 增强工具，在 MyBatis 的基础上只做增强不做改变，为简化开发、提高效率而生。
- [MyBatis-Flex](https://gitee.com/mybatis-flex/mybatis-flex)：一个优雅的 MyBatis 增强框架，无其他任何第三方依赖，支持 CRUD、分页查询、多表查询、批量操作。
-- [Redisson](https://github.com/redisson/redisson "redisson")：Redis 基础上的一个 Java 驻内存数据网格（In-Memory Data Grid）,支持超过 30 个对象和服务:`Set`,`SortedSet`, `Map`, `List`, `Queue`, `Deque` ……，并且提供了多种分布式锁的实现。更多介绍请看：[《Redisson 项目介绍》](https://github.com/redisson/redisson/wiki/Redisson%E9%A1%B9%E7%9B%AE%E4%BB%8B%E7%BB%8D "Redisson项目介绍")。
+- [jOOQ](https://github.com/jOOQ/jOOQ)：用 Java 编写 SQL 的最佳方式。
+- [Redisson](https://github.com/redisson/redisson "redisson")：Redisson 是一款架设在 Redis 基础之上的 Java 驻内存数据网格 (In-Memory Data Grid)，它充分利用了 Redis 键值数据库的优势，为 Java 开发者提供了一系列具有分布式特性的常用工具类。例如，分布式 Java 对象（`Set`，`SortedSet`，`Map`，`List`，`Queue`，`Deque` 等）、分布式锁等。详细介绍请看：[Redisson 项目介绍](https://github.com/redisson/redisson/wiki/Redisson%E9%A1%B9%E7%9B%AE%E4%BB%8B%E7%BB%8D "Redisson项目介绍")。
### 数据同步
@@ -115,9 +117,12 @@ icon: "xitongsheji"
### API 调试
-- [Insomnia](https://insomnia.rest/) :像人类而不是机器人一样调试 API。我平时经常用的，界面美观且轻量，总之很喜欢。
-- [Postman](https://www.getpostman.com/)：API 请求生成器。
-- [Postwoman](https://github.com/liyasthomas/postwoman "postwoman")：API 请求生成器-一个免费、快速、漂亮的 Postma 替代品。
+- [Reqable](https://reqable.com/zh-CN/)：新一代开源 API 开发工具。Reqable = Fiddler + Charles + Postman, 让 API 调试更快。
+- [Insomnia](https://insomnia.rest/) :像人类而不是机器人一样调试 API。我平时经常用的一款 API 开发工具，界面美观且轻量，总之很喜欢。
+- [RapidAPI](https://paw.cloud/)：一款功能齐全的 HTTP 客户端，但仅支持 Mac。
+- [Postcat](https://github.com/Postcatlab/postcat)：一个可扩展的开源 API 工具平台。
+- [Postman](https://www.getpostman.com/)：开发者最常用的 API 测试工具之一。
+- [Hoppscotch](https://github.com/liyasthomas/postwoman "postwoman")（原 Postwoman）：开源 API 测试工具。官方定位是 Postman、Insomnia 等产品的开源替代品。
- [Restful Fast Request](https://gitee.com/dromara/fast-request)：IDEA 版 Postman，API 调试工具 + API 管理工具 + API 搜索工具。
## 任务调度
@@ -125,9 +130,15 @@ icon: "xitongsheji"
- [Quartz](https://github.com/quartz-scheduler/quartz)：一个很火的开源任务调度框架，Java 定时任务领域的老大哥或者说参考标准， 很多其他任务调度框架都是基于 `quartz` 开发的，比如当当网的`elastic-job`就是基于`quartz`二次开发之后的分布式调度解决方案
- [XXL-JOB](https://github.com/xuxueli/xxl-job) :XXL-JOB 是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。
- [Elastic-Job](http://elasticjob.io/index_zh.html)：Elastic-Job 是当当网开源的一个基于 Quartz 和 Zookeeper 的分布式调度解决方案，由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成，一般我们只要使用 Elastic-Job-Lite 就好。
-- [EasyScheduler](https://github.com/analysys/EasyScheduler "EasyScheduler") （已经更名为 DolphinScheduler，已经成为 Apache 孵化器项目）：Easy Scheduler 是一个分布式工作流任务调度系统，主要解决“复杂任务依赖但无法直接监控任务健康状态”的问题。Easy Scheduler 以 DAG 方式组装任务，可以实时监控任务的运行状态。同时，它支持重试，重新运行等操作... 。
+- [EasyScheduler](https://github.com/analysys/EasyScheduler "EasyScheduler") （已经更名为 DolphinScheduler，已经成为 Apache 孵化器项目）：分布式易扩展的可视化工作流任务调度平台，主要解决“复杂任务依赖但无法直接监控任务健康状态”的问题。
- [PowerJob](https://gitee.com/KFCFans/PowerJob)：新一代分布式任务调度与计算框架，支持 CRON、API、固定频率、固定延迟等调度策略，提供工作流来编排任务解决依赖关系，使用简单，功能强大，文档齐全，欢迎各位接入使用！
+- Spock 没办法 Mock 静态方法和私有方法 ，Mockito 3.4.0 以后，支持静态方法的 Mock，具体可以看这个 issue：，具体教程可以看这篇文章：
- Spock 基于 Groovy，写出来的测试代码更清晰易读，比较规范(自带 given-when-then 的常用测试结构规范)。Mockito 没有具体的结构规范，需要项目组自己约定一个或者遵守比较好的测试代码实践。通常来说，同样的测试用例，Spock 的代码要更简洁。
- Mockito 使用的人群更广泛，稳定可靠。并且，Mockito 是 SpringBoot Test 默认集成的 Mock 工具。
diff --git a/docs/system-design/framework/spring/Async.md b/docs/system-design/framework/spring/Async.md
new file mode 100644
index 00000000000..a27eb61c970
--- /dev/null
+++ b/docs/system-design/framework/spring/Async.md
@@ -0,0 +1,721 @@
+---
+title: Async 注解原理分析
+category: 框架
+tag:
+ - Spring
+---
+
+`@Async` 注解由 Spring 框架提供，被该注解标注的类或方法会在 **异步线程** 中执行。这意味着当方法被调用时，调用者将不会等待该方法执行完成，而是可以继续执行后续的代码。
+
+`@Async` 注解的使用非常简单，需要两个步骤：
+
+1. 在启动类上添加注解 `@EnableAsync` ，开启异步任务。
+2. 在需要异步执行的方法或类上添加注解 `@Async` 。
+
+```java
+@SpringBootApplication
+// 开启异步任务
+@EnableAsync
+public class YourApplication {
+
+ public static void main(String[] args) {
+ SpringApplication.run(YourApplication.class, args);
+ }
+}
+
+// 异步服务类
+@Service
+public class MyService {
+
+ // 推荐使用自定义线程池，这里只是演示基本用法
+ @Async
+ public CompletableFuture doSomethingAsync() {
+
+ // 这里会有一些业务耗时操作
+ // ...
+ // 使用 CompletableFuture 可以更方便地处理异步任务的结果，避免阻塞主线程
+ return CompletableFuture.completedFuture("Async Task Completed");
+ }
+
+}
+```
+
+接下来，我们一起来看看 `@Async` 的底层原理。
+
+## @Async 原理分析
+
+`@Async` 可以异步执行任务，本质上是使用 **动态代理** 来实现的。通过 Spring 中的后置处理器 `BeanPostProcessor` 为使用 `@Async` 注解的类创建动态代理，之后 `@Async` 注解方法的调用会被动态代理拦截，在拦截器中将方法的执行封装为异步任务提交给线程池处理。
+
+接下来，我们来详细分析一下。
+
+### 开启异步
+
+使用 `@Async` 之前，需要在启动类上添加 `@EnableAsync` 来开启异步，`@EnableAsync` 注解如下：
+
+```JAVA
+// 省略其他注解 ...
+@Import(AsyncConfigurationSelector.class)
+public @interface EnableAsync { /* ... */ }
+```
+
+在 `@EnableAsync` 注解上通过 `@Import` 注解引入了 `AsyncConfigurationSelector` ，因此 Spring 会去加载通过 `@Import` 注解引入的类。
+
+`AsyncConfigurationSelector` 类实现了 `ImportSelector` 接口，因此在该类中会重写 `selectImports()` 方法来自定义加载 Bean 的逻辑，如下：
+
+```JAVA
+public class AsyncConfigurationSelector extends AdviceModeImportSelector {
+ @Override
+ @Nullable
+ public String[] selectImports(AdviceMode adviceMode) {
+ switch (adviceMode) {
+ // 基于 JDK 代理织入的通知
+ case PROXY:
+ return new String[] {ProxyAsyncConfiguration.class.getName()};
+ // 基于 AspectJ 织入的通知
+ case ASPECTJ:
+ return new String[] {ASYNC_EXECUTION_ASPECT_CONFIGURATION_CLASS_NAME};
+ default:
+ return null;
+ }
+ }
+}
+```
+
+在 `selectImports()` 方法中，会根据通知的不同类型来选择加载不同的类，其中 `adviceMode` 默认值为 `PROXY` 。
+
+这里以基于 JDK 代理的通知为例，此时会加载 `ProxyAsyncConfiguration` 类，如下：
+
+```JAVA
+@Configuration
+@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
+public class ProxyAsyncConfiguration extends AbstractAsyncConfiguration {
+ @Bean(name = TaskManagementConfigUtils.ASYNC_ANNOTATION_PROCESSOR_BEAN_NAME)
+ @Role(BeanDefinition.ROLE_INFRASTRUCTURE)
+ public AsyncAnnotationBeanPostProcessor asyncAdvisor() {
+ // ...
+ // 加载后置处理器
+ AsyncAnnotationBeanPostProcessor bpp = new AsyncAnnotationBeanPostProcessor();
+
+ // ...
+ return bpp;
+ }
+}
+```
+
+### 后置处理器
+
+在 `ProxyAsyncConfiguration` 类中，会通过 `@Bean` 注解加载一个后置处理器 `AsyncAnnotationBeanPostProcessor` ，这个后置处理器是使 `@Async` 注解起作用的关键。
+
+如果某一个类或者方法上使用了 `@Async` 注解，`AsyncAnnotationBeanPostProcessor` 处理器就会为该类创建一个动态代理。
+
+该类的方法在执行时，会被代理对象的拦截器所拦截，其中被 `@Async` 注解标记的方法会异步执行。
+
+`AsyncAnnotationBeanPostProcessor` 代码如下：
+
+```JAVA
+public class AsyncAnnotationBeanPostProcessor extends AbstractBeanFactoryAwareAdvisingPostProcessor {
+ @Override
+ public void setBeanFactory(BeanFactory beanFactory) {
+ super.setBeanFactory(beanFactory);
+ // 创建 AsyncAnnotationAdvisor，它是一个 Advisor
+ // 用于拦截带有 @Async 注解的方法并将这些方法异步执行。
+ AsyncAnnotationAdvisor advisor = new AsyncAnnotationAdvisor(this.executor, this.exceptionHandler);
+ // 如果设置了自定义的 asyncAnnotationType，则将其设置到 advisor 中。
+ // asyncAnnotationType 用于指定自定义的异步注解，例如 @MyAsync。
+ if (this.asyncAnnotationType != null) {
+ advisor.setAsyncAnnotationType(this.asyncAnnotationType);
+ }
+ advisor.setBeanFactory(beanFactory);
+ this.advisor = advisor;
+ }
+}
+```
+
+`AsyncAnnotationBeanPostProcessor` 的父类实现了 `BeanFactoryAware` 接口，因此在该类中重写了 `setBeanFactory()` 方法作为扩展点，来加载 `AsyncAnnotationAdvisor` 。
+
+#### 创建 Advisor
+
+`Advisor` 是 `Spring AOP` 对 `Advice` 和 `Pointcut` 的抽象。`Advice` 为执行的通知逻辑，`Pointcut` 为通知执行的切入点。
+
+在后置处理器 `AsyncAnnotationBeanPostProcessor` 中会去创建 `AsyncAnnotationAdvisor` ， 在它的构造方法中，会构建对应的 `Advice` 和 `Pointcut` ，如下：
+
+```JAVA
+public class AsyncAnnotationAdvisor extends AbstractPointcutAdvisor implements BeanFactoryAware {
+
+ private Advice advice; // 异步执行的 Advice
+ private Pointcut pointcut; // 匹配 @Async 注解方法的切点
+
+ // 构造函数
+ public AsyncAnnotationAdvisor(/* 参数省略 */) {
+ // 1. 创建 Advice，负责异步执行逻辑
+ this.advice = buildAdvice(executor, exceptionHandler);
+ // 2. 创建 Pointcut，选择要被增强的目标方法
+ this.pointcut = buildPointcut(asyncAnnotationTypes);
+ }
+
+ // 创建 Advice
+ protected Advice buildAdvice(/* 参数省略 */) {
+ // 创建处理异步执行的拦截器
+ AnnotationAsyncExecutionInterceptor interceptor = new AnnotationAsyncExecutionInterceptor(null);
+ // 使用执行器和异常处理器配置拦截器
+ interceptor.configure(executor, exceptionHandler);
+ return interceptor;
+ }
+
+ // 创建 Pointcut
+ protected Pointcut buildPointcut(Set> asyncAnnotationTypes) {
+ ComposablePointcut result = null;
+ for (Class asyncAnnotationType : asyncAnnotationTypes) {
+ // 1. 类级别切点：如果类上有注解则匹配
+ Pointcut cpc = new AnnotationMatchingPointcut(asyncAnnotationType, true);
+ // 2. 方法级别切点：如果方法上有注解则匹配
+ Pointcut mpc = new AnnotationMatchingPointcut(null, asyncAnnotationType, true);
+
+ if (result == null) {
+ result = new ComposablePointcut(cpc);
+ } else {
+ // 使用 union 合并之前的切点
+ result.union(cpc);
+ }
+ // 将方法级别切点添加到组合切点
+ result = result.union(mpc);
+ }
+ // 返回组合切点，如果没有提供注解类型则返回 Pointcut.TRUE
+ return (result != null ? result : Pointcut.TRUE);
+ }
+}
+```
+
+`AsyncAnnotationAdvisor` 的核心在于构建 `Advice` 和 `Pointcut` ：
+
+- 构建 `Advice` ：会创建 `AnnotationAsyncExecutionInterceptor` 拦截器，在拦截器的 `invoke()` 方法中会执行通知的逻辑。
+- 构建 `Pointcut` ：由 `ClassFilter` 和 `MethodMatcher` 组成，用于匹配哪些方法需要执行通知（ `Advice` ）的逻辑。
+
+#### 后置处理逻辑
+
+`AsyncAnnotationBeanPostProcessor` 后置处理器中实现的 `postProcessAfterInitialization()` 方法在其父类 `AbstractAdvisingBeanPostProcessor` 中，在 `Bean` 初始化之后，会进入到 `postProcessAfterInitialization()` 方法进行后置处理。
+
+在后置处理方法中，会判断 `Bean` 是否符合后置处理器中 `Advisor` 通知的条件，如果符合，则创建代理对象。如下：
+
+```JAVA
+// AbstractAdvisingBeanPostProcessor
+public Object postProcessAfterInitialization(Object bean, String beanName) {
+ if (this.advisor == null || bean instanceof AopInfrastructureBean) {
+ return bean;
+ }
+ if (bean instanceof Advised) {
+ Advised advised = (Advised) bean;
+ if (!advised.isFrozen() && isEligible(AopUtils.getTargetClass(bean))) {
+ if (this.beforeExistingAdvisors) {
+ advised.addAdvisor(0, this.advisor);
+ }
+ else {
+ advised.addAdvisor(this.advisor);
+ }
+ return bean;
+ }
+ }
+ // 判断给定的 Bean 是否符合后置处理器中 Advisor 通知的条件，符合的话，就创建代理对象。
+ if (isEligible(bean, beanName)) {
+ ProxyFactory proxyFactory = prepareProxyFactory(bean, beanName);
+ if (!proxyFactory.isProxyTargetClass()) {
+ evaluateProxyInterfaces(bean.getClass(), proxyFactory);
+ }
+ // 添加 Advisor。
+ proxyFactory.addAdvisor(this.advisor);
+ customizeProxyFactory(proxyFactory);
+ // 返回代理对象。
+ return proxyFactory.getProxy(getProxyClassLoader());
+ }
+ return bean;
+}
+```
+
+### @Async 注解方法的拦截
+
+`@Async` 注解方法的执行会在 `AnnotationAsyncExecutionInterceptor` 中被拦截，在 `invoke()` 方法中执行拦截器的逻辑。此时会将 `@Async` 注解标注的方法封装为异步任务，交给执行器来执行。
+
+`invoke()` 方法在 `AnnotationAsyncExecutionInterceptor` 的父类 `AsyncExecutionInterceptor` 中定义，如下：
+
+```JAVA
+public class AsyncExecutionInterceptor extends AsyncExecutionAspectSupport implements MethodInterceptor, Ordered {
+ @Override
+ @Nullable
+ public Object invoke(final MethodInvocation invocation) throws Throwable {
+ Class targetClass = (invocation.getThis() != null ? AopUtils.getTargetClass(invocation.getThis()) : null);
+ Method specificMethod = ClassUtils.getMostSpecificMethod(invocation.getMethod(), targetClass);
+ final Method userDeclaredMethod = BridgeMethodResolver.findBridgedMethod(specificMethod);
+
+ // 1、确定异步任务执行器
+ AsyncTaskExecutor executor = determineAsyncExecutor(userDeclaredMethod);
+
+ // 2、将要执行的方法封装为 Callable 异步任务
+ Callable task = () -> {
+ try {
+ // 2.1、执行方法
+ Object result = invocation.proceed();
+ // 2.2、如果方法返回值是 Future 类型，阻塞等待结果
+ if (result instanceof Future) {
+ return ((Future) result).get();
+ }
+ }
+ catch (ExecutionException ex) {
+ handleError(ex.getCause(), userDeclaredMethod, invocation.getArguments());
+ }
+ catch (Throwable ex) {
+ handleError(ex, userDeclaredMethod, invocation.getArguments());
+ }
+ return null;
+ };
+ // 3、提交任务
+ return doSubmit(task, executor, invocation.getMethod().getReturnType());
+ }
+}
+```
+
+在 `invoke()` 方法中，主要有 3 个步骤：
+
+1. 确定执行异步任务的执行器。
+2. 将 `@Async` 注解标注的方法封装为 `Callable` 异步任务。
+3. 将任务提交给执行器执行。
+
+#### 1、获取异步任务执行器
+
+在 `determineAsyncExecutor()` 方法中，会获取异步任务的执行器（即执行异步任务的 **线程池** ）。代码如下：
+
+```JAVA
+// 确定异步任务的执行器
+protected AsyncTaskExecutor determineAsyncExecutor(Method method) {
+ // 1、先从缓存中获取。
+ AsyncTaskExecutor executor = this.executors.get(method);
+ if (executor == null) {
+ Executor targetExecutor;
+ // 2、获取执行器的限定符。
+ String qualifier = getExecutorQualifier(method);
+ if (StringUtils.hasLength(qualifier)) {
+ // 3、根据限定符获取对应的执行器。
+ targetExecutor = findQualifiedExecutor(this.beanFactory, qualifier);
+ }
+ else {
+ // 4、如果没有限定符，则使用默认的执行器。即 Spring 提供的默认线程池：SimpleAsyncTaskExecutor。
+ targetExecutor = this.defaultExecutor.get();
+ }
+ if (targetExecutor == null) {
+ return null;
+ }
+ // 5、将执行器包装为 TaskExecutorAdapter 适配器。
+ // TaskExecutorAdapter 是 Spring 对于 JDK 线程池做的一层抽象，还是继承自 JDK 的线程池 Executor。这里可以不用管太多，只要知道它是线程池就可以了。
+ executor = (targetExecutor instanceof AsyncListenableTaskExecutor ?
+ (AsyncListenableTaskExecutor) targetExecutor : new TaskExecutorAdapter(targetExecutor));
+ this.executors.put(method, executor);
+ }
+ return executor;
+}
+```
+
+在 `determineAsyncExecutor()` 方法中确定了异步任务的执行器（线程池），主要是通过 `@Async` 注解的 `value` 值来获取执行器的限定符，根据限定符再去 `BeanFactory` 中查找对应的执行器就可以了。
+
+如果在 `@Async` 注解中没有指定线程池，则会通过 `this.defaultExecutor.get()` 来获取默认的线程池，其中 `defaultExecutor` 在下边方法中进行赋值：
+
+```JAVA
+// AsyncExecutionInterceptor
+protected Executor getDefaultExecutor(@Nullable BeanFactory beanFactory) {
+ // 1、尝试从 beanFactory 中获取线程池。
+ Executor defaultExecutor = super.getDefaultExecutor(beanFactory);
+ // 2、如果 beanFactory 中没有，则创建 SimpleAsyncTaskExecutor 线程池。
+ return (defaultExecutor != null ? defaultExecutor : new SimpleAsyncTaskExecutor());
+}
+```
+
+其中 `super.getDefaultExecutor()` 会在 `beanFactory` 中尝试获取 `Executor` 类型的线程池。代码如下：
+
+```JAVA
+protected Executor getDefaultExecutor(@Nullable BeanFactory beanFactory) {
+ if (beanFactory != null) {
+ try {
+ // 1、从 beanFactory 中获取 TaskExecutor 类型的线程池。
+ return beanFactory.getBean(TaskExecutor.class);
+ }
+ catch (NoUniqueBeanDefinitionException ex) {
+ try {
+ // 2、如果有多个，则尝试从 beanFactory 中获取执行名称的 Executor 线程池。
+ return beanFactory.getBean(DEFAULT_TASK_EXECUTOR_BEAN_NAME, Executor.class);
+ }
+ catch (NoSuchBeanDefinitionException ex2) {
+ if (logger.isInfoEnabled()) {
+ // ...
+ }
+ }
+ }
+ catch (NoSuchBeanDefinitionException ex) {
+ try {
+ // 3、如果没有，则尝试从 beanFactory 中获取执行名称的 Executor 线程池。
+ return beanFactory.getBean(DEFAULT_TASK_EXECUTOR_BEAN_NAME, Executor.class);
+ }
+ catch (NoSuchBeanDefinitionException ex2) {
+ // ...
+ }
+ }
+ }
+ return null;
+}
+```
+
+在 `getDefaultExecutor()` 中，如果从 `beanFactory` 获取线程池失败的话，则会创建 `SimpleAsyncTaskExecutor` 线程池。
+
+该线程池的在每次执行异步任务时，都会创建一个新的线程去执行任务，并不会对线程进行复用，从而导致异步任务执行的开销很大。一旦在 `@Async` 注解标注的方法某一瞬间并发量剧增，应用就会大量创建线程，从而影响服务质量甚至出现服务不可用。
+
+同一时刻如果向 `SimpleAsyncTaskExecutor` 线程池提交 10000 个任务，那么该线程池就会创建 10000 个线程，其的 `execute()` 方法如下：
+
+```JAVA
+// SimpleAsyncTaskExecutor：execute() 内部会调用 doExecute()
+protected void doExecute(Runnable task) {
+ // 创建新线程
+ Thread thread = (this.threadFactory != null ? this.threadFactory.newThread(task) : createThread(task));
+ thread.start();
+}
+```
+
+**建议：在使用 `@Async` 时需要自己指定线程池，避免 Spring 默认线程池带来的风险。**
+
+在 `@Async` 注解中的 `value` 指定了线程池的限定符，根据限定符可以获取 **自定义的线程池** 。获取限定符的代码如下：
+
+```JAVA
+// AnnotationAsyncExecutionInterceptor
+protected String getExecutorQualifier(Method method) {
+ // 1.从方法上获取 Async 注解。
+ Async async = AnnotatedElementUtils.findMergedAnnotation(method, Async.class);
+ // 2. 如果方法上没有找到 @Async 注解，则尝试从方法所在的类上获取 @Async 注解。
+ if (async == null) {
+ async = AnnotatedElementUtils.findMergedAnnotation(method.getDeclaringClass(), Async.class);
+ }
+ // 3. 如果找到了 @Async 注解，则获取注解的 value 值并返回，作为线程池的限定符。
+ // 如果 "value" 属性值为空字符串，则使用默认的线程池。
+ // 如果没有找到 @Async 注解，则返回 null，同样使用默认的线程池。
+ return (async != null ? async.value() : null);
+}
+```
+
+#### 2、将方法封装为异步任务
+
+在 `invoke()` 方法获取执行器之后，会将方法封装为异步任务，代码如下：
+
+```JAVA
+// 将要执行的方法封装为 Callable 异步任务
+Callable task = () -> {
+ try {
+ // 2.1、执行被拦截的方法 (proceed() 方法是 AOP 中的核心方法，用于执行目标方法)
+ Object result = invocation.proceed();
+
+ // 2.2、如果被拦截方法的返回值是 Future 类型，则需要阻塞等待结果，
+ // 并将 Future 的结果作为异步任务的结果返回。 这是为了处理异步方法嵌套调用的情况。
+ // 例如，一个异步方法内部调用了另一个异步方法，则需要等待内部异步方法执行完成，
+ // 才能返回最终的结果。
+ if (result instanceof Future) {
+ return ((Future) result).get(); // 阻塞等待 Future 的结果
+ }
+ }
+ catch (ExecutionException ex) {
+ // 2.3、处理 ExecutionException 异常。 ExecutionException 是 Future.get() 方法抛出的异常，
+ handleError(ex.getCause(), userDeclaredMethod, invocation.getArguments()); // 处理原始异常
+ }
+ catch (Throwable ex) {
+ // 2.4、处理其他类型的异常。 将异常、被拦截的方法和方法参数作为参数调用 handleError() 方法进行处理。
+ handleError(ex, userDeclaredMethod, invocation.getArguments());
+ }
+ // 2.5、如果方法返回值不是 Future 类型，或者发生异常，则返回 null。
+ return null;
+};
+```
+
+相比于 `Runnable` ，`Callable` 可以返回结果，并且抛出异常。
+
+将 `invocation.proceed()` 的执行（原方法的执行）封装为 `Callable` 异步任务。这里仅仅当 `result` （方法返回值）类型为 `Future` 才返回，如果是其他类型则直接返回 `null` 。
+
+因此使用 `@Async` 注解标注的方法如果使用 `Future` 类型之外的返回值，则无法获取方法的执行结果。
+
+#### 3、提交异步任务
+
+在 `AsyncExecutionInterceptor # invoke()` 中将要执行的方法封装为 Callable 任务之后，就会将任务交给执行器来执行。提交相关的代码如下：
+
+```JAVA
+protected Object doSubmit(Callable task, AsyncTaskExecutor executor, Class returnType) {
+ // 根据方法的返回值类型，选择不同的异步执行方式并返回结果。
+ // 1. 如果方法返回值是 CompletableFuture 类型
+ if (CompletableFuture.class.isAssignableFrom(returnType)) {
+ // 使用 CompletableFuture.supplyAsync() 方法异步执行任务。
+ return CompletableFuture.supplyAsync(() -> {
+ try {
+ return task.call();
+ }
+ catch (Throwable ex) {
+ throw new CompletionException(ex); // 将异常包装为 CompletionException，以便在 future.get() 时抛出
+ }
+ }, executor);
+ }
+ // 2. 如果方法返回值是 ListenableFuture 类型
+ else if (ListenableFuture.class.isAssignableFrom(returnType)) {
+ // 将 AsyncTaskExecutor 强制转换为 AsyncListenableTaskExecutor，
+ // 并调用 submitListenable() 方法提交任务。
+ // AsyncListenableTaskExecutor 是 ListenableFuture 的专用异步执行器，
+ // 它可以返回一个 ListenableFuture 对象，允许添加回调函数来监听任务的完成。
+ return ((AsyncListenableTaskExecutor) executor).submitListenable(task);
+ }
+ // 3. 如果方法返回值是 Future 类型
+ else if (Future.class.isAssignableFrom(returnType)) {
+ // 直接调用 AsyncTaskExecutor 的 submit() 方法提交任务，并返回一个 Future 对象。
+ return executor.submit(task);
+ }
+ // 4. 如果方法返回值是 void 或其他类型
+ else {
+ // 直接调用 AsyncTaskExecutor 的 submit() 方法提交任务。
+ // 由于方法返回值是 void，因此不需要返回任何结果，直接返回 null。
+ executor.submit(task);
+ return null;
+ }
+}
+```
+
+在 `doSubmit()` 方法中，会根据 `@Async` 注解标注方法的返回值不同，来选择不同的任务提交方式，最后任务会由执行器（线程池）执行。
+
+### 总结
+
+
+
+理解 `@Async` 原理的核心在于理解 `@EnableAsync` 注解，该注解开启了异步任务的功能。
+
+主要流程如上图，会通过后置处理器来创建代理对象，之后代理对象中 `@Async` 方法的执行会走到 `Advice` 内部的拦截器中，之后将方法封装为异步任务，并提交线程池进行处理。
+
+## @Async 使用建议
+
+### 自定义线程池
+
+如果没有显式地配置线程池，在 `@Async` 底层会先在 `BeanFactory` 中尝试获取线程池，如果获取不到，则会创建一个 `SimpleAsyncTaskExecutor` 实现。`SimpleAsyncTaskExecutor` 本质上不算是一个真正的线程池，因为它对于每个请求都会启动一个新线程而不重用现有线程，这会带来一些潜在的问题，例如资源消耗过大。
+
+具体线程池获取可以参考这篇文章：[浅析 Spring 中 Async 注解底层异步线程池原理｜得物技术](https://mp.weixin.qq.com/s/FySv5L0bCdrlb5MoSfQtAA)。
+
+一定要显式配置一个线程池，推荐`ThreadPoolTaskExecutor`。并且，还可以根据任务的性质和需求，为不同的异步方法指定不同的线程池。
+
+```java
+@Configuration
+@EnableAsync
+public class AsyncConfig {
+
+ @Bean(name = "executor1")
+ public Executor executor1() {
+ ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
+ executor.setCorePoolSize(3);
+ executor.setMaxPoolSize(5);
+ executor.setQueueCapacity(50);
+ executor.setThreadNamePrefix("AsyncExecutor1-");
+ executor.initialize();
+ return executor;
+ }
+
+ @Bean(name = "executor2")
+ public Executor executor2() {
+ ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
+ executor.setCorePoolSize(2);
+ executor.setMaxPoolSize(4);
+ executor.setQueueCapacity(100);
+ executor.setThreadNamePrefix("AsyncExecutor2-");
+ executor.initialize();
+ return executor;
+ }
+}
+```
+
+`@Async` 注解中指定线程池的 Bean 名称：
+
+```java
+@Service
+public class AsyncService {
+
+ @Async("executor1")
+ public void performTask1() {
+ // 任务1的逻辑
+ System.out.println("Executing Task1 with Executor1");
+ }
+
+ @Async("executor2")
+ public void performTask2() {
+ // 任务2的逻辑
+ System.out.println("Executing Task2 with Executor2");
+ }
+}
+```
+
+### 避免 @Async 注解失效
+
+`@Async` 注解会在以下几个场景失效，需要注意：
+
+**1、同一类中调用异步方法**
+
+如果你在同一个类内部调用一个`@Async`注解的方法，那这个方法将不会异步执行。
+
+```java
+@Service
+public class MyService {
+
+ public void myMethod() {
+ // 直接通过 this 引用调用，绕过了 Spring 的代理机制，异步执行失效
+ asyncMethod();
+ }
+
+ @Async
+ public void asyncMethod() {
+ // 异步执行的逻辑
+ }
+}
+```
+
+这是因为 Spring 的异步机制是通过 **代理** 实现的，而在同一个类内部的方法调用会绕过 Spring 的代理机制，也就是绕过了代理对象，直接通过 this 引用调用的。由于没有经过代理，所有的代理相关的处理（即将任务提交线程池异步执行）都不会发生。
+
+为了避免这个问题，比较推荐的做法是将异步方法移至另一个 Spring Bean 中。
+
+```java
+@Service
+public class AsyncService {
+ @Async
+ public void asyncMethod() {
+ // 异步执行的逻辑
+ }
+}
+
+@Service
+public class MyService {
+ @Autowired
+ private AsyncService asyncService;
+
+ public void myMethod() {
+ asyncService.asyncMethod();
+ }
+}
+```
+
+**2、使用 static 关键字修饰异步方法**
+
+如果`@Async`注解的方法被 `static` 关键字修饰，那这个方法将不会异步执行。
+
+这是因为 Spring 的异步机制是通过代理实现的，由于静态方法不属于实例而是属于类且不参与继承，Spring 的代理机制（无论是基于 JDK 还是 CGLIB）无法拦截静态方法来提供如异步执行这样的增强功能。
+
+篇幅问题，这里没有进一步详细介绍，不了解的代理机制的朋友，可以看看我写的 [Java 代理模式详解](https://javaguide.cn/java/basis/proxy.html)这篇文章。
+
+如果你需要异步执行一个静态方法的逻辑，可以考虑设计一个非静态的包装方法，这个包装方法使用 `@Async` 注解，并在其内部调用静态方法
+
+```java
+@Service
+public class AsyncService {
+
+ @Async
+ public void asyncWrapper() {
+ // 调用静态方法
+ SClass.staticMethod();
+ }
+}
+
+public class SClass {
+ public static void staticMethod() {
+ // 执行一些操作
+ }
+}
+```
+
+**3、忘记开启异步支持**
+
+Spring Boot 默认情况下不启用异步支持，确保在主配置类 `Application` 上添加`@EnableAsync`注解以启用异步功能。
+
+```java
+@SpringBootApplication
+@EnableAsync
+public class Application {
+ public static void main(String[] args) {
+ SpringApplication.run(Application.class, args);
+ }
+}
+```
+
+**4、`@Async` 注解的方法所在的类必须是 Spring Bean**
+
+`@Async` 注解的方法必须位于 Spring 管理的 Bean 中，只有这样，Spring 才能在创建 Bean 时应用代理，代理能够拦截方法调用并实现异步执行的逻辑。如果该方法不在 Spring 管理的 bean 中，Spring 就无法创建必要的代理，`@Async` 注解就不会产生任何效果。
+
+### 返回值类型
+
+建议将 `@Async` 注解方法的返回值类型定义为 `void` 和 `Future` 。
+
+- 如果不需要获取异步方法返回的结果，将返回值类型定义为 `void` 。
+- 如果需要获取异步方法返回的结果，将返回值类型定义为 `Future`（例如`CompletableFuture` 、 `ListenableFuture` ）。
+
+如果将 `@Async` 注解方法的返回值定义为其他类型（如 `Object` 、 `String` 等等），则无法获取方法返回值。
+
+这种设计符合异步编程的基本原则，即调用者不应立即期待一个结果，而是应该能够在未来某个时间点获取结果。如果返回类型是 `Future`，调用者可以使用这个返回的 `Future` 对象来查询任务的状态，取消任务，或者在任务完成时获取结果。
+
+### 处理异步方法中的异常
+
+异步方法中抛出的异常默认不会被调用者捕获。为了管理这些异常，建议使用`CompletableFuture`的异常处理功能，或者配置一个全局的`AsyncUncaughtExceptionHandler`来处理没有正确捕获的异常。
+
+```java
+@Configuration
+@EnableAsync
+public class AsyncConfig implements AsyncConfigurer{
+
+ @Override
+ public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
+ return new CustomAsyncExceptionHandler();
+ }
+
+}
+
+// 自定义异常处理器
+class CustomAsyncExceptionHandler implements AsyncUncaughtExceptionHandler {
+
+ @Override
+ public void handleUncaughtException(Throwable ex, Method method, Object... params) {
+ // 日志记录或其他处理逻辑
+ }
+}
+```
+
+### 未考虑事务管理
+
+`@Async`注解的方法需要事务支持时，务必在该异步方法上独立使用。
+
+```java
+@Service
+public class AsyncTransactionalService {
+
+ @Async
+ // Propagation.REQUIRES_NEW 表示 Spring 在执行异步方法时开启一个新的、与当前事务无关的事务
+ @Transactional(propagation = Propagation.REQUIRES_NEW)
+ public void asyncTransactionalMethod() {
+ // 这里的操作会在新的事务中执行
+ // 执行一些数据库操作
+ }
+}
+```
+
+### 未指定异步方法执行顺序
+
+`@Async`注解的方法执行是非阻塞的，它们可能以任意顺序完成。如果需要按照特定的顺序处理结果，你可以将方法的返回值设定为 `Future` 或 `CompletableFuture` ，通过返回值对象来实现一个方法在另一个方法完成后再执行。
+
+```java
+@Async
+public CompletableFuture fetchDataAsync() {
+ return CompletableFuture.completedFuture("Data");
+}
+
+@Async
+public CompletableFuture processDataAsync(String data) {
+ return CompletableFuture.supplyAsync(() -> "Processed " + data);
+}
+```
+
+`processDataAsync` 方法在 `fetchDataAsync`后执行：
+
+```java
+CompletableFuture dataFuture = asyncService.fetchDataAsync();
+dataFuture.thenCompose(data -> asyncService.processDataAsync(data))
+ .thenAccept(result -> System.out.println(result));
+```
+
+##
diff --git a/docs/system-design/framework/spring/async.md b/docs/system-design/framework/spring/async.md
new file mode 100644
index 00000000000..a27eb61c970
--- /dev/null
+++ b/docs/system-design/framework/spring/async.md
@@ -0,0 +1,721 @@
+---
+title: Async 注解原理分析
+category: 框架
+tag:
+ - Spring
+---
+
+`@Async` 注解由 Spring 框架提供，被该注解标注的类或方法会在 **异步线程** 中执行。这意味着当方法被调用时，调用者将不会等待该方法执行完成，而是可以继续执行后续的代码。
+
+`@Async` 注解的使用非常简单，需要两个步骤：
+
+1. 在启动类上添加注解 `@EnableAsync` ，开启异步任务。
+2. 在需要异步执行的方法或类上添加注解 `@Async` 。
+
+```java
+@SpringBootApplication
+// 开启异步任务
+@EnableAsync
+public class YourApplication {
+
+ public static void main(String[] args) {
+ SpringApplication.run(YourApplication.class, args);
+ }
+}
+
+// 异步服务类
+@Service
+public class MyService {
+
+ // 推荐使用自定义线程池，这里只是演示基本用法
+ @Async
+ public CompletableFuture doSomethingAsync() {
+
+ // 这里会有一些业务耗时操作
+ // ...
+ // 使用 CompletableFuture 可以更方便地处理异步任务的结果，避免阻塞主线程
+ return CompletableFuture.completedFuture("Async Task Completed");
+ }
+
+}
+```
+
+接下来，我们一起来看看 `@Async` 的底层原理。
+
+## @Async 原理分析
+
+`@Async` 可以异步执行任务，本质上是使用 **动态代理** 来实现的。通过 Spring 中的后置处理器 `BeanPostProcessor` 为使用 `@Async` 注解的类创建动态代理，之后 `@Async` 注解方法的调用会被动态代理拦截，在拦截器中将方法的执行封装为异步任务提交给线程池处理。
+
+接下来，我们来详细分析一下。
+
+### 开启异步
+
+使用 `@Async` 之前，需要在启动类上添加 `@EnableAsync` 来开启异步，`@EnableAsync` 注解如下：
+
+```JAVA
+// 省略其他注解 ...
+@Import(AsyncConfigurationSelector.class)
+public @interface EnableAsync { /* ... */ }
+```
+
+在 `@EnableAsync` 注解上通过 `@Import` 注解引入了 `AsyncConfigurationSelector` ，因此 Spring 会去加载通过 `@Import` 注解引入的类。
+
+`AsyncConfigurationSelector` 类实现了 `ImportSelector` 接口，因此在该类中会重写 `selectImports()` 方法来自定义加载 Bean 的逻辑，如下：
+
+```JAVA
+public class AsyncConfigurationSelector extends AdviceModeImportSelector {
+ @Override
+ @Nullable
+ public String[] selectImports(AdviceMode adviceMode) {
+ switch (adviceMode) {
+ // 基于 JDK 代理织入的通知
+ case PROXY:
+ return new String[] {ProxyAsyncConfiguration.class.getName()};
+ // 基于 AspectJ 织入的通知
+ case ASPECTJ:
+ return new String[] {ASYNC_EXECUTION_ASPECT_CONFIGURATION_CLASS_NAME};
+ default:
+ return null;
+ }
+ }
+}
+```
+
+在 `selectImports()` 方法中，会根据通知的不同类型来选择加载不同的类，其中 `adviceMode` 默认值为 `PROXY` 。
+
+这里以基于 JDK 代理的通知为例，此时会加载 `ProxyAsyncConfiguration` 类，如下：
+
+```JAVA
+@Configuration
+@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
+public class ProxyAsyncConfiguration extends AbstractAsyncConfiguration {
+ @Bean(name = TaskManagementConfigUtils.ASYNC_ANNOTATION_PROCESSOR_BEAN_NAME)
+ @Role(BeanDefinition.ROLE_INFRASTRUCTURE)
+ public AsyncAnnotationBeanPostProcessor asyncAdvisor() {
+ // ...
+ // 加载后置处理器
+ AsyncAnnotationBeanPostProcessor bpp = new AsyncAnnotationBeanPostProcessor();
+
+ // ...
+ return bpp;
+ }
+}
+```
+
+### 后置处理器
+
+在 `ProxyAsyncConfiguration` 类中，会通过 `@Bean` 注解加载一个后置处理器 `AsyncAnnotationBeanPostProcessor` ，这个后置处理器是使 `@Async` 注解起作用的关键。
+
+如果某一个类或者方法上使用了 `@Async` 注解，`AsyncAnnotationBeanPostProcessor` 处理器就会为该类创建一个动态代理。
+
+该类的方法在执行时，会被代理对象的拦截器所拦截，其中被 `@Async` 注解标记的方法会异步执行。
+
+`AsyncAnnotationBeanPostProcessor` 代码如下：
+
+```JAVA
+public class AsyncAnnotationBeanPostProcessor extends AbstractBeanFactoryAwareAdvisingPostProcessor {
+ @Override
+ public void setBeanFactory(BeanFactory beanFactory) {
+ super.setBeanFactory(beanFactory);
+ // 创建 AsyncAnnotationAdvisor，它是一个 Advisor
+ // 用于拦截带有 @Async 注解的方法并将这些方法异步执行。
+ AsyncAnnotationAdvisor advisor = new AsyncAnnotationAdvisor(this.executor, this.exceptionHandler);
+ // 如果设置了自定义的 asyncAnnotationType，则将其设置到 advisor 中。
+ // asyncAnnotationType 用于指定自定义的异步注解，例如 @MyAsync。
+ if (this.asyncAnnotationType != null) {
+ advisor.setAsyncAnnotationType(this.asyncAnnotationType);
+ }
+ advisor.setBeanFactory(beanFactory);
+ this.advisor = advisor;
+ }
+}
+```
+
+`AsyncAnnotationBeanPostProcessor` 的父类实现了 `BeanFactoryAware` 接口，因此在该类中重写了 `setBeanFactory()` 方法作为扩展点，来加载 `AsyncAnnotationAdvisor` 。
+
+#### 创建 Advisor
+
+`Advisor` 是 `Spring AOP` 对 `Advice` 和 `Pointcut` 的抽象。`Advice` 为执行的通知逻辑，`Pointcut` 为通知执行的切入点。
+
+在后置处理器 `AsyncAnnotationBeanPostProcessor` 中会去创建 `AsyncAnnotationAdvisor` ， 在它的构造方法中，会构建对应的 `Advice` 和 `Pointcut` ，如下：
+
+```JAVA
+public class AsyncAnnotationAdvisor extends AbstractPointcutAdvisor implements BeanFactoryAware {
+
+ private Advice advice; // 异步执行的 Advice
+ private Pointcut pointcut; // 匹配 @Async 注解方法的切点
+
+ // 构造函数
+ public AsyncAnnotationAdvisor(/* 参数省略 */) {
+ // 1. 创建 Advice，负责异步执行逻辑
+ this.advice = buildAdvice(executor, exceptionHandler);
+ // 2. 创建 Pointcut，选择要被增强的目标方法
+ this.pointcut = buildPointcut(asyncAnnotationTypes);
+ }
+
+ // 创建 Advice
+ protected Advice buildAdvice(/* 参数省略 */) {
+ // 创建处理异步执行的拦截器
+ AnnotationAsyncExecutionInterceptor interceptor = new AnnotationAsyncExecutionInterceptor(null);
+ // 使用执行器和异常处理器配置拦截器
+ interceptor.configure(executor, exceptionHandler);
+ return interceptor;
+ }
+
+ // 创建 Pointcut
+ protected Pointcut buildPointcut(Set> asyncAnnotationTypes) {
+ ComposablePointcut result = null;
+ for (Class asyncAnnotationType : asyncAnnotationTypes) {
+ // 1. 类级别切点：如果类上有注解则匹配
+ Pointcut cpc = new AnnotationMatchingPointcut(asyncAnnotationType, true);
+ // 2. 方法级别切点：如果方法上有注解则匹配
+ Pointcut mpc = new AnnotationMatchingPointcut(null, asyncAnnotationType, true);
+
+ if (result == null) {
+ result = new ComposablePointcut(cpc);
+ } else {
+ // 使用 union 合并之前的切点
+ result.union(cpc);
+ }
+ // 将方法级别切点添加到组合切点
+ result = result.union(mpc);
+ }
+ // 返回组合切点，如果没有提供注解类型则返回 Pointcut.TRUE
+ return (result != null ? result : Pointcut.TRUE);
+ }
+}
+```
+
+`AsyncAnnotationAdvisor` 的核心在于构建 `Advice` 和 `Pointcut` ：
+
+- 构建 `Advice` ：会创建 `AnnotationAsyncExecutionInterceptor` 拦截器，在拦截器的 `invoke()` 方法中会执行通知的逻辑。
+- 构建 `Pointcut` ：由 `ClassFilter` 和 `MethodMatcher` 组成，用于匹配哪些方法需要执行通知（ `Advice` ）的逻辑。
+
+#### 后置处理逻辑
+
+`AsyncAnnotationBeanPostProcessor` 后置处理器中实现的 `postProcessAfterInitialization()` 方法在其父类 `AbstractAdvisingBeanPostProcessor` 中，在 `Bean` 初始化之后，会进入到 `postProcessAfterInitialization()` 方法进行后置处理。
+
+在后置处理方法中，会判断 `Bean` 是否符合后置处理器中 `Advisor` 通知的条件，如果符合，则创建代理对象。如下：
+
+```JAVA
+// AbstractAdvisingBeanPostProcessor
+public Object postProcessAfterInitialization(Object bean, String beanName) {
+ if (this.advisor == null || bean instanceof AopInfrastructureBean) {
+ return bean;
+ }
+ if (bean instanceof Advised) {
+ Advised advised = (Advised) bean;
+ if (!advised.isFrozen() && isEligible(AopUtils.getTargetClass(bean))) {
+ if (this.beforeExistingAdvisors) {
+ advised.addAdvisor(0, this.advisor);
+ }
+ else {
+ advised.addAdvisor(this.advisor);
+ }
+ return bean;
+ }
+ }
+ // 判断给定的 Bean 是否符合后置处理器中 Advisor 通知的条件，符合的话，就创建代理对象。
+ if (isEligible(bean, beanName)) {
+ ProxyFactory proxyFactory = prepareProxyFactory(bean, beanName);
+ if (!proxyFactory.isProxyTargetClass()) {
+ evaluateProxyInterfaces(bean.getClass(), proxyFactory);
+ }
+ // 添加 Advisor。
+ proxyFactory.addAdvisor(this.advisor);
+ customizeProxyFactory(proxyFactory);
+ // 返回代理对象。
+ return proxyFactory.getProxy(getProxyClassLoader());
+ }
+ return bean;
+}
+```
+
+### @Async 注解方法的拦截
+
+`@Async` 注解方法的执行会在 `AnnotationAsyncExecutionInterceptor` 中被拦截，在 `invoke()` 方法中执行拦截器的逻辑。此时会将 `@Async` 注解标注的方法封装为异步任务，交给执行器来执行。
+
+`invoke()` 方法在 `AnnotationAsyncExecutionInterceptor` 的父类 `AsyncExecutionInterceptor` 中定义，如下：
+
+```JAVA
+public class AsyncExecutionInterceptor extends AsyncExecutionAspectSupport implements MethodInterceptor, Ordered {
+ @Override
+ @Nullable
+ public Object invoke(final MethodInvocation invocation) throws Throwable {
+ Class targetClass = (invocation.getThis() != null ? AopUtils.getTargetClass(invocation.getThis()) : null);
+ Method specificMethod = ClassUtils.getMostSpecificMethod(invocation.getMethod(), targetClass);
+ final Method userDeclaredMethod = BridgeMethodResolver.findBridgedMethod(specificMethod);
+
+ // 1、确定异步任务执行器
+ AsyncTaskExecutor executor = determineAsyncExecutor(userDeclaredMethod);
+
+ // 2、将要执行的方法封装为 Callable 异步任务
+ Callable task = () -> {
+ try {
+ // 2.1、执行方法
+ Object result = invocation.proceed();
+ // 2.2、如果方法返回值是 Future 类型，阻塞等待结果
+ if (result instanceof Future) {
+ return ((Future) result).get();
+ }
+ }
+ catch (ExecutionException ex) {
+ handleError(ex.getCause(), userDeclaredMethod, invocation.getArguments());
+ }
+ catch (Throwable ex) {
+ handleError(ex, userDeclaredMethod, invocation.getArguments());
+ }
+ return null;
+ };
+ // 3、提交任务
+ return doSubmit(task, executor, invocation.getMethod().getReturnType());
+ }
+}
+```
+
+在 `invoke()` 方法中，主要有 3 个步骤：
+
+1. 确定执行异步任务的执行器。
+2. 将 `@Async` 注解标注的方法封装为 `Callable` 异步任务。
+3. 将任务提交给执行器执行。
+
+#### 1、获取异步任务执行器
+
+在 `determineAsyncExecutor()` 方法中，会获取异步任务的执行器（即执行异步任务的 **线程池** ）。代码如下：
+
+```JAVA
+// 确定异步任务的执行器
+protected AsyncTaskExecutor determineAsyncExecutor(Method method) {
+ // 1、先从缓存中获取。
+ AsyncTaskExecutor executor = this.executors.get(method);
+ if (executor == null) {
+ Executor targetExecutor;
+ // 2、获取执行器的限定符。
+ String qualifier = getExecutorQualifier(method);
+ if (StringUtils.hasLength(qualifier)) {
+ // 3、根据限定符获取对应的执行器。
+ targetExecutor = findQualifiedExecutor(this.beanFactory, qualifier);
+ }
+ else {
+ // 4、如果没有限定符，则使用默认的执行器。即 Spring 提供的默认线程池：SimpleAsyncTaskExecutor。
+ targetExecutor = this.defaultExecutor.get();
+ }
+ if (targetExecutor == null) {
+ return null;
+ }
+ // 5、将执行器包装为 TaskExecutorAdapter 适配器。
+ // TaskExecutorAdapter 是 Spring 对于 JDK 线程池做的一层抽象，还是继承自 JDK 的线程池 Executor。这里可以不用管太多，只要知道它是线程池就可以了。
+ executor = (targetExecutor instanceof AsyncListenableTaskExecutor ?
+ (AsyncListenableTaskExecutor) targetExecutor : new TaskExecutorAdapter(targetExecutor));
+ this.executors.put(method, executor);
+ }
+ return executor;
+}
+```
+
+在 `determineAsyncExecutor()` 方法中确定了异步任务的执行器（线程池），主要是通过 `@Async` 注解的 `value` 值来获取执行器的限定符，根据限定符再去 `BeanFactory` 中查找对应的执行器就可以了。
+
+如果在 `@Async` 注解中没有指定线程池，则会通过 `this.defaultExecutor.get()` 来获取默认的线程池，其中 `defaultExecutor` 在下边方法中进行赋值：
+
+```JAVA
+// AsyncExecutionInterceptor
+protected Executor getDefaultExecutor(@Nullable BeanFactory beanFactory) {
+ // 1、尝试从 beanFactory 中获取线程池。
+ Executor defaultExecutor = super.getDefaultExecutor(beanFactory);
+ // 2、如果 beanFactory 中没有，则创建 SimpleAsyncTaskExecutor 线程池。
+ return (defaultExecutor != null ? defaultExecutor : new SimpleAsyncTaskExecutor());
+}
+```
+
+其中 `super.getDefaultExecutor()` 会在 `beanFactory` 中尝试获取 `Executor` 类型的线程池。代码如下：
+
+```JAVA
+protected Executor getDefaultExecutor(@Nullable BeanFactory beanFactory) {
+ if (beanFactory != null) {
+ try {
+ // 1、从 beanFactory 中获取 TaskExecutor 类型的线程池。
+ return beanFactory.getBean(TaskExecutor.class);
+ }
+ catch (NoUniqueBeanDefinitionException ex) {
+ try {
+ // 2、如果有多个，则尝试从 beanFactory 中获取执行名称的 Executor 线程池。
+ return beanFactory.getBean(DEFAULT_TASK_EXECUTOR_BEAN_NAME, Executor.class);
+ }
+ catch (NoSuchBeanDefinitionException ex2) {
+ if (logger.isInfoEnabled()) {
+ // ...
+ }
+ }
+ }
+ catch (NoSuchBeanDefinitionException ex) {
+ try {
+ // 3、如果没有，则尝试从 beanFactory 中获取执行名称的 Executor 线程池。
+ return beanFactory.getBean(DEFAULT_TASK_EXECUTOR_BEAN_NAME, Executor.class);
+ }
+ catch (NoSuchBeanDefinitionException ex2) {
+ // ...
+ }
+ }
+ }
+ return null;
+}
+```
+
+在 `getDefaultExecutor()` 中，如果从 `beanFactory` 获取线程池失败的话，则会创建 `SimpleAsyncTaskExecutor` 线程池。
+
+该线程池的在每次执行异步任务时，都会创建一个新的线程去执行任务，并不会对线程进行复用，从而导致异步任务执行的开销很大。一旦在 `@Async` 注解标注的方法某一瞬间并发量剧增，应用就会大量创建线程，从而影响服务质量甚至出现服务不可用。
+
+同一时刻如果向 `SimpleAsyncTaskExecutor` 线程池提交 10000 个任务，那么该线程池就会创建 10000 个线程，其的 `execute()` 方法如下：
+
+```JAVA
+// SimpleAsyncTaskExecutor：execute() 内部会调用 doExecute()
+protected void doExecute(Runnable task) {
+ // 创建新线程
+ Thread thread = (this.threadFactory != null ? this.threadFactory.newThread(task) : createThread(task));
+ thread.start();
+}
+```
+
+**建议：在使用 `@Async` 时需要自己指定线程池，避免 Spring 默认线程池带来的风险。**
+
+在 `@Async` 注解中的 `value` 指定了线程池的限定符，根据限定符可以获取 **自定义的线程池** 。获取限定符的代码如下：
+
+```JAVA
+// AnnotationAsyncExecutionInterceptor
+protected String getExecutorQualifier(Method method) {
+ // 1.从方法上获取 Async 注解。
+ Async async = AnnotatedElementUtils.findMergedAnnotation(method, Async.class);
+ // 2. 如果方法上没有找到 @Async 注解，则尝试从方法所在的类上获取 @Async 注解。
+ if (async == null) {
+ async = AnnotatedElementUtils.findMergedAnnotation(method.getDeclaringClass(), Async.class);
+ }
+ // 3. 如果找到了 @Async 注解，则获取注解的 value 值并返回，作为线程池的限定符。
+ // 如果 "value" 属性值为空字符串，则使用默认的线程池。
+ // 如果没有找到 @Async 注解，则返回 null，同样使用默认的线程池。
+ return (async != null ? async.value() : null);
+}
+```
+
+#### 2、将方法封装为异步任务
+
+在 `invoke()` 方法获取执行器之后，会将方法封装为异步任务，代码如下：
+
+```JAVA
+// 将要执行的方法封装为 Callable 异步任务
+Callable task = () -> {
+ try {
+ // 2.1、执行被拦截的方法 (proceed() 方法是 AOP 中的核心方法，用于执行目标方法)
+ Object result = invocation.proceed();
+
+ // 2.2、如果被拦截方法的返回值是 Future 类型，则需要阻塞等待结果，
+ // 并将 Future 的结果作为异步任务的结果返回。 这是为了处理异步方法嵌套调用的情况。
+ // 例如，一个异步方法内部调用了另一个异步方法，则需要等待内部异步方法执行完成，
+ // 才能返回最终的结果。
+ if (result instanceof Future) {
+ return ((Future) result).get(); // 阻塞等待 Future 的结果
+ }
+ }
+ catch (ExecutionException ex) {
+ // 2.3、处理 ExecutionException 异常。 ExecutionException 是 Future.get() 方法抛出的异常，
+ handleError(ex.getCause(), userDeclaredMethod, invocation.getArguments()); // 处理原始异常
+ }
+ catch (Throwable ex) {
+ // 2.4、处理其他类型的异常。 将异常、被拦截的方法和方法参数作为参数调用 handleError() 方法进行处理。
+ handleError(ex, userDeclaredMethod, invocation.getArguments());
+ }
+ // 2.5、如果方法返回值不是 Future 类型，或者发生异常，则返回 null。
+ return null;
+};
+```
+
+相比于 `Runnable` ，`Callable` 可以返回结果，并且抛出异常。
+
+将 `invocation.proceed()` 的执行（原方法的执行）封装为 `Callable` 异步任务。这里仅仅当 `result` （方法返回值）类型为 `Future` 才返回，如果是其他类型则直接返回 `null` 。
+
+因此使用 `@Async` 注解标注的方法如果使用 `Future` 类型之外的返回值，则无法获取方法的执行结果。
+
+#### 3、提交异步任务
+
+在 `AsyncExecutionInterceptor # invoke()` 中将要执行的方法封装为 Callable 任务之后，就会将任务交给执行器来执行。提交相关的代码如下：
+
+```JAVA
+protected Object doSubmit(Callable task, AsyncTaskExecutor executor, Class returnType) {
+ // 根据方法的返回值类型，选择不同的异步执行方式并返回结果。
+ // 1. 如果方法返回值是 CompletableFuture 类型
+ if (CompletableFuture.class.isAssignableFrom(returnType)) {
+ // 使用 CompletableFuture.supplyAsync() 方法异步执行任务。
+ return CompletableFuture.supplyAsync(() -> {
+ try {
+ return task.call();
+ }
+ catch (Throwable ex) {
+ throw new CompletionException(ex); // 将异常包装为 CompletionException，以便在 future.get() 时抛出
+ }
+ }, executor);
+ }
+ // 2. 如果方法返回值是 ListenableFuture 类型
+ else if (ListenableFuture.class.isAssignableFrom(returnType)) {
+ // 将 AsyncTaskExecutor 强制转换为 AsyncListenableTaskExecutor，
+ // 并调用 submitListenable() 方法提交任务。
+ // AsyncListenableTaskExecutor 是 ListenableFuture 的专用异步执行器，
+ // 它可以返回一个 ListenableFuture 对象，允许添加回调函数来监听任务的完成。
+ return ((AsyncListenableTaskExecutor) executor).submitListenable(task);
+ }
+ // 3. 如果方法返回值是 Future 类型
+ else if (Future.class.isAssignableFrom(returnType)) {
+ // 直接调用 AsyncTaskExecutor 的 submit() 方法提交任务，并返回一个 Future 对象。
+ return executor.submit(task);
+ }
+ // 4. 如果方法返回值是 void 或其他类型
+ else {
+ // 直接调用 AsyncTaskExecutor 的 submit() 方法提交任务。
+ // 由于方法返回值是 void，因此不需要返回任何结果，直接返回 null。
+ executor.submit(task);
+ return null;
+ }
+}
+```
+
+在 `doSubmit()` 方法中，会根据 `@Async` 注解标注方法的返回值不同，来选择不同的任务提交方式，最后任务会由执行器（线程池）执行。
+
+### 总结
+
+
+
+理解 `@Async` 原理的核心在于理解 `@EnableAsync` 注解，该注解开启了异步任务的功能。
+
+主要流程如上图，会通过后置处理器来创建代理对象，之后代理对象中 `@Async` 方法的执行会走到 `Advice` 内部的拦截器中，之后将方法封装为异步任务，并提交线程池进行处理。
+
+## @Async 使用建议
+
+### 自定义线程池
+
+如果没有显式地配置线程池，在 `@Async` 底层会先在 `BeanFactory` 中尝试获取线程池，如果获取不到，则会创建一个 `SimpleAsyncTaskExecutor` 实现。`SimpleAsyncTaskExecutor` 本质上不算是一个真正的线程池，因为它对于每个请求都会启动一个新线程而不重用现有线程，这会带来一些潜在的问题，例如资源消耗过大。
+
+具体线程池获取可以参考这篇文章：[浅析 Spring 中 Async 注解底层异步线程池原理｜得物技术](https://mp.weixin.qq.com/s/FySv5L0bCdrlb5MoSfQtAA)。
+
+一定要显式配置一个线程池，推荐`ThreadPoolTaskExecutor`。并且，还可以根据任务的性质和需求，为不同的异步方法指定不同的线程池。
+
+```java
+@Configuration
+@EnableAsync
+public class AsyncConfig {
+
+ @Bean(name = "executor1")
+ public Executor executor1() {
+ ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
+ executor.setCorePoolSize(3);
+ executor.setMaxPoolSize(5);
+ executor.setQueueCapacity(50);
+ executor.setThreadNamePrefix("AsyncExecutor1-");
+ executor.initialize();
+ return executor;
+ }
+
+ @Bean(name = "executor2")
+ public Executor executor2() {
+ ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
+ executor.setCorePoolSize(2);
+ executor.setMaxPoolSize(4);
+ executor.setQueueCapacity(100);
+ executor.setThreadNamePrefix("AsyncExecutor2-");
+ executor.initialize();
+ return executor;
+ }
+}
+```
+
+`@Async` 注解中指定线程池的 Bean 名称：
+
+```java
+@Service
+public class AsyncService {
+
+ @Async("executor1")
+ public void performTask1() {
+ // 任务1的逻辑
+ System.out.println("Executing Task1 with Executor1");
+ }
+
+ @Async("executor2")
+ public void performTask2() {
+ // 任务2的逻辑
+ System.out.println("Executing Task2 with Executor2");
+ }
+}
+```
+
+### 避免 @Async 注解失效
+
+`@Async` 注解会在以下几个场景失效，需要注意：
+
+**1、同一类中调用异步方法**
+
+如果你在同一个类内部调用一个`@Async`注解的方法，那这个方法将不会异步执行。
+
+```java
+@Service
+public class MyService {
+
+ public void myMethod() {
+ // 直接通过 this 引用调用，绕过了 Spring 的代理机制，异步执行失效
+ asyncMethod();
+ }
+
+ @Async
+ public void asyncMethod() {
+ // 异步执行的逻辑
+ }
+}
+```
+
+这是因为 Spring 的异步机制是通过 **代理** 实现的，而在同一个类内部的方法调用会绕过 Spring 的代理机制，也就是绕过了代理对象，直接通过 this 引用调用的。由于没有经过代理，所有的代理相关的处理（即将任务提交线程池异步执行）都不会发生。
+
+为了避免这个问题，比较推荐的做法是将异步方法移至另一个 Spring Bean 中。
+
+```java
+@Service
+public class AsyncService {
+ @Async
+ public void asyncMethod() {
+ // 异步执行的逻辑
+ }
+}
+
+@Service
+public class MyService {
+ @Autowired
+ private AsyncService asyncService;
+
+ public void myMethod() {
+ asyncService.asyncMethod();
+ }
+}
+```
+
+**2、使用 static 关键字修饰异步方法**
+
+如果`@Async`注解的方法被 `static` 关键字修饰，那这个方法将不会异步执行。
+
+这是因为 Spring 的异步机制是通过代理实现的，由于静态方法不属于实例而是属于类且不参与继承，Spring 的代理机制（无论是基于 JDK 还是 CGLIB）无法拦截静态方法来提供如异步执行这样的增强功能。
+
+篇幅问题，这里没有进一步详细介绍，不了解的代理机制的朋友，可以看看我写的 [Java 代理模式详解](https://javaguide.cn/java/basis/proxy.html)这篇文章。
+
+如果你需要异步执行一个静态方法的逻辑，可以考虑设计一个非静态的包装方法，这个包装方法使用 `@Async` 注解，并在其内部调用静态方法
+
+```java
+@Service
+public class AsyncService {
+
+ @Async
+ public void asyncWrapper() {
+ // 调用静态方法
+ SClass.staticMethod();
+ }
+}
+
+public class SClass {
+ public static void staticMethod() {
+ // 执行一些操作
+ }
+}
+```
+
+**3、忘记开启异步支持**
+
+Spring Boot 默认情况下不启用异步支持，确保在主配置类 `Application` 上添加`@EnableAsync`注解以启用异步功能。
+
+```java
+@SpringBootApplication
+@EnableAsync
+public class Application {
+ public static void main(String[] args) {
+ SpringApplication.run(Application.class, args);
+ }
+}
+```
+
+**4、`@Async` 注解的方法所在的类必须是 Spring Bean**
+
+`@Async` 注解的方法必须位于 Spring 管理的 Bean 中，只有这样，Spring 才能在创建 Bean 时应用代理，代理能够拦截方法调用并实现异步执行的逻辑。如果该方法不在 Spring 管理的 bean 中，Spring 就无法创建必要的代理，`@Async` 注解就不会产生任何效果。
+
+### 返回值类型
+
+建议将 `@Async` 注解方法的返回值类型定义为 `void` 和 `Future` 。
+
+- 如果不需要获取异步方法返回的结果，将返回值类型定义为 `void` 。
+- 如果需要获取异步方法返回的结果，将返回值类型定义为 `Future`（例如`CompletableFuture` 、 `ListenableFuture` ）。
+
+如果将 `@Async` 注解方法的返回值定义为其他类型（如 `Object` 、 `String` 等等），则无法获取方法返回值。
+
+这种设计符合异步编程的基本原则，即调用者不应立即期待一个结果，而是应该能够在未来某个时间点获取结果。如果返回类型是 `Future`，调用者可以使用这个返回的 `Future` 对象来查询任务的状态，取消任务，或者在任务完成时获取结果。
+
+### 处理异步方法中的异常
+
+异步方法中抛出的异常默认不会被调用者捕获。为了管理这些异常，建议使用`CompletableFuture`的异常处理功能，或者配置一个全局的`AsyncUncaughtExceptionHandler`来处理没有正确捕获的异常。
+
+```java
+@Configuration
+@EnableAsync
+public class AsyncConfig implements AsyncConfigurer{
+
+ @Override
+ public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
+ return new CustomAsyncExceptionHandler();
+ }
+
+}
+
+// 自定义异常处理器
+class CustomAsyncExceptionHandler implements AsyncUncaughtExceptionHandler {
+
+ @Override
+ public void handleUncaughtException(Throwable ex, Method method, Object... params) {
+ // 日志记录或其他处理逻辑
+ }
+}
+```
+
+### 未考虑事务管理
+
+`@Async`注解的方法需要事务支持时，务必在该异步方法上独立使用。
+
+```java
+@Service
+public class AsyncTransactionalService {
+
+ @Async
+ // Propagation.REQUIRES_NEW 表示 Spring 在执行异步方法时开启一个新的、与当前事务无关的事务
+ @Transactional(propagation = Propagation.REQUIRES_NEW)
+ public void asyncTransactionalMethod() {
+ // 这里的操作会在新的事务中执行
+ // 执行一些数据库操作
+ }
+}
+```
+
+### 未指定异步方法执行顺序
+
+`@Async`注解的方法执行是非阻塞的，它们可能以任意顺序完成。如果需要按照特定的顺序处理结果，你可以将方法的返回值设定为 `Future` 或 `CompletableFuture` ，通过返回值对象来实现一个方法在另一个方法完成后再执行。
+
+```java
+@Async
+public CompletableFuture fetchDataAsync() {
+ return CompletableFuture.completedFuture("Data");
+}
+
+@Async
+public CompletableFuture processDataAsync(String data) {
+ return CompletableFuture.supplyAsync(() -> "Processed " + data);
+}
+```
+
+`processDataAsync` 方法在 `fetchDataAsync`后执行：
+
+```java
+CompletableFuture dataFuture = asyncService.fetchDataAsync();
+dataFuture.thenCompose(data -> asyncService.processDataAsync(data))
+ .thenAccept(result -> System.out.println(result));
+```
+
+##
diff --git a/docs/system-design/framework/spring/images/async/async.png b/docs/system-design/framework/spring/images/async/async.png
new file mode 100644
index 00000000000..6b68fd35084
Binary files /dev/null and b/docs/system-design/framework/spring/images/async/async.png differ
diff --git a/docs/system-design/framework/spring/ioc-and-aop.md b/docs/system-design/framework/spring/ioc-and-aop.md
index 8881f464370..e58f40f81af 100644
--- a/docs/system-design/framework/spring/ioc-and-aop.md
+++ b/docs/system-design/framework/spring/ioc-and-aop.md
@@ -36,7 +36,7 @@ IoC （Inversion of Control ）即控制反转/反转控制。它是一种思想
- **控制** ：指的是对象创建（实例化、管理）的权力
- **反转** ：控制权交给外部环境（IoC 容器）
-
+
### IoC 解决了什么问题?
@@ -49,17 +49,15 @@ IoC 的思想就是两方之间不互相依赖，由第三方容器来管理相
在没有使用 IoC 思想的情况下，Service 层想要使用 Dao 层的具体实现的话，需要通过 new 关键字在`UserServiceImpl` 中手动 new 出 `IUserDao` 的具体实现类 `UserDaoImpl`（不能直接 new 接口类）。
-
-
很完美，这种方式也是可以实现的，但是我们想象一下如下场景：
开发过程中突然接到一个新的需求，针对`IUserDao` 接口开发出另一个具体实现类。因为 Server 层依赖了`IUserDao`的具体实现，所以我们需要修改`UserServiceImpl`中 new 的对象。如果只有一个类引用了`IUserDao`的具体实现，可能觉得还好，修改起来也不是很费力气，但是如果有许许多多的地方都引用了`IUserDao`的具体实现的话，一旦需要更换`IUserDao` 的实现方式，那修改起来将会非常的头疼。
-
+
-使用 IoC 的思想，我们将对象的控制权（创建、管理）交有 IoC 容器去管理，我们在使用的时候直接向 IoC 容器 “要” 就可以了
+使用 IoC 的思想，我们将对象的控制权（创建、管理）交由 IoC 容器去管理，我们在使用的时候直接向 IoC 容器 “要” 就可以了
-
+
### IoC 和 DI 有区别吗？
@@ -87,6 +85,8 @@ AOP 的目的是将横切关注点（如日志记录、事务管理、权限控
AOP 之所以叫面向切面编程，是因为它的核心思想就是将横切关注点从核心业务逻辑中分离出来，形成一个个的**切面（Aspect）**。
+
+
这里顺带总结一下 AOP 关键术语（不理解也没关系，可以继续往下看）：
- **横切关注点（cross-cutting concerns）** ：多个类或对象中的公共行为（如日志记录、事务管理、权限控制、接口限流、接口幂等等）。
@@ -94,7 +94,17 @@ AOP 之所以叫面向切面编程，是因为它的核心思想就是将横切
- **连接点（JoinPoint）**：连接点是方法调用或者方法执行时的某个特定时刻（如方法调用、异常抛出等）。
- **通知（Advice）**：通知就是切面在某个连接点要执行的操作。通知有五种类型，分别是前置通知（Before）、后置通知（After）、返回通知（AfterReturning）、异常通知（AfterThrowing）和环绕通知（Around）。前四种通知都是在目标方法的前后执行，而环绕通知可以控制目标方法的执行过程。
- **切点（Pointcut）**：一个切点是一个表达式，它用来匹配哪些连接点需要被切面所增强。切点可以通过注解、正则表达式、逻辑运算等方式来定义。比如 `execution(* com.xyz.service..*(..))`匹配 `com.xyz.service` 包及其子包下的类或接口。
-- **织入（Weaving）**：织入是将切面和目标对象连接起来的过程，也就是将通知应用到切点匹配的连接点上。常见的织入时机有两种，分别是编译期织入（AspectJ）和运行期织入（AspectJ）。
+- **织入（Weaving）**：织入是将切面和目标对象连接起来的过程，也就是将通知应用到切点匹配的连接点上。常见的织入时机有两种，分别是编译期织入（Compile-Time Weaving 如：AspectJ）和运行期织入（Runtime Weaving 如：AspectJ、Spring AOP）。
+
+### AOP 常见的通知类型有哪些？
+
+
+
+- **Before**（前置通知）：目标对象的方法调用之前触发
+- **After** （后置通知）：目标对象的方法调用之后触发
+- **AfterReturning**（返回通知）：目标对象的方法调用完成，在返回结果值之后触发
+- **AfterThrowing**（异常通知）：目标对象的方法运行中抛出 / 触发异常后触发。AfterReturning 和 AfterThrowing 两者互斥。如果方法调用成功无异常，则会有返回值；如果方法抛出了异常，则不会有返回值。
+- **Around** （环绕通知）：编程式控制目标对象的方法调用。环绕通知是所有通知类型中可操作范围最大的一种，因为它可以直接拿到目标对象，以及要执行的方法，所以环绕通知可以任意的在目标对象的方法调用前后搞事，甚至不调用目标对象的方法
### AOP 解决了什么问题？
@@ -200,14 +210,80 @@ public CommonResponse method1() {
AOP 的常见实现方式有动态代理、字节码操作等方式。
-Spring AOP 就是基于动态代理的，如果要代理的对象，实现了某个接口，那么 Spring AOP 会使用 **JDK Proxy**，去创建代理对象，而对于没有实现接口的对象，就无法使用 JDK Proxy 去进行代理了，这时候 Spring AOP 会使用 **Cglib** 生成一个被代理对象的子类来作为代理，如下图所示：
+Spring AOP 就是基于动态代理的，如果要代理的对象，实现了某个接口，那么 Spring AOP 会使用 **JDK Proxy**，去创建代理对象，而对于没有实现接口的对象，就无法使用 JDK Proxy 去进行代理了，这时候 Spring AOP 会使用 CGLIB 生成一个被代理对象的子类来作为代理，如下图所示：
+**Spring Boot 和 Spring 的动态代理的策略是不是也是一样的呢？**其实不一样，很多人都理解错了。
+
+Spring Boot 2.0 之前，默认使用 **JDK 动态代理**。如果目标类没有实现接口，会抛出异常，开发者必须显式配置（`spring.aop.proxy-target-class=true`）使用 **CGLIB 动态代理** 或者注入接口来解决。Spring Boot 1.5.x 自动配置 AOP 代码如下：
+
+```java
+@Configuration
+@ConditionalOnClass({ EnableAspectJAutoProxy.class, Aspect.class, Advice.class })
+@ConditionalOnProperty(prefix = "spring.aop", name = "auto", havingValue = "true", matchIfMissing = true)
+public class AopAutoConfiguration {
+
+ @Configuration
+ @EnableAspectJAutoProxy(proxyTargetClass = false)
+ // 该配置类只有在 spring.aop.proxy-target-class=false 或未显式配置时才会生效。
+ // 也就是说，如果开发者未明确选择代理方式，Spring 会默认加载 JDK 动态代理。
+ @ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "false", matchIfMissing = true)
+ public static class JdkDynamicAutoProxyConfiguration {
+
+ }
+
+ @Configuration
+ @EnableAspectJAutoProxy(proxyTargetClass = true)
+ // 该配置类只有在 spring.aop.proxy-target-class=true 时才会生效。
+ // 即开发者通过属性配置明确指定使用 CGLIB 动态代理时，Spring 会加载这个配置类。
+ @ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true", matchIfMissing = false)
+ public static class CglibAutoProxyConfiguration {
+
+ }
+
+}
+```
+
+Spring Boot 2.0 开始，如果用户什么都不配置的话，默认使用 **CGLIB 动态代理**。如果需要强制使用 JDK 动态代理，可以在配置文件中添加：`spring.aop.proxy-target-class=false`。Spring Boot 2.0 自动配置 AOP 代码如下：
+
+```java
+@Configuration
+@ConditionalOnClass({ EnableAspectJAutoProxy.class, Aspect.class, Advice.class,
+ AnnotatedElement.class })
+@ConditionalOnProperty(prefix = "spring.aop", name = "auto", havingValue = "true", matchIfMissing = true)
+public class AopAutoConfiguration {
+
+ @Configuration
+ @EnableAspectJAutoProxy(proxyTargetClass = false)
+ // 该配置类只有在 spring.aop.proxy-target-class=false 时才会生效。
+ // 即开发者通过属性配置明确指定使用 JDK 动态代理时，Spring 会加载这个配置类。
+ @ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "false", matchIfMissing = false)
+ public static class JdkDynamicAutoProxyConfiguration {
+
+ }
+
+ @Configuration
+ @EnableAspectJAutoProxy(proxyTargetClass = true)
+ // 该配置类只有在 spring.aop.proxy-target-class=true 或未显式配置时才会生效。
+ // 也就是说，如果开发者未明确选择代理方式，Spring 会默认加载 CGLIB 代理。
+ @ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true", matchIfMissing = true)
+ public static class CglibAutoProxyConfiguration {
+
+ }
+
+}
+```
+
当然你也可以使用 **AspectJ** ！Spring AOP 已经集成了 AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。
**Spring AOP 属于运行时增强，而 AspectJ 是编译时增强。** Spring AOP 基于代理(Proxying)，而 AspectJ 基于字节码操作(Bytecode Manipulation)。
-Spring AOP 已经集成了 AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。AspectJ 相比于 Spring AOP 功能更加强大，但是 Spring AOP 相对来说更简单，
+Spring AOP 已经集成了 AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。AspectJ 相比于 Spring AOP 功能更加强大，但是 Spring AOP 相对来说更简单。
如果我们的切面比较少，那么两者性能差异不大。但是，当切面太多的话，最好选择 AspectJ ，它比 Spring AOP 快很多。
+
+## 参考
+
+- AOP in Spring Boot, is it a JDK dynamic proxy or a Cglib dynamic proxy?：
diff --git a/docs/system-design/framework/spring/spring-common-annotations.md b/docs/system-design/framework/spring/spring-common-annotations.md
index 521d7cd4621..e51fb4b9603 100644
--- a/docs/system-design/framework/spring/spring-common-annotations.md
+++ b/docs/system-design/framework/spring/spring-common-annotations.md
@@ -6,21 +6,19 @@ tag:
- Spring
---
-### 0.前言
-
-可以毫不夸张地说，这篇文章介绍的 Spring/SpringBoot 常用注解基本已经涵盖你工作中遇到的大部分常用的场景。对于每一个注解我都说了具体用法，掌握搞懂，使用 SpringBoot 来开发项目基本没啥大问题了！
+可以毫不夸张地说，这篇文章介绍的 Spring/SpringBoot 常用注解基本已经涵盖你工作中遇到的大部分常用的场景。对于每一个注解本文都提供了具体用法，掌握这些内容后，使用 Spring Boot 来开发项目基本没啥大问题了！
**为什么要写这篇文章？**
-最近看到网上有一篇关于 SpringBoot 常用注解的文章被转载的比较多，我看了文章内容之后属实觉得质量有点低，并且有点会误导没有太多实际使用经验的人（这些人又占据了大多数）。所以，自己索性花了大概 两天时间简单总结一下了。
+最近看到网上有一篇关于 Spring Boot 常用注解的文章被广泛转载，但文章内容存在一些误导性，可能对没有太多实际使用经验的开发者不太友好。于是我花了几天时间总结了这篇文章，希望能够帮助大家更好地理解和使用 Spring 注解。
-**因为我个人的能力和精力有限，如果有任何不对或者需要完善的地方，请帮忙指出！Guide 感激不尽！**
+**因为个人能力和精力有限，如果有任何错误或遗漏，欢迎指正！非常感激！**
-### 1. `@SpringBootApplication`
+## Spring Boot 基础注解
-这里先单独拎出`@SpringBootApplication` 注解说一下，虽然我们一般不会主动去使用它。
+`@SpringBootApplication` 是 Spring Boot 应用的核心注解，通常用于标注主启动类。
-_Guide：这个注解是 Spring Boot 项目的基石，创建 SpringBoot 项目之后会默认在主类加上。_
+示例：
```java
@SpringBootApplication
@@ -31,7 +29,13 @@ public class SpringSecurityJwtGuideApplication {
}
```
-我们可以把 `@SpringBootApplication`看作是 `@Configuration`、`@EnableAutoConfiguration`、`@ComponentScan` 注解的集合。
+我们可以把 `@SpringBootApplication`看作是下面三个注解的组合：
+
+- **`@EnableAutoConfiguration`**：启用 Spring Boot 的自动配置机制。
+- **`@ComponentScan`**：扫描 `@Component`、`@Service`、`@Repository`、`@Controller` 等注解的类。
+- **`@Configuration`**：允许注册额外的 Spring Bean 或导入其他配置类。
+
+源码如下：
```java
package org.springframework.boot.autoconfigure;
@@ -58,87 +62,233 @@ public @interface SpringBootConfiguration {
}
```
-根据 SpringBoot 官网，这三个注解的作用分别是：
+## Spring Bean
-- `@EnableAutoConfiguration`：启用 SpringBoot 的自动配置机制
-- `@ComponentScan`：扫描被`@Component` (`@Repository`,`@Service`,`@Controller`)注解的 bean，注解默认会扫描该类所在的包下所有的类。
-- `@Configuration`：允许在 Spring 上下文中注册额外的 bean 或导入其他配置类
+### 依赖注入（Dependency Injection, DI）
-### 2. Spring Bean 相关
-
-#### 2.1. `@Autowired`
-
-自动导入对象到类中，被注入进的类同样要被 Spring 容器管理比如：Service 类注入到 Controller 类中。
+`@Autowired` 用于自动注入依赖项（即其他 Spring Bean）。它可以标注在构造器、字段、Setter 方法或配置方法上，Spring 容器会自动查找匹配类型的 Bean 并将其注入。
```java
@Service
-public class UserService {
- ......
+public class UserServiceImpl implements UserService {
+ // ...
}
@RestController
-@RequestMapping("/users")
public class UserController {
- @Autowired
- private UserService userService;
- ......
+ // 字段注入
+ @Autowired
+ private UserService userService;
+ // ...
}
```
-#### 2.2. `@Component`,`@Repository`,`@Service`, `@Controller`
+当存在多个相同类型的 Bean 时，`@Autowired` 默认按类型注入可能产生歧义。此时，可以与 `@Qualifier` 结合使用，通过指定 Bean 的名称来精确选择需要注入的实例。
-我们一般使用 `@Autowired` 注解让 Spring 容器帮我们自动装配 bean。要想把类标识成可用于 `@Autowired` 注解自动装配的 bean 的类,可以采用以下注解实现：
+```java
+@Repository("userRepositoryA")
+public class UserRepositoryA implements UserRepository { /* ... */ }
-- `@Component`：通用的注解，可标注任意类为 `Spring` 组件。如果一个 Bean 不知道属于哪个层，可以使用`@Component` 注解标注。
-- `@Repository` : 对应持久层即 Dao 层，主要用于数据库相关操作。
-- `@Service` : 对应服务层，主要涉及一些复杂的逻辑，需要用到 Dao 层。
-- `@Controller` : 对应 Spring MVC 控制层，主要用于接受用户请求并调用 Service 层返回数据给前端页面。
+@Repository("userRepositoryB")
+public class UserRepositoryB implements UserRepository { /* ... */ }
-#### 2.3. `@RestController`
+@Service
+public class UserService {
+ @Autowired
+ @Qualifier("userRepositoryA") // 指定注入名为 "userRepositoryA" 的 Bean
+ private UserRepository userRepository;
+ // ...
+}
+```
-`@RestController`注解是`@Controller`和`@ResponseBody`的合集,表示这是个控制器 bean,并且是将函数的返回值直接填入 HTTP 响应体中,是 REST 风格的控制器。
+`@Primary`同样是为了解决同一类型存在多个 Bean 实例的注入问题。在 Bean 定义时（例如使用 `@Bean` 或类注解）添加 `@Primary` 注解，表示该 Bean 是**首选**的注入对象。当进行 `@Autowired` 注入时，如果没有使用 `@Qualifier` 指定名称，Spring 将优先选择带有 `@Primary` 的 Bean。
-_Guide：现在都是前后端分离，说实话我已经很久没有用过`@Controller`。如果你的项目太老了的话，就当我没说。_
+```java
+@Primary // 将 UserRepositoryA 设为首选注入对象
+@Repository("userRepositoryA")
+public class UserRepositoryA implements UserRepository { /* ... */ }
-单独使用 `@Controller` 不加 `@ResponseBody`的话一般是用在要返回一个视图的情况，这种情况属于比较传统的 Spring MVC 的应用，对应于前后端不分离的情况。`@Controller` +`@ResponseBody` 返回 JSON 或 XML 形式数据
+@Repository("userRepositoryB")
+public class UserRepositoryB implements UserRepository { /* ... */ }
-关于`@RestController` 和 `@Controller`的对比，请看这篇文章：[@RestController vs @Controller](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485544&idx=1&sn=3cc95b88979e28fe3bfe539eb421c6d8&chksm=cea247a3f9d5ceb5e324ff4b8697adc3e828ecf71a3468445e70221cce768d1e722085359907&token=1725092312&lang=zh_CN#rd)。
+@Service
+public class UserService {
+ @Autowired // 会自动注入 UserRepositoryA，因为它是 @Primary
+ private UserRepository userRepository;
+ // ...
+}
+```
+
+`@Resource(name="beanName")`是 JSR-250 规范定义的注解，也用于依赖注入。它默认按**名称 (by Name)** 查找 Bean 进行注入，而 `@Autowired`默认按**类型 (by Type)** 。如果未指定 `name` 属性，它会尝试根据字段名或方法名查找，如果找不到，则回退到按类型查找（类似 `@Autowired`）。
+
+`@Resource`只能标注在字段 和 Setter 方法上，不支持构造器注入。
+
+```java
+@Service
+public class UserService {
+ @Resource(name = "userRepositoryA")
+ private UserRepository userRepository;
+ // ...
+}
+```
-#### 2.4. `@Scope`
+### Bean 作用域
-声明 Spring Bean 的作用域，使用方法:
+`@Scope("scopeName")` 定义 Spring Bean 的作用域，即 Bean 实例的生命周期和可见范围。常用的作用域包括：
+
+- **singleton** : IoC 容器中只有唯一的 bean 实例。Spring 中的 bean 默认都是单例的，是对单例设计模式的应用。
+- **prototype** : 每次获取都会创建一个新的 bean 实例。也就是说，连续 `getBean()` 两次，得到的是不同的 Bean 实例。
+- **request** （仅 Web 应用可用）: 每一次 HTTP 请求都会产生一个新的 bean（请求 bean），该 bean 仅在当前 HTTP request 内有效。
+- **session** （仅 Web 应用可用） : 每一次来自新 session 的 HTTP 请求都会产生一个新的 bean（会话 bean），该 bean 仅在当前 HTTP session 内有效。
+- **application/global-session** （仅 Web 应用可用）：每个 Web 应用在启动时创建一个 Bean（应用 Bean），该 bean 仅在当前应用启动时间内有效。
+- **websocket** （仅 Web 应用可用）：每一次 WebSocket 会话产生一个新的 bean。
```java
-@Bean
-@Scope("singleton")
-public Person personSingleton() {
- return new Person();
+@Component
+// 每次获取都会创建新的 PrototypeBean 实例
+@Scope("prototype")
+public class PrototypeBean {
+ // ...
}
```
-**四种常见的 Spring Bean 的作用域：**
+### Bean 注册
+
+Spring 容器需要知道哪些类需要被管理为 Bean。除了使用 `@Bean` 方法显式声明（通常在 `@Configuration` 类中），更常见的方式是使用 Stereotype（构造型） 注解标记类，并配合组件扫描（Component Scanning）机制，让 Spring 自动发现并注册这些类作为 Bean。这些 Bean 后续可以通过 `@Autowired` 等方式注入到其他组件中。
+
+下面是常见的一些注册 Bean 的注解：
+
+- `@Component`：通用的注解，可标注任意类为 `Spring` 组件。如果一个 Bean 不知道属于哪个层，可以使用`@Component` 注解标注。
+- `@Repository` : 对应持久层即 Dao 层，主要用于数据库相关操作。
+- `@Service` : 对应服务层，主要涉及一些复杂的逻辑，需要用到 Dao 层。
+- `@Controller` : 对应 Spring MVC 控制层，主要用于接受用户请求并调用 Service 层返回数据给前端页面。
+- `@RestController`：一个组合注解，等效于 `@Controller` + `@ResponseBody`。它专门用于构建 RESTful Web 服务的控制器。标注了 `@RestController` 的类，其所有处理器方法（handler methods）的返回值都会被自动序列化（通常为 JSON）并写入 HTTP 响应体，而不是被解析为视图名称。
+
+`@Controller` vs `@RestController`：
-- singleton : 唯一 bean 实例，Spring 中的 bean 默认都是单例的。
-- prototype : 每次请求都会创建一个新的 bean 实例。
-- request : 每一次 HTTP 请求都会产生一个新的 bean，该 bean 仅在当前 HTTP request 内有效。
-- session : 每一个 HTTP Session 会产生一个新的 bean，该 bean 仅在当前 HTTP session 内有效。
+- `@Controller`：主要用于传统的 Spring MVC 应用，方法返回值通常是逻辑视图名，需要视图解析器配合渲染页面。如果需要返回数据（如 JSON），则需要在方法上额外添加 `@ResponseBody` 注解。
+- `@RestController`：专为构建返回数据的 RESTful API 设计。类上使用此注解后，所有方法的返回值都会默认被视为响应体内容（相当于每个方法都隐式添加了 `@ResponseBody`），通常用于返回 JSON 或 XML 数据。在现代前后端分离的应用中，`@RestController` 是更常用的选择。
-#### 2.5. `@Configuration`
+关于`@RestController` 和 `@Controller`的对比，请看这篇文章：[@RestController vs @Controller](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485544&idx=1&sn=3cc95b88979e28fe3bfe539eb421c6d8&chksm=cea247a3f9d5ceb5e324ff4b8697adc3e828ecf71a3468445e70221cce768d1e722085359907&token=1725092312&lang=zh_CN#rd)。
+
+## 配置
+
+### 声明配置类
-一般用来声明配置类，可以使用 `@Component`注解替代，不过使用`@Configuration`注解声明配置类更加语义化。
+`@Configuration` 主要用于声明一个类是 Spring 的配置类。虽然也可以用 `@Component` 注解替代，但 `@Configuration` 能够更明确地表达该类的用途（定义 Bean），语义更清晰，也便于 Spring 进行特定的处理（例如，通过 CGLIB 代理确保 `@Bean` 方法的单例行为）。
```java
@Configuration
public class AppConfig {
+
+ // @Bean 注解用于在配置类中声明一个 Bean
@Bean
public TransferService transferService() {
return new TransferServiceImpl();
}
+ // 配置类中可以包含一个或多个 @Bean 方法。
+}
+```
+
+### 读取配置信息
+
+在应用程序开发中，我们经常需要管理一些配置信息，例如数据库连接细节、第三方服务（如阿里云 OSS、短信服务、微信认证）的密钥或地址等。通常，这些信息会**集中存放在配置文件**（如 `application.yml` 或 `application.properties`）中，方便管理和修改。
+
+Spring 提供了多种便捷的方式来读取这些配置信息。假设我们有如下 `application.yml` 文件：
+
+```yaml
+wuhan2020: 2020年初武汉爆发了新型冠状病毒，疫情严重，但是，我相信一切都会过去！武汉加油！中国加油！
+
+my-profile:
+ name: Guide哥
+ email: koushuangbwcx@163.com
+
+library:
+ location: 湖北武汉加油中国加油
+ books:
+ - name: 天才基本法
+ description: 二十二岁的林朝夕在父亲确诊阿尔茨海默病这天，得知自己暗恋多年的校园男神裴之即将出国深造的消息——对方考取的学校，恰是父亲当年为她放弃的那所。
+ - name: 时间的秩序
+ description: 为什么我们记得过去，而非未来？时间“流逝”意味着什么？是我们存在于时间之内，还是时间存在于我们之中？卡洛·罗韦利用诗意的文字，邀请我们思考这一亘古难题——时间的本质。
+ - name: 了不起的我
+ description: 如何养成一个新习惯？如何让心智变得更成熟？如何拥有高质量的关系？ 如何走出人生的艰难时刻？
+```
+
+下面介绍几种常用的读取配置的方式：
+
+1、`@Value("${property.key}")` 注入配置文件（如 `application.properties` 或 `application.yml`）中的单个属性值。它还支持 Spring 表达式语言 (SpEL)，可以实现更复杂的注入逻辑。
+
+```java
+@Value("${wuhan2020}")
+String wuhan2020;
+```
+
+2、`@ConfigurationProperties`可以读取配置信息并与 Bean 绑定，用的更多一些。
+
+```java
+@Component
+@ConfigurationProperties(prefix = "library")
+class LibraryProperties {
+ @NotEmpty
+ private String location;
+ private List books;
+
+ @Setter
+ @Getter
+ @ToString
+ static class Book {
+ String name;
+ String description;
+ }
+ 省略getter/setter
+ ......
+}
+```
+
+你可以像使用普通的 Spring Bean 一样，将其注入到类中使用。
+
+```java
+@Service
+public class LibraryService {
+
+ private final LibraryProperties libraryProperties;
+
+ @Autowired
+ public LibraryService(LibraryProperties libraryProperties) {
+ this.libraryProperties = libraryProperties;
+ }
+
+ public void printLibraryInfo() {
+ System.out.println(libraryProperties);
+ }
+}
+```
+
+### 加载指定的配置文件
+
+`@PropertySource` 注解允许加载自定义的配置文件。适用于需要将部分配置信息独立存储的场景。
+
+```java
+@Component
+@PropertySource("classpath:website.properties")
+
+class WebSite {
+ @Value("${url}")
+ private String url;
+
+ 省略getter/setter
+ ......
}
```
-### 3. 处理常见的 HTTP 请求类型
+**注意**：当使用 `@PropertySource` 时，确保外部文件路径正确，且文件在类路径（classpath）中。
+
+更多内容请查看我的这篇文章：[10 分钟搞定 SpringBoot 如何优雅读取配置文件？](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247486181&idx=2&sn=10db0ae64ef501f96a5b0dbc4bd78786&chksm=cea2452ef9d5cc384678e456427328600971180a77e40c13936b19369672ca3e342c26e92b50&token=816772476&lang=zh_CN#rd) 。
+
+## MVC
+
+### HTTP 请求
**5 种常见的请求类型:**
@@ -148,9 +298,9 @@ public class AppConfig {
- **DELETE**：从服务器删除特定的资源。举个例子：`DELETE /users/12`（删除编号为 12 的学生）
- **PATCH**：更新服务器上的资源（客户端提供更改的属性，可以看做作是部分更新），使用的比较少，这里就不举例子了。
-#### 3.1. GET 请求
+#### GET 请求
-`@GetMapping("users")` 等价于`@RequestMapping(value="/users",method=RequestMethod.GET)`
+`@GetMapping("users")` 等价于`@RequestMapping(value="/users",method=RequestMethod.GET)`。
```java
@GetMapping("/users")
@@ -159,11 +309,11 @@ public ResponseEntity> getAllUsers() {
}
```
-#### 3.2. POST 请求
+#### POST 请求
-`@PostMapping("users")` 等价于`@RequestMapping(value="/users",method=RequestMethod.POST)`
+`@PostMapping("users")` 等价于`@RequestMapping(value="/users",method=RequestMethod.POST)`。
-关于`@RequestBody`注解的使用，在下面的“前后端传值”这块会讲到。
+`@PostMapping` 通常与 `@RequestBody` 配合，用于接收 JSON 数据并映射为 Java 对象。
```java
@PostMapping("/users")
@@ -172,9 +322,9 @@ public ResponseEntity createUser(@Valid @RequestBody UserCreateRequest use
}
```
-#### 3.3. PUT 请求
+#### PUT 请求
-`@PutMapping("/users/{userId}")` 等价于`@RequestMapping(value="/users/{userId}",method=RequestMethod.PUT)`
+`@PutMapping("/users/{userId}")` 等价于`@RequestMapping(value="/users/{userId}",method=RequestMethod.PUT)`。
```java
@PutMapping("/users/{userId}")
@@ -184,7 +334,7 @@ public ResponseEntity updateUser(@PathVariable(value = "userId") Long user
}
```
-#### 3.4. **DELETE 请求**
+#### DELETE 请求
`@DeleteMapping("/users/{userId}")`等价于`@RequestMapping(value="/users/{userId}",method=RequestMethod.DELETE)`
@@ -195,7 +345,7 @@ public ResponseEntity deleteUser(@PathVariable(value = "userId") Long userId){
}
```
-#### 3.5. **PATCH 请求**
+#### PATCH 请求
一般实际项目中，我们都是 PUT 不够用了之后才用 PATCH 请求去更新数据。
@@ -207,32 +357,40 @@ public ResponseEntity deleteUser(@PathVariable(value = "userId") Long userId){
}
```
-### 4. 前后端传值
+### 参数绑定
-**掌握前后端传值的正确姿势，是你开始 CRUD 的第一步！**
+在处理 HTTP 请求时，Spring MVC 提供了多种注解用于绑定请求参数到方法参数中。以下是常见的参数绑定方式：
-#### 4.1. `@PathVariable` 和 `@RequestParam`
+#### 从 URL 路径中提取参数
-`@PathVariable`用于获取路径参数，`@RequestParam`用于获取查询参数。
-
-举个简单的例子：
+`@PathVariable` 用于从 URL 路径中提取参数。例如：
```java
@GetMapping("/klasses/{klassId}/teachers")
-public List getKlassRelatedTeachers(
- @PathVariable("klassId") Long klassId,
- @RequestParam(value = "type", required = false) String type ) {
-...
+public List getTeachersByClass(@PathVariable("klassId") Long klassId) {
+ return teacherService.findTeachersByClass(klassId);
}
```
-如果我们请求的 url 是：`/klasses/123456/teachers?type=web`
+若请求 URL 为 `/klasses/123/teachers`，则 `klassId = 123`。
+
+#### 绑定查询参数
-那么我们服务获取到的数据就是：`klassId=123456,type=web`。
+`@RequestParam` 用于绑定查询参数。例如：
-#### 4.2. `@RequestBody`
+```java
+@GetMapping("/klasses/{klassId}/teachers")
+public List getTeachersByClass(@PathVariable Long klassId,
+ @RequestParam(value = "type", required = false) String type) {
+ return teacherService.findTeachersByClassAndType(klassId, type);
+}
+```
-用于读取 Request 请求（可能是 POST,PUT,DELETE,GET 请求）的 body 部分并且**Content-Type 为 application/json** 格式的数据，接收到数据之后会自动将数据绑定到 Java 对象上去。系统会使用`HttpMessageConverter`或者自定义的`HttpMessageConverter`将请求的 body 中的 json 字符串转换为 java 对象。
+若请求 URL 为 `/klasses/123/teachers?type=web`，则 `klassId = 123`，`type = web`。
+
+#### 绑定请求体中的 JSON 数据
+
+`@RequestBody` 用于读取 Request 请求（可能是 POST,PUT,DELETE,GET 请求）的 body 部分并且**Content-Type 为 application/json** 格式的数据，接收到数据之后会自动将数据绑定到 Java 对象上去。系统会使用`HttpMessageConverter`或者自定义的`HttpMessageConverter`将请求的 body 中的 json 字符串转换为 java 对象。
我用一个简单的例子来给演示一下基本使用！
@@ -272,134 +430,73 @@ public class UserRegisterRequest {
-👉 需要注意的是：**一个请求方法只可以有一个`@RequestBody`，但是可以有多个`@RequestParam`和`@PathVariable`**。 如果你的方法必须要用两个 `@RequestBody`来接受数据的话，大概率是你的数据库设计或者系统设计出问题了！
+**注意**：
-### 5. 读取配置信息
+- 一个方法只能有一个 `@RequestBody` 参数，但可以有多个 `@PathVariable` 和 `@RequestParam`。
+- 如果需要接收多个复杂对象，建议合并成一个单一对象。
-**很多时候我们需要将一些常用的配置信息比如阿里云 oss、发送短信、微信认证的相关配置信息等等放到配置文件中。**
+## 数据校验
-**下面我们来看一下 Spring 为我们提供了哪些方式帮助我们从配置文件中读取这些配置信息。**
+数据校验是保障系统稳定性和安全性的关键环节。即使在用户界面（前端）已经实施了数据校验，**后端服务仍必须对接收到的数据进行再次校验**。这是因为前端校验可以被轻易绕过（例如，通过开发者工具修改请求或使用 Postman、curl 等 HTTP 工具直接调用 API），恶意或错误的数据可能直接发送到后端。因此，后端校验是防止非法数据、维护数据一致性、确保业务逻辑正确执行的最后一道，也是最重要的一道防线。
-我们的数据源`application.yml`内容如下：
+Bean Validation 是一套定义 JavaBean 参数校验标准的规范 (JSR 303, 349, 380)，它提供了一系列注解，可以直接用于 JavaBean 的属性上，从而实现便捷的参数校验。
-```yaml
-wuhan2020: 2020年初武汉爆发了新型冠状病毒，疫情严重，但是，我相信一切都会过去！武汉加油！中国加油！
+- **JSR 303 (Bean Validation 1.0):** 奠定了基础，引入了核心校验注解（如 `@NotNull`、`@Size`、`@Min`、`@Max` 等），定义了如何通过注解的方式对 JavaBean 的属性进行校验，并支持嵌套对象校验和自定义校验器。
+- **JSR 349 (Bean Validation 1.1):** 在 1.0 基础上进行扩展，例如引入了对方法参数和返回值校验的支持、增强了对分组校验（Group Validation）的处理。
+- **JSR 380 (Bean Validation 2.0):** 拥抱 Java 8 的新特性，并进行了一些改进，例如支持 `java.time` 包中的日期和时间类型、引入了一些新的校验注解（如 `@NotEmpty`, `@NotBlank`等）。
-my-profile:
- name: Guide哥
- email: koushuangbwcx@163.com
+Bean Validation 本身只是一套**规范（接口和注解）**，我们需要一个实现了这套规范的**具体框架**来执行校验逻辑。目前，**Hibernate Validator** 是 Bean Validation 规范最权威、使用最广泛的参考实现。
-library:
- location: 湖北武汉加油中国加油
- books:
- - name: 天才基本法
- description: 二十二岁的林朝夕在父亲确诊阿尔茨海默病这天，得知自己暗恋多年的校园男神裴之即将出国深造的消息——对方考取的学校，恰是父亲当年为她放弃的那所。
- - name: 时间的秩序
- description: 为什么我们记得过去，而非未来？时间“流逝”意味着什么？是我们存在于时间之内，还是时间存在于我们之中？卡洛·罗韦利用诗意的文字，邀请我们思考这一亘古难题——时间的本质。
- - name: 了不起的我
- description: 如何养成一个新习惯？如何让心智变得更成熟？如何拥有高质量的关系？ 如何走出人生的艰难时刻？
-```
+- Hibernate Validator 4.x 实现了 Bean Validation 1.0 (JSR 303)。
+- Hibernate Validator 5.x 实现了 Bean Validation 1.1 (JSR 349)。
+- Hibernate Validator 6.x 及更高版本实现了 Bean Validation 2.0 (JSR 380)。
-#### 5.1. `@Value`(常用)
+在 Spring Boot 项目中使用 Bean Validation 非常方便，这得益于 Spring Boot 的自动配置能力。关于依赖引入，需要注意：
-使用 `@Value("${property}")` 读取比较简单的配置信息：
+- 在较早版本的 Spring Boot（通常指 2.3.x 之前）中，`spring-boot-starter-web` 依赖默认包含了 hibernate-validator。因此，只要引入了 Web Starter，就无需额外添加校验相关的依赖。
+- 从 Spring Boot 2.3.x 版本开始，为了更精细化的依赖管理，校验相关的依赖被移出了 spring-boot-starter-web。如果你的项目使用了这些或更新的版本，并且需要 Bean Validation 功能，那么你需要显式地添加 `spring-boot-starter-validation` 依赖：
-```java
-@Value("${wuhan2020}")
-String wuhan2020;
+```xml
+
+ org.springframework.boot
+ spring-boot-starter-validation
+
```
-#### 5.2. `@ConfigurationProperties`(常用)
-
-通过`@ConfigurationProperties`读取配置信息并与 bean 绑定。
-
-```java
-@Component
-@ConfigurationProperties(prefix = "library")
-class LibraryProperties {
- @NotEmpty
- private String location;
- private List books;
-
- @Setter
- @Getter
- @ToString
- static class Book {
- String name;
- String description;
- }
- 省略getter/setter
- ......
-}
-```
-
-你可以像使用普通的 Spring bean 一样，将其注入到类中使用。
-
-#### 5.3. `@PropertySource`（不常用）
-
-`@PropertySource`读取指定 properties 文件
-
-```java
-@Component
-@PropertySource("classpath:website.properties")
-
-class WebSite {
- @Value("${url}")
- private String url;
-
- 省略getter/setter
- ......
-}
-```
-
-更多内容请查看我的这篇文章：[《10 分钟搞定 SpringBoot 如何优雅读取配置文件？》](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247486181&idx=2&sn=10db0ae64ef501f96a5b0dbc4bd78786&chksm=cea2452ef9d5cc384678e456427328600971180a77e40c13936b19369672ca3e342c26e92b50&token=816772476&lang=zh_CN#rd) 。
-
-### 6. 参数校验
-
-**数据的校验的重要性就不用说了，即使在前端对数据进行校验的情况下，我们还是要对传入后端的数据再进行一遍校验，避免用户绕过浏览器直接通过一些 HTTP 工具直接向后端请求一些违法数据。**
-
-**JSR(Java Specification Requests）** 是一套 JavaBean 参数校验的标准，它定义了很多常用的校验注解，我们可以直接将这些注解加在我们 JavaBean 的属性上面，这样就可以在需要校验的时候进行校验了，非常方便！
-
-校验的时候我们实际用的是 **Hibernate Validator** 框架。Hibernate Validator 是 Hibernate 团队最初的数据校验框架，Hibernate Validator 4.x 是 Bean Validation 1.0（JSR 303）的参考实现，Hibernate Validator 5.x 是 Bean Validation 1.1（JSR 349）的参考实现，目前最新版的 Hibernate Validator 6.x 是 Bean Validation 2.0（JSR 380）的参考实现。
+
-SpringBoot 项目的 spring-boot-starter-web 依赖中已经有 hibernate-validator 包，不需要引用相关依赖。如下图所示（通过 idea 插件—Maven Helper 生成）：
+非 SpringBoot 项目需要自行引入相关依赖包，这里不多做讲解，具体可以查看我的这篇文章：[如何在 Spring/Spring Boot 中做参数校验？你需要了解的都在这里！](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485783&idx=1&sn=a407f3b75efa17c643407daa7fb2acd6&chksm=cea2469cf9d5cf8afbcd0a8a1c9cc4294d6805b8e01bee6f76bb2884c5bc15478e91459def49&token=292197051&lang=zh_CN#rd)。
-**注**：更新版本的 spring-boot-starter-web 依赖中不再有 hibernate-validator 包（如 2.3.11.RELEASE），需要自己引入 `spring-boot-starter-validation` 依赖。
+👉 需要注意的是：所有的注解，推荐使用 JSR 注解，即`javax.validation.constraints`，而不是`org.hibernate.validator.constraints`
-
+### 一些常用的字段验证的注解
-非 SpringBoot 项目需要自行引入相关依赖包，这里不多做讲解，具体可以查看我的这篇文章：《[如何在 Spring/Spring Boot 中做参数校验？你需要了解的都在这里！](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485783&idx=1&sn=a407f3b75efa17c643407daa7fb2acd6&chksm=cea2469cf9d5cf8afbcd0a8a1c9cc4294d6805b8e01bee6f76bb2884c5bc15478e91459def49&token=292197051&lang=zh_CN#rd)》。
+Bean Validation 规范及其实现（如 Hibernate Validator）提供了丰富的注解，用于声明式地定义校验规则。以下是一些常用的注解及其说明：
-👉 需要注意的是：**所有的注解，推荐使用 JSR 注解，即`javax.validation.constraints`，而不是`org.hibernate.validator.constraints`**
+- `@NotNull`: 检查被注解的元素（任意类型）不能为 `null`。
+- `@NotEmpty`: 检查被注解的元素（如 `CharSequence`、`Collection`、`Map`、`Array`）不能为 `null` 且其大小/长度不能为 0。注意：对于字符串，`@NotEmpty` 允许包含空白字符的字符串，如 `" "`。
+- `@NotBlank`: 检查被注解的 `CharSequence`（如 `String`）不能为 `null`，并且去除首尾空格后的长度必须大于 0。（即，不能为空白字符串）。
+- `@Null`: 检查被注解的元素必须为 `null`。
+- `@AssertTrue` / `@AssertFalse`: 检查被注解的 `boolean` 或 `Boolean` 类型元素必须为 `true` / `false`。
+- `@Min(value)` / `@Max(value)`: 检查被注解的数字类型（或其字符串表示）的值必须大于等于 / 小于等于指定的 `value`。适用于整数类型（`byte`、`short`、`int`、`long`、`BigInteger` 等）。
+- `@DecimalMin(value)` / `@DecimalMax(value)`: 功能类似 `@Min` / `@Max`，但适用于包含小数的数字类型（`BigDecimal`、`BigInteger`、`CharSequence`、`byte`、`short`、`int`、`long`及其包装类）。 `value` 必须是数字的字符串表示。
+- `@Size(min=, max=)`: 检查被注解的元素（如 `CharSequence`、`Collection`、`Map`、`Array`）的大小/长度必须在指定的 `min` 和 `max` 范围之内（包含边界）。
+- `@Digits(integer=, fraction=)`: 检查被注解的数字类型（或其字符串表示）的值，其整数部分的位数必须 ≤ `integer`，小数部分的位数必须 ≤ `fraction`。
+- `@Pattern(regexp=, flags=)`: 检查被注解的 `CharSequence`（如 `String`）是否匹配指定的正则表达式 (`regexp`)。`flags` 可以指定匹配模式（如不区分大小写）。
+- `@Email`: 检查被注解的 `CharSequence`（如 `String`）是否符合 Email 格式（内置了一个相对宽松的正则表达式）。
+- `@Past` / `@Future`: 检查被注解的日期或时间类型（`java.util.Date`、`java.util.Calendar`、JSR 310 `java.time` 包下的类型）是否在当前时间之前 / 之后。
+- `@PastOrPresent` / `@FutureOrPresent`: 类似 `@Past` / `@Future`，但允许等于当前时间。
+- ......
-#### 6.1. 一些常用的字段验证的注解
+### 验证请求体(RequestBody)
-- `@NotEmpty` 被注释的字符串的不能为 null 也不能为空
-- `@NotBlank` 被注释的字符串非 null，并且必须包含一个非空白字符
-- `@Null` 被注释的元素必须为 null
-- `@NotNull` 被注释的元素必须不为 null
-- `@AssertTrue` 被注释的元素必须为 true
-- `@AssertFalse` 被注释的元素必须为 false
-- `@Pattern(regex=,flag=)`被注释的元素必须符合指定的正则表达式
-- `@Email` 被注释的元素必须是 Email 格式。
-- `@Min(value)`被注释的元素必须是一个数字，其值必须大于等于指定的最小值
-- `@Max(value)`被注释的元素必须是一个数字，其值必须小于等于指定的最大值
-- `@DecimalMin(value)`被注释的元素必须是一个数字，其值必须大于等于指定的最小值
-- `@DecimalMax(value)` 被注释的元素必须是一个数字，其值必须小于等于指定的最大值
-- `@Size(max=, min=)`被注释的元素的大小必须在指定的范围内
-- `@Digits(integer, fraction)`被注释的元素必须是一个数字，其值必须在可接受的范围内
-- `@Past`被注释的元素必须是一个过去的日期
-- `@Future` 被注释的元素必须是一个将来的日期
-- ……
-
-#### 6.2. 验证请求体(RequestBody)
+当 Controller 方法使用 `@RequestBody` 注解来接收请求体并将其绑定到一个对象时，可以在该参数前添加 `@Valid` 注解来触发对该对象的校验。如果验证失败，它将抛出`MethodArgumentNotValidException`。
```java
@Data
@AllArgsConstructor
@NoArgsConstructor
public class Person {
-
@NotNull(message = "classId 不能为空")
private String classId;
@@ -414,17 +511,12 @@ public class Person {
@Email(message = "email 格式不正确")
@NotNull(message = "email 不能为空")
private String email;
-
}
-```
-我们在需要验证的参数上加上了`@Valid`注解，如果验证失败，它将抛出`MethodArgumentNotValidException`。
-```java
@RestController
@RequestMapping("/api")
public class PersonController {
-
@PostMapping("/person")
public ResponseEntity getPerson(@RequestBody @Valid Person person) {
return ResponseEntity.ok().body(person);
@@ -432,26 +524,45 @@ public class PersonController {
}
```
-#### 6.3. 验证请求参数(Path Variables 和 Request Parameters)
+### 验证请求参数(Path Variables 和 Request Parameters)
+
+对于直接映射到方法参数的简单类型数据（如路径变量 `@PathVariable` 或请求参数 `@RequestParam`），校验方式略有不同：
-**一定一定不要忘记在类上加上 `@Validated` 注解了，这个参数可以告诉 Spring 去校验方法参数。**
+1. **在 Controller 类上添加 `@Validated` 注解**：这个注解是 Spring 提供的（非 JSR 标准），它使得 Spring 能够处理方法级别的参数校验注解。**这是必需步骤。**
+2. **将校验注解直接放在方法参数上**：将 `@Min`, `@Max`, `@Size`, `@Pattern` 等校验注解直接应用于对应的 `@PathVariable` 或 `@RequestParam` 参数。
+
+一定一定不要忘记在类上加上 `@Validated` 注解了，这个参数可以告诉 Spring 去校验方法参数。
```java
@RestController
@RequestMapping("/api")
-@Validated
+@Validated // 关键步骤 1: 必须在类上添加 @Validated
public class PersonController {
@GetMapping("/person/{id}")
- public ResponseEntity getPersonByID(@Valid @PathVariable("id") @Max(value = 5,message = "超过 id 的范围了") Integer id) {
+ public ResponseEntity getPersonByID(
+ @PathVariable("id")
+ @Max(value = 5, message = "ID 不能超过 5") // 关键步骤 2: 校验注解直接放在参数上
+ Integer id
+ ) {
+ // 如果传入的 id > 5，Spring 会在进入方法体前抛出 ConstraintViolationException 异常。
+ // 全局异常处理器同样需要处理此异常。
return ResponseEntity.ok().body(id);
}
+
+ @GetMapping("/person")
+ public ResponseEntity findPersonByName(
+ @RequestParam("name")
+ @NotBlank(message = "姓名不能为空") // 同样适用于 @RequestParam
+ @Size(max = 10, message = "姓名长度不能超过 10")
+ String name
+ ) {
+ return ResponseEntity.ok().body("Found person: " + name);
+ }
}
```
-更多关于如何在 Spring 项目中进行参数校验的内容，请看《[如何在 Spring/Spring Boot 中做参数校验？你需要了解的都在这里！](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485783&idx=1&sn=a407f3b75efa17c643407daa7fb2acd6&chksm=cea2469cf9d5cf8afbcd0a8a1c9cc4294d6805b8e01bee6f76bb2884c5bc15478e91459def49&token=292197051&lang=zh_CN#rd)》这篇文章。
-
-### 7. 全局处理 Controller 层异常
+## 全局异常处理
介绍一下我们 Spring 项目必备的全局处理 Controller 层异常。
@@ -482,34 +593,61 @@ public class GlobalExceptionHandler {
1. [SpringBoot 处理异常的几种常见姿势](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485568&idx=2&sn=c5ba880fd0c5d82e39531fa42cb036ac&chksm=cea2474bf9d5ce5dcbc6a5f6580198fdce4bc92ef577579183a729cb5d1430e4994720d59b34&token=2133161636&lang=zh_CN#rd)
2. [使用枚举简单封装一个优雅的 Spring Boot 全局异常处理！](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247486379&idx=2&sn=48c29ae65b3ed874749f0803f0e4d90e&chksm=cea24460f9d5cd769ed53ad7e17c97a7963a89f5350e370be633db0ae8d783c3a3dbd58c70f8&token=1054498516&lang=zh_CN#rd)
-### 8. JPA 相关
+## 事务
+
+在要开启事务的方法上使用`@Transactional`注解即可!
-#### 8.1. 创建表
+```java
+@Transactional(rollbackFor = Exception.class)
+public void save() {
+ ......
+}
-`@Entity`声明一个类对应一个数据库实体。
+```
-`@Table` 设置表名
+我们知道 Exception 分为运行时异常 RuntimeException 和非运行时异常。在`@Transactional`注解中如果不配置`rollbackFor`属性,那么事务只会在遇到`RuntimeException`的时候才会回滚,加上`rollbackFor=Exception.class`,可以让事务在遇到非运行时异常时也回滚。
+
+`@Transactional` 注解一般可以作用在`类`或者`方法`上。
+
+- **作用于类**：当把`@Transactional` 注解放在类上时，表示所有该类的 public 方法都配置相同的事务属性信息。
+- **作用于方法**：当类配置了`@Transactional`，方法也配置了`@Transactional`，方法的事务会覆盖类的事务配置信息。
+
+更多关于 Spring 事务的内容请查看我的这篇文章：[可能是最漂亮的 Spring 事务管理详解](./spring-transaction.md) 。
+
+## JPA
+
+Spring Data JPA 提供了一系列注解和功能，帮助开发者轻松实现 ORM（对象关系映射）。
+
+### 创建表
+
+`@Entity` 用于声明一个类为 JPA 实体类，与数据库中的表映射。`@Table` 指定实体对应的表名。
```java
@Entity
@Table(name = "role")
public class Role {
+
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
+
private String name;
private String description;
- 省略getter/setter......
+
+ // 省略 getter/setter
}
```
-#### 8.2. 创建主键
+### 主键生成策略
-`@Id`：声明一个字段为主键。
+`@Id`声明字段为主键。`@GeneratedValue` 指定主键的生成策略。
-使用`@Id`声明之后，我们还需要定义主键的生成策略。我们可以使用 `@GeneratedValue` 指定主键生成策略。
+JPA 提供了 4 种主键生成策略：
-**1.通过 `@GeneratedValue`直接使用 JPA 内置提供的四种主键生成策略来指定主键生成策略。**
+- **`GenerationType.TABLE`**：通过数据库表生成主键。
+- **`GenerationType.SEQUENCE`**：通过数据库序列生成主键（适用于 Oracle 等数据库）。
+- **`GenerationType.IDENTITY`**：主键自增长（适用于 MySQL 等数据库）。
+- **`GenerationType.AUTO`**：由 JPA 自动选择合适的生成策略（默认策略）。
```java
@Id
@@ -517,51 +655,7 @@ public class Role {
private Long id;
```
-JPA 使用枚举定义了 4 种常见的主键生成策略，如下：
-
-_Guide：枚举替代常量的一种用法_
-
-```java
-public enum GenerationType {
-
- /**
- * 使用一个特定的数据库表格来保存主键
- * 持久化引擎通过关系数据库的一张特定的表格来生成主键,
- */
- TABLE,
-
- /**
- *在某些数据库中,不支持主键自增长,比如Oracle、PostgreSQL其提供了一种叫做"序列(sequence)"的机制生成主键
- */
- SEQUENCE,
-
- /**
- * 主键自增长
- */
- IDENTITY,
-
- /**
- *把主键生成策略交给持久化引擎(persistence engine),
- *持久化引擎会根据数据库在以上三种主键生成 策略中选择其中一种
- */
- AUTO
-}
-
-```
-
-`@GeneratedValue`注解默认使用的策略是`GenerationType.AUTO`
-
-```java
-public @interface GeneratedValue {
-
- GenerationType strategy() default AUTO;
- String generator() default "";
-}
-```
-
-一般使用 MySQL 数据库的话，使用`GenerationType.IDENTITY`策略比较普遍一点（分布式系统的话需要另外考虑使用分布式 ID）。
-
-**2.通过 `@GenericGenerator`声明一个主键策略，然后 `@GeneratedValue`使用这个策略**
+通过 `@GenericGenerator` 声明自定义主键生成策略：
```java
@Id
@@ -578,7 +672,7 @@ private Long id;
private Long id;
```
-jpa 提供的主键生成策略有如下几种：
+JPA 提供的主键生成策略有如下几种：
```java
public class DefaultIdentifierGeneratorFactory
@@ -613,148 +707,112 @@ public class DefaultIdentifierGeneratorFactory
}
```
-#### 8.3. 设置字段类型
-
-`@Column` 声明字段。
+### 字段映射
-**示例：**
+`@Column` 用于指定实体字段与数据库列的映射关系。
-设置属性 userName 对应的数据库字段名为 user_name，长度为 32，非空
+- **`name`**：指定数据库列名。
+- **`nullable`**：指定是否允许为 `null`。
+- **`length`**：设置字段的长度（仅适用于 `String` 类型）。
+- **`columnDefinition`**：指定字段的数据库类型和默认值。
```java
-@Column(name = "user_name", nullable = false, length=32)
+@Column(name = "user_name", nullable = false, length = 32)
private String userName;
-```
-设置字段类型并且加默认值，这个还是挺常用的。
-
-```java
@Column(columnDefinition = "tinyint(1) default 1")
private Boolean enabled;
```
-#### 8.4. 指定不持久化特定字段
+### 忽略字段
-`@Transient`：声明不需要与数据库映射的字段，在保存的时候不需要保存进数据库 。
-
-如果我们想让`secrect` 这个字段不被持久化，可以使用 `@Transient`关键字声明。
+`@Transient` 用于声明不需要持久化的字段。
```java
-@Entity(name="USER")
+@Entity
public class User {
- ......
@Transient
- private String secrect; // not persistent because of @Transient
-
+ private String temporaryField; // 不会映射到数据库表中
}
```
-除了 `@Transient`关键字声明， 还可以采用下面几种方法：
-
-```java
-static String secrect; // not persistent because of static
-final String secrect = "Satish"; // not persistent because of final
-transient String secrect; // not persistent because of transient
-```
+其他不被持久化的字段方式：
-一般使用注解的方式比较多。
+- **`static`**：静态字段不会被持久化。
+- **`final`**：最终字段不会被持久化。
+- **`transient`**：使用 Java 的 `transient` 关键字声明的字段不会被序列化或持久化。
-#### 8.5. 声明大字段
+### 大字段存储
-`@Lob`:声明某个字段为大字段。
+`@Lob` 用于声明大字段（如 `CLOB` 或 `BLOB`）。
```java
@Lob
-private String content;
-```
-
-更详细的声明：
-
-```java
-@Lob
-//指定 Lob 类型数据的获取策略， FetchType.EAGER 表示非延迟加载，而 FetchType.LAZY 表示延迟加载 ；
-@Basic(fetch = FetchType.EAGER)
-//columnDefinition 属性指定数据表对应的 Lob 字段类型
@Column(name = "content", columnDefinition = "LONGTEXT NOT NULL")
private String content;
```
-#### 8.6. 创建枚举类型的字段
+### 枚举类型映射
-可以使用枚举类型的字段，不过枚举字段要用`@Enumerated`注解修饰。
+`@Enumerated` 用于将枚举类型映射为数据库字段。
+
+- **`EnumType.ORDINAL`**：存储枚举的序号（默认）。
+- **`EnumType.STRING`**：存储枚举的名称（推荐）。
```java
public enum Gender {
- MALE("男性"),
- FEMALE("女性");
-
- private String value;
- Gender(String str){
- value=str;
- }
+ MALE,
+ FEMALE
}
-```
-```java
@Entity
-@Table(name = "role")
-public class Role {
- @Id
- @GeneratedValue(strategy = GenerationType.IDENTITY)
- private Long id;
- private String name;
- private String description;
+public class User {
+
@Enumerated(EnumType.STRING)
private Gender gender;
- 省略getter/setter......
}
```
-数据库里面对应存储的是 MALE/FEMALE。
+数据库中存储的值为 `MALE` 或 `FEMALE`。
+
+### 审计功能
-#### 8.7. 增加审计功能
+通过 JPA 的审计功能，可以在实体中自动记录创建时间、更新时间、创建人和更新人等信息。
-只要继承了 `AbstractAuditBase`的类都会默认加上下面四个字段。
+审计基类:
```java
@Data
-@AllArgsConstructor
-@NoArgsConstructor
@MappedSuperclass
-@EntityListeners(value = AuditingEntityListener.class)
+@EntityListeners(AuditingEntityListener.class)
public abstract class AbstractAuditBase {
@CreatedDate
@Column(updatable = false)
- @JsonIgnore
private Instant createdAt;
@LastModifiedDate
- @JsonIgnore
private Instant updatedAt;
@CreatedBy
@Column(updatable = false)
- @JsonIgnore
private String createdBy;
@LastModifiedBy
- @JsonIgnore
private String updatedBy;
}
-
```
-我们对应的审计功能对应地配置类可能是下面这样的（Spring Security 项目）:
+配置审计功能:
```java
-
@Configuration
@EnableJpaAuditing
-public class AuditSecurityConfiguration {
+public class AuditConfig {
+
@Bean
- AuditorAware auditorAware() {
+ public AuditorAware auditorProvider() {
return () -> Optional.ofNullable(SecurityContextHolder.getContext())
.map(SecurityContext::getAuthentication)
.filter(Authentication::isAuthenticated)
@@ -766,101 +824,101 @@ public class AuditSecurityConfiguration {
简单介绍一下上面涉及到的一些注解：
1. `@CreatedDate`: 表示该字段为创建时间字段，在这个实体被 insert 的时候，会设置值
-2. `@CreatedBy` :表示该字段为创建人，在这个实体被 insert 的时候，会设置值
-
- `@LastModifiedDate`、`@LastModifiedBy`同理。
+2. `@CreatedBy` :表示该字段为创建人，在这个实体被 insert 的时候，会设置值 `@LastModifiedDate`、`@LastModifiedBy`同理。
+3. `@EnableJpaAuditing`：开启 JPA 审计功能。
-`@EnableJpaAuditing`：开启 JPA 审计功能。
+### 修改和删除操作
-#### 8.8. 删除/修改数据
-
-`@Modifying` 注解提示 JPA 该操作是修改操作,注意还要配合`@Transactional`注解使用。
+`@Modifying` 注解用于标识修改或删除操作，必须与 `@Transactional` 一起使用。
```java
@Repository
-public interface UserRepository extends JpaRepository {
+public interface UserRepository extends JpaRepository {
@Modifying
- @Transactional(rollbackFor = Exception.class)
+ @Transactional
void deleteByUserName(String userName);
}
```
-#### 8.9. 关联关系
+### 关联关系
-- `@OneToOne` 声明一对一关系
-- `@OneToMany` 声明一对多关系
-- `@ManyToOne` 声明多对一关系
-- `@ManyToMany` 声明多对多关系
+JPA 提供了 4 种关联关系的注解：
-更多关于 Spring Boot JPA 的文章请看我的这篇文章：[一文搞懂如何在 Spring Boot 正确中使用 JPA](https://mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247485689&idx=1&sn=061b32c2222869932be5631fb0bb5260&chksm=cea24732f9d5ce24a356fb3675170e7843addbfcc79ee267cfdb45c83fc7e90babf0f20d22e1&token=292197051&lang=zh_CN#rd) 。
+- **`@OneToOne`**：一对一关系。
+- **`@OneToMany`**：一对多关系。
+- **`@ManyToOne`**：多对一关系。
+- **`@ManyToMany`**：多对多关系。
-### 9. 事务 `@Transactional`
+```java
+@Entity
+public class User {
-在要开启事务的方法上使用`@Transactional`注解即可!
+ @OneToOne
+ private Profile profile;
-```java
-@Transactional(rollbackFor = Exception.class)
-public void save() {
- ......
+ @OneToMany(mappedBy = "user")
+ private List orders;
}
-
```
-我们知道 Exception 分为运行时异常 RuntimeException 和非运行时异常。在`@Transactional`注解中如果不配置`rollbackFor`属性,那么事务只会在遇到`RuntimeException`的时候才会回滚,加上`rollbackFor=Exception.class`,可以让事务在遇到非运行时异常时也回滚。
-
-`@Transactional` 注解一般可以作用在`类`或者`方法`上。
-
-- **作用于类**：当把`@Transactional` 注解放在类上时，表示所有该类的 public 方法都配置相同的事务属性信息。
-- **作用于方法**：当类配置了`@Transactional`，方法也配置了`@Transactional`，方法的事务会覆盖类的事务配置信息。
+## JSON 数据处理
-更多关于 Spring 事务的内容请查看我的这篇文章：[可能是最漂亮的 Spring 事务管理详解](./spring-transaction.md) 。
+在 Web 开发中，经常需要处理 Java 对象与 JSON 格式之间的转换。Spring 通常集成 Jackson 库来完成此任务，以下是一些常用的 Jackson 注解，可以帮助我们定制化 JSON 的序列化（Java 对象转 JSON）和反序列化（JSON 转 Java 对象）过程。
-### 10. json 数据处理
+### 过滤 JSON 字段
-#### 10.1. 过滤 json 数据
+有时我们不希望 Java 对象的某些字段被包含在最终生成的 JSON 中，或者在将 JSON 转换为 Java 对象时不处理某些 JSON 属性。
-**`@JsonIgnoreProperties` 作用在类上用于过滤掉特定字段不返回或者不解析。**
+`@JsonIgnoreProperties` 作用在类上用于过滤掉特定字段不返回或者不解析。
```java
-//生成json时将userRoles属性过滤
+// 在生成 JSON 时忽略 userRoles 属性
+// 如果允许未知属性（即 JSON 中有而类中没有的属性），可以添加 ignoreUnknown = true
@JsonIgnoreProperties({"userRoles"})
public class User {
-
private String userName;
private String fullName;
private String password;
private List userRoles = new ArrayList<>();
+ // getters and setters...
}
```
-**`@JsonIgnore`一般用于类的属性上，作用和上面的`@JsonIgnoreProperties` 一样。**
+`@JsonIgnore`作用于字段或` getter/setter` 方法级别，用于指定在序列化或反序列化时忽略该特定属性。
```java
-
public class User {
-
private String userName;
private String fullName;
private String password;
- //生成json时将userRoles属性过滤
+
+ // 在生成 JSON 时忽略 userRoles 属性
@JsonIgnore
private List userRoles = new ArrayList<>();
+ // getters and setters...
}
```
-#### 10.2. 格式化 json 数据
+`@JsonIgnoreProperties` 更适用于在类定义时明确排除多个字段，或继承场景下的字段排除；`@JsonIgnore` 则更直接地用于标记单个具体字段。
-`@JsonFormat`一般用来格式化 json 数据。
+### 格式化 JSON 数据
+
+`@JsonFormat` 用于指定属性在序列化和反序列化时的格式。常用于日期时间类型的格式化。
比如：
```java
-@JsonFormat(shape=JsonFormat.Shape.STRING, pattern="yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", timezone="GMT")
+// 指定 Date 类型序列化为 ISO 8601 格式字符串，并设置时区为 GMT
+@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", timezone = "GMT")
private Date date;
```
-#### 10.3. 扁平化对象
+### 扁平化 JSON 对象
+
+`@JsonUnwrapped` 注解作用于字段上，用于在序列化时将其嵌套对象的属性“提升”到当前对象的层级，反序列化时执行相反操作。这可以使 JSON 结构更扁平。
+
+假设有 `Account` 类，包含 `Location` 和 `PersonInfo` 两个嵌套对象。
```java
@Getter
@@ -888,7 +946,7 @@ public class Account {
```
-未扁平化之前：
+未扁平化之前的 JSON 结构：
```json
{
@@ -903,7 +961,7 @@ public class Account {
}
```
-使用`@JsonUnwrapped` 扁平对象之后：
+使用`@JsonUnwrapped` 扁平对象：
```java
@Getter
@@ -918,6 +976,8 @@ public class Account {
}
```
+扁平化后的 JSON 结构：
+
```json
{
"provinceName": "湖北",
@@ -927,36 +987,37 @@ public class Account {
}
```
-### 11. 测试相关
+## 测试
-**`@ActiveProfiles`一般作用于测试类上， 用于声明生效的 Spring 配置文件。**
+`@ActiveProfiles`一般作用于测试类上， 用于声明生效的 Spring 配置文件。
```java
-@SpringBootTest(webEnvironment = RANDOM_PORT)
+// 指定在 RANDOM_PORT 上启动应用上下文，并激活 "test" profile
+@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@ActiveProfiles("test")
@Slf4j
public abstract class TestBase {
- ......
+ // Common test setup or abstract methods...
}
```
-**`@Test`声明一个方法为测试方法**
+`@Test` 是 JUnit 框架（通常是 JUnit 5 Jupiter）提供的注解，用于标记一个方法为测试方法。虽然不是 Spring 自身的注解，但它是执行单元测试和集成测试的基础。
-**`@Transactional`被声明的测试方法的数据会回滚，避免污染测试数据。**
+`@Transactional`被声明的测试方法的数据会回滚，避免污染测试数据。
-**`@WithMockUser` Spring Security 提供的，用来模拟一个真实用户，并且可以赋予权限。**
+`@WithMockUser` 是 Spring Security Test 模块提供的注解，用于在测试期间模拟一个已认证的用户。可以方便地指定用户名、密码、角色（authorities）等信息，从而测试受安全保护的端点或方法。
```java
+public class MyServiceTest extends TestBase { // Assuming TestBase provides Spring context
+
@Test
- @Transactional
- @WithMockUser(username = "user-id-18163138155", authorities = "ROLE_TEACHER")
- void should_import_student_success() throws Exception {
- ......
+ @Transactional // 测试数据将回滚
+ @WithMockUser(username = "test-user", authorities = { "ROLE_TEACHER", "read" }) // 模拟一个名为 "test-user"，拥有 TEACHER 角色和 read 权限的用户
+ void should_perform_action_requiring_teacher_role() throws Exception {
+ // ... 测试逻辑 ...
+ // 这里可以调用需要 "ROLE_TEACHER" 权限的服务方法
}
+}
```
-_暂时总结到这里吧！虽然花了挺长时间才写完，不过可能还是会一些常用的注解的被漏掉，所以，我将文章也同步到了 Github 上去，Github 地址： 欢迎完善！_
-
-本文已经收录进我的 75K Star 的 Java 开源项目 JavaGuide：[https://github.com/Snailclimb/JavaGuide](https://github.com/Snailclimb/JavaGuide)。
-
diff --git a/docs/system-design/framework/spring/spring-design-patterns-summary.md b/docs/system-design/framework/spring/spring-design-patterns-summary.md
index 9efa5caa3a4..e4499b00f2e 100644
--- a/docs/system-design/framework/spring/spring-design-patterns-summary.md
+++ b/docs/system-design/framework/spring/spring-design-patterns-summary.md
@@ -142,7 +142,7 @@ public Object getSingleton(String beanName, ObjectFactory singletonFactory) {
**Spring AOP 属于运行时增强，而 AspectJ 是编译时增强。** Spring AOP 基于代理(Proxying)，而 AspectJ 基于字节码操作(Bytecode Manipulation)。
-Spring AOP 已经集成了 AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。AspectJ 相比于 Spring AOP 功能更加强大，但是 Spring AOP 相对来说更简单，
+Spring AOP 已经集成了 AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。AspectJ 相比于 Spring AOP 功能更加强大，但是 Spring AOP 相对来说更简单。
如果我们的切面比较少，那么两者性能差异不大。但是，当切面太多的话，最好选择 AspectJ ，它比 Spring AOP 快很多。
@@ -346,7 +346,6 @@ Spring 框架中用到了哪些设计模式？
- 《Spring 技术内幕》
-
-
-
diff --git a/docs/system-design/framework/spring/spring-knowledge-and-questions-summary.md b/docs/system-design/framework/spring/spring-knowledge-and-questions-summary.md
index b7f97be75f5..eab9117ad90 100644
--- a/docs/system-design/framework/spring/spring-knowledge-and-questions-summary.md
+++ b/docs/system-design/framework/spring/spring-knowledge-and-questions-summary.md
@@ -279,6 +279,78 @@ private SmsService smsService;
- 当一个接口存在多个实现类的情况下，`@Autowired` 和`@Resource`都需要通过名称才能正确匹配到对应的 Bean。`Autowired` 可以通过 `@Qualifier` 注解来显式指定名称，`@Resource`可以通过 `name` 属性来显式指定名称。
- `@Autowired` 支持在构造函数、方法、字段和参数上使用。`@Resource` 主要用于字段和方法上的注入，不支持在构造函数或参数上使用。
+### 注入 Bean 的方式有哪些？
+
+依赖注入 (Dependency Injection, DI) 的常见方式：
+
+1. 构造函数注入：通过类的构造函数来注入依赖项。
+1. Setter 注入：通过类的 Setter 方法来注入依赖项。
+1. Field（字段） 注入：直接在类的字段上使用注解（如 `@Autowired` 或 `@Resource`）来注入依赖项。
+
+构造函数注入示例：
+
+```java
+@Service
+public class UserService {
+
+ private final UserRepository userRepository;
+
+ public UserService(UserRepository userRepository) {
+ this.userRepository = userRepository;
+ }
+
+ //...
+}
+```
+
+Setter 注入示例：
+
+```java
+@Service
+public class UserService {
+
+ private UserRepository userRepository;
+
+ // 在 Spring 4.3 及以后的版本，特定情况下 @Autowired 可以省略不写
+ @Autowired
+ public void setUserRepository(UserRepository userRepository) {
+ this.userRepository = userRepository;
+ }
+
+ //...
+}
+```
+
+Field 注入示例：
+
+```java
+@Service
+public class UserService {
+
+ @Autowired
+ private UserRepository userRepository;
+
+ //...
+}
+```
+
+### 构造函数注入还是 Setter 注入？
+
+Spring 官方有对这个问题的回答：。
+
+我这里主要提取总结完善一下 Spring 官方的建议。
+
+**Spring 官方推荐构造函数注入**，这种注入方式的优势如下：
+
+1. 依赖完整性：确保所有必需依赖在对象创建时就被注入，避免了空指针异常的风险。
+2. 不可变性：有助于创建不可变对象，提高了线程安全性。
+3. 初始化保证：组件在使用前已完全初始化，减少了潜在的错误。
+4. 测试便利性：在单元测试中，可以直接通过构造函数传入模拟的依赖项，而不必依赖 Spring 容器进行注入。
+
+构造函数注入适合处理**必需的依赖项**，而 **Setter 注入** 则更适合**可选的依赖项**，这些依赖项可以有默认值或在对象生命周期中动态设置。虽然 `@Autowired` 可以用于 Setter 方法来处理必需的依赖项，但构造函数注入仍然是更好的选择。
+
+在某些情况下（例如第三方类不提供 Setter 方法），构造函数注入可能是**唯一的选择**。
+
### Bean 的作用域有哪些?
Spring 中 Bean 的作用域通常有下面几种：
@@ -316,12 +388,68 @@ Spring 框架中的 Bean 是否线程安全，取决于其作用域和状态。
prototype 作用域下，每次获取都会创建一个新的 bean 实例，不存在资源竞争问题，所以不存在线程安全问题。singleton 作用域下，IoC 容器中只有唯一的 bean 实例，可能会存在资源竞争问题（取决于 Bean 是否有状态）。如果这个 bean 是有状态的话，那就存在线程安全问题（有状态 Bean 是指包含可变的成员变量的对象）。
+有状态 Bean 示例：
+
+```java
+// 定义了一个购物车类，其中包含一个保存用户的购物车里商品的 List
+@Component
+public class ShoppingCart {
+ private List items = new ArrayList<>();
+
+ public void addItem(String item) {
+ items.add(item);
+ }
+
+ public List getItems() {
+ return items;
+ }
+}
+```
+
不过，大部分 Bean 实际都是无状态（没有定义可变的成员变量）的（比如 Dao、Service），这种情况下， Bean 是线程安全的。
-对于有状态单例 Bean 的线程安全问题，常见的有两种解决办法：
+无状态 Bean 示例：
+
+```java
+// 定义了一个用户服务，它仅包含业务逻辑而不保存任何状态。
+@Component
+public class UserService {
+
+ public User findUserById(Long id) {
+ //...
+ }
+ //...
+}
+```
+
+对于有状态单例 Bean 的线程安全问题，常见的三种解决办法是：
+
+1. **避免可变成员变量**: 尽量设计 Bean 为无状态。
+2. **使用`ThreadLocal`**: 将可变成员变量保存在 `ThreadLocal` 中，确保线程独立。
+3. **使用同步机制**: 利用 `synchronized` 或 `ReentrantLock` 来进行同步控制，确保线程安全。
+
+这里以 `ThreadLocal`为例，演示一下`ThreadLocal` 保存用户登录信息的场景：
-1. 在 Bean 中尽量避免定义可变的成员变量。
-2. 在类中定义一个 `ThreadLocal` 成员变量，将需要的可变成员变量保存在 `ThreadLocal` 中（推荐的一种方式）。
+```java
+public class UserThreadLocal {
+
+ private UserThreadLocal() {}
+
+ private static final ThreadLocal LOCAL = ThreadLocal.withInitial(() -> null);
+
+ public static void put(SysUser sysUser) {
+ LOCAL.set(sysUser);
+ }
+
+ public static SysUser get() {
+ return LOCAL.get();
+ }
+
+ public static void remove() {
+ LOCAL.remove();
+ }
+}
+```
### Bean 的生命周期了解么?
@@ -456,13 +584,24 @@ AOP 切面编程涉及到的一些专业术语：
### Spring AOP 和 AspectJ AOP 有什么区别？
-**Spring AOP 属于运行时增强，而 AspectJ 是编译时增强。** Spring AOP 基于代理(Proxying)，而 AspectJ 基于字节码操作(Bytecode Manipulation)。
+| 特性 | Spring AOP | AspectJ |
+| -------------- | -------------------------------------------------------- | ------------------------------------------ |
+| **增强方式** | 运行时增强（基于动态代理） | 编译时增强、类加载时增强（直接操作字节码） |
+| **切入点支持** | 方法级（Spring Bean 范围内，不支持 final 和 staic 方法） | 方法级、字段、构造器、静态方法等 |
+| **性能** | 运行时依赖代理，有一定开销，切面多时性能较低 | 运行时无代理开销，性能更高 |
+| **复杂性** | 简单，易用，适合大多数场景 | 功能强大，但相对复杂 |
+| **使用场景** | Spring 应用下比较简单的 AOP 需求 | 高性能、高复杂度的 AOP 需求 |
+
+**如何选择？**
-Spring AOP 已经集成了 AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。AspectJ 相比于 Spring AOP 功能更加强大，但是 Spring AOP 相对来说更简单，
+- **功能考量**：AspectJ 支持更复杂的 AOP 场景，Spring AOP 更简单易用。如果你需要增强 `final` 方法、静态方法、字段访问、构造器调用等，或者需要在非 Spring 管理的对象上应用增强逻辑，AspectJ 是唯一的选择。
+- **性能考量**：切面数量较少时两者性能差异不大，但切面较多时 AspectJ 性能更优。
-如果我们的切面比较少，那么两者性能差异不大。但是，当切面太多的话，最好选择 AspectJ ，它比 Spring AOP 快很多。
+**一句话总结**：简单场景优先使用 Spring AOP；复杂场景或高性能需求时，选择 AspectJ。
-### AspectJ 定义的通知类型有哪些？
+### AOP 常见的通知类型有哪些？
+
+
- **Before**（前置通知）：目标对象的方法调用之前触发
- **After** （后置通知）：目标对象的方法调用之后触发
@@ -569,6 +708,16 @@ MVC 是一种设计模式，Spring MVC 是一款很优秀的 MVC 框架。Spring
6. `DispaterServlet` 把返回的 `Model` 传给 `View`（视图渲染）。
7. 把 `View` 返回给请求者（浏览器）
+上述流程是传统开发模式（JSP，Thymeleaf 等）的工作原理。然而现在主流的开发方式是前后端分离，这种情况下 Spring MVC 的 `View` 概念发生了一些变化。由于 `View` 通常由前端框架（Vue, React 等）来处理，后端不再负责渲染页面，而是只负责提供数据，因此：
+
+- 前后端分离时，后端通常不再返回具体的视图，而是返回**纯数据**（通常是 JSON 格式），由前端负责渲染和展示。
+- `View` 的部分在前后端分离的场景下往往不需要设置，Spring MVC 的控制器方法只需要返回数据，不再返回 `ModelAndView`，而是直接返回数据，Spring 会自动将其转换为 JSON 格式。相应的，`ViewResolver` 也将不再被使用。
+
+怎么做到呢？
+
+- 使用 `@RestController` 注解代替传统的 `@Controller` 注解，这样所有方法默认会返回 JSON 格式的数据，而不是试图解析视图。
+- 如果你使用的是 `@Controller`，可以结合 `@ResponseBody` 注解来返回 JSON。
+
### 统一异常处理怎么做？
推荐使用注解的方式统一异常处理，具体会使用到 `@ControllerAdvice` + `@ExceptionHandler` 这两个注解 。
@@ -632,6 +781,164 @@ public class GlobalExceptionHandler {
- **适配器模式** : Spring AOP 的增强或通知(Advice)使用到了适配器模式、spring MVC 中也是用到了适配器模式适配`Controller`。
- ……
+## Spring 的循环依赖
+
+### Spring 循环依赖了解吗，怎么解决？
+
+循环依赖是指 Bean 对象循环引用，是两个或多个 Bean 之间相互持有对方的引用，例如 CircularDependencyA → CircularDependencyB → CircularDependencyA。
+
+```java
+@Component
+public class CircularDependencyA {
+ @Autowired
+ private CircularDependencyB circB;
+}
+
+@Component
+public class CircularDependencyB {
+ @Autowired
+ private CircularDependencyA circA;
+}
+```
+
+单个对象的自我依赖也会出现循环依赖，但这种概率极低，属于是代码编写错误。
+
+```java
+@Component
+public class CircularDependencyA {
+ @Autowired
+ private CircularDependencyA circA;
+}
+```
+
+Spring 框架通过使用三级缓存来解决这个问题，确保即使在循环依赖的情况下也能正确创建 Bean。
+
+Spring 中的三级缓存其实就是三个 Map，如下：
+
+```java
+// 一级缓存
+/** Cache of singleton objects: bean name to bean instance. */
+private final Map singletonObjects = new ConcurrentHashMap<>(256);
+
+// 二级缓存
+/** Cache of early singleton objects: bean name to bean instance. */
+private final Map earlySingletonObjects = new HashMap<>(16);
+
+// 三级缓存
+/** Cache of singleton factories: bean name to ObjectFactory. */
+private final Map> singletonFactories = new HashMap<>(16);
+```
+
+简单来说，Spring 的三级缓存包括：
+
+1. **一级缓存（singletonObjects）**：存放最终形态的 Bean（已经实例化、属性填充、初始化），单例池，为“Spring 的单例属性”⽽⽣。一般情况我们获取 Bean 都是从这里获取的，但是并不是所有的 Bean 都在单例池里面，例如原型 Bean 就不在里面。
+2. **二级缓存（earlySingletonObjects）**：存放过渡 Bean（半成品，尚未属性填充），也就是三级缓存中`ObjectFactory`产生的对象，与三级缓存配合使用的，可以防止 AOP 的情况下，每次调用`ObjectFactory#getObject()`都是会产生新的代理对象的。
+3. **三级缓存（singletonFactories）**：存放`ObjectFactory`，`ObjectFactory`的`getObject()`方法（最终调用的是`getEarlyBeanReference()`方法）可以生成原始 Bean 对象或者代理对象（如果 Bean 被 AOP 切面代理）。三级缓存只会对单例 Bean 生效。
+
+接下来说一下 Spring 创建 Bean 的流程：
+
+1. 先去 **一级缓存 `singletonObjects`** 中获取，存在就返回；
+2. 如果不存在或者对象正在创建中，于是去 **二级缓存 `earlySingletonObjects`** 中获取；
+3. 如果还没有获取到，就去 **三级缓存 `singletonFactories`** 中获取，通过执行 `ObjectFacotry` 的 `getObject()` 就可以获取该对象，获取成功之后，从三级缓存移除，并将该对象加入到二级缓存中。
+
+在三级缓存中存储的是 `ObjectFacoty` ：
+
+```java
+public interface ObjectFactory {
+ T getObject() throws BeansException;
+}
+```
+
+Spring 在创建 Bean 的时候，如果允许循环依赖的话，Spring 就会将刚刚实例化完成，但是属性还没有初始化完的 Bean 对象给提前暴露出去，这里通过 `addSingletonFactory` 方法，向三级缓存中添加一个 `ObjectFactory` 对象：
+
+```java
+// AbstractAutowireCapableBeanFactory # doCreateBean #
+public abstract class AbstractAutowireCapableBeanFactory ... {
+ protected Object doCreateBean(...) {
+ //...
+
+ // 支撑循环依赖：将 ()->getEarlyBeanReference 作为一个 ObjectFactory 对象的 getObject() 方法加入到三级缓存中
+ addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
+ }
+}
+```
+
+那么上边在说 Spring 创建 Bean 的流程时说了，如果一级缓存、二级缓存都取不到对象时，会去三级缓存中通过 `ObjectFactory` 的 `getObject` 方法获取对象。
+
+```java
+class A {
+ // 使用了 B
+ private B b;
+}
+class B {
+ // 使用了 A
+ private A a;
+}
+```
+
+以上面的循环依赖代码为例，整个解决循环依赖的流程如下：
+
+- 当 Spring 创建 A 之后，发现 A 依赖了 B ，又去创建 B，B 依赖了 A ，又去创建 A；
+- 在 B 创建 A 的时候，那么此时 A 就发生了循环依赖，由于 A 此时还没有初始化完成，因此在 **一二级缓存** 中肯定没有 A；
+- 那么此时就去三级缓存中调用 `getObject()` 方法去获取 A 的 **前期暴露的对象** ，也就是调用上边加入的 `getEarlyBeanReference()` 方法，生成一个 A 的 **前期暴露对象**；
+- 然后就将这个 `ObjectFactory` 从三级缓存中移除，并且将前期暴露对象放入到二级缓存中，那么 B 就将这个前期暴露对象注入到依赖，来支持循环依赖。
+
+**只用两级缓存够吗？** 在没有 AOP 的情况下，确实可以只使用一级和二级缓存来解决循环依赖问题。但是，当涉及到 AOP 时，三级缓存就显得非常重要了，因为它确保了即使在 Bean 的创建过程中有多次对早期引用的请求，也始终只返回同一个代理对象，从而避免了同一个 Bean 有多个代理对象的问题。
+
+**最后总结一下 Spring 如何解决三级缓存**：
+
+在三级缓存这一块，主要记一下 Spring 是如何支持循环依赖的即可，也就是如果发生循环依赖的话，就去 **三级缓存 `singletonFactories`** 中拿到三级缓存中存储的 `ObjectFactory` 并调用它的 `getObject()` 方法来获取这个循环依赖对象的前期暴露对象（虽然还没初始化完成，但是可以拿到该对象在堆中的存储地址了），并且将这个前期暴露对象放到二级缓存中，这样在循环依赖时，就不会重复初始化了！
+
+不过，这种机制也有一些缺点，比如增加了内存开销（需要维护三级缓存，也就是三个 Map），降低了性能（需要进行多次检查和转换）。并且，还有少部分情况是不支持循环依赖的，比如非单例的 bean 和`@Async`注解的 bean 无法支持循环依赖。
+
+### @Lazy 能解决循环依赖吗？
+
+`@Lazy` 用来标识类是否需要懒加载/延迟加载，可以作用在类上、方法上、构造器上、方法参数上、成员变量中。
+
+Spring Boot 2.2 新增了**全局懒加载属性**，开启后全局 bean 被设置为懒加载，需要时再去创建。
+
+配置文件配置全局懒加载：
+
+```properties
+#默认false
+spring.main.lazy-initialization=true
+```
+
+编码的方式设置全局懒加载：
+
+```java
+SpringApplication springApplication=new SpringApplication(Start.class);
+springApplication.setLazyInitialization(false);
+springApplication.run(args);
+```
+
+如非必要，尽量不要用全局懒加载。全局懒加载会让 Bean 第一次使用的时候加载会变慢，并且它会延迟应用程序问题的发现（当 Bean 被初始化时，问题才会出现）。
+
+如果一个 Bean 没有被标记为懒加载，那么它会在 Spring IoC 容器启动的过程中被创建和初始化。如果一个 Bean 被标记为懒加载，那么它不会在 Spring IoC 容器启动时立即实例化，而是在第一次被请求时才创建。这可以帮助减少应用启动时的初始化时间，也可以用来解决循环依赖问题。
+
+循环依赖问题是如何通过`@Lazy` 解决的呢？这里举一个例子，比如说有两个 Bean，A 和 B，他们之间发生了循环依赖，那么 A 的构造器上添加 `@Lazy` 注解之后（延迟 Bean B 的实例化），加载的流程如下：
+
+- 首先 Spring 会去创建 A 的 Bean，创建时需要注入 B 的属性；
+- 由于在 A 上标注了 `@Lazy` 注解，因此 Spring 会去创建一个 B 的代理对象，将这个代理对象注入到 A 中的 B 属性；
+- 之后开始执行 B 的实例化、初始化，在注入 B 中的 A 属性时，此时 A 已经创建完毕了，就可以将 A 给注入进去。
+
+从上面的加载流程可以看出： `@Lazy` 解决循环依赖的关键点在于代理对象的使用。
+
+- **没有 `@Lazy` 的情况下**：在 Spring 容器初始化 `A` 时会立即尝试创建 `B`，而在创建 `B` 的过程中又会尝试创建 `A`，最终导致循环依赖（即无限递归，最终抛出异常）。
+- **使用 `@Lazy` 的情况下**：Spring 不会立即创建 `B`，而是会注入一个 `B` 的代理对象。由于此时 `B` 仍未被真正初始化，`A` 的初始化可以顺利完成。等到 `A` 实例实际调用 `B` 的方法时，代理对象才会触发 `B` 的真正初始化。
+
+`@Lazy` 能够在一定程度上打破循环依赖链，允许 Spring 容器顺利地完成 Bean 的创建和注入。但这并不是一个根本性的解决方案，尤其是在构造函数注入、复杂的多级依赖等场景中，`@Lazy` 无法有效地解决问题。因此，最佳实践仍然是尽量避免设计上的循环依赖。
+
+### SpringBoot 允许循环依赖发生么？
+
+SpringBoot 2.6.x 以前是默认允许循环依赖的，也就是说你的代码出现了循环依赖问题，一般情况下也不会报错。SpringBoot 2.6.x 以后官方不再推荐编写存在循环依赖的代码，建议开发者自己写代码的时候去减少不必要的互相依赖。这其实也是我们最应该去做的，循环依赖本身就是一种设计缺陷，我们不应该过度依赖 Spring 而忽视了编码的规范和质量，说不定未来某个 SpringBoot 版本就彻底禁止循环依赖的代码了。
+
+SpringBoot 2.6.x 以后，如果你不想重构循环依赖的代码的话，也可以采用下面这些方法：
+
+- 在全局配置文件中设置允许循环依赖存在：`spring.main.allow-circular-references=true`。最简单粗暴的方式，不太推荐。
+- 在导致循环依赖的 Bean 上添加 `@Lazy` 注解，这是一种比较推荐的方式。`@Lazy` 用来标识类是否需要懒加载/延迟加载，可以作用在类上、方法上、构造器上、方法参数上、成员变量中。
+- ……
+
## Spring 事务
关于 Spring 事务的详细介绍，可以看我写的 [Spring 事务详解](https://javaguide.cn/system-design/framework/spring/spring-transaction.html) 这篇文章。
diff --git a/docs/system-design/framework/spring/spring-transaction.md b/docs/system-design/framework/spring/spring-transaction.md
index 47eac108cb8..c9358ab2f9f 100644
--- a/docs/system-design/framework/spring/spring-transaction.md
+++ b/docs/system-design/framework/spring/spring-transaction.md
@@ -419,33 +419,66 @@ Class B {
**3.`TransactionDefinition.PROPAGATION_NESTED`**:
-如果当前存在事务，就在嵌套事务内执行；如果当前没有事务，就执行与`TransactionDefinition.PROPAGATION_REQUIRED`类似的操作。也就是说：
+如果当前存在事务，则创建一个事务作为当前事务的嵌套事务执行； 如果当前没有事务，就执行与`TransactionDefinition.PROPAGATION_REQUIRED`类似的操作。也就是说：
- 在外部方法开启事务的情况下，在内部开启一个新的事务，作为嵌套事务存在。
- 如果外部方法无事务，则单独开启一个事务，与 `PROPAGATION_REQUIRED` 类似。
-这里还是简单举个例子：如果 `bMethod()` 回滚的话，`aMethod()`不会回滚。如果 `aMethod()` 回滚的话，`bMethod()`会回滚。
-
-```java
-@Service
-Class A {
- @Autowired
- B b;
- @Transactional(propagation = Propagation.REQUIRED)
- public void aMethod {
- //do something
- b.bMethod();
+`TransactionDefinition.PROPAGATION_NESTED`代表的嵌套事务以父子关系呈现，其核心理念是子事务不会独立提交，依赖于父事务，在父事务中运行；当父事务提交时，子事务也会随着提交，理所当然的，当父事务回滚时，子事务也会回滚；
+> 与`TransactionDefinition.PROPAGATION_REQUIRES_NEW`区别于：`PROPAGATION_REQUIRES_NEW`是独立事务，不依赖于外部事务，以平级关系呈现，执行完就会立即提交，与外部事务无关；
+
+子事务也有自己的特性，可以独立进行回滚，不会引发父事务的回滚，但是前提是需要处理子事务的异常，避免异常被父事务感知导致外部事务回滚；
+
+举个例子：
+- 如果 `aMethod()` 回滚的话，作为嵌套事务的`bMethod()`会回滚。
+- 如果 `bMethod()` 回滚的话，`aMethod()`是否回滚，要看`bMethod()`的异常是否被处理：
+ - `bMethod()`的异常没有被处理，即`bMethod()`内部没有处理异常，且`aMethod()`也没有处理异常，那么`aMethod()`将感知异常致使整体回滚。
+ ```java
+ @Service
+ Class A {
+ @Autowired
+ B b;
+ @Transactional(propagation = Propagation.REQUIRED)
+ public void aMethod (){
+ //do something
+ b.bMethod();
+ }
}
-}
-
-@Service
-Class B {
- @Transactional(propagation = Propagation.NESTED)
- public void bMethod {
- //do something
+
+ @Service
+ Class B {
+ @Transactional(propagation = Propagation.NESTED)
+ public void bMethod (){
+ //do something and throw an exception
+ }
}
-}
-```
+ ```
+ - `bMethod()`处理异常或`aMethod()`处理异常，`aMethod()`不会回滚。
+
+ ```java
+ @Service
+ Class A {
+ @Autowired
+ B b;
+ @Transactional(propagation = Propagation.REQUIRED)
+ public void aMethod (){
+ //do something
+ try {
+ b.bMethod();
+ } catch (Exception e) {
+ System.out.println("方法回滚");
+ }
+ }
+ }
+
+ @Service
+ Class B {
+ @Transactional(propagation = Propagation.NESTED)
+ public void bMethod {
+ //do something and throw an exception
+ }
+ }
+ ```
**4.`TransactionDefinition.PROPAGATION_MANDATORY`**
diff --git a/docs/system-design/security/advantages-and-disadvantages-of-jwt.md b/docs/system-design/security/advantages-and-disadvantages-of-jwt.md
index 4d3c9b4b693..bbb6d19778f 100644
--- a/docs/system-design/security/advantages-and-disadvantages-of-jwt.md
+++ b/docs/system-design/security/advantages-and-disadvantages-of-jwt.md
@@ -5,15 +5,11 @@ tag:
- 安全
---
-在 [JWT 基本概念详解](https://javaguide.cn/system-design/security/jwt-intro.html)这篇文章中，我介绍了：
+校招面试中，遇到大部分的候选者认证登录这块用的都是 JWT。提问 JWT 的概念性问题以及使用 JWT 的原因，基本都能回答一些，但当问到 JWT 存在的一些问题和解决方案时，只有一小部分候选者回答的还可以。
-- 什么是 JWT?
-- JWT 由哪些部分组成？
-- 如何基于 JWT 进行身份验证？
-- JWT 如何防止 Token 被篡改？
-- 如何加强 JWT 的安全性？
+JWT 不是银弹，也有很多缺陷，很多时候并不是最优的选择。这篇文章，我们一起探讨一下 JWT 身份认证的优缺点以及常见问题的解决办法，来看看为什么很多人不再推荐使用 JWT 了。
-这篇文章，我们一起探讨一下 JWT 身份认证的优缺点以及常见问题的解决办法。
+关于 JWT 的基本概念介绍请看我写的这篇文章： [JWT 基本概念详解](https://javaguide.cn/system-design/security/jwt-intro.html)。
## JWT 的优势
@@ -21,7 +17,7 @@ tag:
### 无状态
-JWT 自身包含了身份验证所需要的所有信息，因此，我们的服务器不需要存储 Session 信息。这显然增加了系统的可用性和伸缩性，大大减轻了服务端的压力。
+JWT 自身包含了身份验证所需要的所有信息，因此，我们的服务器不需要存储 JWT 信息。这显然增加了系统的可用性和伸缩性，大大减轻了服务端的压力。
不过，也正是由于 JWT 的无状态，也导致了它最大的缺点：**不可控！**
@@ -170,15 +166,35 @@ JWT 认证的话，我们应该如何解决续签问题呢？查阅了很多资
- 重新请求获取 JWT 的过程中会有短暂 JWT 不可用的情况（可以通过在客户端设置定时器，当 accessJWT 快过期的时候，提前去通过 refreshJWT 获取新的 accessJWT）;
- 存在安全问题，只要拿到了未过期的 refreshJWT 就一直可以获取到 accessJWT。不过，由于 refreshJWT 只用来获取 accessJWT，不容易被泄露。
+### JWT 体积太大
+
+JWT 结构复杂（Header、Payload 和 Signature），包含了更多额外的信息，还需要进行 Base64Url 编码，这会使得 JWT 体积较大，增加了网络传输的开销。
+
+JWT 组成:
+
+
+
+JWT 示例：
+
+```plain
+eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
+eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
+SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+```
+
+解决办法：
+
+- 尽量减少 JWT Payload（载荷）中的信息，只保留必要的用户和权限信息。
+- 在传输 JWT 之前，使用压缩算法（如 GZIP）对 JWT 进行压缩以减少体积。
+- 在某些情况下，使用传统的 Token 可能更合适。传统的 Token 通常只是一个唯一标识符，对应的信息（例如用户 ID、Token 过期时间、权限信息）存储在服务端，通常会通过 Redis 保存。
+
## 总结
-JWT 其中一个很重要的优势是无状态，但实际上，我们想要在实际项目中合理使用 JWT 的话，也还是需要保存 JWT 信息。
+JWT 其中一个很重要的优势是无状态，但实际上，我们想要在实际项目中合理使用 JWT 做认证登录的话，也还是需要保存 JWT 信息。
JWT 也不是银弹，也有很多缺陷，具体是选择 JWT 还是 Session 方案还是要看项目的具体需求。万万不可尬吹 JWT，而看不起其他身份认证方案。
-另外，不用 JWT 直接使用普通的 Token(随机生成，不包含具体的信息) 结合 Redis 来做身份认证也是可以的。我在 [「优质开源项目推荐」](https://javaguide.cn/open-source-project/)的第 8 期推荐过的 [Sa-Token](https://github.com/dromara/sa-token) 这个项目是一个比较完善的 基于 JWT 的身份认证解决方案，支持自动续签、踢人下线、账号封禁、同端互斥登录等功能，感兴趣的朋友可以看看。
-
-
+另外，不用 JWT 直接使用普通的 Token(随机生成的 ID，不包含具体的信息) 结合 Redis 来做身份认证也是可以的。
## 参考
diff --git a/docs/system-design/security/data-desensitization.md b/docs/system-design/security/data-desensitization.md
index 83b186a1433..08b5052f268 100644
--- a/docs/system-design/security/data-desensitization.md
+++ b/docs/system-design/security/data-desensitization.md
@@ -368,21 +368,36 @@ FastJSON 实现数据脱敏的方式主要有两种：
- 基于注解 `@JSONField` 实现：需要自定义一个用于脱敏的序列化的类，然后在需要脱敏的字段上通过 `@JSONField` 中的 `serializeUsing` 指定为我们自定义的序列化类型即可。
- 基于序列化过滤器：需要实现 `ValueFilter` 接口，重写 `process` 方法完成自定义脱敏，然后在 JSON 转换时使用自定义的转换策略。具体实现可参考这篇文章： 。
-### Mybatis-mate
+### Mybatis-Mate
-MybatisPlus 也提供了数据脱敏模块 mybatis-mate。mybatis-mate 为 MybatisPlus 企业级模块，使用之前需要配置授权码（付费），旨在更敏捷优雅处理数据。
+先介绍一下 MyBatis、MyBatis-Plus 和 Mybatis-Mate 这三者的关系：
-配置内容如下所示：
+- MyBatis 是一款优秀的持久层框架，它支持定制化 SQL、存储过程以及高级映射。
+- MyBatis-Plus 是一个 MyBatis 的增强工具，能够极大地简化持久层的开发工作。
+- Mybatis-Mate 是为 MyBatis-Plus 提供的企业级模块，旨在更敏捷优雅处理数据。不过，使用之前需要配置授权码（付费）。
-```yaml
-# Mybatis Mate 配置
-mybatis-mate:
- cert:
- grant: jxftsdfggggx
- license: GKXP9r4MCJhGID/DTGigcBcLmZjb1YZGjE4GXaAoxbtGsPC20sxpEtiUr2F7Nb1ANTUekvF6Syo6DzraA4M4oacwoLVTglzfvaEfadfsd232485eLJK1QsskrSJmreMnEaNh9lsV7Lpbxy9JeGCeM0HPEbRvq8Y+8dUt5bQYLklsa3ZIBexir+4XykZY15uqn1pYIp4pEK0+aINTa57xjJNoWuBIqm7BdFIb4l1TAcPYMTsMXhF5hfMmKD2h391HxWTshJ6jbt4YqdKD167AgeoM+B+DE1jxlLjcpskY+kFs9piOS7RCcmKBBUOgX2BD/JxhR2gQ==
-```
+Mybatis-Mate 支持敏感词脱敏，内置手机号、邮箱、银行卡号等 9 种常用脱敏规则。
+
+```java
+@FieldSensitive("testStrategy")
+private String username;
+
+@Configuration
+public class SensitiveStrategyConfig {
+
+ /**
+ * 注入脱敏策略
+ */
+ @Bean
+ public ISensitiveStrategy sensitiveStrategy() {
+ // 自定义 testStrategy 类型脱敏处理
+ return new SensitiveStrategy().addStrategy("testStrategy", t -> t + "***test***");
+ }
+}
-具体实现可参考 baomidou 提供的如下代码： 。
+// 跳过脱密处理，用于编辑场景
+RequestDataTransfer.skipSensitive();
+```
### MyBatis-Flex
@@ -390,16 +405,6 @@ mybatis-mate:
MyBatis-Flex 提供了 `@ColumnMask()` 注解，以及内置的 9 种脱敏规则，开箱即用：
-- 用户名脱敏
-- 手机号脱敏
-- 固定电话脱敏
-- 身份证号脱敏
-- 车牌号脱敏
-- 地址脱敏
-- 邮件脱敏
-- 密码脱敏
-- 银行卡号脱敏
-
```java
/**
* 内置的数据脱敏方式
@@ -465,14 +470,57 @@ public class Account {
如果这些内置的脱敏规则不满足你的要求的话，你还可以自定义脱敏规则。
-## 总结
+1、通过 `MaskManager` 注册新的脱敏规则：
+
+```java
+MaskManager.registerMaskProcessor("自定义规则名称"
+ , data -> {
+ return data;
+ })
+```
-本文主要介绍了数据脱敏的相关内容，首先介绍了数据脱敏的概念，在此基础上介绍了常用的数据脱敏规则；随后介绍了本文的重点 Hutool 工具及其使用方法，在此基础上进行了实操，分别演示了使用 DesensitizedUtil 工具类、配合 Jackson 通过注解的方式完成数据脱敏；最后，介绍了一些常见的数据脱敏方法，并附上了对应的教程链接供大家参考，本文内容如有不当之处，还请大家批评指正。
+2、使用自定义的脱敏规则
+
+```java
+@Table("tb_account")
+public class Account {
+
+ @Id(keyType = KeyType.Auto)
+ private Long id;
+
+ @ColumnMask("自定义规则名称")
+ private String userName;
+}
+```
+
+并且，对于需要跳过脱密处理的场景，例如进入编辑页面编辑用户数据，MyBatis-Flex 也提供了对应的支持：
+
+1. **`MaskManager#execWithoutMask`**（推荐）：该方法使用了模版方法设计模式，保障跳过脱敏处理并执行相关逻辑后自动恢复脱敏处理。
+2. **`MaskManager#skipMask`**：跳过脱敏处理。
+3. **`MaskManager#restoreMask`**：恢复脱敏处理，确保后续的操作继续使用脱敏逻辑。
+
+`MaskManager#execWithoutMask`方法实现如下：
+
+```java
+public static T execWithoutMask(Supplier supplier) {
+ try {
+ skipMask();
+ return supplier.get();
+ } finally {
+ restoreMask();
+ }
+}
+```
+
+`MaskManager` 的`skipMask`和`restoreMask`方法一般配套使用，推荐`try{...}finally{...}`模式。
+
+## 总结
-## 推荐阅读
+这篇文章主要介绍了：
-- [Spring Boot 日志、配置文件、接口数据如何脱敏？老鸟们都是这样玩的！](https://mp.weixin.qq.com/s/59osrnjyPJ7BV070x6ABwQ)
-- [大厂也在用的 6 种数据脱敏方案，严防泄露数据的“内鬼”](https://mp.weixin.qq.com/s/_Dgekk1AJsIx0TTlnH6kUA)
+- 数据脱敏的定义：数据脱敏是指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。
+- 常用的脱敏规则：替换、删除、重排、加噪和加密。
+- 常用的脱敏工具：Hutool、Apache ShardingSphere、FastJSON、Mybatis-Mate 和 MyBatis-Flex。
## 参考
diff --git a/docs/system-design/security/data-validation.md b/docs/system-design/security/data-validation.md
new file mode 100644
index 00000000000..fdeb6fb95cc
--- /dev/null
+++ b/docs/system-design/security/data-validation.md
@@ -0,0 +1,203 @@
+---
+title: 为什么前后端都要做数据校验
+category: 系统设计
+tag:
+ - 安全
+---
+
+> 相关面试题：
+>
+> - 前端做了校验，后端还还需要做校验吗？
+> - 前端已经做了数据校验，为什么后端还需要再做一遍同样（甚至更严格）的校验呢？
+> - 前端/后端需要对哪些内容进行校验？
+
+咱们平时做 Web 开发，不管是写前端页面还是后端接口，都离不开跟数据打交道。那怎么保证这些传来传去的数据是靠谱的、安全的呢？这就得靠**数据校验**了。而且，这活儿，前端得干，后端**更得干**，还得加上**权限校验**这道重要的“锁”，缺一不可！
+
+为啥这么说？你想啊，前端校验主要是为了用户体验和挡掉一些明显的“瞎填”数据，但懂点技术的人绕过前端校验简直不要太轻松（比如直接用 Postman 之类的工具发请求）。所以，**后端校验才是咱们系统安全和数据准确性的最后一道，也是最硬核的防线**。它得确保进到系统里的数据不仅格式对，还得符合业务规矩，最重要的是，执行这个操作的人得有**权限**！
+
+
+
+## 前端校验
+
+前端校验就像个贴心的门卫，主要目的是在用户填数据的时候，就赶紧告诉他哪儿不对，让他改，省得提交了半天，结果后端说不行，还得重来。这样做的好处显而易见：
+
+1. **用户体验好：** 输入时就有提示，错了马上知道，改起来方便，用户感觉流畅不闹心。
+2. **减轻后端压力：** 把一些明显格式错误、必填项没填的数据在前端就拦下来，减少了发往后端的无效请求，省了服务器资源和网络流量。需要注意的是，后端同样还是要校验，只是加上前端校验可以减少很多无效请求。
+
+那前端一般都得校验点啥呢？
+
+- **必填项校验:** 最基本的，该填的地儿可不能空着。
+- **格式校验:** 比如邮箱得像个邮箱样儿 (xxx@xx.com)，手机号得是 11 位数字等。正则表达式这时候就派上用场了。
+- **重复输入校验：** 确保两次输入的内容一致，例如注册时的“确认密码”字段。
+- **范围/长度校验:** 年龄不能是负数吧？密码长度得在 6 到 20 位之间吧？这种都得看着。
+- **合法性/业务校验:** 比如用户名是不是已经被注册了？选的商品还有没有库存？这得根据具体业务来，需要配合后端来做。
+- **文件上传校验：**限制文件类型（如仅支持 `.jpg`、`.png` 格式）和文件大小。
+- **安全性校验:** 防范像 XSS（跨站脚本攻击）这种坏心思，对用户输入的东西做点处理，别让人家写的脚本在咱们页面上跑起来。
+- ...等等，根据业务需求来。
+
+总之，前端校验的核心是 **引导用户正确输入** 和 **提升交互体验**。
+
+## 后端校验
+
+前端校验只是第一道防线，虽然提升了用户体验，但毕竟可以被绕过，真正起决定性作用的是后端校验。后端需要对所有前端传来的数据都抱着“可能有问题”的态度，进行全面审查。后端校验不仅要覆盖前端的基本检查（如格式、范围、长度等），还需要更严格、更深入的验证，确保系统的安全性和数据的一致性。以下是后端校验的重点内容：
+
+1. **完整性校验:** 接口文档中明确要求的字段必须存在，例如 `userId` 和 `orderId`。如果缺失任何必需字段，后端应立即返回错误，拒绝处理请求。
+2. **合法性/存在性校验:** 验证传入的数据是否真实有效。例如，传过来的 `productId` 是否存在于数据库中？`couponId` 是否已经过期或被使用？这通常需要通过查库或调用其他服务来确认。
+3. **一致性校验:** 针对涉及多个数据对象的操作，验证它们是否符合业务逻辑。例如，更新订单状态前，需要确保订单的当前状态允许修改，不能直接从“未支付”跳到“已完成”。一致性校验是保证数据流转正确性的关键。
+4. **安全性校验:** 后端必须防范各种恶意攻击，包括但不限于 XSS、SQL 注入等。所有外部输入都应进行严格的过滤和验证，例如使用参数化查询防止 SQL 注入，或对返回的 HTML 数据进行转义，避免跨站脚本攻击。
+5. ...基本上，前端能做的校验，后端为了安全都得再来一遍。
+
+在 Java 后端，每次都手写 if-else 来做这些基础校验太累了。好在 Java 社区给我们提供了 **Bean Validation** 这套标准规范。它允许我们用**注解**的方式，直接在 JavaBean（比如我们的 DTO 对象）的属性上声明校验规则，非常方便。
+
+- **JSR 303 (1.0):** 打下了基础，引入了 `@NotNull`, `@Size`, `@Min`, `@Max` 这些老朋友。
+- **JSR 349 (1.1):** 增加了对方法参数和返回值的校验，还有分组校验等增强。
+- **JSR 380 (2.0):** 拥抱 Java 8，支持了新的日期时间 API，还加了 `@NotEmpty`, `@NotBlank`, `@Email` 等更实用的注解。
+
+早期的 Spring Boot (大概 2.3.x 之前): spring-boot-starter-web 里自带了 `hibernate-validator`，你啥都不用加。
+
+Spring Boot 2.3.x 及之后: 为了更灵活，校验相关的依赖被单独拎出来了。你需要手动添加 `spring-boot-starter-validation` 依赖：
+
+```xml
+
+ org.springframework.boot
+ spring-boot-starter-validation
+
+```
+
+Bean Validation 规范及其实现（如 Hibernate Validator）提供了丰富的注解，用于声明式地定义校验规则。以下是一些常用的注解及其说明：
+
+- `@NotNull`: 检查被注解的元素（任意类型）不能为 `null`。
+- `@NotEmpty`: 检查被注解的元素（如 `CharSequence`、`Collection`、`Map`、`Array`）不能为 `null` 且其大小/长度不能为 0。注意：对于字符串，`@NotEmpty` 允许包含空白字符的字符串，如 `" "`。
+- `@NotBlank`: 检查被注解的 `CharSequence`（如 `String`）不能为 `null`，并且去除首尾空格后的长度必须大于 0。（即，不能为空白字符串）。
+- `@Null`: 检查被注解的元素必须为 `null`。
+- `@AssertTrue` / `@AssertFalse`: 检查被注解的 `boolean` 或 `Boolean` 类型元素必须为 `true` / `false`。
+- `@Min(value)` / `@Max(value)`: 检查被注解的数字类型（或其字符串表示）的值必须大于等于 / 小于等于指定的 `value`。适用于整数类型（`byte`、`short`、`int`、`long`、`BigInteger` 等）。
+- `@DecimalMin(value)` / `@DecimalMax(value)`: 功能类似 `@Min` / `@Max`，但适用于包含小数的数字类型（`BigDecimal`、`BigInteger`、`CharSequence`、`byte`、`short`、`int`、`long`及其包装类）。 `value` 必须是数字的字符串表示。
+- `@Size(min=, max=)`: 检查被注解的元素（如 `CharSequence`、`Collection`、`Map`、`Array`）的大小/长度必须在指定的 `min` 和 `max` 范围之内（包含边界）。
+- `@Digits(integer=, fraction=)`: 检查被注解的数字类型（或其字符串表示）的值，其整数部分的位数必须 ≤ `integer`，小数部分的位数必须 ≤ `fraction`。
+- `@Pattern(regexp=, flags=)`: 检查被注解的 `CharSequence`（如 `String`）是否匹配指定的正则表达式 (`regexp`)。`flags` 可以指定匹配模式（如不区分大小写）。
+- `@Email`: 检查被注解的 `CharSequence`（如 `String`）是否符合 Email 格式（内置了一个相对宽松的正则表达式）。
+- `@Past` / `@Future`: 检查被注解的日期或时间类型（`java.util.Date`、`java.util.Calendar`、JSR 310 `java.time` 包下的类型）是否在当前时间之前 / 之后。
+- `@PastOrPresent` / `@FutureOrPresent`: 类似 `@Past` / `@Future`，但允许等于当前时间。
+- ......
+
+当 Controller 方法使用 `@RequestBody` 注解来接收请求体并将其绑定到一个对象时，可以在该参数前添加 `@Valid` 注解来触发对该对象的校验。如果验证失败，它将抛出`MethodArgumentNotValidException`。
+
+```java
+@Data
+@AllArgsConstructor
+@NoArgsConstructor
+public class Person {
+ @NotNull(message = "classId 不能为空")
+ private String classId;
+
+ @Size(max = 33)
+ @NotNull(message = "name 不能为空")
+ private String name;
+
+ @Pattern(regexp = "((^Man$|^Woman$|^UGM$))", message = "sex 值不在可选范围")
+ @NotNull(message = "sex 不能为空")
+ private String sex;
+
+ @Email(message = "email 格式不正确")
+ @NotNull(message = "email 不能为空")
+ private String email;
+}
+
+
+@RestController
+@RequestMapping("/api")
+public class PersonController {
+ @PostMapping("/person")
+ public ResponseEntity getPerson(@RequestBody @Valid Person person) {
+ return ResponseEntity.ok().body(person);
+ }
+}
+```
+
+对于直接映射到方法参数的简单类型数据（如路径变量 `@PathVariable` 或请求参数 `@RequestParam`），校验方式略有不同：
+
+1. **在 Controller 类上添加 `@Validated` 注解**：这个注解是 Spring 提供的（非 JSR 标准），它使得 Spring 能够处理方法级别的参数校验注解。**这是必需步骤。**
+2. **将校验注解直接放在方法参数上**：将 `@Min`, `@Max`, `@Size`, `@Pattern` 等校验注解直接应用于对应的 `@PathVariable` 或 `@RequestParam` 参数。
+
+一定一定不要忘记在类上加上 `@Validated` 注解了，这个参数可以告诉 Spring 去校验方法参数。
+
+```java
+@RestController
+@RequestMapping("/api")
+@Validated // 关键步骤 1: 必须在类上添加 @Validated
+public class PersonController {
+
+ @GetMapping("/person/{id}")
+ public ResponseEntity getPersonByID(
+ @PathVariable("id")
+ @Max(value = 5, message = "ID 不能超过 5") // 关键步骤 2: 校验注解直接放在参数上
+ Integer id
+ ) {
+ // 如果传入的 id > 5，Spring 会在进入方法体前抛出 ConstraintViolationException 异常。
+ // 全局异常处理器同样需要处理此异常。
+ return ResponseEntity.ok().body(id);
+ }
+
+ @GetMapping("/person")
+ public ResponseEntity findPersonByName(
+ @RequestParam("name")
+ @NotBlank(message = "姓名不能为空") // 同样适用于 @RequestParam
+ @Size(max = 10, message = "姓名长度不能超过 10")
+ String name
+ ) {
+ return ResponseEntity.ok().body("Found person: " + name);
+ }
+}
+```
+
+Bean Validation 主要解决的是**数据格式、语法层面**的校验。但光有这个还不够。
+
+## 权限校验
+
+数据格式都验过了，没问题。但是，**这个操作，当前登录的这个用户，他有权做吗？** 这就是**权限校验**要解决的问题。比如：
+
+- 普通用户能修改别人的订单吗？（不行）
+- 游客能访问管理员后台接口吗？（不行）
+- 游客能管理其他用户的信息吗？（不行）
+- VIP 用户能使用专属的优惠券吗？（可以）
+- ......
+
+权限校验发生在**数据校验之后**，它关心的是“**谁 (Who)** 能对 **什么资源 (What)** 执行 **什么操作 (Action)**”。
+
+**为啥权限校验这么重要？**
+
+- **安全基石：** 防止未经授权的访问和操作，保护用户数据和系统安全。
+- **业务隔离：** 确保不同角色（管理员、普通用户、VIP 用户等）只能访问和操作其权限范围内的功能。
+- **合规要求：** 很多行业法规对数据访问权限有严格要求。
+
+目前 Java 后端主流的方式是使用成熟的安全框架来实现权限校验，而不是自己手写（容易出错且难以维护）。
+
+1. **Spring Security (业界标准，推荐):** 基于过滤器链（Filter Chain）拦截请求，进行认证（Authentication - 你是谁？）和授权（Authorization - 你能干啥？）。Spring Security 功能强大、社区活跃、与 Spring 生态无缝集成。不过，配置相对复杂，学习曲线较陡峭。
+2. **Apache Shiro:** 另一个流行的安全框架，相对 Spring Security 更轻量级，API 更直观易懂。同样提供认证、授权、会话管理、加密等功能。对于不熟悉 Spring 或觉得 Spring Security 太重的项目，是一个不错的选择。
+3. **Sa-Token:** 国产的轻量级 Java 权限认证框架。支持认证授权、单点登录、踢人下线、自动续签等功能。相比于 Spring Security 和 Shiro 来说，Sa-Token 内置的开箱即用的功能更多，使用也更简单。
+4. **手动检查 (不推荐用于复杂场景):** 在 Service 层或 Controller 层代码里，手动获取当前用户信息（例如从 SecurityContextHolder 或 Session 中），然后 if-else 判断用户角色或权限。权限逻辑与业务逻辑耦合、代码重复、难以维护、容易遗漏。只适用于非常简单的权限场景。
+
+**权限模型简介:**
+
+- **RBAC (Role-Based Access Control):** 基于角色的访问控制。给用户分配角色，给角色分配权限。用户拥有其所有角色的权限总和。这是最常见的模型。
+- **ABAC (Attribute-Based Access Control):** 基于属性的访问控制。决策基于用户属性、资源属性、操作属性和环境属性。更灵活但也更复杂。
+
+一般情况下，绝大部分系统都使用的是 RBAC 权限模型或者其简化版本。用一个图来描述如下：
+
+
+
+关于权限系统设计的详细介绍，可以看这篇文章：[权限系统设计详解](https://javaguide.cn/system-design/security/design-of-authority-system.html)。
+
+## 总结
+
+总而言之，要想构建一个安全、稳定、用户体验好的 Web 应用，前后端数据校验和后端权限校验这三道关卡，都得设好，而且各有侧重：
+
+- **前端数据校验：** 提升用户体验，减少无效请求，是第一道“友好”的防线。
+- **后端数据校验：** 保证数据格式正确、符合业务规则，是防止“脏数据”入库的“技术”防线。 Bean Validation 允许我们用注解的方式，直接在 JavaBean（比如我们的 DTO 对象）的属性上声明校验规则，非常方便。
+- **后端权限校验：** 确保“对的人”做“对的事”，是防止越权操作的“安全”防线。Spring Security、Shiro、Sa-Token 等框架可以帮助我们实现权限校验。
+
+## 参考
+
+- 为什么前后端都需要进行数据校验？:
+- 权限系统设计详解：
diff --git a/docs/system-design/security/encryption-algorithms.md b/docs/system-design/security/encryption-algorithms.md
index 94573d69e10..cb75b10a415 100644
--- a/docs/system-design/security/encryption-algorithms.md
+++ b/docs/system-design/security/encryption-algorithms.md
@@ -7,19 +7,23 @@ tag:
加密算法是一种用数学方法对数据进行变换的技术，目的是保护数据的安全，防止被未经授权的人读取或修改。加密算法可以分为三大类：对称加密算法、非对称加密算法和哈希算法（也叫摘要算法）。
-日常开发中常见的需要用到的加密算法的场景：
+日常开发中常见的需要用到加密算法的场景：
1. 保存在数据库中的密码需要加盐之后使用哈希算法（比如 BCrypt）进行加密。
2. 保存在数据库中的银行卡号、身份号这类敏感数据需要使用对称加密算法（比如 AES）保存。
3. 网络传输的敏感数据比如银行卡号、身份号需要用 HTTPS + 非对称加密算法（如 RSA）来保证传输数据的安全性。
4. ……
+ps: 严格上来说，哈希算法其实不属于加密算法，只是可以用到某些加密场景中（例如密码加密），两者可以看作是并列关系。加密算法通常指的是可以将明文转换为密文，并且能够通过某种方式（如密钥）再将密文还原为明文的算法。而哈希算法是一种单向过程，它将输入信息转换成一个固定长度的、看似随机的哈希值，但这个过程是不可逆的，也就是说，不能从哈希值还原出原始信息。
+
## 哈希算法
哈希算法也叫散列函数或摘要算法，它的作用是对任意长度的数据生成一个固定长度的唯一标识，也叫哈希值、散列值或消息摘要（后文统称为哈希值）。
+哈希算法的是不可逆的，你无法通过哈希之后的值再得到原值。
+
哈希值的作用是可以用来验证数据的完整性和一致性。
举两个实际的例子：
@@ -32,17 +36,19 @@ tag:
- 不能从哈希值还原出原始数据。
- 原始数据的任何改变都会导致哈希值的巨大变化。
-哈希算法分为两类：
+哈希算法可以简单分为两类：
+
+1. **加密哈希算法**：安全性较高的哈希算法，它可以提供一定的数据完整性保护和数据防篡改能力，能够抵御一定的攻击手段，安全性相对较高，但性能较差，适用于对安全性要求较高的场景。例如 SHA2、SHA3、SM3、RIPEMD-160、BLAKE2、SipHash 等等。
+2. **非加密哈希算法**：安全性相对较低的哈希算法，易受到暴力破解、冲突攻击等攻击手段的影响，但性能较高，适用于对安全性没有要求的业务场景。例如 CRC32、MurMurHash3、SipHash 等等。
-- **加密哈希算法**：安全性较高的哈希算法，它可以提供一定的数据完整性保护和数据防篡改能力，能够抵御一定的攻击手段，安全性相对较高，适用于对安全性要求较高的场景。例如，SHA-256、SHA-512、SM3、Bcrypt 等等。
-- **非加密哈希算法**：安全性相对较低的哈希算法，易受到暴力破解、冲突攻击等攻击手段的影响，但性能较高，适用于对安全性没有要求的业务场景。例如，CRC32、MurMurHash3 等等。
+除了这两种之外，还有一些特殊的哈希算法，例如安全性更高的**慢哈希算法**。
常见的哈希算法有：
- MD（Message Digest，消息摘要算法）：MD2、MD4、MD5 等，已经不被推荐使用。
- SHA（Secure Hash Algorithm，安全哈希算法）：SHA-1 系列安全性低，SHA2，SHA3 系列安全性较高。
- 国密算法：例如 SM2、SM3、SM4，其中 SM2 为非对称加密算法，SM4 为对称加密算法，SM3 为哈希算法（安全性及效率和 SHA-256 相当，但更适合国内的应用环境）。
-- Bcrypt（密码哈希算法）：基于 Blowfish 加密算法的密码哈希算法，专门为密码加密而设计，安全性高。
+- Bcrypt（密码哈希算法）：基于 Blowfish 加密算法的密码哈希算法，专门为密码加密而设计，安全性高，属于慢哈希算法。
- MAC（Message Authentication Code，消息认证码算法）：HMAC 是一种基于哈希的 MAC，可以与任何安全的哈希算法结合使用，例如 SHA-256。
- CRC：（Cyclic Redundancy Check，循环冗余校验）：CRC32 是一种 CRC 算法，它的特点是生成 32 位的校验值，通常用于数据完整性校验、文件校验等场景。
- SipHash：加密哈希算法，它的设计目的是在速度和安全性之间达到一个平衡，用于防御[哈希泛洪 DoS 攻击](https://aumasson.jp/siphash/siphashdos_29c3_slides.pdf)。Rust 默认使用 SipHash 作为哈希算法，从 Redis4.0 开始，哈希算法被替换为 SipHash。
@@ -360,8 +366,8 @@ DSA 算法签名过程：
## 参考
-- 深入理解完美哈希 - 腾讯技术工程：https://mp.weixin.qq.com/s/M8Wcj8sZ7UF1CMr887Puog
-- 写给开发人员的实用密码学（二）—— 哈希函数：https://thiscute.world/posts/practical-cryptography-basics-2-hash/
+- 深入理解完美哈希 - 腾讯技术工程：
+- 写给开发人员的实用密码学（二）—— 哈希函数：
- AES-GCM 加密简介：
- Java AES 256 GCM Encryption and Decryption Example | JCE Unlimited Strength：。
+
+Docker Compose 的核心功能：
+
+- **多容器管理**：允许用户在一个 YAML 文件中定义和管理多个容器。
+- **服务编排**：配置容器间的网络和依赖关系。
+- **一键部署**：通过简单的命令，如`docker-compose up`和`docker-compose down`，可以轻松地启动和停止整个应用程序。
+
+Docker Compose 简化了多容器应用程序的开发、测试和部署过程，提高了开发团队的生产力，同时降低了应用程序的部署复杂度和管理成本。
+
+### Docker Compose 文件基本结构
+
+Docker Compose 文件是 Docker Compose 工具的核心，用于定义和配置多容器 Docker 应用。这个文件通常命名为 `docker-compose.yml`，采用 YAML（YAML Ain't Markup Language）格式编写。
+
+Docker Compose 文件基本结构如下：
+
+- **版本（version）：** 指定 Compose 文件格式的版本。版本决定了可用的配置选项。
+- **服务（services）：** 定义了应用中的每个容器（服务）。每个服务可以使用不同的镜像、环境设置和依赖关系。
+ - **镜像（image）：** 从指定的镜像中启动容器，可以是存储仓库、标签以及镜像 ID。
+ - **命令（command）：** 可选，覆盖容器启动后默认执行的命令。在启动服务时运行特定的命令或脚本，常用于启动应用程序、执行初始化脚本等。
+ - **端口（ports）：** 可选，映射容器和宿主机的端口。
+ - **依赖（depends_on）：** 依赖配置的选项，意思是如果服务启动是如果有依赖于其他服务的，先启动被依赖的服务，启动完成后在启动该服务。
+ - **环境变量（environment）：** 可选，设置服务运行所需的环境变量。
+ - **重启（restart）:** 可选，控制容器的重启策略。在容器退出时，根据指定的策略自动重启容器。
+ - **服务卷（volumes）:** 可选，定义服务使用的卷，用于数据持久化或在容器之间共享数据。
+ - **构建（build）：** 指定构建镜像的 dockerfile 的上下文路径，或者详细配置对象。
+- **网络（networks）：** 定义了容器间的网络连接。
+- **卷（volumes）：** 用于数据持久化和共享的数据卷定义。常用于数据库存储、配置文件、日志等数据的持久化。
+
+```yaml
+version: "3.8" # 定义版本， 表示当前使用的 docker-compose 语法的版本
+services: # 服务，可以存在多个
+ servicename1: # 服务名字，它也是内部 bridge 网络可以使用的 DNS name，如果不是集群模式相当于 docker run 的时候指定的一个名称，
+ #集群（Swarm）模式是多个容器的逻辑抽象
+ image: # 镜像的名字
+ command: # 可选，如果设置，则会覆盖默认镜像里的 CMD 命令
+ environment: # 可选，等价于 docker container run 里的 --env 选项设置环境变量
+ volumes: # 可选，等价于 docker container run 里的 -v 选项 绑定数据卷
+ networks: # 可选，等价于 docker container run 里的 --network 选项指定网络
+ ports: # 可选，等价于 docker container run 里的 -p 选项指定端口映射
+ restart: # 可选，控制容器的重启策略
+ build: #构建目录
+ depends_on: #服务依赖配置
+ servicename2:
+ image:
+ command:
+ networks:
+ ports:
+ servicename3:
+ #...
+volumes: # 可选，需要创建的数据卷，类似 docker volume create
+ db_data:
+networks: # 可选，等价于 docker network create
+```
+
+### Docker Compose 常见命令
-**Docker 运行过程也就是去仓库把镜像拉到本地，然后用一条命令把镜像运行起来变成容器。所以，我们也常常将 Docker 称为码头工人或码头装卸工，这和 Docker 的中文翻译搬运工人如出一辙。**
+#### 启动
-## 七 简单了解一下 Docker 底层原理
+`docker-compose up`会根据 `docker-compose.yml` 文件中定义的服务来创建和启动容器，并将它们连接到默认的网络中。
-### 7.1 虚拟化技术
+```bash
+# 在当前目录下寻找 docker-compose.yml 文件，并根据其中定义的服务启动应用程序
+docker-compose up
+# 后台启动
+docker-compose up -d
+# 强制重新创建所有容器，即使它们已经存在
+docker-compose up --force-recreate
+# 重新构建镜像
+docker-compose up --build
+# 指定要启动的服务名称，而不是启动所有服务
+# 可以同时指定多个服务，用空格分隔。
+docker-compose up service_name
+```
+
+另外，如果 Compose 文件名称不是 `docker-compose.yml` 也没问题，可以通过 `-f` 参数指定。
+
+```bash
+docker-compose -f docker-compose.prod.yml up
+```
+
+#### 暂停
+
+`docker-compose down`用于停止并移除通过 `docker-compose up` 启动的容器和网络。
+
+```bash
+# 在当前目录下寻找 docker-compose.yml 文件
+# 根据其中定义移除启动的所有容器，网络和卷。
+docker-compose down
+# 停止容器但不移除
+docker-compose down --stop
+# 指定要停止和移除的特定服务，而不是停止和移除所有服务
+# 可以同时指定多个服务，用空格分隔。
+docker-compose down service_name
+```
+
+同样地，如果 Compose 文件名称不是 `docker-compose.yml` 也没问题，可以通过 `-f` 参数指定。
-首先，Docker **容器虚拟化**技术为基础的软件，那么什么是虚拟化技术呢？
+```bash
+docker-compose -f docker-compose.prod.yml down
+```
+
+#### 查看
+
+`docker-compose ps`用于查看通过 `docker-compose up` 启动的所有容器的状态信息。
+
+```bash
+# 查看所有容器的状态信息
+docker-compose ps
+# 只显示服务名称
+docker-compose ps --services
+# 查看指定服务的容器
+docker-compose ps service_name
+```
+
+#### 其他
+
+| 命令 | 介绍 |
+| ------------------------ | ---------------------- |
+| `docker-compose version` | 查看版本 |
+| `docker-compose images` | 列出所有容器使用的镜像 |
+| `docker-compose kill` | 强制停止服务的容器 |
+| `docker-compose exec` | 在容器中执行命令 |
+| `docker-compose logs` | 查看日志 |
+| `docker-compose pause` | 暂停服务 |
+| `docker-compose unpause` | 恢复服务 |
+| `docker-compose push` | 推送服务镜像 |
+| `docker-compose start` | 启动当前停止的某个容器 |
+| `docker-compose stop` | 停止当前运行的某个容器 |
+| `docker-compose rm` | 删除服务停止的容器 |
+| `docker-compose top` | 查看进程 |
+
+## Docker 底层原理
+
+首先，Docker 是基于轻量级虚拟化技术的软件，那什么是虚拟化技术呢？
简单点来说，虚拟化技术可以这样定义：
> 虚拟化技术是一种资源管理技术，是将计算机的各种[实体资源](https://zh.wikipedia.org/wiki/計算機科學 "实体资源"))（[CPU](https://zh.wikipedia.org/wiki/CPU "CPU")、[内存](https://zh.wikipedia.org/wiki/内存 "内存")、[磁盘空间](https://zh.wikipedia.org/wiki/磁盘空间 "磁盘空间")、[网络适配器](https://zh.wikipedia.org/wiki/網路適配器 "网络适配器")等），予以抽象、转换后呈现出来并可供分割、组合为一个或多个电脑配置环境。由此，打破实体结构间的不可切割的障碍，使用户可以比原本的配置更好的方式来应用这些电脑硬件资源。这些资源的新虚拟部分是不受现有资源的架设方式，地域或物理配置所限制。一般所指的虚拟化资源包括计算能力和数据存储。
-### 7.2 Docker 基于 LXC 虚拟容器技术
-
Docker 技术是基于 LXC（Linux container- Linux 容器）虚拟容器技术的。
> LXC，其名称来自 Linux 软件容器（Linux Containers）的缩写，一种操作系统层虚拟化（Operating system–level virtualization）技术，为 Linux 内核容器功能的一个用户空间接口。它将应用软件系统打包成一个软件容器（Container），内含应用软件本身的代码，以及所需要的操作系统核心和库。通过统一的名字空间和共用 API 来分配不同软件容器的可用硬件资源，创造出应用程序的独立沙箱运行环境，使得 Linux 用户可以容易的创建和管理系统或应用容器。
@@ -273,9 +461,9 @@ LXC 技术主要是借助 Linux 内核中提供的 CGroup 功能和 namespace
- **namespace 是 Linux 内核用来隔离内核资源的方式。** 通过 namespace 可以让一些进程只能看到与自己相关的一部分资源，而另外一些进程也只能看到与它们自己相关的资源，这两拨进程根本就感觉不到对方的存在。具体的实现方式是把一个或多个进程的相关资源指定在同一个 namespace 中。Linux namespaces 是对全局系统资源的一种封装隔离，使得处于不同 namespace 的进程拥有独立的全局系统资源，改变一个 namespace 中的系统资源只会影响当前 namespace 里的进程，对其他 namespace 中的进程没有影响。
- （以上关于 namespace 介绍内容来自 ，更多关于 namespace 的呢内容可以查看这篇文章 ）。
+ （以上关于 namespace 介绍内容来自 ，更多关于 namespace 的内容可以查看这篇文章 ）。
-- **CGroup 是 Control Groups 的缩写，是 Linux 内核提供的一种可以限制、记录、隔离进程组 (process groups) 所使用的物力资源 (如 cpu memory i/o 等等) 的机制。**
+- **CGroup 是 Control Groups 的缩写，是 Linux 内核提供的一种可以限制、记录、隔离进程组 (process groups) 所使用的物理资源 (如 cpu memory i/o 等等) 的机制。**
（以上关于 CGroup 介绍内容来自 ，更多关于 CGroup 的内容可以查看这篇文章 ）。
@@ -283,17 +471,17 @@ LXC 技术主要是借助 Linux 内核中提供的 CGroup 功能和 namespace
两者都是将进程进行分组，但是两者的作用还是有本质区别。namespace 是为了隔离进程组之间的资源，而 cgroup 是为了对一组进程进行统一的资源监控和限制。
-## 八 总结
+## 总结
-本文主要把 Docker 中的一些常见概念做了详细的阐述，但是并不涉及 Docker 的安装、镜像的使用、容器的操作等内容。这部分东西，希望读者自己可以通过阅读书籍与官方文档的形式掌握。如果觉得官方文档阅读起来很费力的话，这里推荐一本书籍《Docker 技术入门与实战第二版》。
+本文主要把 Docker 中的一些常见概念和命令做了详细的阐述。从零到上手实战可以看[Docker 从入门到上手干事](https://javaguide.cn/tools/docker/docker-in-action.html)这篇文章，内容非常详细！
-## 九 推荐阅读
+另外，再给大家推荐一本质量非常高的开源书籍[《Docker 从入门到实践》](https://yeasy.gitbook.io/docker_practice/introduction/why "《Docker 从入门到实践》") ，这本书的内容非常新，毕竟书籍的内容是开源的，可以随时改进。
-- [10 分钟看懂 Docker 和 K8S](https://zhuanlan.zhihu.com/p/53260098 "10分钟看懂Docker和K8S")
-- [从零开始入门 K8s：详解 K8s 容器基本概念](https://www.infoq.cn/article/te70FlSyxhltL1Cr7gzM "从零开始入门 K8s：详解 K8s 容器基本概念")
+
-## 十 参考
+## 参考
+- [Docker Compose：从零基础到实战应用的全面指南](https://juejin.cn/post/7306756690727747610)
- [Linux Namespace 和 Cgroup](https://segmentfault.com/a/1190000009732550 "Linux Namespace和Cgroup")
- [LXC vs Docker: Why Docker is Better](https://www.upguard.com/articles/docker-vs-lxc "LXC vs Docker: Why Docker is Better")
- [CGroup 介绍、应用实例及原理描述](https://www.ibm.com/developerworks/cn/linux/1506_cgroup/index.html "CGroup 介绍、应用实例及原理描述")
diff --git a/docs/tools/gradle/gradle-core-concepts.md b/docs/tools/gradle/gradle-core-concepts.md
index d699351f315..7f0763c0fec 100644
--- a/docs/tools/gradle/gradle-core-concepts.md
+++ b/docs/tools/gradle/gradle-core-concepts.md
@@ -78,7 +78,7 @@ Gradle Wrapper 会给我们带来下面这些好处：
### 生成 Gradle Wrapper
-如果想要生成 Gradle Wrapper 的话，需要本地配置好 Gradle 环境变量。Gradle 中已经内置了内置了 Wrapper Task，在项目根目录执行执行`gradle wrapper`命令即可帮助我们生成 Gradle Wrapper。
+如果想要生成 Gradle Wrapper 的话，需要本地配置好 Gradle 环境变量。Gradle 中已经内置了 Wrapper Task，在项目根目录执行执行`gradle wrapper`命令即可帮助我们生成 Gradle Wrapper。
执行命令 `gradle wrapper` 命令时可以指定一些参数来控制 wrapper 的生成。具体有如下两个配置参数：
diff --git a/docs/tools/maven/maven-best-practices.md b/docs/tools/maven/maven-best-practices.md
index 120c194e772..0f682f46d1d 100644
--- a/docs/tools/maven/maven-best-practices.md
+++ b/docs/tools/maven/maven-best-practices.md
@@ -23,12 +23,12 @@ Maven 遵循标准目录结构来保持项目之间的一致性。遵循这种
Maven 项目的标准目录结构如下：
```groovy
-src /
- main /
+src/
+ main/
java/
resources/
- test/ java
- /
+ test/
+ java/
resources/
pom.xml
```
diff --git a/docs/tools/maven/maven-core-concepts.md b/docs/tools/maven/maven-core-concepts.md
index 07f46bc5cb2..14b344d7524 100644
--- a/docs/tools/maven/maven-core-concepts.md
+++ b/docs/tools/maven/maven-core-concepts.md
@@ -197,7 +197,7 @@ Maven 在遇到这种问题的时候，会遵循 **路径最短优先** 和 **
根据路径最短优先原则，X(1.0) 会被解析使用，也就是说实际用的是 1.0 版本的 X。
-但是！！！这会一些问题：如果 D 依赖用到了 1.5 版本的 X 中才有的一个类，运行项目就会报`NoClassDefFoundError`错误。如果 D 依赖用到了 1.5 版本的 X 中才有的一个方法，运行项目就会报`NoSuchMethodError`错误。
+但是！！！这会一些问题：如果 C 依赖用到了 1.5 版本的 X 中才有的一个类，运行项目就会报`NoClassDefFoundError`错误。如果 C 依赖用到了 1.5 版本的 X 中才有的一个方法，运行项目就会报`NoSuchMethodError`错误。
现在知道为什么你的 Maven 项目总是会报`NoClassDefFoundError`和`NoSuchMethodError`错误了吧？
@@ -217,7 +217,7 @@ Maven 在遇到这种问题的时候，会遵循 **路径最短优先** 和 **
一般我们在解决依赖冲突的时候，都会优先保留版本较高的。这是因为大部分 jar 在升级的时候都会做到向下兼容。
-如果高版本修改了低版本的一些类或者方法的话，这个时候就能直接保留高版本了，而是应该考虑优化上层依赖，比如升级上层依赖的版本。
+如果高版本修改了低版本的一些类或者方法的话，这个时候就不能直接保留高版本了，而是应该考虑优化上层依赖，比如升级上层依赖的版本。
还是上面的例子：
diff --git a/docs/zhuanlan/readme.md b/docs/zhuanlan/README.md
similarity index 100%
rename from docs/zhuanlan/readme.md
rename to docs/zhuanlan/README.md
diff --git a/package.json b/package.json
index 2dab8c67c23..fa13424e049 100644
--- a/package.json
+++ b/package.json
@@ -19,20 +19,19 @@
"**/*": "prettier --write --ignore-unknown",
".md": "markdownlint-cli2"
},
- "packageManager": "pnpm@8.15.1",
"dependencies": {
- "@vuepress/bundler-vite": "2.0.0-rc.9",
- "@vuepress/plugin-copyright": "2.0.0-rc.21",
- "@vuepress/plugin-feed": "2.0.0-rc.21",
- "@vuepress/plugin-search": "2.0.0-rc.21",
- "husky": "9.0.10",
- "markdownlint-cli2": "0.12.1",
+ "@vuepress/bundler-vite": "2.0.0-rc.19",
+ "@vuepress/plugin-feed": "2.0.0-rc.70",
+ "@vuepress/plugin-search": "2.0.0-rc.70",
+ "husky": "9.1.7",
+ "markdownlint-cli2": "0.17.1",
"mathjax-full": "3.2.2",
"nano-staged": "0.8.0",
- "nodejs-jieba": "0.1.2",
- "prettier": "3.2.5",
- "vue": "^3.4.21",
- "vuepress": "2.0.0-rc.9",
- "vuepress-theme-hope": "2.0.0-rc.32"
- }
+ "prettier": "3.4.2",
+ "sass-embedded": "1.83.1",
+ "vue": "^3.5.13",
+ "vuepress": "2.0.0-rc.19",
+ "vuepress-theme-hope": "2.0.0-rc.68"
+ },
+ "packageManager": "pnpm@10.0.0"
}
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index dfad3795844..d174a9236f9 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -1,2695 +1,1997 @@
-lockfileVersion: '6.1'
+lockfileVersion: '9.0'
settings:
autoInstallPeers: true
excludeLinksFromLockfile: false
-dependencies:
- '@vuepress/bundler-vite':
- specifier: 2.0.0-rc.9
- version: 2.0.0-rc.9
- '@vuepress/plugin-copyright':
- specifier: 2.0.0-rc.21
- version: 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-feed':
- specifier: 2.0.0-rc.21
- version: 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-search':
- specifier: 2.0.0-rc.21
- version: 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- husky:
- specifier: 9.0.10
- version: 9.0.10
- markdownlint-cli2:
- specifier: 0.12.1
- version: 0.12.1
- mathjax-full:
- specifier: 3.2.2
- version: 3.2.2
- nano-staged:
- specifier: 0.8.0
- version: 0.8.0
- nodejs-jieba:
- specifier: 0.1.2
- version: 0.1.2
- prettier:
- specifier: 3.2.5
- version: 3.2.5
- vue:
- specifier: ^3.4.21
- version: 3.4.21
- vuepress:
- specifier: 2.0.0-rc.9
- version: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- vuepress-theme-hope:
- specifier: 2.0.0-rc.32
- version: 2.0.0-rc.32(@vuepress/plugin-feed@2.0.0-rc.21)(@vuepress/plugin-search@2.0.0-rc.21)(markdown-it@14.1.0)(mathjax-full@3.2.2)(nodejs-jieba@0.1.2)(vuepress@2.0.0-rc.9)
+importers:
+
+ .:
+ dependencies:
+ '@vuepress/bundler-vite':
+ specifier: 2.0.0-rc.19
+ version: 2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1)
+ '@vuepress/plugin-feed':
+ specifier: 2.0.0-rc.70
+ version: 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-search':
+ specifier: 2.0.0-rc.70
+ version: 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ husky:
+ specifier: 9.1.7
+ version: 9.1.7
+ markdownlint-cli2:
+ specifier: 0.17.1
+ version: 0.17.1
+ mathjax-full:
+ specifier: 3.2.2
+ version: 3.2.2
+ nano-staged:
+ specifier: 0.8.0
+ version: 0.8.0
+ prettier:
+ specifier: 3.4.2
+ version: 3.4.2
+ sass-embedded:
+ specifier: 1.83.1
+ version: 1.83.1
+ vue:
+ specifier: ^3.5.13
+ version: 3.5.13
+ vuepress:
+ specifier: 2.0.0-rc.19
+ version: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ vuepress-theme-hope:
+ specifier: 2.0.0-rc.68
+ version: 2.0.0-rc.68(@vuepress/plugin-feed@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)))(@vuepress/plugin-search@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)))(katex@0.16.20)(markdown-it@14.1.0)(mathjax-full@3.2.2)(nodejs-jieba@0.2.1(encoding@0.1.13))(sass-embedded@1.83.1)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
packages:
- /@babel/helper-string-parser@7.24.1:
- resolution: {integrity: sha512-2ofRCjnnA9y+wk8b9IAREroeUP02KHp431N2mhKniy2yKIDKpbrHv9eXwm8cBeWQYcJmzv5qKCu65P47eCF7CQ==}
+ '@babel/helper-string-parser@7.25.9':
+ resolution: {integrity: sha512-4A/SCr/2KLd5jrtOMFzaKjVtAei3+2r/NChoBNoZ3EyP/+GlhoaEGoWOZUmFmoITP7zOJyHIMm+DYRd8o3PvHA==}
engines: {node: '>=6.9.0'}
- dev: false
- /@babel/helper-validator-identifier@7.22.20:
- resolution: {integrity: sha512-Y4OZ+ytlatR8AI+8KZfKuL5urKp7qey08ha31L8b3BwewJAoJamTzyvxPR/5D+KkdJCGPq/+8TukHBlY10FX9A==}
+ '@babel/helper-validator-identifier@7.25.9':
+ resolution: {integrity: sha512-Ed61U6XJc3CVRfkERJWDz4dJwKe7iLmmJsbOGu9wSloNSFttHV0I8g6UAgb7qnK5ly5bGLPd4oXZlxCdANBOWQ==}
engines: {node: '>=6.9.0'}
- dev: false
- /@babel/parser@7.24.1:
- resolution: {integrity: sha512-Zo9c7N3xdOIQrNip7Lc9wvRPzlRtovHVE4lkz8WEDr7uYh/GMQhSiIgFxGIArRHYdJE5kxtZjAf8rT0xhdLCzg==}
+ '@babel/parser@7.26.5':
+ resolution: {integrity: sha512-SRJ4jYmXRqV1/Xc+TIVG84WjHBXKlxO9sHQnA2Pf12QQEAp1LOh6kDzNHXcUnbH1QI0FDoPPVOt+vyUDucxpaw==}
engines: {node: '>=6.0.0'}
hasBin: true
- dependencies:
- '@babel/types': 7.24.0
- dev: false
- /@babel/types@7.24.0:
- resolution: {integrity: sha512-+j7a5c253RfKh8iABBhywc8NSfP5LURe7Uh4qpsh6jc+aLJguvmIUBdjSdEMQv2bENrCR5MfRdjGo7vzS/ob7w==}
+ '@babel/types@7.26.5':
+ resolution: {integrity: sha512-L6mZmwFDK6Cjh1nRCLXpa6no13ZIioJDz7mdkzHv399pThrTa/k0nUlNaenOeh2kWu/iaOQYElEpKPUswUa9Vg==}
engines: {node: '>=6.9.0'}
- dependencies:
- '@babel/helper-string-parser': 7.24.1
- '@babel/helper-validator-identifier': 7.22.20
- to-fast-properties: 2.0.0
- dev: false
- /@esbuild/aix-ppc64@0.20.2:
- resolution: {integrity: sha512-D+EBOJHXdNZcLJRBkhENNG8Wji2kgc9AZ9KiPr1JuZjsNtyHzrsfLRrY0tk2H2aoFu6RANO1y1iPPUCDYWkb5g==}
+ '@bufbuild/protobuf@2.2.3':
+ resolution: {integrity: sha512-tFQoXHJdkEOSwj5tRIZSPNUuXK3RaR7T1nUrPgbYX1pUbvqqaaZAsfo+NXBPsz5rZMSKVFrgK1WL8Q/MSLvprg==}
+
+ '@esbuild/aix-ppc64@0.21.5':
+ resolution: {integrity: sha512-1SDgH6ZSPTlggy1yI6+Dbkiz8xzpHJEVAlF/AM1tHPLsf5STom9rwtjE4hKAF20FfXXNTFqEYXyJNWh1GiZedQ==}
engines: {node: '>=12'}
cpu: [ppc64]
os: [aix]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/android-arm64@0.20.2:
- resolution: {integrity: sha512-mRzjLacRtl/tWU0SvD8lUEwb61yP9cqQo6noDZP/O8VkwafSYwZ4yWy24kan8jE/IMERpYncRt2dw438LP3Xmg==}
+ '@esbuild/aix-ppc64@0.24.2':
+ resolution: {integrity: sha512-thpVCb/rhxE/BnMLQ7GReQLLN8q9qbHmI55F4489/ByVg2aQaQ6kbcLb6FHkocZzQhxc4gx0sCk0tJkKBFzDhA==}
+ engines: {node: '>=18'}
+ cpu: [ppc64]
+ os: [aix]
+
+ '@esbuild/android-arm64@0.21.5':
+ resolution: {integrity: sha512-c0uX9VAUBQ7dTDCjq+wdyGLowMdtR/GoC2U5IYk/7D1H1JYC0qseD7+11iMP2mRLN9RcCMRcjC4YMclCzGwS/A==}
engines: {node: '>=12'}
cpu: [arm64]
os: [android]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/android-arm@0.20.2:
- resolution: {integrity: sha512-t98Ra6pw2VaDhqNWO2Oph2LXbz/EJcnLmKLGBJwEwXX/JAN83Fym1rU8l0JUWK6HkIbWONCSSatf4sf2NBRx/w==}
+ '@esbuild/android-arm64@0.24.2':
+ resolution: {integrity: sha512-cNLgeqCqV8WxfcTIOeL4OAtSmL8JjcN6m09XIgro1Wi7cF4t/THaWEa7eL5CMoMBdjoHOTh/vwTO/o2TRXIyzg==}
+ engines: {node: '>=18'}
+ cpu: [arm64]
+ os: [android]
+
+ '@esbuild/android-arm@0.21.5':
+ resolution: {integrity: sha512-vCPvzSjpPHEi1siZdlvAlsPxXl7WbOVUBBAowWug4rJHb68Ox8KualB+1ocNvT5fjv6wpkX6o/iEpbDrf68zcg==}
engines: {node: '>=12'}
cpu: [arm]
os: [android]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/android-x64@0.20.2:
- resolution: {integrity: sha512-btzExgV+/lMGDDa194CcUQm53ncxzeBrWJcncOBxuC6ndBkKxnHdFJn86mCIgTELsooUmwUm9FkhSp5HYu00Rg==}
+ '@esbuild/android-arm@0.24.2':
+ resolution: {integrity: sha512-tmwl4hJkCfNHwFB3nBa8z1Uy3ypZpxqxfTQOcHX+xRByyYgunVbZ9MzUUfb0RxaHIMnbHagwAxuTL+tnNM+1/Q==}
+ engines: {node: '>=18'}
+ cpu: [arm]
+ os: [android]
+
+ '@esbuild/android-x64@0.21.5':
+ resolution: {integrity: sha512-D7aPRUUNHRBwHxzxRvp856rjUHRFW1SdQATKXH2hqA0kAZb1hKmi02OpYRacl0TxIGz/ZmXWlbZgjwWYaCakTA==}
engines: {node: '>=12'}
cpu: [x64]
os: [android]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/darwin-arm64@0.20.2:
- resolution: {integrity: sha512-4J6IRT+10J3aJH3l1yzEg9y3wkTDgDk7TSDFX+wKFiWjqWp/iCfLIYzGyasx9l0SAFPT1HwSCR+0w/h1ES/MjA==}
+ '@esbuild/android-x64@0.24.2':
+ resolution: {integrity: sha512-B6Q0YQDqMx9D7rvIcsXfmJfvUYLoP722bgfBlO5cGvNVb5V/+Y7nhBE3mHV9OpxBf4eAS2S68KZztiPaWq4XYw==}
+ engines: {node: '>=18'}
+ cpu: [x64]
+ os: [android]
+
+ '@esbuild/darwin-arm64@0.21.5':
+ resolution: {integrity: sha512-DwqXqZyuk5AiWWf3UfLiRDJ5EDd49zg6O9wclZ7kUMv2WRFr4HKjXp/5t8JZ11QbQfUS6/cRCKGwYhtNAY88kQ==}
engines: {node: '>=12'}
cpu: [arm64]
os: [darwin]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/darwin-x64@0.20.2:
- resolution: {integrity: sha512-tBcXp9KNphnNH0dfhv8KYkZhjc+H3XBkF5DKtswJblV7KlT9EI2+jeA8DgBjp908WEuYll6pF+UStUCfEpdysA==}
+ '@esbuild/darwin-arm64@0.24.2':
+ resolution: {integrity: sha512-kj3AnYWc+CekmZnS5IPu9D+HWtUI49hbnyqk0FLEJDbzCIQt7hg7ucF1SQAilhtYpIujfaHr6O0UHlzzSPdOeA==}
+ engines: {node: '>=18'}
+ cpu: [arm64]
+ os: [darwin]
+
+ '@esbuild/darwin-x64@0.21.5':
+ resolution: {integrity: sha512-se/JjF8NlmKVG4kNIuyWMV/22ZaerB+qaSi5MdrXtd6R08kvs2qCN4C09miupktDitvh8jRFflwGFBQcxZRjbw==}
engines: {node: '>=12'}
cpu: [x64]
os: [darwin]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/freebsd-arm64@0.20.2:
- resolution: {integrity: sha512-d3qI41G4SuLiCGCFGUrKsSeTXyWG6yem1KcGZVS+3FYlYhtNoNgYrWcvkOoaqMhwXSMrZRl69ArHsGJ9mYdbbw==}
+ '@esbuild/darwin-x64@0.24.2':
+ resolution: {integrity: sha512-WeSrmwwHaPkNR5H3yYfowhZcbriGqooyu3zI/3GGpF8AyUdsrrP0X6KumITGA9WOyiJavnGZUwPGvxvwfWPHIA==}
+ engines: {node: '>=18'}
+ cpu: [x64]
+ os: [darwin]
+
+ '@esbuild/freebsd-arm64@0.21.5':
+ resolution: {integrity: sha512-5JcRxxRDUJLX8JXp/wcBCy3pENnCgBR9bN6JsY4OmhfUtIHe3ZW0mawA7+RDAcMLrMIZaf03NlQiX9DGyB8h4g==}
engines: {node: '>=12'}
cpu: [arm64]
os: [freebsd]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/freebsd-x64@0.20.2:
- resolution: {integrity: sha512-d+DipyvHRuqEeM5zDivKV1KuXn9WeRX6vqSqIDgwIfPQtwMP4jaDsQsDncjTDDsExT4lR/91OLjRo8bmC1e+Cw==}
+ '@esbuild/freebsd-arm64@0.24.2':
+ resolution: {integrity: sha512-UN8HXjtJ0k/Mj6a9+5u6+2eZ2ERD7Edt1Q9IZiB5UZAIdPnVKDoG7mdTVGhHJIeEml60JteamR3qhsr1r8gXvg==}
+ engines: {node: '>=18'}
+ cpu: [arm64]
+ os: [freebsd]
+
+ '@esbuild/freebsd-x64@0.21.5':
+ resolution: {integrity: sha512-J95kNBj1zkbMXtHVH29bBriQygMXqoVQOQYA+ISs0/2l3T9/kj42ow2mpqerRBxDJnmkUDCaQT/dfNXWX/ZZCQ==}
engines: {node: '>=12'}
cpu: [x64]
os: [freebsd]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/linux-arm64@0.20.2:
- resolution: {integrity: sha512-9pb6rBjGvTFNira2FLIWqDk/uaf42sSyLE8j1rnUpuzsODBq7FvpwHYZxQ/It/8b+QOS1RYfqgGFNLRI+qlq2A==}
+ '@esbuild/freebsd-x64@0.24.2':
+ resolution: {integrity: sha512-TvW7wE/89PYW+IevEJXZ5sF6gJRDY/14hyIGFXdIucxCsbRmLUcjseQu1SyTko+2idmCw94TgyaEZi9HUSOe3Q==}
+ engines: {node: '>=18'}
+ cpu: [x64]
+ os: [freebsd]
+
+ '@esbuild/linux-arm64@0.21.5':
+ resolution: {integrity: sha512-ibKvmyYzKsBeX8d8I7MH/TMfWDXBF3db4qM6sy+7re0YXya+K1cem3on9XgdT2EQGMu4hQyZhan7TeQ8XkGp4Q==}
engines: {node: '>=12'}
cpu: [arm64]
os: [linux]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/linux-arm@0.20.2:
- resolution: {integrity: sha512-VhLPeR8HTMPccbuWWcEUD1Az68TqaTYyj6nfE4QByZIQEQVWBB8vup8PpR7y1QHL3CpcF6xd5WVBU/+SBEvGTg==}
+ '@esbuild/linux-arm64@0.24.2':
+ resolution: {integrity: sha512-7HnAD6074BW43YvvUmE/35Id9/NB7BeX5EoNkK9obndmZBUk8xmJJeU7DwmUeN7tkysslb2eSl6CTrYz6oEMQg==}
+ engines: {node: '>=18'}
+ cpu: [arm64]
+ os: [linux]
+
+ '@esbuild/linux-arm@0.21.5':
+ resolution: {integrity: sha512-bPb5AHZtbeNGjCKVZ9UGqGwo8EUu4cLq68E95A53KlxAPRmUyYv2D6F0uUI65XisGOL1hBP5mTronbgo+0bFcA==}
engines: {node: '>=12'}
cpu: [arm]
os: [linux]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/linux-ia32@0.20.2:
- resolution: {integrity: sha512-o10utieEkNPFDZFQm9CoP7Tvb33UutoJqg3qKf1PWVeeJhJw0Q347PxMvBgVVFgouYLGIhFYG0UGdBumROyiig==}
+ '@esbuild/linux-arm@0.24.2':
+ resolution: {integrity: sha512-n0WRM/gWIdU29J57hJyUdIsk0WarGd6To0s+Y+LwvlC55wt+GT/OgkwoXCXvIue1i1sSNWblHEig00GBWiJgfA==}
+ engines: {node: '>=18'}
+ cpu: [arm]
+ os: [linux]
+
+ '@esbuild/linux-ia32@0.21.5':
+ resolution: {integrity: sha512-YvjXDqLRqPDl2dvRODYmmhz4rPeVKYvppfGYKSNGdyZkA01046pLWyRKKI3ax8fbJoK5QbxblURkwK/MWY18Tg==}
engines: {node: '>=12'}
cpu: [ia32]
os: [linux]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/linux-loong64@0.20.2:
- resolution: {integrity: sha512-PR7sp6R/UC4CFVomVINKJ80pMFlfDfMQMYynX7t1tNTeivQ6XdX5r2XovMmha/VjR1YN/HgHWsVcTRIMkymrgQ==}
+ '@esbuild/linux-ia32@0.24.2':
+ resolution: {integrity: sha512-sfv0tGPQhcZOgTKO3oBE9xpHuUqguHvSo4jl+wjnKwFpapx+vUDcawbwPNuBIAYdRAvIDBfZVvXprIj3HA+Ugw==}
+ engines: {node: '>=18'}
+ cpu: [ia32]
+ os: [linux]
+
+ '@esbuild/linux-loong64@0.21.5':
+ resolution: {integrity: sha512-uHf1BmMG8qEvzdrzAqg2SIG/02+4/DHB6a9Kbya0XDvwDEKCoC8ZRWI5JJvNdUjtciBGFQ5PuBlpEOXQj+JQSg==}
engines: {node: '>=12'}
cpu: [loong64]
os: [linux]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/linux-mips64el@0.20.2:
- resolution: {integrity: sha512-4BlTqeutE/KnOiTG5Y6Sb/Hw6hsBOZapOVF6njAESHInhlQAghVVZL1ZpIctBOoTFbQyGW+LsVYZ8lSSB3wkjA==}
+ '@esbuild/linux-loong64@0.24.2':
+ resolution: {integrity: sha512-CN9AZr8kEndGooS35ntToZLTQLHEjtVB5n7dl8ZcTZMonJ7CCfStrYhrzF97eAecqVbVJ7APOEe18RPI4KLhwQ==}
+ engines: {node: '>=18'}
+ cpu: [loong64]
+ os: [linux]
+
+ '@esbuild/linux-mips64el@0.21.5':
+ resolution: {integrity: sha512-IajOmO+KJK23bj52dFSNCMsz1QP1DqM6cwLUv3W1QwyxkyIWecfafnI555fvSGqEKwjMXVLokcV5ygHW5b3Jbg==}
engines: {node: '>=12'}
cpu: [mips64el]
os: [linux]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/linux-ppc64@0.20.2:
- resolution: {integrity: sha512-rD3KsaDprDcfajSKdn25ooz5J5/fWBylaaXkuotBDGnMnDP1Uv5DLAN/45qfnf3JDYyJv/ytGHQaziHUdyzaAg==}
+ '@esbuild/linux-mips64el@0.24.2':
+ resolution: {integrity: sha512-iMkk7qr/wl3exJATwkISxI7kTcmHKE+BlymIAbHO8xanq/TjHaaVThFF6ipWzPHryoFsesNQJPE/3wFJw4+huw==}
+ engines: {node: '>=18'}
+ cpu: [mips64el]
+ os: [linux]
+
+ '@esbuild/linux-ppc64@0.21.5':
+ resolution: {integrity: sha512-1hHV/Z4OEfMwpLO8rp7CvlhBDnjsC3CttJXIhBi+5Aj5r+MBvy4egg7wCbe//hSsT+RvDAG7s81tAvpL2XAE4w==}
engines: {node: '>=12'}
cpu: [ppc64]
os: [linux]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/linux-riscv64@0.20.2:
- resolution: {integrity: sha512-snwmBKacKmwTMmhLlz/3aH1Q9T8v45bKYGE3j26TsaOVtjIag4wLfWSiZykXzXuE1kbCE+zJRmwp+ZbIHinnVg==}
+ '@esbuild/linux-ppc64@0.24.2':
+ resolution: {integrity: sha512-shsVrgCZ57Vr2L8mm39kO5PPIb+843FStGt7sGGoqiiWYconSxwTiuswC1VJZLCjNiMLAMh34jg4VSEQb+iEbw==}
+ engines: {node: '>=18'}
+ cpu: [ppc64]
+ os: [linux]
+
+ '@esbuild/linux-riscv64@0.21.5':
+ resolution: {integrity: sha512-2HdXDMd9GMgTGrPWnJzP2ALSokE/0O5HhTUvWIbD3YdjME8JwvSCnNGBnTThKGEB91OZhzrJ4qIIxk/SBmyDDA==}
engines: {node: '>=12'}
cpu: [riscv64]
os: [linux]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/linux-s390x@0.20.2:
- resolution: {integrity: sha512-wcWISOobRWNm3cezm5HOZcYz1sKoHLd8VL1dl309DiixxVFoFe/o8HnwuIwn6sXre88Nwj+VwZUvJf4AFxkyrQ==}
+ '@esbuild/linux-riscv64@0.24.2':
+ resolution: {integrity: sha512-4eSFWnU9Hhd68fW16GD0TINewo1L6dRrB+oLNNbYyMUAeOD2yCK5KXGK1GH4qD/kT+bTEXjsyTCiJGHPZ3eM9Q==}
+ engines: {node: '>=18'}
+ cpu: [riscv64]
+ os: [linux]
+
+ '@esbuild/linux-s390x@0.21.5':
+ resolution: {integrity: sha512-zus5sxzqBJD3eXxwvjN1yQkRepANgxE9lgOW2qLnmr8ikMTphkjgXu1HR01K4FJg8h1kEEDAqDcZQtbrRnB41A==}
engines: {node: '>=12'}
cpu: [s390x]
os: [linux]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/linux-x64@0.20.2:
- resolution: {integrity: sha512-1MdwI6OOTsfQfek8sLwgyjOXAu+wKhLEoaOLTjbijk6E2WONYpH9ZU2mNtR+lZ2B4uwr+usqGuVfFT9tMtGvGw==}
+ '@esbuild/linux-s390x@0.24.2':
+ resolution: {integrity: sha512-S0Bh0A53b0YHL2XEXC20bHLuGMOhFDO6GN4b3YjRLK//Ep3ql3erpNcPlEFed93hsQAjAQDNsvcK+hV90FubSw==}
+ engines: {node: '>=18'}
+ cpu: [s390x]
+ os: [linux]
+
+ '@esbuild/linux-x64@0.21.5':
+ resolution: {integrity: sha512-1rYdTpyv03iycF1+BhzrzQJCdOuAOtaqHTWJZCWvijKD2N5Xu0TtVC8/+1faWqcP9iBCWOmjmhoH94dH82BxPQ==}
engines: {node: '>=12'}
cpu: [x64]
os: [linux]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/netbsd-x64@0.20.2:
- resolution: {integrity: sha512-K8/DhBxcVQkzYc43yJXDSyjlFeHQJBiowJ0uVL6Tor3jGQfSGHNNJcWxNbOI8v5k82prYqzPuwkzHt3J1T1iZQ==}
+ '@esbuild/linux-x64@0.24.2':
+ resolution: {integrity: sha512-8Qi4nQcCTbLnK9WoMjdC9NiTG6/E38RNICU6sUNqK0QFxCYgoARqVqxdFmWkdonVsvGqWhmm7MO0jyTqLqwj0Q==}
+ engines: {node: '>=18'}
+ cpu: [x64]
+ os: [linux]
+
+ '@esbuild/netbsd-arm64@0.24.2':
+ resolution: {integrity: sha512-wuLK/VztRRpMt9zyHSazyCVdCXlpHkKm34WUyinD2lzK07FAHTq0KQvZZlXikNWkDGoT6x3TD51jKQ7gMVpopw==}
+ engines: {node: '>=18'}
+ cpu: [arm64]
+ os: [netbsd]
+
+ '@esbuild/netbsd-x64@0.21.5':
+ resolution: {integrity: sha512-Woi2MXzXjMULccIwMnLciyZH4nCIMpWQAs049KEeMvOcNADVxo0UBIQPfSmxB3CWKedngg7sWZdLvLczpe0tLg==}
engines: {node: '>=12'}
cpu: [x64]
os: [netbsd]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/openbsd-x64@0.20.2:
- resolution: {integrity: sha512-eMpKlV0SThJmmJgiVyN9jTPJ2VBPquf6Kt/nAoo6DgHAoN57K15ZghiHaMvqjCye/uU4X5u3YSMgVBI1h3vKrQ==}
+ '@esbuild/netbsd-x64@0.24.2':
+ resolution: {integrity: sha512-VefFaQUc4FMmJuAxmIHgUmfNiLXY438XrL4GDNV1Y1H/RW3qow68xTwjZKfj/+Plp9NANmzbH5R40Meudu8mmw==}
+ engines: {node: '>=18'}
+ cpu: [x64]
+ os: [netbsd]
+
+ '@esbuild/openbsd-arm64@0.24.2':
+ resolution: {integrity: sha512-YQbi46SBct6iKnszhSvdluqDmxCJA+Pu280Av9WICNwQmMxV7nLRHZfjQzwbPs3jeWnuAhE9Jy0NrnJ12Oz+0A==}
+ engines: {node: '>=18'}
+ cpu: [arm64]
+ os: [openbsd]
+
+ '@esbuild/openbsd-x64@0.21.5':
+ resolution: {integrity: sha512-HLNNw99xsvx12lFBUwoT8EVCsSvRNDVxNpjZ7bPn947b8gJPzeHWyNVhFsaerc0n3TsbOINvRP2byTZ5LKezow==}
engines: {node: '>=12'}
cpu: [x64]
os: [openbsd]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/sunos-x64@0.20.2:
- resolution: {integrity: sha512-2UyFtRC6cXLyejf/YEld4Hajo7UHILetzE1vsRcGL3earZEW77JxrFjH4Ez2qaTiEfMgAXxfAZCm1fvM/G/o8w==}
+ '@esbuild/openbsd-x64@0.24.2':
+ resolution: {integrity: sha512-+iDS6zpNM6EnJyWv0bMGLWSWeXGN/HTaF/LXHXHwejGsVi+ooqDfMCCTerNFxEkM3wYVcExkeGXNqshc9iMaOA==}
+ engines: {node: '>=18'}
+ cpu: [x64]
+ os: [openbsd]
+
+ '@esbuild/sunos-x64@0.21.5':
+ resolution: {integrity: sha512-6+gjmFpfy0BHU5Tpptkuh8+uw3mnrvgs+dSPQXQOv3ekbordwnzTVEb4qnIvQcYXq6gzkyTnoZ9dZG+D4garKg==}
engines: {node: '>=12'}
cpu: [x64]
os: [sunos]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/win32-arm64@0.20.2:
- resolution: {integrity: sha512-GRibxoawM9ZCnDxnP3usoUDO9vUkpAxIIZ6GQI+IlVmr5kP3zUq+l17xELTHMWTWzjxa2guPNyrpq1GWmPvcGQ==}
+ '@esbuild/sunos-x64@0.24.2':
+ resolution: {integrity: sha512-hTdsW27jcktEvpwNHJU4ZwWFGkz2zRJUz8pvddmXPtXDzVKTTINmlmga3ZzwcuMpUvLw7JkLy9QLKyGpD2Yxig==}
+ engines: {node: '>=18'}
+ cpu: [x64]
+ os: [sunos]
+
+ '@esbuild/win32-arm64@0.21.5':
+ resolution: {integrity: sha512-Z0gOTd75VvXqyq7nsl93zwahcTROgqvuAcYDUr+vOv8uHhNSKROyU961kgtCD1e95IqPKSQKH7tBTslnS3tA8A==}
engines: {node: '>=12'}
cpu: [arm64]
os: [win32]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/win32-ia32@0.20.2:
- resolution: {integrity: sha512-HfLOfn9YWmkSKRQqovpnITazdtquEW8/SoHW7pWpuEeguaZI4QnCRW6b+oZTztdBnZOS2hqJ6im/D5cPzBTTlQ==}
+ '@esbuild/win32-arm64@0.24.2':
+ resolution: {integrity: sha512-LihEQ2BBKVFLOC9ZItT9iFprsE9tqjDjnbulhHoFxYQtQfai7qfluVODIYxt1PgdoyQkz23+01rzwNwYfutxUQ==}
+ engines: {node: '>=18'}
+ cpu: [arm64]
+ os: [win32]
+
+ '@esbuild/win32-ia32@0.21.5':
+ resolution: {integrity: sha512-SWXFF1CL2RVNMaVs+BBClwtfZSvDgtL//G/smwAc5oVK/UPu2Gu9tIaRgFmYFFKrmg3SyAjSrElf0TiJ1v8fYA==}
engines: {node: '>=12'}
cpu: [ia32]
os: [win32]
- requiresBuild: true
- dev: false
- optional: true
- /@esbuild/win32-x64@0.20.2:
- resolution: {integrity: sha512-N49X4lJX27+l9jbLKSqZ6bKNjzQvHaT8IIFUy+YIqmXQdjYCToGWwOItDrfby14c78aDd5NHQl29xingXfCdLQ==}
+ '@esbuild/win32-ia32@0.24.2':
+ resolution: {integrity: sha512-q+iGUwfs8tncmFC9pcnD5IvRHAzmbwQ3GPS5/ceCyHdjXubwQWI12MKWSNSMYLJMq23/IUCvJMS76PDqXe1fxA==}
+ engines: {node: '>=18'}
+ cpu: [ia32]
+ os: [win32]
+
+ '@esbuild/win32-x64@0.21.5':
+ resolution: {integrity: sha512-tQd/1efJuzPC6rCFwEvLtci/xNFcTZknmXs98FYDfGE4wP9ClFV98nyKrzJKVPMhdDnjzLhdUyMX4PsQAPjwIw==}
engines: {node: '>=12'}
cpu: [x64]
os: [win32]
- requiresBuild: true
- dev: false
- optional: true
- /@isaacs/cliui@8.0.2:
+ '@esbuild/win32-x64@0.24.2':
+ resolution: {integrity: sha512-7VTgWzgMGvup6aSqDPLiW5zHaxYJGTO4OokMjIlrCtf+VpEL+cXKtCvg723iguPYI5oaUNdS+/V7OU2gvXVWEg==}
+ engines: {node: '>=18'}
+ cpu: [x64]
+ os: [win32]
+
+ '@isaacs/cliui@8.0.2':
resolution: {integrity: sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA==}
engines: {node: '>=12'}
- dependencies:
- string-width: 5.1.2
- string-width-cjs: /string-width@4.2.3
- strip-ansi: 7.1.0
- strip-ansi-cjs: /strip-ansi@6.0.1
- wrap-ansi: 8.1.0
- wrap-ansi-cjs: /wrap-ansi@7.0.0
- dev: false
- /@jridgewell/sourcemap-codec@1.4.15:
- resolution: {integrity: sha512-eF2rxCRulEKXHTRiDrDy6erMYWqNw4LPdQ8UQA4huuxaQsVeRPFl2oM8oDGxMFhJUWZf9McpLtJasDDZb/Bpeg==}
- dev: false
+ '@jridgewell/sourcemap-codec@1.5.0':
+ resolution: {integrity: sha512-gv3ZRaISU3fjPAgNsriBRqGWQL6quFx04YMPW/zD8XMLsU32mhCCbfbO6KZFLjvYpCZ8zyDEgqsgf+PwPaM7GQ==}
- /@lit-labs/ssr-dom-shim@1.2.0:
- resolution: {integrity: sha512-yWJKmpGE6lUURKAaIltoPIE/wrbY3TEkqQt+X0m+7fQNnAv0keydnYvbiJFP1PnMhizmIWRWOG5KLhYyc/xl+g==}
- dev: false
+ '@lit-labs/ssr-dom-shim@1.3.0':
+ resolution: {integrity: sha512-nQIWonJ6eFAvUUrSlwyHDm/aE8PBDu5kRpL0vHMg6K8fK3Diq1xdPjTnsJSwxABhaZ+5eBi1btQB5ShUTKo4nQ==}
- /@lit/reactive-element@2.0.4:
+ '@lit/reactive-element@2.0.4':
resolution: {integrity: sha512-GFn91inaUa2oHLak8awSIigYz0cU0Payr1rcFsrkf5OJ5eSPxElyZfKh0f2p9FsTiZWXQdWGJeXZICEfXXYSXQ==}
- dependencies:
- '@lit-labs/ssr-dom-shim': 1.2.0
- dev: false
- /@mapbox/node-pre-gyp@1.0.11:
+ '@mapbox/node-pre-gyp@1.0.11':
resolution: {integrity: sha512-Yhlar6v9WQgUp/He7BdgzOz8lqMQ8sU+jkCq7Wx8Myc5YFJLbEe7lgui/V7G1qB1DJykHSGwreceSaD60Y0PUQ==}
hasBin: true
- dependencies:
- detect-libc: 2.0.3
- https-proxy-agent: 5.0.1
- make-dir: 3.1.0
- node-fetch: 2.7.0
- nopt: 5.0.0
- npmlog: 5.0.1
- rimraf: 3.0.2
- semver: 7.6.0
- tar: 6.2.1
- transitivePeerDependencies:
- - encoding
- - supports-color
- dev: false
- /@mdit-vue/plugin-component@2.0.0:
- resolution: {integrity: sha512-cTRxlocav/+mfgDcp0P2z/gWuWBez+iNuN4D+b74LpX4AR6UAx2ZvWtCrUZ8VXrO4eCt1/G0YC/Af7mpIb3aoQ==}
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
+ '@mdit-vue/plugin-component@2.1.3':
+ resolution: {integrity: sha512-9AG17beCgpEw/4ldo/M6Y/1Rh4E1bqMmr/rCkWKmCAxy9tJz3lzY7HQJanyHMJufwsb3WL5Lp7Om/aPcQTZ9SA==}
- /@mdit-vue/plugin-frontmatter@2.0.0:
- resolution: {integrity: sha512-/LrT6E60QI4XV4mqx3J87hqYXlR7ZyMvndmftR2RGz7cRAwa/xL+kyFLlgrMxkBIKitOShKa3LS/9Ov9b0fU+g==}
- dependencies:
- '@mdit-vue/types': 2.0.0
- '@types/markdown-it': 13.0.7
- gray-matter: 4.0.3
- markdown-it: 14.1.0
- dev: false
+ '@mdit-vue/plugin-frontmatter@2.1.3':
+ resolution: {integrity: sha512-KxsSCUVBEmn6sJcchSTiI5v9bWaoRxe68RBYRDGcSEY1GTnfQ5gQPMIsM48P4q1luLEIWurVGGrRu7u93//LDQ==}
- /@mdit-vue/plugin-headers@2.0.0:
- resolution: {integrity: sha512-ITMMPCnLEYHHgj3XEUL2l75jsNn8guxNqr26YrMSi1f5zcgq4XVy1LIvfwvJ1puqM6Cc5v4BHk3oAyorAi7l1A==}
- dependencies:
- '@mdit-vue/shared': 2.0.0
- '@mdit-vue/types': 2.0.0
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
+ '@mdit-vue/plugin-headers@2.1.3':
+ resolution: {integrity: sha512-AcL7a7LHQR3ISINhfjGJNE/bHyM0dcl6MYm1Sr//zF7ZgokPGwD/HhD7TzwmrKA9YNYCcO9P3QmF/RN9XyA6CA==}
- /@mdit-vue/plugin-sfc@2.0.0:
- resolution: {integrity: sha512-OXrMXOyk0iwdIou2jRoIHIbjskwghkO14C9/OjgVHXSSX+iM/WQ4l4yi1aWmNlbQNjtP8IXcVAyJB9K0DFYmLg==}
- dependencies:
- '@mdit-vue/types': 2.0.0
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
+ '@mdit-vue/plugin-sfc@2.1.3':
+ resolution: {integrity: sha512-Ezl0dNvQNS639Yl4siXm+cnWtQvlqHrg+u+lnau/OHpj9Xh3LVap/BSQVugKIV37eR13jXXYf3VaAOP1fXPN+w==}
- /@mdit-vue/plugin-title@2.0.0:
- resolution: {integrity: sha512-eqBoETPVkMXNLvwFshz/A2+Cz81VB5HEkXDm0tt6RBW/rTvnoWmGJ1Z+mvcjR5ck5W4nYdIyT68oHxX2JI2M4g==}
- dependencies:
- '@mdit-vue/shared': 2.0.0
- '@mdit-vue/types': 2.0.0
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
+ '@mdit-vue/plugin-title@2.1.3':
+ resolution: {integrity: sha512-XWVOQoZqczoN97xCDrnQicmXKoqwOjIymIm9HQnRXhHnYKOgJPW1CxSGhkcOGzvDU1v0mD/adojVyyj/s6ggWw==}
- /@mdit-vue/plugin-toc@2.0.0:
- resolution: {integrity: sha512-PKQ8sZna3D5chTnt2lxL+ddpyXd++6Nyc0l8VXCeDgStlySQwiP9jaLeeC88oqY4BtRu4cAmILmxDrvuX0Rrdg==}
- dependencies:
- '@mdit-vue/shared': 2.0.0
- '@mdit-vue/types': 2.0.0
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
+ '@mdit-vue/plugin-toc@2.1.3':
+ resolution: {integrity: sha512-41Q+iXpLHZt0zJdApVwoVt7WF6za/xUjtjEPf90Z3KLzQO01TXsv48Xp9BsrFHPcPcm8tiZ0+O1/ICJO80V/MQ==}
- /@mdit-vue/shared@2.0.0:
- resolution: {integrity: sha512-PdxpQpbyTazeo2JT87qms6RPZIzyJd+gwuB+1jSwLDI7+0u5g79y2XgTAbZromSVgY2f3UU5HWdwaLbV9w4uOw==}
- dependencies:
- '@mdit-vue/types': 2.0.0
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
+ '@mdit-vue/shared@2.1.3':
+ resolution: {integrity: sha512-27YI8b0VVZsAlNwaWoaOCWbr4eL8B04HxiYk/y2ktblO/nMcOEOLt4p0RjuobvdyUyjHvGOS09RKhq7qHm1CHQ==}
- /@mdit-vue/types@2.0.0:
- resolution: {integrity: sha512-1BeEB+DbtmDMUAfvbNUj5Hso8cSl2sBVK2iTyOMAqhfDVLdh+/9+D0JmQHaCeUk/vuJoMhOwbweZvh55wHxm4w==}
- dev: false
+ '@mdit-vue/types@2.1.0':
+ resolution: {integrity: sha512-TMBB/BQWVvwtpBdWD75rkZx4ZphQ6MN0O4QB2Bc0oI5PC2uE57QerhNxdRZ7cvBHE2iY2C+BUNUziCfJbjIRRA==}
- /@mdit/plugin-alert@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-mxA/lhOyDDR6/qSAegGG/XZRjUbr1wjwdULudbpkA/CCQi6piW9D0Z8crDQGYz4KPQM9Bgx4Ac81QFSzHOV66Q==}
+ '@mdit/helper@0.16.0':
+ resolution: {integrity: sha512-vUmLSZp+7UXJIYxOya9BkD0OgjgQ+6gpX+htEnc4SKaDPx4S1E7h5TE6Wy4E9Gm/JhkMHoD6TdeoQwrN/I9cLQ==}
+ engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
+ peerDependenciesMeta:
+ markdown-it:
+ optional: true
+
+ '@mdit/plugin-alert@0.16.0':
+ resolution: {integrity: sha512-T+0BUVhKjp+Azp6sNdDbiZwydDIcZP6/NAg9uivPvcsDnI9u4lMRCdXI090xNJOdhHO3l/lOsoO//s+++MJNtA==}
+ peerDependencies:
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-align@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-OJPYzSdmT0UZj/QTvnKYE4GelAL0OD8bNIPxpidXbFd3IqYv/8+xMjT6XeR+R3oZEvtbYSc2e1MmO5fo3DopJA==}
+ '@mdit/plugin-align@0.16.0':
+ resolution: {integrity: sha512-BJhOjX4Zobs+ZKEpDtxGrUCnppkFCTGIBLjXkCPmxeLf4Tsh7dqv5vVhbRueSOz/EIzc2RJzR0dlMLofsaCFeA==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@mdit/plugin-container': 0.8.0(markdown-it@14.1.0)
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-attrs@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-ewmx5i+b3M4CRJNDpDNBA0YTHa1snn+adDsDDpDtPPSzCH1NhtWXdzwI0TrcCQUnueeSEEWX/wY4ESo+NRkBNQ==}
+ '@mdit/plugin-attrs@0.16.2':
+ resolution: {integrity: sha512-ftzyOo6mDquRfpwcrSYPu9DIUhIRvC9ZTjUq1lGUd/ts93PKF9v6YCio/L376CEKLMVibHdNYBQAkGTQFwAgnA==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-container@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-uWK3t0CWssintcmT5PTJVhAwbstcD+SrtijQKs6BhLRtGGgHJ9mOf0ybGjlJhn4077yFFTHmaCIT3K+n5ZVjPg==}
+ '@mdit/plugin-container@0.16.0':
+ resolution: {integrity: sha512-NCsyEiOmoJvXSEVJSY6vaEcvbE11sciRSx5qXBvQQZxUYGYsB+ObYSFVZDFPezsEN35X3b07rurLx8P2Mi9DgQ==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-demo@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-yFRXnp3Lj0g4H9ImzHKQwwgtSykrL/BDNEQzql9fdA9FbSygfu0CIxfm+A8lsVos8cAvdsgxy3gILySxpfR89g==}
+ '@mdit/plugin-demo@0.16.0':
+ resolution: {integrity: sha512-EoSpHz8ViLk5HLBCSzQZGOa36JXGHM4q5zOJ0ppgZymxnzRr6vUo+GX022uLivxyNMW1+l30IiF+jbse+JtBGw==}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-figure@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-/o4RoKjnkdWc+K7m6mR7BAu2J79yYE38s8HUc8iKk9v+e9j1E+6LeXcpx1LoPnHzUhT4EO2QmUsv+kAaPFfZYw==}
+ '@mdit/plugin-figure@0.16.0':
+ resolution: {integrity: sha512-0lYZX3cCUNaygtQXXZH2fHXzmF7sMZ5Jbk5MXDxEDIk1Nkxj8ADo/SctvXN5exwyGpJyw8nTbm7CGgMqifDpmQ==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-footnote@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-AaX1rfkJwq9vLX+H/a+XQ3ZxahOXrnMLr5dVZfNdazjqdDEJ7Cc/A7UFtLfOM19F2w3EgvcHR1gbINxIVDn/eg==}
+ '@mdit/plugin-footnote@0.16.0':
+ resolution: {integrity: sha512-vaJWhOsya7bYfplLlMHYBxGTbME0e46/eTVKBROemWtAf873DTkV4IhkAq7MzGqeYrw0L9gxQPgGDFphGfySMA==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
+ markdown-it: ^14.1.0
+
+ '@mdit/plugin-icon@0.16.5':
+ resolution: {integrity: sha512-9T34gnNrjCMdqNLnC1oi+kZT1iCnwlHAtH3D7sjVkcP8Cw4GoDoAGy50oyryivDlczrKubOFtF05lYAfXZauuA==}
+ peerDependencies:
+ markdown-it: ^14.1.0
+ peerDependenciesMeta:
+ markdown-it:
+ optional: true
- /@mdit/plugin-img-lazyload@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-Rrlf2FzOxxyszbv3DpkIwEgmYKmtwHdxIO+Whkn0a9QckxnEKkaGl5KARCnM7LqX2fhEyFLgnfkr3onVOJG54g==}
+ '@mdit/plugin-img-lazyload@0.16.0':
+ resolution: {integrity: sha512-Ilf3e5SKG7hd+RAoYQalpjoz8LMCxCe3BBHFYerv8u4wLnKe/L0Gqc8kXSpR37flzv3Ncw/NMqmD4ZZ0QQnK9A==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-img-mark@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-4P6z2QOfLHLMSXUP4mB/2Rnd6KeHmJBkUXJWJhybcXoIG5S5FDTFHJxOycSP4eGzfdOYAWSlkx6XwXEUGGZz5w==}
+ '@mdit/plugin-img-mark@0.16.0':
+ resolution: {integrity: sha512-BUYqQRWUxNKB0BbMb8SZtlTeDZNXxuJ9AuiuB54RIWlbx3iRlQkbQI3B/AxTT5/EbRMDhxOq0R8PumBuA1gNFA==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-img-size@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-r+LbAizP/hw5SisY44VbHEnR7XUKpcHM2k2fwu5wb1+V1crxeigG4sa8rzrJEddU+k6uCl27yL5FTGbHjAl82Q==}
+ '@mdit/plugin-img-size@0.16.0':
+ resolution: {integrity: sha512-4FBvIHYWT22bjU+kO1I00xLtnCi7aXdZ7QD3CJnK4Xl6gN8/WB9IkfqYnBPv8yDiaZrabduQo8Dh8Dm8hPOm2A==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-include@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-e8Z8q5VkJ6UX04tTgELraupB/MdHio7hkdYT71wBJ6UQuhSmFv/xMOxFfTcGKH5yzsbEM45BtAFHzSXIi3dMCw==}
+ '@mdit/plugin-include@0.16.0':
+ resolution: {integrity: sha512-9ESwsc+/jYkS0hIzpWqMQ9bHgHG//35datnfp0KUOql/DSuLVhufPtNkKNe/SVNO/+AOBTTlRYzej9Jl7JjD7g==}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- upath: 2.0.1
- dev: false
- /@mdit/plugin-katex@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-u7CX3Xv5nuc2bu2sHrk1nil83/9ETKTBMmy0icbW8zlqBC0ykLo1xTCEBXmdhXtnJtPi9f/wUZVs6iMZrJzbNg==}
+ '@mdit/plugin-katex-slim@0.16.2':
+ resolution: {integrity: sha512-NVq2fL6Zlbd/se8a69qGoOJ43wfQ+WJ33oIPDuh/n+pBtOnXS2P8oq01k/peen40wdPQBo62rQDxTgd+sMCOsA==}
engines: {node: '>= 18'}
peerDependencies:
katex: ^0.16.9
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
katex:
optional: true
markdown-it:
optional: true
- dependencies:
- '@mdit/plugin-tex': 0.8.0(markdown-it@14.1.0)
- '@types/katex': 0.16.7
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-mark@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-1hImu8FskIZ9dumWD2VIyB5USyVGwGY2IuaPxYO25tFvMZkhu4rYBjkSK8x+vXExwp94OLzFUlGgVl94S+nw9w==}
+ '@mdit/plugin-mark@0.16.0':
+ resolution: {integrity: sha512-VY8HhLaNw6iO6E1pSZr3bG6MzyxcAdQmQ+S0r/l87S0EKHCBrUJusaUjxa9aTVHiBcgGUjg9aumribGrWfuitA==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-mathjax@0.8.0(markdown-it@14.1.0)(mathjax-full@3.2.2):
- resolution: {integrity: sha512-y016KQHa3PoXDUIcQseISMAz5q2mZJ/qocEs2EABT4PjquXPEh/4rw7Ql7KX9gf/SQIUyzj8hYs4bHyRZc6x4w==}
+ '@mdit/plugin-mathjax-slim@0.16.0':
+ resolution: {integrity: sha512-bbo6HtNOFdNMGZH/pxc3X1vZOvOW1FF9RMiAW2pkmyk7sPnMziB8uwxm0Ra1RajEC/NDxJ3wcF7xynkLmS6PfA==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
mathjax-full: ^3.2.2
peerDependenciesMeta:
markdown-it:
optional: true
mathjax-full:
optional: true
- dependencies:
- '@mdit/plugin-tex': 0.8.0(markdown-it@14.1.0)
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- mathjax-full: 3.2.2
- upath: 2.0.1
- dev: false
- /@mdit/plugin-stylize@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-oNFI3Z7UTxP8CKxS3CIuawLmsyrc0n9jIw9mPzUcPNp+LtYmLktfZc3FIRlqpUUq34YwHTH3yihayBRdSkVV6A==}
+ '@mdit/plugin-plantuml@0.16.0':
+ resolution: {integrity: sha512-ZjGOWYxPcGFq/TAJ2wOU6vCYH82685ERFQAC+xUsd/f6G41oGmk5i2aNqfNYYPmoQvcPvimGUPky9L6k2IXKXw==}
+ peerDependencies:
+ markdown-it: ^14.1.0
+ peerDependenciesMeta:
+ markdown-it:
+ optional: true
+
+ '@mdit/plugin-spoiler@0.16.0':
+ resolution: {integrity: sha512-lm2lLx5H6649igzmbEe7KGsYfS6EOHn3Ps1ZdOHIFo0AY9eEh//gbjPOuJNJU58vtMnzLYzQHQKp/JqViYTIQQ==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-sub@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-oqCcmJVJykESgNJ4fFmDKKxRRQddwkXWIT4PjF83XSeXHxTOz8gMfke/V1mE7BAfKKCLP4io8HbrYfvIiOTZ4A==}
+ '@mdit/plugin-stylize@0.16.0':
+ resolution: {integrity: sha512-uxM9aFdgS5YCXOSNSdYyC+uXyCnmqv1VUPRNAv0g/iOts0pUp63ZEUEO2sNlbXj1rGGEWylXyXqh3OU9rRngzg==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-sup@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-5/uE2lONNjCgGDXC8jZ265tzefjUNQNakmK4PSCI4D5jD80xFrxc6MKh70VLCOL8Xk6COK/K9f0SAU2lwa97Tg==}
+ '@mdit/plugin-sub@0.16.0':
+ resolution: {integrity: sha512-XpGcZW11SAWuiWtx9aYugM67OLtQJSfN87Q/aZbEfm6ahgdbO5lAe/vBFTBmL9aDc2EVatytGeZL3kA7pfHlOA==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-tab@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-SNa1S14Buuy564egiUTkU9HTTNFrEURJZLqA1+jr/2xYCdICPym0FWcB0cLtBl3lrQZkFtbxhzC6ws5JBt/ERQ==}
+ '@mdit/plugin-sup@0.16.0':
+ resolution: {integrity: sha512-45Sws9TC9h9ZRB/IcXAae+uYXb+FkVr/rkr9eMYKMFKksjMBddN+WY3Gpl9O7LhaGPipqTkm68QZnRSS1jvFkw==}
+ engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
+ peerDependenciesMeta:
+ markdown-it:
+ optional: true
+
+ '@mdit/plugin-tab@0.16.0':
+ resolution: {integrity: sha512-c+/oT319DIWaMHyx5chueW8cy4pjC7E09QOg3qp86abTCdG2ljGLOlMAQbst5i/iH684QG/i8EJpB4oUeQdhkw==}
+ peerDependencies:
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-tasklist@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-vfOTZdXIL/jk/ConUqCODI5WuqgB9qiBGc+wIa7UMhe73KcpwFeGFJVQZm9AvjhXDDYqznJxSMVRP/TN7TxVVw==}
+ '@mdit/plugin-tasklist@0.16.0':
+ resolution: {integrity: sha512-pxVxartDd8LYxhdYxyrh4c7JEAq+4cEMLI1HNCHTMK9cfO+SoVd/YpibfrDUg+LHvffc8Pf2Yc8pWXNoW34B1g==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-tex@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-uh4kOhwBVEESz6dMmHk4Hn/AVfVtUhMA1UKpwMc1EL9qelodJ0YzSYfNXp6d/PS+E1l53yp8nMZK90DUO+3vpA==}
+ '@mdit/plugin-tex@0.16.0':
+ resolution: {integrity: sha512-VWb5rJYP0eBRRjYhcaRE3r8UQkUaBXzu0l42ck7DOp+MSPsgXfS+bmk8/tyHG6/X/Mig9H92Lh1jzTqp3f5yKg==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@mdit/plugin-uml@0.8.0(markdown-it@14.1.0):
- resolution: {integrity: sha512-6TOVxLhmdzV7bzjlJCRP5uCFq62Xwk2ZAeYUK3RLx9lgM3s2Mww5ENhdysnQMd7VQlUHsPmp4XIMBZZjPddg3g==}
+ '@mdit/plugin-uml@0.16.0':
+ resolution: {integrity: sha512-BIsq6PpmRgoThtVR2j4BGiRGis6jrcxxqQW3RICacrG52Ps2RWEGwu7B/IvXs+KJZJLJsrKFQ2Pqaxttbjx3kw==}
engines: {node: '>= 18'}
peerDependencies:
- markdown-it: ^14.0.0
+ markdown-it: ^14.1.0
peerDependenciesMeta:
markdown-it:
optional: true
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /@nodelib/fs.scandir@2.1.5:
+ '@nodelib/fs.scandir@2.1.5':
resolution: {integrity: sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g==}
engines: {node: '>= 8'}
- dependencies:
- '@nodelib/fs.stat': 2.0.5
- run-parallel: 1.2.0
- dev: false
- /@nodelib/fs.stat@2.0.5:
+ '@nodelib/fs.stat@2.0.5':
resolution: {integrity: sha512-RkhPPp2zrqDAQA/2jNhnztcPAlv64XdhIp7a7454A5ovI7Bukxgt7MX7udwAu3zg1DcpPU0rz3VV1SeaqvY4+A==}
engines: {node: '>= 8'}
- dev: false
- /@nodelib/fs.walk@1.2.8:
+ '@nodelib/fs.walk@1.2.8':
resolution: {integrity: sha512-oGB+UxlgWcgQkgwo8GcEGwemoTFt3FIO9ababBmaGwXIoBKZ+GTy0pP185beGg7Llih/NSHSV2XAs1lnznocSg==}
engines: {node: '>= 8'}
- dependencies:
- '@nodelib/fs.scandir': 2.1.5
- fastq: 1.17.1
- dev: false
- /@npmcli/agent@2.2.1:
- resolution: {integrity: sha512-H4FrOVtNyWC8MUwL3UfjOsAihHvT1Pe8POj3JvjXhSTJipsZMtgUALCT4mGyYZNxymkUfOw3PUj6dE4QPp6osQ==}
+ '@npmcli/agent@2.2.2':
+ resolution: {integrity: sha512-OrcNPXdpSl9UX7qPVRWbmWMCSXrcDa2M9DvrbOTj7ao1S4PlqVFYv9/yLKMkrJKZ/V5A/kDBC690or307i26Og==}
engines: {node: ^16.14.0 || >=18.0.0}
- dependencies:
- agent-base: 7.1.1
- http-proxy-agent: 7.0.2
- https-proxy-agent: 7.0.4
- lru-cache: 10.2.0
- socks-proxy-agent: 8.0.3
- transitivePeerDependencies:
- - supports-color
- dev: false
- /@npmcli/fs@3.1.0:
- resolution: {integrity: sha512-7kZUAaLscfgbwBQRbvdMYaZOWyMEcPTH/tJjnyAWJ/dvvs9Ef+CERx/qJb9GExJpl1qipaDGn7KqHnFGGixd0w==}
+ '@npmcli/fs@3.1.1':
+ resolution: {integrity: sha512-q9CRWjpHCMIh5sVyefoD1cA7PkvILqCZsnSOEUUivORLjxCO/Irmue2DprETiNgEqktDBZaM1Bi+jrarx1XdCg==}
engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
- dependencies:
- semver: 7.6.0
- dev: false
- /@pkgjs/parseargs@0.11.0:
+ '@pkgjs/parseargs@0.11.0':
resolution: {integrity: sha512-+1VkjdD0QBLPodGrJUeqarH8VAIvQODIbwh9XpP5Syisf7YoQgsJKPNFoqqLQlu+VQ/tVSshMR6loPMn8U+dPg==}
engines: {node: '>=14'}
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-android-arm-eabi@4.13.2:
- resolution: {integrity: sha512-3XFIDKWMFZrMnao1mJhnOT1h2g0169Os848NhhmGweEcfJ4rCi+3yMCOLG4zA61rbJdkcrM/DjVZm9Hg5p5w7g==}
+ '@rollup/rollup-android-arm-eabi@4.30.1':
+ resolution: {integrity: sha512-pSWY+EVt3rJ9fQ3IqlrEUtXh3cGqGtPDH1FQlNZehO2yYxCHEX1SPsz1M//NXwYfbTlcKr9WObLnJX9FsS9K1Q==}
cpu: [arm]
os: [android]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-android-arm64@4.13.2:
- resolution: {integrity: sha512-GdxxXbAuM7Y/YQM9/TwwP+L0omeE/lJAR1J+olu36c3LqqZEBdsIWeQ91KBe6nxwOnb06Xh7JS2U5ooWU5/LgQ==}
+ '@rollup/rollup-android-arm64@4.30.1':
+ resolution: {integrity: sha512-/NA2qXxE3D/BRjOJM8wQblmArQq1YoBVJjrjoTSBS09jgUisq7bqxNHJ8kjCHeV21W/9WDGwJEWSN0KQ2mtD/w==}
cpu: [arm64]
os: [android]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-darwin-arm64@4.13.2:
- resolution: {integrity: sha512-mCMlpzlBgOTdaFs83I4XRr8wNPveJiJX1RLfv4hggyIVhfB5mJfN4P8Z6yKh+oE4Luz+qq1P3kVdWrCKcMYrrA==}
+ '@rollup/rollup-darwin-arm64@4.30.1':
+ resolution: {integrity: sha512-r7FQIXD7gB0WJ5mokTUgUWPl0eYIH0wnxqeSAhuIwvnnpjdVB8cRRClyKLQr7lgzjctkbp5KmswWszlwYln03Q==}
cpu: [arm64]
os: [darwin]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-darwin-x64@4.13.2:
- resolution: {integrity: sha512-yUoEvnH0FBef/NbB1u6d3HNGyruAKnN74LrPAfDQL3O32e3k3OSfLrPgSJmgb3PJrBZWfPyt6m4ZhAFa2nZp2A==}
+ '@rollup/rollup-darwin-x64@4.30.1':
+ resolution: {integrity: sha512-x78BavIwSH6sqfP2xeI1hd1GpHL8J4W2BXcVM/5KYKoAD3nNsfitQhvWSw+TFtQTLZ9OmlF+FEInEHyubut2OA==}
cpu: [x64]
os: [darwin]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-linux-arm-gnueabihf@4.13.2:
- resolution: {integrity: sha512-GYbLs5ErswU/Xs7aGXqzc3RrdEjKdmoCrgzhJWyFL0r5fL3qd1NPcDKDowDnmcoSiGJeU68/Vy+OMUluRxPiLQ==}
+ '@rollup/rollup-freebsd-arm64@4.30.1':
+ resolution: {integrity: sha512-HYTlUAjbO1z8ywxsDFWADfTRfTIIy/oUlfIDmlHYmjUP2QRDTzBuWXc9O4CXM+bo9qfiCclmHk1x4ogBjOUpUQ==}
+ cpu: [arm64]
+ os: [freebsd]
+
+ '@rollup/rollup-freebsd-x64@4.30.1':
+ resolution: {integrity: sha512-1MEdGqogQLccphhX5myCJqeGNYTNcmTyaic9S7CG3JhwuIByJ7J05vGbZxsizQthP1xpVx7kd3o31eOogfEirw==}
+ cpu: [x64]
+ os: [freebsd]
+
+ '@rollup/rollup-linux-arm-gnueabihf@4.30.1':
+ resolution: {integrity: sha512-PaMRNBSqCx7K3Wc9QZkFx5+CX27WFpAMxJNiYGAXfmMIKC7jstlr32UhTgK6T07OtqR+wYlWm9IxzennjnvdJg==}
cpu: [arm]
os: [linux]
- requiresBuild: true
- dev: false
- optional: true
+ libc: [glibc]
- /@rollup/rollup-linux-arm64-gnu@4.13.2:
- resolution: {integrity: sha512-L1+D8/wqGnKQIlh4Zre9i4R4b4noxzH5DDciyahX4oOz62CphY7WDWqJoQ66zNR4oScLNOqQJfNSIAe/6TPUmQ==}
- cpu: [arm64]
+ '@rollup/rollup-linux-arm-musleabihf@4.30.1':
+ resolution: {integrity: sha512-B8Rcyj9AV7ZlEFqvB5BubG5iO6ANDsRKlhIxySXcF1axXYUyqwBok+XZPgIYGBgs7LDXfWfifxhw0Ik57T0Yug==}
+ cpu: [arm]
+ os: [linux]
+ libc: [musl]
+
+ '@rollup/rollup-linux-arm64-gnu@4.30.1':
+ resolution: {integrity: sha512-hqVyueGxAj3cBKrAI4aFHLV+h0Lv5VgWZs9CUGqr1z0fZtlADVV1YPOij6AhcK5An33EXaxnDLmJdQikcn5NEw==}
+ cpu: [arm64]
os: [linux]
libc: [glibc]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-linux-arm64-musl@4.13.2:
- resolution: {integrity: sha512-tK5eoKFkXdz6vjfkSTCupUzCo40xueTOiOO6PeEIadlNBkadH1wNOH8ILCPIl8by/Gmb5AGAeQOFeLev7iZDOA==}
+ '@rollup/rollup-linux-arm64-musl@4.30.1':
+ resolution: {integrity: sha512-i4Ab2vnvS1AE1PyOIGp2kXni69gU2DAUVt6FSXeIqUCPIR3ZlheMW3oP2JkukDfu3PsexYRbOiJrY+yVNSk9oA==}
cpu: [arm64]
os: [linux]
libc: [musl]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-linux-powerpc64le-gnu@4.13.2:
- resolution: {integrity: sha512-zvXvAUGGEYi6tYhcDmb9wlOckVbuD+7z3mzInCSTACJ4DQrdSLPNUeDIcAQW39M3q6PDquqLWu7pnO39uSMRzQ==}
- cpu: [ppc64le]
+ '@rollup/rollup-linux-loongarch64-gnu@4.30.1':
+ resolution: {integrity: sha512-fARcF5g296snX0oLGkVxPmysetwUk2zmHcca+e9ObOovBR++9ZPOhqFUM61UUZ2EYpXVPN1redgqVoBB34nTpQ==}
+ cpu: [loong64]
os: [linux]
libc: [glibc]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-linux-riscv64-gnu@4.13.2:
- resolution: {integrity: sha512-C3GSKvMtdudHCN5HdmAMSRYR2kkhgdOfye4w0xzyii7lebVr4riCgmM6lRiSCnJn2w1Xz7ZZzHKuLrjx5620kw==}
+ '@rollup/rollup-linux-powerpc64le-gnu@4.30.1':
+ resolution: {integrity: sha512-GLrZraoO3wVT4uFXh67ElpwQY0DIygxdv0BNW9Hkm3X34wu+BkqrDrkcsIapAY+N2ATEbvak0XQ9gxZtCIA5Rw==}
+ cpu: [ppc64]
+ os: [linux]
+ libc: [glibc]
+
+ '@rollup/rollup-linux-riscv64-gnu@4.30.1':
+ resolution: {integrity: sha512-0WKLaAUUHKBtll0wvOmh6yh3S0wSU9+yas923JIChfxOaaBarmb/lBKPF0w/+jTVozFnOXJeRGZ8NvOxvk/jcw==}
cpu: [riscv64]
os: [linux]
libc: [glibc]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-linux-s390x-gnu@4.13.2:
- resolution: {integrity: sha512-l4U0KDFwzD36j7HdfJ5/TveEQ1fUTjFFQP5qIt9gBqBgu1G8/kCaq5Ok05kd5TG9F8Lltf3MoYsUMw3rNlJ0Yg==}
+ '@rollup/rollup-linux-s390x-gnu@4.30.1':
+ resolution: {integrity: sha512-GWFs97Ruxo5Bt+cvVTQkOJ6TIx0xJDD/bMAOXWJg8TCSTEK8RnFeOeiFTxKniTc4vMIaWvCplMAFBt9miGxgkA==}
cpu: [s390x]
os: [linux]
libc: [glibc]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-linux-x64-gnu@4.13.2:
- resolution: {integrity: sha512-xXMLUAMzrtsvh3cZ448vbXqlUa7ZL8z0MwHp63K2IIID2+DeP5iWIT6g1SN7hg1VxPzqx0xZdiDM9l4n9LRU1A==}
+ '@rollup/rollup-linux-x64-gnu@4.30.1':
+ resolution: {integrity: sha512-UtgGb7QGgXDIO+tqqJ5oZRGHsDLO8SlpE4MhqpY9Llpzi5rJMvrK6ZGhsRCST2abZdBqIBeXW6WPD5fGK5SDwg==}
cpu: [x64]
os: [linux]
libc: [glibc]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-linux-x64-musl@4.13.2:
- resolution: {integrity: sha512-M/JYAWickafUijWPai4ehrjzVPKRCyDb1SLuO+ZyPfoXgeCEAlgPkNXewFZx0zcnoIe3ay4UjXIMdXQXOZXWqA==}
+ '@rollup/rollup-linux-x64-musl@4.30.1':
+ resolution: {integrity: sha512-V9U8Ey2UqmQsBT+xTOeMzPzwDzyXmnAoO4edZhL7INkwQcaW1Ckv3WJX3qrrp/VHaDkEWIBWhRwP47r8cdrOow==}
cpu: [x64]
os: [linux]
libc: [musl]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-win32-arm64-msvc@4.13.2:
- resolution: {integrity: sha512-2YWwoVg9KRkIKaXSh0mz3NmfurpmYoBBTAXA9qt7VXk0Xy12PoOP40EFuau+ajgALbbhi4uTj3tSG3tVseCjuA==}
+ '@rollup/rollup-win32-arm64-msvc@4.30.1':
+ resolution: {integrity: sha512-WabtHWiPaFF47W3PkHnjbmWawnX/aE57K47ZDT1BXTS5GgrBUEpvOzq0FI0V/UYzQJgdb8XlhVNH8/fwV8xDjw==}
cpu: [arm64]
os: [win32]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-win32-ia32-msvc@4.13.2:
- resolution: {integrity: sha512-2FSsE9aQ6OWD20E498NYKEQLneShWes0NGMPQwxWOdws35qQXH+FplabOSP5zEe1pVjurSDOGEVCE2agFwSEsw==}
+ '@rollup/rollup-win32-ia32-msvc@4.30.1':
+ resolution: {integrity: sha512-pxHAU+Zv39hLUTdQQHUVHf4P+0C47y/ZloorHpzs2SXMRqeAWmGghzAhfOlzFHHwjvgokdFAhC4V+6kC1lRRfw==}
cpu: [ia32]
os: [win32]
- requiresBuild: true
- dev: false
- optional: true
- /@rollup/rollup-win32-x64-msvc@4.13.2:
- resolution: {integrity: sha512-7h7J2nokcdPePdKykd8wtc8QqqkqxIrUz7MHj6aNr8waBRU//NLDVnNjQnqQO6fqtjrtCdftpbTuOKAyrAQETQ==}
+ '@rollup/rollup-win32-x64-msvc@4.30.1':
+ resolution: {integrity: sha512-D6qjsXGcvhTjv0kI4fU8tUuBDF/Ueee4SVX79VfNDXZa64TfCW1Slkb6Z7O1p7vflqZjcmOVdZlqf8gvJxc6og==}
cpu: [x64]
os: [win32]
- requiresBuild: true
- dev: false
- optional: true
- /@sindresorhus/merge-streams@1.0.0:
- resolution: {integrity: sha512-rUV5WyJrJLoloD4NDN1V1+LDMDWOa4OTsT4yYJwQNpTU6FWxkxHpL7eu4w+DmiH8x/EAM1otkPE1+LaspIbplw==}
- engines: {node: '>=18'}
- dev: false
+ '@sec-ant/readable-stream@0.4.1':
+ resolution: {integrity: sha512-831qok9r2t8AlxLko40y2ebgSDhenenCatLVeW/uBtnHPyhHOvG0C7TvfgecV+wHzIm5KUICgzmVpWS+IMEAeg==}
+
+ '@shikijs/core@1.26.2':
+ resolution: {integrity: sha512-ORyu3MrY7dCC7FDLDsFSkBM9b/AT9/Y8rH+UQ07Rtek48pp0ZhQOMPTKolqszP4bBCas6FqTZQYt18BBamVl/g==}
+
+ '@shikijs/engine-javascript@1.26.2':
+ resolution: {integrity: sha512-ngkIu9swLVo9Zt5QBtz5Sk08vmPcwuj01r7pPK/Zjmo2U2WyKMK4WMUMmkdQiUacdcLth0zt8u1onp4zhkFXKQ==}
+
+ '@shikijs/engine-oniguruma@1.26.2':
+ resolution: {integrity: sha512-mlN7Qrs+w60nKrd7at7XkXSwz6728Pe34taDmHrG6LRHjzCqQ+ysg+/AT6/D2LMk0s2lsr71DjpI73430QP4/w==}
+
+ '@shikijs/langs@1.26.2':
+ resolution: {integrity: sha512-o5cdPycB2Kw3IgncHxWopWPiTkjAj7dG01fLkkUyj3glb5ftxL/Opecq9F54opMlrgXy7ZIqDERvFLlUzsCOuA==}
- /@sindresorhus/merge-streams@2.3.0:
+ '@shikijs/themes@1.26.2':
+ resolution: {integrity: sha512-y4Pn6PM5mODz/e3yF6jAUG7WLKJzqL2tJ5qMJCUkMUB1VRgtQVvoa1cHh7NScryGXyrYGJ8nPnRDhdv2rw0xpA==}
+
+ '@shikijs/transformers@1.26.2':
+ resolution: {integrity: sha512-nAwivOhYDKudYsX9xOmA9ekkqYv+Q/IadX5ca0nV7qPTN+wf/tXHrjxVmJJlsEVtakCEuMR0a0AVL+V9QZxi7w==}
+
+ '@shikijs/types@1.26.2':
+ resolution: {integrity: sha512-PO2jucx2FIdlLBPYbIUlMtWSLs5ulcRcuV93cR3T65lkK5SJP4MGBRt9kmWGXiQc0f7+FHj/0BEawditZcI/fQ==}
+
+ '@shikijs/vscode-textmate@10.0.1':
+ resolution: {integrity: sha512-fTIQwLF+Qhuws31iw7Ncl1R3HUDtGwIipiJ9iU+UsDUwMhegFcQKQHd51nZjb7CArq0MvON8rbgCGQYWHUKAdg==}
+
+ '@sindresorhus/merge-streams@2.3.0':
resolution: {integrity: sha512-LtoMMhxAlorcGhmFYI+LhPgbPZCkgP6ra1YL604EeF6U98pLlQ3iWIGMdWSC+vWmPBWBNgmDBAhnAobLROJmwg==}
engines: {node: '>=18'}
- dev: false
- /@stackblitz/sdk@1.9.0:
- resolution: {integrity: sha512-3m6C7f8pnR5KXys/Hqx2x6ylnpqOak6HtnZI6T5keEO0yT+E4Spkw37VEbdwuC+2oxmjdgq6YZEgiKX7hM1GmQ==}
- dev: false
+ '@sindresorhus/merge-streams@4.0.0':
+ resolution: {integrity: sha512-tlqY9xq5ukxTUZBmoOp+m61cqwQD5pHJtFY3Mn8CA8ps6yghLH/Hw8UPdqg4OLmFW3IFlcXnQNmo/dh8HzXYIQ==}
+ engines: {node: '>=18'}
+
+ '@stackblitz/sdk@1.11.0':
+ resolution: {integrity: sha512-DFQGANNkEZRzFk1/rDP6TcFdM82ycHE+zfl9C/M/jXlH68jiqHWHFMQURLELoD8koxvu/eW5uhg94NSAZlYrUQ==}
- /@types/debug@4.1.12:
+ '@types/debug@4.1.12':
resolution: {integrity: sha512-vIChWdVG3LG1SMxEvI/AK+FWJthlrqlTu7fbrlywTkkaONwk/UAGaULXRlf8vkzFBLVm0zkMdCquhL5aOjhXPQ==}
- dependencies:
- '@types/ms': 0.7.34
- dev: false
- /@types/estree@1.0.5:
- resolution: {integrity: sha512-/kYRxGDLWzHOB7q+wtSUQlFrtcdUccpfy+X+9iMBpHK8QLLhx2wIPYuS5DYtR9Wa/YlZAbIovy7qVdB1Aq6Lyw==}
- dev: false
+ '@types/estree@1.0.6':
+ resolution: {integrity: sha512-AYnb1nQyY49te+VRAVgmzfcgjYS91mY5P0TKUDCLEM+gNnA+3T6rWITXRLYCpahpqSQbN5cE+gHpnPyXjHWxcw==}
- /@types/fs-extra@11.0.4:
+ '@types/fs-extra@11.0.4':
resolution: {integrity: sha512-yTbItCNreRooED33qjunPthRcSjERP1r4MqCZc7wv0u2sUkzTFp45tgUfS5+r7FrZPdmCCNflLhVSP/o+SemsQ==}
- dependencies:
- '@types/jsonfile': 6.1.4
- '@types/node': 20.12.2
- dev: false
- /@types/hash-sum@1.0.2:
+ '@types/hash-sum@1.0.2':
resolution: {integrity: sha512-UP28RddqY8xcU0SCEp9YKutQICXpaAq9N8U2klqF5hegGha7KzTOL8EdhIIV3bOSGBzjEpN9bU/d+nNZBdJYVw==}
- dev: false
- /@types/jsonfile@6.1.4:
+ '@types/hast@3.0.4':
+ resolution: {integrity: sha512-WPs+bbQw5aCj+x6laNGWLH3wviHtoCv/P3+otBhbOhJgG8qtpdAMlTCxLtsTWA7LH1Oh/bFCHsBn0TPS5m30EQ==}
+
+ '@types/jsonfile@6.1.4':
resolution: {integrity: sha512-D5qGUYwjvnNNextdU59/+fI+spnwtTFmyQP0h+PfIOSkNfpU6AOICUOkm4i0OnSk+NyjdPJrxCDro0sJsWlRpQ==}
- dependencies:
- '@types/node': 20.12.2
- dev: false
- /@types/katex@0.16.7:
+ '@types/katex@0.16.7':
resolution: {integrity: sha512-HMwFiRujE5PjrgwHQ25+bsLJgowjGjm5Z8FVSf0N6PwgJrwxH0QxzHYDcKsTfV3wva0vzrpqMTJS2jXPr5BMEQ==}
- dev: false
- /@types/linkify-it@3.0.5:
- resolution: {integrity: sha512-yg6E+u0/+Zjva+buc3EIb+29XEg4wltq7cSmd4Uc2EE/1nUVmxyzpX6gUXD0V8jIrG0r7YeOGVIbYRkxeooCtw==}
- dev: false
+ '@types/linkify-it@5.0.0':
+ resolution: {integrity: sha512-sVDA58zAw4eWAffKOaQH5/5j3XeayukzDk+ewSsnv3p4yJEZHCCzMDiZM8e0OUrRvmpGZ85jf4yDHkHsgBNr9Q==}
- /@types/markdown-it-emoji@2.0.4:
- resolution: {integrity: sha512-H6ulk/ZmbDxOayPwI/leJzrmoW1YKX1Z+MVSCHXuYhvqckV4I/c+hPTf6UiqJyn2avWugfj30XroheEb6/Ekqg==}
- dependencies:
- '@types/markdown-it': 13.0.7
- dev: false
+ '@types/markdown-it-emoji@3.0.1':
+ resolution: {integrity: sha512-cz1j8R35XivBqq9mwnsrP2fsz2yicLhB8+PDtuVkKOExwEdsVBNI+ROL3sbhtR5occRZ66vT0QnwFZCqdjf3pA==}
- /@types/markdown-it@13.0.7:
- resolution: {integrity: sha512-U/CBi2YUUcTHBt5tjO2r5QV/x0Po6nsYwQU4Y04fBS6vfoImaiZ6f8bi3CjTCxBPQSO1LMyUqkByzi8AidyxfA==}
- dependencies:
- '@types/linkify-it': 3.0.5
- '@types/mdurl': 1.0.5
- dev: false
+ '@types/markdown-it@14.1.2':
+ resolution: {integrity: sha512-promo4eFwuiW+TfGxhi+0x3czqTYJkG8qB17ZUJiVF10Xm7NLVRSLUsfRTU/6h1e24VvRnXCx+hG7li58lkzog==}
- /@types/mdurl@1.0.5:
- resolution: {integrity: sha512-6L6VymKTzYSrEf4Nev4Xa1LCHKrlTlYCBMTlQKFuddo1CvQcE52I0mwfOJayueUC7MJuXOeHTcIU683lzd0cUA==}
- dev: false
+ '@types/mdast@4.0.4':
+ resolution: {integrity: sha512-kGaNbPh1k7AFzgpud/gMdvIm5xuECykRR+JnWKQno9TAXVa6WIVCGTPvYGekIDL4uwCZQSYbUxNBSb1aUo79oA==}
- /@types/ms@0.7.34:
+ '@types/mdurl@2.0.0':
+ resolution: {integrity: sha512-RGdgjQUZba5p6QEFAVx2OGb8rQDL/cPRG7GiedRzMcJ1tYnUANBncjbSB1NRGwbvjcPeikRABz2nshyPk1bhWg==}
+
+ '@types/ms@0.7.34':
resolution: {integrity: sha512-nG96G3Wp6acyAgJqGasjODb+acrI7KltPiRxzHPXnP3NgI28bpQDRv53olbqGXbfcgF5aiiHmO3xpwEpS5Ld9g==}
- dev: false
- /@types/node@17.0.45:
+ '@types/node@17.0.45':
resolution: {integrity: sha512-w+tIMs3rq2afQdsPJlODhoUEKzFP1ayaoyl1CcnwtIlsVe7K7bA1NGm4s3PraqTLlXnbIN84zuBlxBWo1u9BLw==}
- dev: false
- /@types/node@20.12.2:
- resolution: {integrity: sha512-zQ0NYO87hyN6Xrclcqp7f8ZbXNbRfoGWNcMvHTPQp9UUrwI0mI7XBz+cu7/W6/VClYo2g63B0cjull/srU7LgQ==}
- dependencies:
- undici-types: 5.26.5
- dev: false
+ '@types/node@22.10.5':
+ resolution: {integrity: sha512-F8Q+SeGimwOo86fiovQh8qiXfFEh2/ocYv7tU5pJ3EXMSSxk1Joj5wefpFK2fHTf/N6HKGSxIDBT9f3gCxXPkQ==}
- /@types/sax@1.2.7:
+ '@types/sax@1.2.7':
resolution: {integrity: sha512-rO73L89PJxeYM3s3pPPjiPgVVcymqU490g0YO5n5By0k2Erzj6tay/4lr1CHAAU4JyOWd1rpQ8bCf6cZfHU96A==}
- dependencies:
- '@types/node': 17.0.45
- dev: false
- /@types/trusted-types@2.0.7:
+ '@types/trusted-types@2.0.7':
resolution: {integrity: sha512-ScaPdn1dQczgbl0QFTeTOmVHFULt394XJgOQNoyVhZ6r2vLnMLJfBPd53SB52T/3G36VI1/g2MZaX0cwDuXsfw==}
- dev: false
- /@types/web-bluetooth@0.0.20:
+ '@types/unist@2.0.11':
+ resolution: {integrity: sha512-CmBKiL6NNo/OqgmMn95Fk9Whlp2mtvIv+KNpQKN2F4SjvrEesubTRWGYSg+BnWZOnlCaSTU1sMpsBOzgbYhnsA==}
+
+ '@types/unist@3.0.3':
+ resolution: {integrity: sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==}
+
+ '@types/web-bluetooth@0.0.20':
resolution: {integrity: sha512-g9gZnnXVq7gM7v3tJCWV/qw7w+KeOlSHAhgF9RytFyifW6AF61hdT2ucrYhPq9hLs5JIryeupHV3qGk95dH9ow==}
- dev: false
- /@vitejs/plugin-vue@5.0.4(vite@5.2.7)(vue@3.4.21):
- resolution: {integrity: sha512-WS3hevEszI6CEVEx28F8RjTX97k3KsrcY6kvTg7+Whm5y3oYvcqzVeGCU3hxSAn4uY2CLCkeokkGKpoctccilQ==}
+ '@ungap/structured-clone@1.2.1':
+ resolution: {integrity: sha512-fEzPV3hSkSMltkw152tJKNARhOupqbH96MZWyRjNaYZOMIzbrTeQDG+MTc6Mr2pgzFQzFxAfmhGDNP5QK++2ZA==}
+
+ '@vitejs/plugin-vue@5.2.1':
+ resolution: {integrity: sha512-cxh314tzaWwOLqVes2gnnCtvBDcM1UMdn+iFR+UjAn411dPT3tOmqrJjbMd7koZpMAmBM/GqeV4n9ge7JSiJJQ==}
engines: {node: ^18.0.0 || >=20.0.0}
peerDependencies:
- vite: ^5.0.0
+ vite: ^5.0.0 || ^6.0.0
vue: ^3.2.25
- dependencies:
- vite: 5.2.7
- vue: 3.4.21
- dev: false
- /@vue/compiler-core@3.4.21:
- resolution: {integrity: sha512-MjXawxZf2SbZszLPYxaFCjxfibYrzr3eYbKxwpLR9EQN+oaziSu3qKVbwBERj1IFIB8OLUewxB5m/BFzi613og==}
- dependencies:
- '@babel/parser': 7.24.1
- '@vue/shared': 3.4.21
- entities: 4.5.0
- estree-walker: 2.0.2
- source-map-js: 1.2.0
- dev: false
+ '@vue/compiler-core@3.5.13':
+ resolution: {integrity: sha512-oOdAkwqUfW1WqpwSYJce06wvt6HljgY3fGeM9NcVA1HaYOij3mZG9Rkysn0OHuyUAGMbEbARIpsG+LPVlBJ5/Q==}
- /@vue/compiler-dom@3.4.21:
- resolution: {integrity: sha512-IZC6FKowtT1sl0CR5DpXSiEB5ayw75oT2bma1BEhV7RRR1+cfwLrxc2Z8Zq/RGFzJ8w5r9QtCOvTjQgdn0IKmA==}
- dependencies:
- '@vue/compiler-core': 3.4.21
- '@vue/shared': 3.4.21
- dev: false
+ '@vue/compiler-dom@3.5.13':
+ resolution: {integrity: sha512-ZOJ46sMOKUjO3e94wPdCzQ6P1Lx/vhp2RSvfaab88Ajexs0AHeV0uasYhi99WPaogmBlRHNRuly8xV75cNTMDA==}
- /@vue/compiler-sfc@3.4.21:
- resolution: {integrity: sha512-me7epoTxYlY+2CUM7hy9PCDdpMPfIwrOvAXud2Upk10g4YLv9UBW7kL798TvMeDhPthkZ0CONNrK2GoeI1ODiQ==}
- dependencies:
- '@babel/parser': 7.24.1
- '@vue/compiler-core': 3.4.21
- '@vue/compiler-dom': 3.4.21
- '@vue/compiler-ssr': 3.4.21
- '@vue/shared': 3.4.21
- estree-walker: 2.0.2
- magic-string: 0.30.8
- postcss: 8.4.38
- source-map-js: 1.2.0
- dev: false
+ '@vue/compiler-sfc@3.5.13':
+ resolution: {integrity: sha512-6VdaljMpD82w6c2749Zhf5T9u5uLBWKnVue6XWxprDobftnletJ8+oel7sexFfM3qIxNmVE7LSFGTpv6obNyaQ==}
- /@vue/compiler-ssr@3.4.21:
- resolution: {integrity: sha512-M5+9nI2lPpAsgXOGQobnIueVqc9sisBFexh5yMIMRAPYLa7+5wEJs8iqOZc1WAa9WQbx9GR2twgznU8LTIiZ4Q==}
- dependencies:
- '@vue/compiler-dom': 3.4.21
- '@vue/shared': 3.4.21
- dev: false
+ '@vue/compiler-ssr@3.5.13':
+ resolution: {integrity: sha512-wMH6vrYHxQl/IybKJagqbquvxpWCuVYpoUJfCqFZwa/JY1GdATAQ+TgVtgrwwMZ0D07QhA99rs/EAAWfvG6KpA==}
- /@vue/devtools-api@6.6.1:
- resolution: {integrity: sha512-LgPscpE3Vs0x96PzSSB4IGVSZXZBZHpfxs+ZA1d+VEPwHdOXowy/Y2CsvCAIFrf+ssVU1pD1jidj505EpUnfbA==}
- dev: false
+ '@vue/devtools-api@6.6.4':
+ resolution: {integrity: sha512-sGhTPMuXqZ1rVOk32RylztWkfXTRhuS7vgAKv0zjqk8gbsHkJ7xfFf+jbySxt7tWObEJwyKaHMikV/WGDiQm8g==}
- /@vue/reactivity@3.4.21:
- resolution: {integrity: sha512-UhenImdc0L0/4ahGCyEzc/pZNwVgcglGy9HVzJ1Bq2Mm9qXOpP8RyNTjookw/gOCUlXSEtuZ2fUg5nrHcoqJcw==}
- dependencies:
- '@vue/shared': 3.4.21
- dev: false
+ '@vue/devtools-api@7.7.0':
+ resolution: {integrity: sha512-bHEv6kT85BHtyGgDhE07bAUMAy7zpv6nnR004nSTd0wWMrAOtcrYoXO5iyr20Hkf5jR8obQOfS3byW+I3l2CCA==}
- /@vue/runtime-core@3.4.21:
- resolution: {integrity: sha512-pQthsuYzE1XcGZznTKn73G0s14eCJcjaLvp3/DKeYWoFacD9glJoqlNBxt3W2c5S40t6CCcpPf+jG01N3ULyrA==}
- dependencies:
- '@vue/reactivity': 3.4.21
- '@vue/shared': 3.4.21
- dev: false
+ '@vue/devtools-kit@7.7.0':
+ resolution: {integrity: sha512-5cvZ+6SA88zKC8XiuxUfqpdTwVjJbvYnQZY5NReh7qlSGPvVDjjzyEtW+gdzLXNSd8tStgOjAdMCpvDQamUXtA==}
- /@vue/runtime-dom@3.4.21:
- resolution: {integrity: sha512-gvf+C9cFpevsQxbkRBS1NpU8CqxKw0ebqMvLwcGQrNpx6gqRDodqKqA+A2VZZpQ9RpK2f9yfg8VbW/EpdFUOJw==}
- dependencies:
- '@vue/runtime-core': 3.4.21
- '@vue/shared': 3.4.21
- csstype: 3.1.3
- dev: false
+ '@vue/devtools-shared@7.7.0':
+ resolution: {integrity: sha512-jtlQY26R5thQxW9YQTpXbI0HoK0Wf9Rd4ekidOkRvSy7ChfK0kIU6vvcBtjj87/EcpeOSK49fZAicaFNJcoTcQ==}
+
+ '@vue/reactivity@3.5.13':
+ resolution: {integrity: sha512-NaCwtw8o48B9I6L1zl2p41OHo/2Z4wqYGGIK1Khu5T7yxrn+ATOixn/Udn2m+6kZKB/J7cuT9DbWWhRxqixACg==}
+
+ '@vue/runtime-core@3.5.13':
+ resolution: {integrity: sha512-Fj4YRQ3Az0WTZw1sFe+QDb0aXCerigEpw418pw1HBUKFtnQHWzwojaukAs2X/c9DQz4MQ4bsXTGlcpGxU/RCIw==}
+
+ '@vue/runtime-dom@3.5.13':
+ resolution: {integrity: sha512-dLaj94s93NYLqjLiyFzVs9X6dWhTdAlEAciC3Moq7gzAc13VJUdCnjjRurNM6uTLFATRHexHCTu/Xp3eW6yoog==}
- /@vue/server-renderer@3.4.21(vue@3.4.21):
- resolution: {integrity: sha512-aV1gXyKSN6Rz+6kZ6kr5+Ll14YzmIbeuWe7ryJl5muJ4uwSwY/aStXTixx76TwkZFJLm1aAlA/HSWEJ4EyiMkg==}
+ '@vue/server-renderer@3.5.13':
+ resolution: {integrity: sha512-wAi4IRJV/2SAW3htkTlB+dHeRmpTiVIK1OGLWV1yeStVSebSQQOwGwIq0D3ZIoBj2C2qpgz5+vX9iEBkTdk5YA==}
peerDependencies:
- vue: 3.4.21
- dependencies:
- '@vue/compiler-ssr': 3.4.21
- '@vue/shared': 3.4.21
- vue: 3.4.21
- dev: false
+ vue: 3.5.13
- /@vue/shared@3.4.21:
- resolution: {integrity: sha512-PuJe7vDIi6VYSinuEbUIQgMIRZGgM8e4R+G+/dQTk0X1NEdvgvvgv7m+rfmDH1gZzyA1OjjoWskvHlfRNfQf3g==}
- dev: false
+ '@vue/shared@3.5.13':
+ resolution: {integrity: sha512-/hnE/qP5ZoGpol0a5mDi45bOd7t3tjYJBjsgCsivow7D48cJeV5l05RD82lPqi7gRiphZM37rnhW1l6ZoCNNnQ==}
- /@vuepress/bundler-vite@2.0.0-rc.9:
- resolution: {integrity: sha512-GcM2eSqW2mPY5xXX4i5kuZujvwUeiTpsLX5kgau9LzPox+FdA3SMUkppCY3hsou2o2RxXPTfjocE7OlYQrUqvA==}
- dependencies:
- '@vitejs/plugin-vue': 5.0.4(vite@5.2.7)(vue@3.4.21)
- '@vuepress/client': 2.0.0-rc.9
- '@vuepress/core': 2.0.0-rc.9
- '@vuepress/shared': 2.0.0-rc.9
- '@vuepress/utils': 2.0.0-rc.9
- autoprefixer: 10.4.19(postcss@8.4.38)
- connect-history-api-fallback: 2.0.0
- postcss: 8.4.38
- postcss-load-config: 5.0.3(postcss@8.4.38)
- rollup: 4.13.2
- vite: 5.2.7
- vue: 3.4.21
- vue-router: 4.3.0(vue@3.4.21)
- transitivePeerDependencies:
- - '@types/node'
- - jiti
- - less
- - lightningcss
- - sass
- - stylus
- - sugarss
- - supports-color
- - terser
- - typescript
- dev: false
+ '@vuepress/bundler-vite@2.0.0-rc.19':
+ resolution: {integrity: sha512-Vn0wEVRcdAld+8NJeELSwrj5JEPObRn0xpRWtAau/UwVWHmMLo16RRkTvXdjSiwpDWeP/9ztC5buyTXVoeb7Dw==}
- /@vuepress/cli@2.0.0-rc.9:
- resolution: {integrity: sha512-uv7Xmv3QmPpzCaUAq0oKEwp2tY64AO+7mxamgr7tr+t6FEnCYqr+X0nLlH17UtMkmGWIsbHLIlMjteprxGxIMg==}
+ '@vuepress/bundlerutils@2.0.0-rc.19':
+ resolution: {integrity: sha512-ln5htptK14OMJV3yeGRxAwYhSkVxrTwEHEaifeWrFvjuNxj2kLmkCl7MDdzr232jSOWwkCcmbOyafbxMsaRDkQ==}
+
+ '@vuepress/cli@2.0.0-rc.19':
+ resolution: {integrity: sha512-QFicPNIj3RZAJbHoLbeYlPJsPchnQLGuw0n8xv0eeUi9ejEXO1huWA8sLoPbTGdiDW+PHr1MHnaVMkyUfwaKcQ==}
hasBin: true
- dependencies:
- '@vuepress/core': 2.0.0-rc.9
- '@vuepress/shared': 2.0.0-rc.9
- '@vuepress/utils': 2.0.0-rc.9
- cac: 6.7.14
- chokidar: 3.6.0
- envinfo: 7.11.1
- esbuild: 0.20.2
- transitivePeerDependencies:
- - supports-color
- - typescript
- dev: false
- /@vuepress/client@2.0.0-rc.9:
- resolution: {integrity: sha512-V5jA6L1nHQ8tXBshRHBJKei7HPFonGxFzmVK5yjj2Ho/Xtp/SD9rBS6dyYd5CSkKRGQDgy19Z+BUUPXtdI1qzg==}
- dependencies:
- '@vue/devtools-api': 6.6.1
- '@vuepress/shared': 2.0.0-rc.9
- vue: 3.4.21
- vue-router: 4.3.0(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ '@vuepress/client@2.0.0-rc.19':
+ resolution: {integrity: sha512-vUAU6n4qmtXqthxkb4LHq0D+VWSDenwBDf0jUs7RaBLuOVrbPtmH/hs4k1vLIlGdwC3Zs/G6tlB4UmuZiiwR8Q==}
- /@vuepress/core@2.0.0-rc.9:
- resolution: {integrity: sha512-uvMkIqYJ7vjfYEC91rMmT8YJt8xXnob5YYY3TzlwWUSEv4yoV3nlVu0l6Zfhenx/7FwKaxRJ/ePlUGIgUHBcBw==}
- dependencies:
- '@vuepress/client': 2.0.0-rc.9
- '@vuepress/markdown': 2.0.0-rc.9
- '@vuepress/shared': 2.0.0-rc.9
- '@vuepress/utils': 2.0.0-rc.9
- vue: 3.4.21
- transitivePeerDependencies:
- - supports-color
- - typescript
- dev: false
+ '@vuepress/core@2.0.0-rc.19':
+ resolution: {integrity: sha512-rvmBPMIWS2dey/2QjxZoO0OcrUU46NE3mSLk3oU7JOP0cG7xvRxf6U1OXiwYLC3fPO4g6XbHiKe6gihkmL6VDA==}
- /@vuepress/helper@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-yKIG8hwsrA63uWo9hx9u7KBc0HvotKe2/0wVZtUdvdsibG3UYNI9enYQNa8MdqbxF92mmlFkPZdosGjUTA+BYw==}
+ '@vuepress/helper@2.0.0-rc.70':
+ resolution: {integrity: sha512-3v8m0x9GyPY3TC+GFBJ8eNQ0Pa3qYLXfT5wK4HtZw+ti4dff6fNufqUtH63a2CgTKMI0BHrdUddw/lmI1LobPw==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vue/shared': 3.4.21
- cheerio: 1.0.0-rc.12
- fflate: 0.8.2
- gray-matter: 4.0.3
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
-
- /@vuepress/markdown@2.0.0-rc.9:
- resolution: {integrity: sha512-e7as2ar3RQp0bUyMiwBPi7L/G2fzscb3s0BywNcAwubFR22o0/dBEYRYdrN0clPQ2FXpPxF6AFj4aD7O1heCbw==}
- dependencies:
- '@mdit-vue/plugin-component': 2.0.0
- '@mdit-vue/plugin-frontmatter': 2.0.0
- '@mdit-vue/plugin-headers': 2.0.0
- '@mdit-vue/plugin-sfc': 2.0.0
- '@mdit-vue/plugin-title': 2.0.0
- '@mdit-vue/plugin-toc': 2.0.0
- '@mdit-vue/shared': 2.0.0
- '@mdit-vue/types': 2.0.0
- '@types/markdown-it': 13.0.7
- '@types/markdown-it-emoji': 2.0.4
- '@vuepress/shared': 2.0.0-rc.9
- '@vuepress/utils': 2.0.0-rc.9
- markdown-it: 14.1.0
- markdown-it-anchor: 8.6.7(@types/markdown-it@13.0.7)(markdown-it@14.1.0)
- markdown-it-emoji: 3.0.0
- mdurl: 2.0.0
- transitivePeerDependencies:
- - supports-color
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-active-header-links@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-6i9TfGDV1zfszQ5aw6bV+/UvPdBWt3VxN2WB4Dg5o1g8Qn4z5CI6AW6VfLKRyaKUD+Rzj6W+Ikgx4xnF5RZAdA==}
+ '@vuepress/highlighter-helper@2.0.0-rc.70':
+ resolution: {integrity: sha512-YNSY22RqLTvpp8ZJ6UQtJPwpqytWBj9EkxUcBX3zf+7p4+QgMg8gdjvKAS/UKC3n2eNFBEH1y+ZRytQBVMW/9g==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vueuse/core': 10.9.0(vue@3.4.21)
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - typescript
- dev: false
+ '@vueuse/core': ^12.2.0
+ vuepress: 2.0.0-rc.19
+ peerDependenciesMeta:
+ '@vueuse/core':
+ optional: true
+
+ '@vuepress/markdown@2.0.0-rc.19':
+ resolution: {integrity: sha512-6jgUXhpEK55PEEGtPhz7Hq/JqTbLU8n9w2D7emXiK2FYcbeKpjoRIbVRzmzB/dXeK3NzHChANu2IIqpOT6Ba1w==}
- /@vuepress/plugin-back-to-top@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-qEWu0BFvadJZRH1r1UQW4mHvBYwHGSJtwNv14C/Qmxuvv2UQnpl8T2qbvPAntUWMdy94wVhr2YWCfyLh7TSEOA==}
+ '@vuepress/plugin-active-header-links@2.0.0-rc.70':
+ resolution: {integrity: sha512-t20HQsVTzkVH+nGyaaBtllV/xR4UKU/+yRSnUOo7jpbdHIpKAppke6JwOTVQAnSTDbTLqX7sD6LmI7WrVBmCVw==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vueuse/core': 10.9.0(vue@3.4.21)
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-blog@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-LCju1cC7vFA4WMaYbcnkhnEuiGno0JcavcDRFS6Np4hlVKhvh5Zoi47R3FBuF88X2OdbvBog63k4m5Jp60f+aQ==}
+ '@vuepress/plugin-back-to-top@2.0.0-rc.70':
+ resolution: {integrity: sha512-zcHN13tTSl2lK+OwStrYpp553I41GvWFf0Havr2DHJ4LlyZBEvzLzcqwJ4kZhyGdU1u0nstkyzqkEyi5PsjlJw==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- chokidar: 3.6.0
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-catalog@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-qWb0K/clF9o0bW8eeiu/30f5MWNt4MZI3jt6pLL67sAOyiMXqlHSMCKI/WYZhzgnPOQi9cnIAWoF4ePsApIzAA==}
+ '@vuepress/plugin-blog@2.0.0-rc.70':
+ resolution: {integrity: sha512-2+lprMHSRbUb2GHhV4mqMmoEZjHdYyX08Q2Tp9A+v4EJ0SNcIbic2IVgpbyysRz9DXjMaTvojkensFZwHWiNvA==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
+
+ '@vuepress/plugin-catalog@2.0.0-rc.70':
+ resolution: {integrity: sha512-mvdA4iTL6sPXjcKFIFGC4aYTye30R5xNJrezkodbmrc/bWfBSqc5NPbOXxBY4hSTYgiVOWx+dVVACIi8O6dBWg==}
+ peerDependencies:
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-comment@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-17Qpwz/W/B3cVLiCTq0UO18dy1ejf563mURas7XgqIcIibGE3G1k5kTftDbwbpehQ0e/4okdIwnkSxPpeGPOFw==}
+ '@vuepress/plugin-comment@2.0.0-rc.70':
+ resolution: {integrity: sha512-AweFgxY75t2TzNKD3d+9ytBPHLT6i2OpPsJWkrwCnfx6IjKT0SExl9uzRDYa7Y9YDVKBZhDtmEMhs7BQEghq4Q==}
peerDependencies:
- '@waline/client': ^3.1.0
- artalk: ^2.7.3
- sass-loader: ^14.0.0
- twikoo: ^1.5.0
- vuepress: 2.0.0-rc.9
+ '@waline/client': ^3.4.3
+ artalk: ^2.9.0
+ twikoo: ^1.6.39
+ vuepress: 2.0.0-rc.19
peerDependenciesMeta:
'@waline/client':
optional: true
artalk:
optional: true
- sass-loader:
- optional: true
twikoo:
optional: true
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- giscus: 1.5.0
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
- /@vuepress/plugin-copy-code@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-280jsPmI/YeKBnXt/MCw/nrv9pUou+zhHK5mOU3ecVYfY7Pu2Xi1zdZ2kK0Ri02Txm5AwLb5YWeSac349JuUUA==}
+ '@vuepress/plugin-copy-code@2.0.0-rc.70':
+ resolution: {integrity: sha512-hTYP2/SJ7qoD7NCEt9a9evZvaw+gfuHh60YISHlY/LmwJoicQyGMSjetraubWMRJFvaL77nGw4JtFxmzvKMqDA==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vueuse/core': 10.9.0(vue@3.4.21)
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-copyright@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-KFDnWkyz3tdts7uuCyVawYr2SdkNjDFJ93CtPYPDounnEJDC9OxQk0d7QSMYHotTZUzmfOiQNmJL/FngEVaDQQ==}
+ '@vuepress/plugin-copyright@2.0.0-rc.70':
+ resolution: {integrity: sha512-5W+ymDFKaGMw49R/lL73tr7x5ibhHP3YxvjdC8S1ftbP0sAvb5xekE2CXVxTxdJYTHMv1QlF4JLYgUq3G2Powg==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vueuse/core': 10.9.0(vue@3.4.21)
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-external-link-icon@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-Wt7hjWpoUccJHj5KHK24Uks+6oWug6y5cw9QzWlNgiCyg+hvII7I+FdORRvibPUG2ndymi6ZOFyJZcR072kbKA==}
+ '@vuepress/plugin-feed@2.0.0-rc.70':
+ resolution: {integrity: sha512-hzAaxh8xi+X8bz/60tmzgT86jc4koSOIPRh7V5iwVrqNcBswk76OxGO+/3bEd8Tt45RXUatwaN3O5RTrjpoU5A==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-feed@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-gtfBDSKw2b1c7aMPah4FvoaHxYj8CKCctsYtRHbuwl7xDLxj1BnRD9tBPag9llTiq7RYxHm1EK7ovezRa1hZfQ==}
+ '@vuepress/plugin-git@2.0.0-rc.68':
+ resolution: {integrity: sha512-k/tXBSIyQM26UrmDK/mN1/q6gw8PmF2uLyIaso+B39qCOFQKUBq4uJF2a0oYTq9tpjM5AHwwBpytPE5cdV/BPQ==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- cheerio: 1.0.0-rc.12
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- xml-js: 1.6.11
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-git@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-Xgrqv86bjrBPFrJr69b1KQlDUhAGhWfBRIGM3GQOI98mOi2VKCX9P4xyWK/lIpn8eVB3s0lY1KewhkXgy7UITg==}
+ '@vuepress/plugin-icon@2.0.0-rc.70':
+ resolution: {integrity: sha512-nQLr5LnfO9pTynqmHIWPXhUZpqzKaxP0JjFW1lbIDOn5F3gLZ04vxcAPvtrJYis0erwmlCR6/yx20u8bGvakIg==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- execa: 8.0.1
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-links-check@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-3dIXKJILTDP7RoPVmhtq/RfytZqX1sCA9Bf++DlgQV6jp2ctcTf4F9I5J/2wQce8yuLogO8fHnWhEgO2rgQXLw==}
+ '@vuepress/plugin-links-check@2.0.0-rc.70':
+ resolution: {integrity: sha512-ZqqU9pjtr7O0lvOOk6bxtWj5EvktL8PMegRpRv2a10uN0kQGXljGg5XihmC2EW3AlVBl3je9gw40+DVHocMDVw==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-nprogress@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-qpGA76195SyfpuQC1Pb9LwgCYIp/zg+BBDnexukJMdLjP1KnaU7HLhS5NnRNIWv8E+IC61zLvlh/wRox17QE+w==}
+ '@vuepress/plugin-markdown-ext@2.0.0-rc.70':
+ resolution: {integrity: sha512-NwB2cAmATP8Nd3mBLPvLDANKXAFj2VxB9HZUOb9/Vrpt3+otSRQ17mBjUwnBllbnE9Yjz1zcAU6HjKuMdkJfEw==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-photo-swipe@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-2zCljlDTlSXUUeYy3Z74zkkAc6uEzV0Tos2HL89RZEhiH5tMyvNJaG4+dTVy7uODcQoe+Fcv1hovdbC6LKCFoQ==}
+ '@vuepress/plugin-markdown-hint@2.0.0-rc.70':
+ resolution: {integrity: sha512-yd9HAKRw9hcG8jsatSpA5H6CVFFm9c8eXBq1OGKsm/1kCCLcznKdc6bdnL6c24ieOrS5se0IL+daCoaklruscQ==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vueuse/core': 10.9.0(vue@3.4.21)
- photoswipe: 5.4.3
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-prismjs@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-dMTCu/TZ1QCmTHXL4THVeh9gWzuqkJV8qhck5U77OP1qmgyf+r529A+MTOgp3ddcph1Yzb/FRb2orlefHk+yNQ==}
+ '@vuepress/plugin-markdown-image@2.0.0-rc.70':
+ resolution: {integrity: sha512-Ao0WnZ0tR3HRClDNhGIFi3+/lhgqrhoU1HWRsfnWx1ONcvTTNZfuR2TrLzKvkPiDzg1D05HZaFH3PggCun9V8Q==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- prismjs: 1.29.0
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-reading-time@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-8ByRTp6z4z0d9W1evfeVyOx55V9OYqxJJeC7KBiJuiA2GP8QkY9b8ajbQ8SWeCjzDLl4H0KudSU1KqH2kqw/zQ==}
+ '@vuepress/plugin-markdown-include@2.0.0-rc.70':
+ resolution: {integrity: sha512-4C4HOieqdIThAF/zi6h5bWkw7l22qUn9vmR5PGPNmnQSZ2anr5L0+ulIYOOElGZxlXL35Io0FD749fXrV2alVg==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-rtl@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-r+4aP898KsFbF6m1J0e+776ZlSE9yaHr9zsMlib1GEUDcqP/OykMYaNKwRsOMB1eFXNmymgHlXFvswBGEHxS7w==}
+ '@vuepress/plugin-markdown-math@2.0.0-rc.70':
+ resolution: {integrity: sha512-PSqMqA7C5d6z5qfhIYbDgCZC3AL+P0644dIEgOMDG4Twg9S6LtDawkbILOshT0nb6RVLlA9gy/0ME5yIc/+zjw==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ katex: ^0.16.10
+ mathjax-full: ^3.2.2
+ vuepress: 2.0.0-rc.19
+ peerDependenciesMeta:
+ katex:
+ optional: true
+ mathjax-full:
+ optional: true
- /@vuepress/plugin-search@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-Dci/gN0ScbQXOKIB2JnUv8x4Ea+0wmU3xKe1IalyKdyg7cnayNqbmXmpqd32p4tlRXcFj9qhipa6AxvdhPcXqA==}
+ '@vuepress/plugin-markdown-stylize@2.0.0-rc.70':
+ resolution: {integrity: sha512-Z0PTI+ePEXpA41llpOpXiBgCJsJvkU9HAJ0cjfeWODMHJ0wa6/Y9aA3w2aXPzg6qBGaHxSAXymRJz51a4H53EA==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- chokidar: 3.6.0
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-seo@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-q8pXhXn5OL0QG6KN9rjyXngj2km5eRDK0VL8ShLrTD9fAwvjhujhjHpI/DRHg6ScWlMDKY7ncEOmslDCBuKLtg==}
+ '@vuepress/plugin-markdown-tab@2.0.0-rc.70':
+ resolution: {integrity: sha512-W/tRQ8dgPiOj94GUz9apWxJHWsLC88RNS10hRX9wBlSaqZ/S9YUcI4D8nWy0uf4KYo6PbOnucJL/y66uuhlrLw==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-sitemap@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-YbotKptHfifjwmXhj4kX6iA8tCGp7gTZAHm9YiPDr/8dYzBkkQ4oC84JCifkZYt3fWkVqq/Qa0vpJfnKPGOidg==}
+ '@vuepress/plugin-notice@2.0.0-rc.70':
+ resolution: {integrity: sha512-a+Z/xJopfm8OZ0SRon78D94RIpkhi8CNbFDUhQYPciS71b/pqN28OFdFPFWNU/PACcRoe3IMBcXWsq1wKZ9/Rg==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- sitemap: 7.1.1
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/plugin-theme-data@2.0.0-rc.21(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-vLXvTKx4gWXY6oVaJ9Z2ECnojnKQuXBIe1ZGIAwJdxCYfr6aaqggrVvmphB8BwTURh0XAuis/l6YTcMrs0bX8Q==}
+ '@vuepress/plugin-nprogress@2.0.0-rc.70':
+ resolution: {integrity: sha512-WYhCs5X1vPbzQ5PhYTWzh5cCRjsCnE52qBlzIzftzM9SNG2Fm8tdMS3V7bmCzpg1IgALcIfwX/9r7uUVcby0OQ==}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vue/devtools-api': 6.6.1
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /@vuepress/shared@2.0.0-rc.9:
- resolution: {integrity: sha512-XfI6CWNv4/Vp9Iew6GJil9RUSy1rM7zGdjwikr0j3Rkh55q3f00w1wud47wE9kxRqsZ0PIvsMget5CxEn5rA/w==}
- dependencies:
- '@mdit-vue/types': 2.0.0
- dev: false
+ '@vuepress/plugin-photo-swipe@2.0.0-rc.70':
+ resolution: {integrity: sha512-z3BlKQttCMycl3u/cBVO2XVdLGEI/1qtW8Rp9u4U5G6Utv3HU5/UL3GIZmz2mNP7l3k4mOE8wnnKaxDVbvIRug==}
+ peerDependencies:
+ vuepress: 2.0.0-rc.19
- /@vuepress/utils@2.0.0-rc.9:
- resolution: {integrity: sha512-qk6Pel4JVKYKxp3bWxyvnwchvx3QaCWc7SqUw7L6qUo/um+0U2U45L0anWoAfckw12RXYhoIEbJ9UZpueiKOPg==}
- dependencies:
- '@types/debug': 4.1.12
- '@types/fs-extra': 11.0.4
- '@types/hash-sum': 1.0.2
- '@vuepress/shared': 2.0.0-rc.9
- debug: 4.3.4
- fs-extra: 11.2.0
- globby: 14.0.1
- hash-sum: 2.0.0
- ora: 8.0.1
- picocolors: 1.0.0
- upath: 2.0.1
- transitivePeerDependencies:
- - supports-color
- dev: false
+ '@vuepress/plugin-reading-time@2.0.0-rc.70':
+ resolution: {integrity: sha512-AemYL6ogRsstEnLiOEDcaMULJecpeftH0RpAqdUTcAPiy3gsWdn4kMgMHlvpgm1J99aE5w6d8G511Kx+i6JxAQ==}
+ peerDependencies:
+ vuepress: 2.0.0-rc.19
- /@vueuse/core@10.9.0(vue@3.4.21):
- resolution: {integrity: sha512-/1vjTol8SXnx6xewDEKfS0Ra//ncg4Hb0DaZiwKf7drgfMsKFExQ+FnnENcN6efPen+1kIzhLQoGSy0eDUVOMg==}
- dependencies:
- '@types/web-bluetooth': 0.0.20
- '@vueuse/metadata': 10.9.0
- '@vueuse/shared': 10.9.0(vue@3.4.21)
- vue-demi: 0.14.7(vue@3.4.21)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - vue
- dev: false
+ '@vuepress/plugin-redirect@2.0.0-rc.70':
+ resolution: {integrity: sha512-je16tvDeuphNz21hqdxQoKHCn/LVfwd6YtB3xNb5t/cEBUUAdB+byrwfUlpUVY3HWqFjr5Ot0RJuQkHFVmBJUA==}
+ hasBin: true
+ peerDependencies:
+ vuepress: 2.0.0-rc.19
- /@vueuse/metadata@10.9.0:
- resolution: {integrity: sha512-iddNbg3yZM0X7qFY2sAotomgdHK7YJ6sKUvQqbvwnf7TmaVPxS4EJydcNsVejNdS8iWCtDk+fYXr7E32nyTnGA==}
- dev: false
+ '@vuepress/plugin-rtl@2.0.0-rc.70':
+ resolution: {integrity: sha512-2odC4M3uRGZEKYFvDLRDwyQOwAJ8YFtRI0ZrDh0paNROqssWsK9JGpYlRSDCLedwtZuQYLp8L/NN44F0kyx+fw==}
+ peerDependencies:
+ vuepress: 2.0.0-rc.19
- /@vueuse/shared@10.9.0(vue@3.4.21):
- resolution: {integrity: sha512-Uud2IWncmAfJvRaFYzv5OHDli+FbOzxiVEQdLCKQKLyhz94PIyFC3CHcH7EDMwIn8NPtD06+PNbC/PiO0LGLtw==}
- dependencies:
- vue-demi: 0.14.7(vue@3.4.21)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - vue
- dev: false
+ '@vuepress/plugin-sass-palette@2.0.0-rc.70':
+ resolution: {integrity: sha512-wy17yNlmc0liQFJSoqc9XEu96Nk3daSof2ncXNuRGJnCsfXbwd0QZr6bNdZos0Zmk5+KolzIffeEBhOGnRw+VA==}
+ peerDependencies:
+ sass: ^1.80.3
+ sass-embedded: ^1.80.3
+ sass-loader: ^16.0.2
+ vuepress: 2.0.0-rc.19
+ peerDependenciesMeta:
+ sass:
+ optional: true
+ sass-embedded:
+ optional: true
+ sass-loader:
+ optional: true
+
+ '@vuepress/plugin-search@2.0.0-rc.70':
+ resolution: {integrity: sha512-Av8yFH4xeC4OUhit6NWMOJ50KwMd2J/LQzGT/e70o/oDn5wV7nomKU972mdnHILIpzin/HrJP0LhvSeXZrLrNQ==}
+ peerDependencies:
+ vuepress: 2.0.0-rc.19
+
+ '@vuepress/plugin-seo@2.0.0-rc.70':
+ resolution: {integrity: sha512-8l4BYboPcCQ96h53Wzmh7eCXOL3x9XzvNjude4pJHsuU4tSl/T0rsCyZI2fPOybKJQSPhahKMiM4sU1+e+/wQg==}
+ peerDependencies:
+ vuepress: 2.0.0-rc.19
+
+ '@vuepress/plugin-shiki@2.0.0-rc.70':
+ resolution: {integrity: sha512-N4E9mnpjUwcC2MRWdTFSGE3q3X7cQeG9HlBK5/Ts6M/qd15pn1q88cOdkemMGmUYGKBJv0PMlm2g2x8OTvjs6A==}
+ peerDependencies:
+ vuepress: 2.0.0-rc.19
+
+ '@vuepress/plugin-sitemap@2.0.0-rc.70':
+ resolution: {integrity: sha512-TL9Oblicr1O9WnJnBqwMuC7VZHad6Z4pOHpEEYQKD2O9vRCnlEeP6f7xYF+xWjXXNjQasq6mYGPzTBboqL/PDA==}
+ peerDependencies:
+ vuepress: 2.0.0-rc.19
+
+ '@vuepress/plugin-theme-data@2.0.0-rc.70':
+ resolution: {integrity: sha512-xIxEvWZb+rZkUNUy4T2h1vA/YXMMflvvXRu3VHjozlnzjDqdICxFGBgqHMDdQ/9cSXKLGJNNLi4MPm4lzMuCRw==}
+ peerDependencies:
+ vuepress: 2.0.0-rc.19
+
+ '@vuepress/shared@2.0.0-rc.19':
+ resolution: {integrity: sha512-xaDeZxX0Qetc2Y6/lrzO6M/40i3LmMm7Fk85bOftBBOaNehZ24RdsmIHBJDDv+bTUv+DBF++1/mOtbt6DBRzEA==}
- /abbrev@1.1.1:
+ '@vuepress/utils@2.0.0-rc.19':
+ resolution: {integrity: sha512-cgzk8/aJquZKgFMNTuqdjbU5NrCzrPmdTyhYBcmliL/6N/He1OTWn3PD9QWUGJNODb1sPRJpklZnCpU07waLmg==}
+
+ '@vueuse/core@12.4.0':
+ resolution: {integrity: sha512-XnjQYcJwCsyXyIafyA6SvyN/OBtfPnjvJmbxNxQjCcyWD198urwm5TYvIUUyAxEAN0K7HJggOgT15cOlWFyLeA==}
+
+ '@vueuse/metadata@12.4.0':
+ resolution: {integrity: sha512-AhPuHs/qtYrKHUlEoNO6zCXufu8OgbR8S/n2oMw1OQuBQJ3+HOLQ+EpvXs+feOlZMa0p8QVvDWNlmcJJY8rW2g==}
+
+ '@vueuse/shared@12.4.0':
+ resolution: {integrity: sha512-9yLgbHVIF12OSCojnjTIoZL1+UA10+O4E1aD6Hpfo/DKVm5o3SZIwz6CupqGy3+IcKI8d6Jnl26EQj/YucnW0Q==}
+
+ abbrev@1.1.1:
resolution: {integrity: sha512-nne9/IiQ/hzIhY6pdDnbBtz7DjPTKrY00P/zvPSm5pOFkl6xuGrGnXn/VtTNNfNtAfZ9/1RtehkszU9qcTii0Q==}
- dev: false
- /abbrev@2.0.0:
+ abbrev@2.0.0:
resolution: {integrity: sha512-6/mh1E2u2YgEsCHdY0Yx5oW+61gZU+1vXaoiHHrpKeuRNNgFvS+/jrwHiQhB5apAf5oB7UB7E19ol2R2LKH8hQ==}
engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
- dev: false
- /agent-base@6.0.2:
+ agent-base@6.0.2:
resolution: {integrity: sha512-RZNwNclF7+MS/8bDg70amg32dyeZGZxiDuQmZxKLAlQjr3jGyLx+4Kkk58UO7D2QdgFIQCovuSuZESne6RG6XQ==}
engines: {node: '>= 6.0.0'}
- dependencies:
- debug: 4.3.4
- transitivePeerDependencies:
- - supports-color
- dev: false
- /agent-base@7.1.1:
- resolution: {integrity: sha512-H0TSyFNDMomMNJQBn8wFV5YC/2eJ+VXECwOadZJT554xP6cODZHPX3H9QMQECxvrgiSOP1pHjy1sMWQVYJOUOA==}
+ agent-base@7.1.3:
+ resolution: {integrity: sha512-jRR5wdylq8CkOe6hei19GGZnxM6rBGwFl3Bg0YItGDimvjGtAvdZk4Pu6Cl4u4Igsws4a1fd1Vq3ezrhn4KmFw==}
engines: {node: '>= 14'}
- dependencies:
- debug: 4.3.4
- transitivePeerDependencies:
- - supports-color
- dev: false
- /aggregate-error@3.1.0:
+ aggregate-error@3.1.0:
resolution: {integrity: sha512-4I7Td01quW/RpocfNayFdFVk1qSuoh0E7JrbRJ16nH01HhKFQ88INq9Sd+nd72zqRySlr9BmDA8xlEJ6vJMrYA==}
engines: {node: '>=8'}
- dependencies:
- clean-stack: 2.2.0
- indent-string: 4.0.0
- dev: false
- /ansi-regex@5.0.1:
+ ansi-regex@5.0.1:
resolution: {integrity: sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==}
engines: {node: '>=8'}
- dev: false
- /ansi-regex@6.0.1:
- resolution: {integrity: sha512-n5M855fKb2SsfMIiFFoVrABHJC8QtHwVx+mHWP3QcEqBHYienj5dHSgjbxtC0WEZXYt4wcD6zrQElDPhFuZgfA==}
+ ansi-regex@6.1.0:
+ resolution: {integrity: sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA==}
engines: {node: '>=12'}
- dev: false
- /ansi-styles@4.3.0:
+ ansi-styles@4.3.0:
resolution: {integrity: sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==}
engines: {node: '>=8'}
- dependencies:
- color-convert: 2.0.1
- dev: false
- /ansi-styles@6.2.1:
+ ansi-styles@6.2.1:
resolution: {integrity: sha512-bN798gFfQX+viw3R7yrGWRqnrN2oRkEkUjjl4JNn4E8GxxbjtG3FbrEIIY3l8/hrwUwIeCZvi4QuOTP4MErVug==}
engines: {node: '>=12'}
- dev: false
- /anymatch@3.1.3:
+ anymatch@3.1.3:
resolution: {integrity: sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==}
engines: {node: '>= 8'}
- dependencies:
- normalize-path: 3.0.0
- picomatch: 2.3.1
- dev: false
- /aproba@2.0.0:
+ aproba@2.0.0:
resolution: {integrity: sha512-lYe4Gx7QT+MKGbDsA+Z+he/Wtef0BiwDOlK/XkBrdfsh9J/jPPXbX0tE9x9cl27Tmu5gg3QUbUrQYa/y+KOHPQ==}
- dev: false
- /are-we-there-yet@2.0.0:
+ are-we-there-yet@2.0.0:
resolution: {integrity: sha512-Ci/qENmwHnsYo9xKIcUJN5LeDKdJ6R1Z1j9V/J5wyq8nh/mYPEpIKJbBZXtZjG04HiK7zV/p6Vs9952MrMeUIw==}
engines: {node: '>=10'}
- dependencies:
- delegates: 1.0.0
- readable-stream: 3.6.2
- dev: false
+ deprecated: This package is no longer supported.
- /arg@5.0.2:
+ arg@5.0.2:
resolution: {integrity: sha512-PYjyFOLKQ9y57JvQ6QLo8dAgNqswh8M1RMJYdQduT6xbWSgK36P/Z/v+p888pM69jMMfS8Xd8F6I1kQ/I9HUGg==}
- dev: false
- /argparse@1.0.10:
+ argparse@1.0.10:
resolution: {integrity: sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==}
- dependencies:
- sprintf-js: 1.0.3
- dev: false
- /argparse@2.0.1:
+ argparse@2.0.1:
resolution: {integrity: sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==}
- dev: false
- /autoprefixer@10.4.19(postcss@8.4.38):
- resolution: {integrity: sha512-BaENR2+zBZ8xXhM4pUaKUxlVdxZ0EZhjvbopwnXmxRUfqDmwSpC2lAi/QXvx7NRdPCo1WKEcEF6mV64si1z4Ew==}
+ autoprefixer@10.4.20:
+ resolution: {integrity: sha512-XY25y5xSv/wEoqzDyXXME4AFfkZI0P23z6Fs3YgymDnKJkCGOnkL0iTxCa85UTqaSgfcqyf3UA6+c7wUvx/16g==}
engines: {node: ^10 || ^12 || >=14}
hasBin: true
peerDependencies:
postcss: ^8.1.0
- dependencies:
- browserslist: 4.23.0
- caniuse-lite: 1.0.30001603
- fraction.js: 4.3.7
- normalize-range: 0.1.2
- picocolors: 1.0.0
- postcss: 8.4.38
- postcss-value-parser: 4.2.0
- dev: false
- /balanced-match@1.0.2:
+ balanced-match@1.0.2:
resolution: {integrity: sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==}
- dev: false
- /balloon-css@1.2.0:
+ balloon-css@1.2.0:
resolution: {integrity: sha512-urXwkHgwp6GsXVF+it01485Z2Cj4pnW02ICnM0TemOlkKmCNnDLmyy+ZZiRXBpwldUXO+aRNr7Hdia4CBvXJ5A==}
- dev: false
- /bcrypt-ts@5.0.2:
- resolution: {integrity: sha512-gDwQ5784AkkfhHACh3jGcg1hUubyZyeq9AtVd5gXkcyHGVOC+mORjRIHSj+fHfqwY5vxwyBLXQpcfk8MpK0ROg==}
+ bcrypt-ts@5.0.3:
+ resolution: {integrity: sha512-2FcgD12xPbwCoe5i9/HK0jJ1xA1m+QfC1e6htG9Bl/hNOnLyaFmQSlqLKcfe3QdnoMPKpKEGFCbESBTg+SJNOw==}
engines: {node: '>=18'}
- dev: false
- /binary-extensions@2.3.0:
+ binary-extensions@2.3.0:
resolution: {integrity: sha512-Ceh+7ox5qe7LJuLHoY0feh3pHuUDHAcRUeyL2VYghZwfpkNIy/+8Ocg0a3UuSoYzavmylwuLWQOf3hl0jjMMIw==}
engines: {node: '>=8'}
- dev: false
- /boolbase@1.0.0:
+ birpc@0.2.19:
+ resolution: {integrity: sha512-5WeXXAvTmitV1RqJFppT5QtUiz2p1mRSYU000Jkft5ZUCLJIk4uQriYNO50HknxKwM6jd8utNc66K1qGIwwWBQ==}
+
+ boolbase@1.0.0:
resolution: {integrity: sha512-JZOSA7Mo9sNGB8+UjSgzdLtokWAky1zbztM3WRLCbZ70/3cTANmQmOdR7y2g+J0e2WXywy1yS468tY+IruqEww==}
- dev: false
- /brace-expansion@1.1.11:
+ brace-expansion@1.1.11:
resolution: {integrity: sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==}
- dependencies:
- balanced-match: 1.0.2
- concat-map: 0.0.1
- dev: false
- /brace-expansion@2.0.1:
+ brace-expansion@2.0.1:
resolution: {integrity: sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==}
- dependencies:
- balanced-match: 1.0.2
- dev: false
- /braces@3.0.2:
- resolution: {integrity: sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==}
+ braces@3.0.3:
+ resolution: {integrity: sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==}
engines: {node: '>=8'}
- dependencies:
- fill-range: 7.0.1
- dev: false
- /browserslist@4.23.0:
- resolution: {integrity: sha512-QW8HiM1shhT2GuzkvklfjcKDiWFXHOeFCIA/huJPwHsslwcydgk7X+z2zXpEijP98UCY7HbubZt5J2Zgvf0CaQ==}
+ browserslist@4.24.4:
+ resolution: {integrity: sha512-KDi1Ny1gSePi1vm0q4oxSF8b4DR44GF4BbmS2YdhPLOEqd8pDviZOGH/GsmRwoWJ2+5Lr085X7naowMwKHDG1A==}
engines: {node: ^6 || ^7 || ^8 || ^9 || ^10 || ^11 || ^12 || >=13.7}
hasBin: true
- dependencies:
- caniuse-lite: 1.0.30001603
- electron-to-chromium: 1.4.722
- node-releases: 2.0.14
- update-browserslist-db: 1.0.13(browserslist@4.23.0)
- dev: false
- /cac@6.7.14:
+ buffer-builder@0.2.0:
+ resolution: {integrity: sha512-7VPMEPuYznPSoR21NE1zvd2Xna6c/CloiZCfcMXR1Jny6PjX0N4Nsa38zcBFo/FMK+BlA+FLKbJCQ0i2yxp+Xg==}
+
+ cac@6.7.14:
resolution: {integrity: sha512-b6Ilus+c3RrdDk+JhLKUAQfzzgLEPy6wcXqS7f/xe1EETvsDP6GORG7SFuOs6cID5YkqchW/LXZbX5bc8j7ZcQ==}
engines: {node: '>=8'}
- dev: false
- /cacache@18.0.2:
- resolution: {integrity: sha512-r3NU8h/P+4lVUHfeRw1dtgQYar3DZMm4/cm2bZgOvrFC/su7budSOeqh52VJIC4U4iG1WWwV6vRW0znqBvxNuw==}
+ cacache@18.0.4:
+ resolution: {integrity: sha512-B+L5iIa9mgcjLbliir2th36yEwPftrzteHYujzsx3dFP/31GCHcIeS8f5MGd80odLOjaOvSpU3EEAmRQptkxLQ==}
engines: {node: ^16.14.0 || >=18.0.0}
- dependencies:
- '@npmcli/fs': 3.1.0
- fs-minipass: 3.0.3
- glob: 10.3.12
- lru-cache: 10.2.0
- minipass: 7.0.4
- minipass-collect: 2.0.1
- minipass-flush: 1.0.5
- minipass-pipeline: 1.2.4
- p-map: 4.0.0
- ssri: 10.0.5
- tar: 6.2.1
- unique-filename: 3.0.0
- dev: false
- /camelcase@5.3.1:
+ camelcase@5.3.1:
resolution: {integrity: sha512-L28STB170nwWS63UjtlEOE3dldQApaJXZkOI1uMFfzf3rRuPegHaHesyee+YxQ+W6SvRDQV6UrdOdRiR153wJg==}
engines: {node: '>=6'}
- dev: false
- /caniuse-lite@1.0.30001603:
- resolution: {integrity: sha512-iL2iSS0eDILMb9n5yKQoTBim9jMZ0Yrk8g0N9K7UzYyWnfIKzXBZD5ngpM37ZcL/cv0Mli8XtVMRYMQAfFpi5Q==}
- dev: false
+ caniuse-lite@1.0.30001692:
+ resolution: {integrity: sha512-A95VKan0kdtrsnMubMKxEKUKImOPSuCpYgxSQBo036P5YYgVIcOYJEgt/txJWqObiRQeISNCfef9nvlQ0vbV7A==}
- /chalk@5.3.0:
- resolution: {integrity: sha512-dLitG79d+GV1Nb/VYcCDFivJeK1hiukt9QjRNVOsUtTy1rR1YJsmpGGTZ3qJos+uw7WmWF4wUwBd9jxjocFC2w==}
+ ccount@2.0.1:
+ resolution: {integrity: sha512-eyrF0jiFpY+3drT6383f1qhkbGsLSifNAjA61IUjZjmLCWjItY6LB9ft9YhoDgwfmclB2zhu51Lc7+95b8NRAg==}
+
+ chalk@5.4.1:
+ resolution: {integrity: sha512-zgVZuo2WcZgfUEmsn6eO3kINexW8RAE4maiQ8QNs8CtpPCSyMiYsULR3HQYkm3w8FIA3SberyMJMSldGsW+U3w==}
engines: {node: ^12.17.0 || ^14.13 || >=16.0.0}
- dev: false
- /cheerio-select@2.1.0:
- resolution: {integrity: sha512-9v9kG0LvzrlcungtnJtpGNxY+fzECQKhK4EGJX2vByejiMX84MFNQw4UxPJl3bFbTMw+Dfs37XaIkCwTZfLh4g==}
- dependencies:
- boolbase: 1.0.0
- css-select: 5.1.0
- css-what: 6.1.0
- domelementtype: 2.3.0
- domhandler: 5.0.3
- domutils: 3.1.0
- dev: false
+ character-entities-html4@2.1.0:
+ resolution: {integrity: sha512-1v7fgQRj6hnSwFpq1Eu0ynr/CDEw0rXo2B61qXrLNdHZmPKgb7fqS1a2JwF0rISo9q77jDI8VMEHoApn8qDoZA==}
- /cheerio@1.0.0-rc.12:
- resolution: {integrity: sha512-VqR8m68vM46BNnuZ5NtnGBKIE/DfN0cRIzg9n40EIq9NOv90ayxLBXA8fXC5gquFRGJSTRqBq25Jt2ECLR431Q==}
- engines: {node: '>= 6'}
- dependencies:
- cheerio-select: 2.1.0
- dom-serializer: 2.0.0
- domhandler: 5.0.3
- domutils: 3.1.0
- htmlparser2: 8.0.2
- parse5: 7.1.2
- parse5-htmlparser2-tree-adapter: 7.0.0
- dev: false
+ character-entities-legacy@3.0.0:
+ resolution: {integrity: sha512-RpPp0asT/6ufRm//AJVwpViZbGM/MkjQFxJccQRHmISF/22NBtsHqAWmL+/pmkPWoIUJdWyeVleTl1wydHATVQ==}
+
+ character-entities@2.0.2:
+ resolution: {integrity: sha512-shx7oQ0Awen/BRIdkjkvz54PnEEI/EjwXDSIZp86/KKdbafHh1Df/RYGBhn4hbe2+uKC9FnT5UCEdyPz3ai9hQ==}
+
+ character-reference-invalid@2.0.1:
+ resolution: {integrity: sha512-iBZ4F4wRbyORVsu0jPV7gXkOsGYjGHPmAyv+HiHG8gi5PtC9KI2j1+v8/tlibRvjoWX027ypmG/n0HtO5t7unw==}
+
+ cheerio-select@2.1.0:
+ resolution: {integrity: sha512-9v9kG0LvzrlcungtnJtpGNxY+fzECQKhK4EGJX2vByejiMX84MFNQw4UxPJl3bFbTMw+Dfs37XaIkCwTZfLh4g==}
+
+ cheerio@1.0.0:
+ resolution: {integrity: sha512-quS9HgjQpdaXOvsZz82Oz7uxtXiy6UIsIQcpBj7HRw2M63Skasm9qlDocAM7jNuaxdhpPU7c4kJN+gA5MCu4ww==}
+ engines: {node: '>=18.17'}
- /chokidar@3.6.0:
+ chokidar@3.6.0:
resolution: {integrity: sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw==}
engines: {node: '>= 8.10.0'}
- dependencies:
- anymatch: 3.1.3
- braces: 3.0.2
- glob-parent: 5.1.2
- is-binary-path: 2.1.0
- is-glob: 4.0.3
- normalize-path: 3.0.0
- readdirp: 3.6.0
- optionalDependencies:
- fsevents: 2.3.3
- dev: false
- /chownr@2.0.0:
+ chokidar@4.0.3:
+ resolution: {integrity: sha512-Qgzu8kfBvo+cA4962jnP1KkS6Dop5NS6g7R5LFYJr4b8Ub94PPQXUksCw9PvXoeXPRRddRNC5C1JQUR2SMGtnA==}
+ engines: {node: '>= 14.16.0'}
+
+ chownr@2.0.0:
resolution: {integrity: sha512-bIomtDF5KGpdogkLd9VspvFzk9KfpyyGlS8YFVZl7TGPBHL5snIOnxeshwVgPteQ9b4Eydl+pVbIyE1DcvCWgQ==}
engines: {node: '>=10'}
- dev: false
- /clean-stack@2.2.0:
+ clean-stack@2.2.0:
resolution: {integrity: sha512-4diC9HaTE+KRAMWhDhrGOECgWZxoevMc5TlkObMqNSsVU62PYzXZ/SMTjzyGAFF1YusgxGcSWTEXBhp0CPwQ1A==}
engines: {node: '>=6'}
- dev: false
- /cli-cursor@4.0.0:
- resolution: {integrity: sha512-VGtlMu3x/4DOtIUwEkRezxUZ2lBacNJCHash0N0WeZDBS+7Ux1dm3XWAgWYxLJFMMdOeXMHXorshEFhbMSGelg==}
- engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0}
- dependencies:
- restore-cursor: 4.0.0
- dev: false
+ cli-cursor@5.0.0:
+ resolution: {integrity: sha512-aCj4O5wKyszjMmDT4tZj93kxyydN/K5zPWSCe6/0AV/AA1pqe5ZBIw0a2ZfPQV7lL5/yb5HsUreJ6UFAF1tEQw==}
+ engines: {node: '>=18'}
- /cli-spinners@2.9.2:
+ cli-spinners@2.9.2:
resolution: {integrity: sha512-ywqV+5MmyL4E7ybXgKys4DugZbX0FC6LnwrhjuykIjnK9k8OQacQ7axGKnjDXWNhns0xot3bZI5h55H8yo9cJg==}
engines: {node: '>=6'}
- dev: false
- /cliui@6.0.0:
+ cliui@6.0.0:
resolution: {integrity: sha512-t6wbgtoCXvAzst7QgXxJYqPt0usEfbgQdftEPbLL/cvv6HPE5VgvqCuAIDR0NgU52ds6rFwqrgakNLrHEjCbrQ==}
- dependencies:
- string-width: 4.2.3
- strip-ansi: 6.0.1
- wrap-ansi: 6.2.0
- dev: false
- /color-convert@2.0.1:
+ color-convert@2.0.1:
resolution: {integrity: sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==}
engines: {node: '>=7.0.0'}
- dependencies:
- color-name: 1.1.4
- dev: false
- /color-name@1.1.4:
+ color-name@1.1.4:
resolution: {integrity: sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==}
- dev: false
- /color-support@1.1.3:
+ color-support@1.1.3:
resolution: {integrity: sha512-qiBjkpbMLO/HL68y+lh4q0/O1MZFj2RX6X/KmMa3+gJD3z+WwI1ZzDHysvqHGS3mP6mznPckpXmw1nI9cJjyRg==}
hasBin: true
- dev: false
- /commander@9.2.0:
+ colorjs.io@0.5.2:
+ resolution: {integrity: sha512-twmVoizEW7ylZSN32OgKdXRmo1qg+wT5/6C3xu5b9QsWzSFAhHLn2xd8ro0diCsKfCj1RdaTP/nrcW+vAoQPIw==}
+
+ comma-separated-tokens@2.0.3:
+ resolution: {integrity: sha512-Fu4hJdvzeylCfQPp9SGWidpzrMs7tTrlu6Vb8XGaRGck8QSNZJJp538Wrb60Lax4fPwR64ViY468OIUTbRlGZg==}
+
+ commander@13.0.0:
+ resolution: {integrity: sha512-oPYleIY8wmTVzkvQq10AEok6YcTC4sRUBl8F9gVuwchGVUCTbl/vhLTaQqutuuySYOsu8YTgV+OxKc/8Yvx+mQ==}
+ engines: {node: '>=18'}
+
+ commander@8.3.0:
+ resolution: {integrity: sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww==}
+ engines: {node: '>= 12'}
+
+ commander@9.2.0:
resolution: {integrity: sha512-e2i4wANQiSXgnrBlIatyHtP1odfUp0BbV5Y5nEGbxtIrStkEOAAzCUirvLBNXHLr7kwLvJl6V+4V3XV9x7Wd9w==}
engines: {node: ^12.20.0 || >=14}
- dev: false
- /concat-map@0.0.1:
+ concat-map@0.0.1:
resolution: {integrity: sha512-/Srv4dswyQNBfohGpz9o6Yb3Gz3SrUDqBH5rTuhGR7ahtlbYKnVxw2bCFMRljaA7EXHaXZ8wsHdodFvbkhKmqg==}
- dev: false
- /connect-history-api-fallback@2.0.0:
+ connect-history-api-fallback@2.0.0:
resolution: {integrity: sha512-U73+6lQFmfiNPrYbXqr6kZ1i1wiRqXnp2nhMsINseWXO8lDau0LGEffJ8kQi4EjLZympVgRdvqjAgiZ1tgzDDA==}
engines: {node: '>=0.8'}
- dev: false
- /console-control-strings@1.1.0:
+ console-control-strings@1.1.0:
resolution: {integrity: sha512-ty/fTekppD2fIwRvnZAVdeOiGd1c7YXEixbgJTNzqcxJWKQnjJ/V1bNEEE6hygpM3WjwHFUVK6HTjWSzV4a8sQ==}
- dev: false
- /create-codepen@1.0.1:
- resolution: {integrity: sha512-XzSWwGCFNeOnNGp3KdCDGaKq4Cp1SvjzpPGQqO0tj1HT3BhksLdl/xQ2ZEY4+0MQ3m1I/K1Fvpm4GGMthtamyA==}
- dev: false
+ copy-anything@3.0.5:
+ resolution: {integrity: sha512-yCEafptTtb4bk7GLEQoM8KVJpxAfdBJYaXyzQEgQQQgYrZiDp8SJmGKlYza6CYjEDNstAdNdKA3UuoULlEbS6w==}
+ engines: {node: '>=12.13'}
+
+ create-codepen@2.0.0:
+ resolution: {integrity: sha512-ehJ0Zw5RSV2G4+/azUb7vEZWRSA/K9cW7HDock1Y9ViDexkgSJUZJRcObdw/YAWeXKjreEQV9l/igNSsJ1yw5A==}
+ engines: {node: '>=18'}
- /cross-spawn@7.0.3:
- resolution: {integrity: sha512-iRDPJKUPVEND7dHPO8rkbOnPpyDygcDFtWjpeWNCgy8WP2rXcxXL8TskReQl6OrB2G7+UJrags1q15Fudc7G6w==}
+ cross-spawn@7.0.6:
+ resolution: {integrity: sha512-uV2QOWP2nWzsy2aMp8aRibhi9dlzF5Hgh5SHaB9OiTGEyDTiJJyx0uy51QXdyWbtAHNua4XJzUKca3OzKUd3vA==}
engines: {node: '>= 8'}
- dependencies:
- path-key: 3.1.1
- shebang-command: 2.0.0
- which: 2.0.2
- dev: false
- /css-select@5.1.0:
+ css-select@5.1.0:
resolution: {integrity: sha512-nwoRF1rvRRnnCqqY7updORDsuqKzqYJ28+oSMaJMMgOauh3fvwHqMS7EZpIPqK8GL+g9mKxF1vP/ZjSeNjEVHg==}
- dependencies:
- boolbase: 1.0.0
- css-what: 6.1.0
- domhandler: 5.0.3
- domutils: 3.1.0
- nth-check: 2.1.1
- dev: false
- /css-what@6.1.0:
+ css-what@6.1.0:
resolution: {integrity: sha512-HTUrgRJ7r4dsZKU6GjmpfRK1O76h97Z8MfS1G0FozR+oF2kG6Vfe8JE6zwrkbxigziPHinCJ+gCPjA9EaBDtRw==}
engines: {node: '>= 6'}
- dev: false
- /csstype@3.1.3:
+ csstype@3.1.3:
resolution: {integrity: sha512-M1uQkMl8rQK/szD0LNhtqxIPLpimGm8sOBwU7lLnCpSbTyY3yeU1Vc7l4KT5zT4s/yOxHH5O7tIuuLOCnLADRw==}
- dev: false
- /dayjs@1.11.10:
- resolution: {integrity: sha512-vjAczensTgRcqDERK0SR2XMwsF/tSvnvlv6VcF2GIhg6Sx4yOIt/irsr1RDJsKiIyBzJDpCoXiWWq28MqH2cnQ==}
- dev: false
+ dayjs@1.11.13:
+ resolution: {integrity: sha512-oaMBel6gjolK862uaPQOVTA7q3TZhuSvuMQAAglQDOWYO9A91IrAOUJEyKVlqJlHE0vq5p5UXxzdPfMH/x6xNg==}
- /debug@4.3.4:
- resolution: {integrity: sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==}
+ debug@4.4.0:
+ resolution: {integrity: sha512-6WTZ/IxCY/T6BALoZHaE4ctp9xm+Z5kY/pzYaCHRFeyVhojxlrm+46y68HA6hr0TcwEssoxNiDEUJQjfPZ/RYA==}
engines: {node: '>=6.0'}
peerDependencies:
supports-color: '*'
peerDependenciesMeta:
supports-color:
optional: true
- dependencies:
- ms: 2.1.2
- dev: false
- /decamelize@1.2.0:
+ decamelize@1.2.0:
resolution: {integrity: sha512-z2S+W9X73hAUUki+N+9Za2lBlun89zigOyGrsax+KUQ6wKW4ZoWpEYBkGhQjwAjjDCkWxhY0VKEhk8wzY7F5cA==}
engines: {node: '>=0.10.0'}
- dev: false
- /delegates@1.0.0:
+ decode-named-character-reference@1.0.2:
+ resolution: {integrity: sha512-O8x12RzrUF8xyVcY0KJowWsmaJxQbmy0/EtnNtHRpsOcT7dFk5W598coHqBVpmWo1oQQfsCqfCmkZN5DJrZVdg==}
+
+ delegates@1.0.0:
resolution: {integrity: sha512-bd2L678uiWATM6m5Z1VzNCErI3jiGzt6HGY8OVICs40JQq/HALfbyNJmp0UDakEY4pMMaN0Ly5om/B1VI/+xfQ==}
- dev: false
- /detect-libc@2.0.3:
+ dequal@2.0.3:
+ resolution: {integrity: sha512-0je+qPKHEMohvfRTCEo3CrPG6cAzAYgmzKyxRiYSSDkS6eGJdyVJm7WaYA5ECaAD9wLB2T4EEeymA5aFVcYXCA==}
+ engines: {node: '>=6'}
+
+ detect-libc@2.0.3:
resolution: {integrity: sha512-bwy0MGW55bG41VqxxypOsdSdGqLwXPI/focwgTYCFMbdUiBAxLg9CFzG08sz2aqzknwiX7Hkl0bQENjg8iLByw==}
engines: {node: '>=8'}
- dev: false
- /dijkstrajs@1.0.3:
+ devlop@1.1.0:
+ resolution: {integrity: sha512-RWmIqhcFf1lRYBvNmr7qTNuyCt/7/ns2jbpp1+PalgE/rDQcBT0fioSMUpJ93irlUhC5hrg4cYqe6U+0ImW0rA==}
+
+ dijkstrajs@1.0.3:
resolution: {integrity: sha512-qiSlmBq9+BCdCA/L46dw8Uy93mloxsPSbwnm5yrKn2vMPiy8KyAskTF6zuV/j5BMsmOGZDPs7KjU+mjb670kfA==}
- dev: false
- /dom-serializer@2.0.0:
+ dom-serializer@2.0.0:
resolution: {integrity: sha512-wIkAryiqt/nV5EQKqQpo3SToSOV9J0DnbJqwK7Wv/Trc92zIAYZ4FlMu+JPFW1DfGFt81ZTCGgDEabffXeLyJg==}
- dependencies:
- domelementtype: 2.3.0
- domhandler: 5.0.3
- entities: 4.5.0
- dev: false
- /domelementtype@2.3.0:
+ domelementtype@2.3.0:
resolution: {integrity: sha512-OLETBj6w0OsagBwdXnPdN0cnMfF9opN69co+7ZrbfPGrdpPVNBUj02spi6B1N7wChLQiPn4CSH/zJvXw56gmHw==}
- dev: false
- /domhandler@5.0.3:
+ domhandler@5.0.3:
resolution: {integrity: sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==}
engines: {node: '>= 4'}
- dependencies:
- domelementtype: 2.3.0
- dev: false
- /domutils@3.1.0:
- resolution: {integrity: sha512-H78uMmQtI2AhgDJjWeQmHwJJ2bLPD3GMmO7Zja/ZZh84wkm+4ut+IUnUdRa8uCGX88DiVx1j6FRe1XfxEgjEZA==}
- dependencies:
- dom-serializer: 2.0.0
- domelementtype: 2.3.0
- domhandler: 5.0.3
- dev: false
+ domutils@3.2.2:
+ resolution: {integrity: sha512-6kZKyUajlDuqlHKVX1w7gyslj9MPIXzIFiz/rGu35uC1wMi+kMhQwGhl4lt9unC9Vb9INnY9Z3/ZA3+FhASLaw==}
- /eastasianwidth@0.2.0:
+ eastasianwidth@0.2.0:
resolution: {integrity: sha512-I88TYZWc9XiYHRQ4/3c5rjjfgkjhLyW2luGIheGERbNQ6OY7yTybanSpDXZa8y7VUP9YmDcYa+eyq4ca7iLqWA==}
- dev: false
- /electron-to-chromium@1.4.722:
- resolution: {integrity: sha512-5nLE0TWFFpZ80Crhtp4pIp8LXCztjYX41yUcV6b+bKR2PqzjskTMOOlBi1VjBHlvHwS+4gar7kNKOrsbsewEZQ==}
- dev: false
+ electron-to-chromium@1.5.80:
+ resolution: {integrity: sha512-LTrKpW0AqIuHwmlVNV+cjFYTnXtM9K37OGhpe0ZI10ScPSxqVSryZHIY3WnCS5NSYbBODRTZyhRMS2h5FAEqAw==}
+
+ emoji-regex-xs@1.0.0:
+ resolution: {integrity: sha512-LRlerrMYoIDrT6jgpeZ2YYl/L8EulRTt5hQcYjy5AInh7HWXKimpqx68aknBFpGL2+/IcogTcaydJEgaTmOpDg==}
- /emoji-regex@10.3.0:
- resolution: {integrity: sha512-QpLs9D9v9kArv4lfDEgg1X/gN5XLnf/A6l9cs8SPZLRZR3ZkY9+kwIQTxm+fsSej5UMYGE8fdoaZVIBlqG0XTw==}
- dev: false
+ emoji-regex@10.4.0:
+ resolution: {integrity: sha512-EC+0oUMY1Rqm4O6LLrgjtYDvcVYTy7chDnM4Q7030tP4Kwj3u/pR6gP9ygnp2CJMK5Gq+9Q2oqmrFJAz01DXjw==}
- /emoji-regex@8.0.0:
+ emoji-regex@8.0.0:
resolution: {integrity: sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==}
- dev: false
- /emoji-regex@9.2.2:
+ emoji-regex@9.2.2:
resolution: {integrity: sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==}
- dev: false
- /encode-utf8@1.0.3:
- resolution: {integrity: sha512-ucAnuBEhUK4boH2HjVYG5Q2mQyPorvv0u/ocS+zhdw0S8AlHYY+GOFhP1Gio5z4icpP2ivFSvhtFjQi8+T9ppw==}
- dev: false
+ encoding-sniffer@0.2.0:
+ resolution: {integrity: sha512-ju7Wq1kg04I3HtiYIOrUrdfdDvkyO9s5XM8QAj/bN61Yo/Vb4vgJxy5vi4Yxk01gWHbrofpPtpxM8bKger9jhg==}
- /encoding@0.1.13:
+ encoding@0.1.13:
resolution: {integrity: sha512-ETBauow1T35Y/WZMkio9jiM0Z5xjHHmJ4XmjZOq1l/dXz3lr2sRn87nJy20RupqSh1F2m3HHPSp8ShIPQJrJ3A==}
- requiresBuild: true
- dependencies:
- iconv-lite: 0.6.3
- dev: false
- optional: true
- /entities@4.5.0:
+ entities@4.5.0:
resolution: {integrity: sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==}
engines: {node: '>=0.12'}
- dev: false
- /env-paths@2.2.1:
+ env-paths@2.2.1:
resolution: {integrity: sha512-+h1lkLKhZMTYjog1VEpJNG7NZJWcuc2DDk/qsqSTRRCOXiLjeQ1d1/udrUGhqMxUgAlwKNZ0cf2uqan5GLuS2A==}
engines: {node: '>=6'}
- dev: false
- /envinfo@7.11.1:
- resolution: {integrity: sha512-8PiZgZNIB4q/Lw4AhOvAfB/ityHAd2bli3lESSWmWSzSsl5dKpy5N1d1Rfkd2teq/g9xN90lc6o98DOjMeYHpg==}
+ envinfo@7.14.0:
+ resolution: {integrity: sha512-CO40UI41xDQzhLB1hWyqUKgFhs250pNcGbyGKe1l/e4FSaI/+YE4IMG76GDt0In67WLPACIITC+sOi08x4wIvg==}
engines: {node: '>=4'}
hasBin: true
- dev: false
- /err-code@2.0.3:
+ err-code@2.0.3:
resolution: {integrity: sha512-2bmlRpNKBxT/CRmPOlyISQpNj+qSeYvcym/uT0Jx2bMOlKLtSy1ZmLuVxSEKKyor/N5yhvp/ZiG1oE3DEYMSFA==}
- dev: false
- /esbuild@0.20.2:
- resolution: {integrity: sha512-WdOOppmUNU+IbZ0PaDiTst80zjnrOkyJNHoKupIcVyU8Lvla3Ugx94VzkQ32Ijqd7UhHJy75gNWDMUekcrSJ6g==}
+ esbuild@0.21.5:
+ resolution: {integrity: sha512-mg3OPMV4hXywwpoDxu3Qda5xCKQi+vCTZq8S9J/EpkhB2HzKXq4SNFZE3+NK93JYxc8VMSep+lOUSC/RVKaBqw==}
engines: {node: '>=12'}
hasBin: true
- requiresBuild: true
- optionalDependencies:
- '@esbuild/aix-ppc64': 0.20.2
- '@esbuild/android-arm': 0.20.2
- '@esbuild/android-arm64': 0.20.2
- '@esbuild/android-x64': 0.20.2
- '@esbuild/darwin-arm64': 0.20.2
- '@esbuild/darwin-x64': 0.20.2
- '@esbuild/freebsd-arm64': 0.20.2
- '@esbuild/freebsd-x64': 0.20.2
- '@esbuild/linux-arm': 0.20.2
- '@esbuild/linux-arm64': 0.20.2
- '@esbuild/linux-ia32': 0.20.2
- '@esbuild/linux-loong64': 0.20.2
- '@esbuild/linux-mips64el': 0.20.2
- '@esbuild/linux-ppc64': 0.20.2
- '@esbuild/linux-riscv64': 0.20.2
- '@esbuild/linux-s390x': 0.20.2
- '@esbuild/linux-x64': 0.20.2
- '@esbuild/netbsd-x64': 0.20.2
- '@esbuild/openbsd-x64': 0.20.2
- '@esbuild/sunos-x64': 0.20.2
- '@esbuild/win32-arm64': 0.20.2
- '@esbuild/win32-ia32': 0.20.2
- '@esbuild/win32-x64': 0.20.2
- dev: false
-
- /escalade@3.1.2:
- resolution: {integrity: sha512-ErCHMCae19vR8vQGe50xIsVomy19rg6gFu3+r3jkEO46suLMWBksvVyoGgQV+jOfl84ZSOSlmv6Gxa89PmTGmA==}
+
+ esbuild@0.24.2:
+ resolution: {integrity: sha512-+9egpBW8I3CD5XPe0n6BfT5fxLzxrlDzqydF3aviG+9ni1lDC/OvMHcxqEFV0+LANZG5R1bFMWfUrjVsdwxJvA==}
+ engines: {node: '>=18'}
+ hasBin: true
+
+ escalade@3.2.0:
+ resolution: {integrity: sha512-WUj2qlxaQtO4g6Pq5c29GTcWGDyd8itL8zTlipgECz3JesAiiOKotd8JU6otB3PACgG6xkJUyVhboMS+bje/jA==}
engines: {node: '>=6'}
- dev: false
- /esm@3.2.25:
+ esm@3.2.25:
resolution: {integrity: sha512-U1suiZ2oDVWv4zPO56S0NcR5QriEahGtdN2OR6FiOG4WJvcjBVFB0qI4+eKoWFH483PKGuLuu6V8Z4T5g63UVA==}
engines: {node: '>=6'}
- dev: false
- /esprima@4.0.1:
+ esprima@4.0.1:
resolution: {integrity: sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A==}
engines: {node: '>=4'}
hasBin: true
- dev: false
- /estree-walker@2.0.2:
+ estree-walker@2.0.2:
resolution: {integrity: sha512-Rfkk/Mp/DL7JVje3u18FxFujQlTNR2q6QfMSMB7AvCBx91NGj/ba3kCfza0f6dVDbw7YlRf/nDrn7pQrCCyQ/w==}
- dev: false
-
- /execa@8.0.1:
- resolution: {integrity: sha512-VyhnebXciFV2DESc+p6B+y0LjSm0krU4OgJN44qFAhBY0TJ+1V61tYD2+wHusZ6F9n5K+vl8k0sTy7PEfV4qpg==}
- engines: {node: '>=16.17'}
- dependencies:
- cross-spawn: 7.0.3
- get-stream: 8.0.1
- human-signals: 5.0.0
- is-stream: 3.0.0
- merge-stream: 2.0.0
- npm-run-path: 5.3.0
- onetime: 6.0.0
- signal-exit: 4.1.0
- strip-final-newline: 3.0.0
- dev: false
- /exponential-backoff@3.1.1:
+ execa@9.5.2:
+ resolution: {integrity: sha512-EHlpxMCpHWSAh1dgS6bVeoLAXGnJNdR93aabr4QCGbzOM73o5XmRfM/e5FUqsw3aagP8S8XEWUWFAxnRBnAF0Q==}
+ engines: {node: ^18.19.0 || >=20.5.0}
+
+ exponential-backoff@3.1.1:
resolution: {integrity: sha512-dX7e/LHVJ6W3DE1MHWi9S1EYzDESENfLrYohG2G++ovZrYOkm4Knwa0mc1cn84xJOR4KEU0WSchhLbd0UklbHw==}
- dev: false
- /extend-shallow@2.0.1:
+ extend-shallow@2.0.1:
resolution: {integrity: sha512-zCnTtlxNoAiDc3gqY2aYAWFx7XWWiasuF2K8Me5WbN8otHKTUKBwjPtNpRs/rbUZm7KxWAaNj7P1a/p52GbVug==}
engines: {node: '>=0.10.0'}
- dependencies:
- is-extendable: 0.1.1
- dev: false
- /fast-glob@3.3.2:
- resolution: {integrity: sha512-oX2ruAFQwf/Orj8m737Y5adxDQO0LAB7/S5MnxCdTNDd4p6BsyIVsv9JQsATbTSq8KHRpLwIHbVlUNatxd+1Ow==}
+ fast-glob@3.3.3:
+ resolution: {integrity: sha512-7MptL8U0cqcFdzIzwOTHoilX9x5BrNqye7Z/LuC7kCMRio1EMSyqRK3BEAUD7sXRq4iT4AzTVuZdhgQ2TCvYLg==}
engines: {node: '>=8.6.0'}
- dependencies:
- '@nodelib/fs.stat': 2.0.5
- '@nodelib/fs.walk': 1.2.8
- glob-parent: 5.1.2
- merge2: 1.4.1
- micromatch: 4.0.5
- dev: false
- /fastq@1.17.1:
- resolution: {integrity: sha512-sRVD3lWVIXWg6By68ZN7vho9a1pQcN/WBFaAAsDDFzlJjvoGx0P8z7V1t72grFJfJhu3YPZBuu25f7Kaw2jN1w==}
- dependencies:
- reusify: 1.0.4
- dev: false
+ fastq@1.18.0:
+ resolution: {integrity: sha512-QKHXPW0hD8g4UET03SdOdunzSouc9N4AuHdsX8XNcTsuz+yYFILVNIX4l9yHABMhiEI9Db0JTTIpu0wB+Y1QQw==}
- /fflate@0.8.2:
+ fflate@0.8.2:
resolution: {integrity: sha512-cPJU47OaAoCbg0pBvzsgpTPhmhqI5eJjh/JIu8tPj5q+T7iLvW/JAYUqmE7KOB4R1ZyEhzBaIQpQpardBF5z8A==}
- dev: false
- /fill-range@7.0.1:
- resolution: {integrity: sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==}
+ figures@6.1.0:
+ resolution: {integrity: sha512-d+l3qxjSesT4V7v2fh+QnmFnUWv9lSpjarhShNTgBOfA0ttejbQUAlHLitbjkoRiDulW0OPoQPYIGhIC8ohejg==}
+ engines: {node: '>=18'}
+
+ fill-range@7.1.1:
+ resolution: {integrity: sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==}
engines: {node: '>=8'}
- dependencies:
- to-regex-range: 5.0.1
- dev: false
- /find-up@4.1.0:
+ find-up@4.1.0:
resolution: {integrity: sha512-PpOwAdQ/YlXQ2vj8a3h8IipDuYRi3wceVQQGYWxNINccq40Anw7BlsEXCMbt1Zt+OLA6Fq9suIpIWD0OsnISlw==}
engines: {node: '>=8'}
- dependencies:
- locate-path: 5.0.0
- path-exists: 4.0.0
- dev: false
- /foreground-child@3.1.1:
- resolution: {integrity: sha512-TMKDUnIte6bfb5nWv7V/caI169OHgvwjb7V4WkeUvbQQdjr5rWKqHFiKWb/fcOwB+CzBT+qbWjvj+DVwRskpIg==}
+ foreground-child@3.3.0:
+ resolution: {integrity: sha512-Ld2g8rrAyMYFXBhEqMz8ZAHBi4J4uS1i/CxGMDnjyFWddMXLVcDp051DZfu+t7+ab7Wv6SMqpWmyFIj5UbfFvg==}
engines: {node: '>=14'}
- dependencies:
- cross-spawn: 7.0.3
- signal-exit: 4.1.0
- dev: false
- /fraction.js@4.3.7:
+ fraction.js@4.3.7:
resolution: {integrity: sha512-ZsDfxO51wGAXREY55a7la9LScWpwv9RxIrYABrlvOFBlH/ShPnrtsXeuUIfXKKOVicNxQ+o8JTbJvjS4M89yew==}
- dev: false
- /fs-extra@11.2.0:
+ fs-extra@11.2.0:
resolution: {integrity: sha512-PmDi3uwK5nFuXh7XDTlVnS17xJS7vW36is2+w3xcv8SVxiB4NyATf4ctkVY5bkSjX0Y4nbvZCq1/EjtEyr9ktw==}
engines: {node: '>=14.14'}
- dependencies:
- graceful-fs: 4.2.11
- jsonfile: 6.1.0
- universalify: 2.0.1
- dev: false
- /fs-minipass@2.1.0:
+ fs-minipass@2.1.0:
resolution: {integrity: sha512-V/JgOLFCS+R6Vcq0slCuaeWEdNC3ouDlJMNIsacH2VtALiu9mV4LPrHc5cDl8k5aw6J8jwgWWpiTo5RYhmIzvg==}
engines: {node: '>= 8'}
- dependencies:
- minipass: 3.3.6
- dev: false
- /fs-minipass@3.0.3:
+ fs-minipass@3.0.3:
resolution: {integrity: sha512-XUBA9XClHbnJWSfBzjkm6RvPsyg3sryZt06BEQoXcF7EK/xpGaQYJgQKDJSUH5SGZ76Y7pFx1QBnXz09rU5Fbw==}
engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
- dependencies:
- minipass: 7.0.4
- dev: false
- /fs.realpath@1.0.0:
+ fs.realpath@1.0.0:
resolution: {integrity: sha512-OO0pH2lK6a0hZnAdau5ItzHPI6pUlvI7jMVnxUQRtw4owF2wk8lOSabtGDCTP4Ggrg2MbGnWO9X8K1t4+fGMDw==}
- dev: false
- /fsevents@2.3.3:
+ fsevents@2.3.3:
resolution: {integrity: sha512-5xoDfX+fL7faATnagmWPpbFtwh/R77WmMMqqHGS65C3vvB0YHrgF+B1YmZ3441tMj5n63k0212XNoJwzlhffQw==}
engines: {node: ^8.16.0 || ^10.6.0 || >=11.0.0}
os: [darwin]
- requiresBuild: true
- dev: false
- optional: true
- /gauge@3.0.2:
+ gauge@3.0.2:
resolution: {integrity: sha512-+5J6MS/5XksCuXq++uFRsnUd7Ovu1XenbeuIuNRJxYWjgQbPuFhT14lAvsWfqfAmnwluf1OwMjz39HjfLPci0Q==}
engines: {node: '>=10'}
- dependencies:
- aproba: 2.0.0
- color-support: 1.1.3
- console-control-strings: 1.1.0
- has-unicode: 2.0.1
- object-assign: 4.1.1
- signal-exit: 3.0.7
- string-width: 4.2.3
- strip-ansi: 6.0.1
- wide-align: 1.1.5
- dev: false
+ deprecated: This package is no longer supported.
- /get-caller-file@2.0.5:
+ get-caller-file@2.0.5:
resolution: {integrity: sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==}
engines: {node: 6.* || 8.* || >= 10.*}
- dev: false
- /get-east-asian-width@1.2.0:
- resolution: {integrity: sha512-2nk+7SIVb14QrgXFHcm84tD4bKQz0RxPuMT8Ag5KPOq7J5fEmAg0UbXdTOSHqNuHSU28k55qnceesxXRZGzKWA==}
+ get-east-asian-width@1.3.0:
+ resolution: {integrity: sha512-vpeMIQKxczTD/0s2CdEWHcb0eeJe6TFjxb+J5xgX7hScxqrGuyjmv4c1D4A/gelKfyox0gJJwIHF+fLjeaM8kQ==}
engines: {node: '>=18'}
- dev: false
- /get-stream@8.0.1:
- resolution: {integrity: sha512-VaUJspBffn/LMCJVoMvSAdmscJyS1auj5Zulnn5UoYcY531UWmdwhRWkcGKnGU93m5HSXP9LP2usOryrBtQowA==}
- engines: {node: '>=16'}
- dev: false
+ get-stream@9.0.1:
+ resolution: {integrity: sha512-kVCxPF3vQM/N0B1PmoqVUqgHP+EeVjmZSQn+1oCRPxd2P21P2F19lIgbR3HBosbB1PUhOAoctJnfEn2GbN2eZA==}
+ engines: {node: '>=18'}
- /giscus@1.5.0:
- resolution: {integrity: sha512-t3LL0qbSO3JXq3uyQeKpF5CegstGfKX/0gI6eDe1cmnI7D56R7j52yLdzw4pdKrg3VnufwCgCM3FDz7G1Qr6lg==}
- dependencies:
- lit: 3.1.2
- dev: false
+ giscus@1.6.0:
+ resolution: {integrity: sha512-Zrsi8r4t1LVW950keaWcsURuZUQwUaMKjvJgTCY125vkW6OiEBkatE7ScJDbpqKHdZwb///7FVC21SE3iFK3PQ==}
- /glob-parent@5.1.2:
+ glob-parent@5.1.2:
resolution: {integrity: sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==}
engines: {node: '>= 6'}
- dependencies:
- is-glob: 4.0.3
- dev: false
- /glob@10.3.12:
- resolution: {integrity: sha512-TCNv8vJ+xz4QiqTpfOJA7HvYv+tNIRHKfUWw/q+v2jdgN4ebz+KY9tGx5J4rHP0o84mNP+ApH66HRX8us3Khqg==}
- engines: {node: '>=16 || 14 >=14.17'}
+ glob@10.4.5:
+ resolution: {integrity: sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==}
hasBin: true
- dependencies:
- foreground-child: 3.1.1
- jackspeak: 2.3.6
- minimatch: 9.0.4
- minipass: 7.0.4
- path-scurry: 1.10.2
- dev: false
- /glob@7.2.3:
+ glob@7.2.3:
resolution: {integrity: sha512-nFR0zLpU2YCaRxwoCJvL6UvCH2JFyFVIvwTLsIf21AuHlMskA1hhTdk+LlYJtOlYt9v6dvszD2BGRqBL+iQK9Q==}
- dependencies:
- fs.realpath: 1.0.0
- inflight: 1.0.6
- inherits: 2.0.4
- minimatch: 3.1.2
- once: 1.4.0
- path-is-absolute: 1.0.1
- dev: false
-
- /globby@14.0.0:
- resolution: {integrity: sha512-/1WM/LNHRAOH9lZta77uGbq0dAEQM+XjNesWwhlERDVenqothRbnzTrL3/LrIoEPPjeUHC3vrS6TwoyxeHs7MQ==}
- engines: {node: '>=18'}
- dependencies:
- '@sindresorhus/merge-streams': 1.0.0
- fast-glob: 3.3.2
- ignore: 5.3.1
- path-type: 5.0.0
- slash: 5.1.0
- unicorn-magic: 0.1.0
- dev: false
+ deprecated: Glob versions prior to v9 are no longer supported
- /globby@14.0.1:
- resolution: {integrity: sha512-jOMLD2Z7MAhyG8aJpNOpmziMOP4rPLcc95oQPKXBazW82z+CEgPFBQvEpRUa1KeIMUJo4Wsm+q6uzO/Q/4BksQ==}
+ globby@14.0.2:
+ resolution: {integrity: sha512-s3Fq41ZVh7vbbe2PN3nrW7yC7U7MFVc5c98/iTl9c2GawNMKx/J648KQRW6WKkuU8GIbbh2IXfIRQjOZnXcTnw==}
engines: {node: '>=18'}
- dependencies:
- '@sindresorhus/merge-streams': 2.3.0
- fast-glob: 3.3.2
- ignore: 5.3.1
- path-type: 5.0.0
- slash: 5.1.0
- unicorn-magic: 0.1.0
- dev: false
- /graceful-fs@4.2.11:
+ graceful-fs@4.2.11:
resolution: {integrity: sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==}
- dev: false
- /gray-matter@4.0.3:
+ gray-matter@4.0.3:
resolution: {integrity: sha512-5v6yZd4JK3eMI3FqqCouswVqwugaA9r4dNZB1wwcmrD02QkV5H0y7XBQW8QwQqEaZY1pM9aqORSORhJRdNK44Q==}
engines: {node: '>=6.0'}
- dependencies:
- js-yaml: 3.14.1
- kind-of: 6.0.3
- section-matter: 1.0.0
- strip-bom-string: 1.0.0
- dev: false
- /has-unicode@2.0.1:
+ has-flag@4.0.0:
+ resolution: {integrity: sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==}
+ engines: {node: '>=8'}
+
+ has-unicode@2.0.1:
resolution: {integrity: sha512-8Rf9Y83NBReMnx0gFzA8JImQACstCYWUplepDa9xprwwtmgEZUF0h/i5xSA625zB/I37EtrswSST6OXxwaaIJQ==}
- dev: false
- /hash-sum@2.0.0:
+ hash-sum@2.0.0:
resolution: {integrity: sha512-WdZTbAByD+pHfl/g9QSsBIIwy8IT+EsPiKDs0KNX+zSHhdDLFKdZu0BQHljvO+0QI/BasbMSUa8wYNCZTvhslg==}
- dev: false
- /htmlparser2@8.0.2:
- resolution: {integrity: sha512-GYdjWKDkbRLkZ5geuHs5NY1puJ+PXwP7+fHPRz06Eirsb9ugf6d8kkXav6ADhcODhFFPMIXyxkxSuMf3D6NCFA==}
- dependencies:
- domelementtype: 2.3.0
- domhandler: 5.0.3
- domutils: 3.1.0
- entities: 4.5.0
- dev: false
+ hast-util-to-html@9.0.4:
+ resolution: {integrity: sha512-wxQzXtdbhiwGAUKrnQJXlOPmHnEehzphwkK7aluUPQ+lEc1xefC8pblMgpp2w5ldBTEfveRIrADcrhGIWrlTDA==}
+
+ hast-util-whitespace@3.0.0:
+ resolution: {integrity: sha512-88JUN06ipLwsnv+dVn+OIYOvAuvBMy/Qoi6O7mQHxdPXpjy+Cd6xRkWwux7DKO+4sYILtLBRIKgsdpS2gQc7qw==}
+
+ hookable@5.5.3:
+ resolution: {integrity: sha512-Yc+BQe8SvoXH1643Qez1zqLRmbA5rCL+sSmk6TVos0LWVfNIB7PGncdlId77WzLGSIB5KaWgTaNTs2lNVEI6VQ==}
+
+ html-void-elements@3.0.0:
+ resolution: {integrity: sha512-bEqo66MRXsUGxWHV5IP0PUiAWwoEjba4VCzg0LjFJBpchPaTfyfCKTG6bc5F8ucKec3q5y6qOdGyYTSBEvhCrg==}
+
+ htmlparser2@9.1.0:
+ resolution: {integrity: sha512-5zfg6mHUoaer/97TxnGpxmbR7zJtPwIYFMZ/H5ucTlPZhKvtum05yiPK3Mgai3a0DyVxv7qYqoweaEd2nrYQzQ==}
- /http-cache-semantics@4.1.1:
+ http-cache-semantics@4.1.1:
resolution: {integrity: sha512-er295DKPVsV82j5kw1Gjt+ADA/XYHsajl82cGNQG2eyoPkvgUhX+nDIyelzhIWbbsXP39EHcI6l5tYs2FYqYXQ==}
- dev: false
- /http-proxy-agent@7.0.2:
+ http-proxy-agent@7.0.2:
resolution: {integrity: sha512-T1gkAiYYDWYx3V5Bmyu7HcfcvL7mUrTWiM6yOfa3PIphViJ/gFPbvidQ+veqSOHci/PxBcDabeUNCzpOODJZig==}
engines: {node: '>= 14'}
- dependencies:
- agent-base: 7.1.1
- debug: 4.3.4
- transitivePeerDependencies:
- - supports-color
- dev: false
- /https-proxy-agent@5.0.1:
+ https-proxy-agent@5.0.1:
resolution: {integrity: sha512-dFcAjpTQFgoLMzC2VwU+C/CbS7uRL0lWmxDITmqm7C+7F0Odmj6s9l6alZc6AELXhrnggM2CeWSXHGOdX2YtwA==}
engines: {node: '>= 6'}
- dependencies:
- agent-base: 6.0.2
- debug: 4.3.4
- transitivePeerDependencies:
- - supports-color
- dev: false
- /https-proxy-agent@7.0.4:
- resolution: {integrity: sha512-wlwpilI7YdjSkWaQ/7omYBMTliDcmCN8OLihO6I9B86g06lMyAoqgoDpV0XqoaPOKj+0DIdAvnsWfyAAhmimcg==}
+ https-proxy-agent@7.0.6:
+ resolution: {integrity: sha512-vK9P5/iUfdl95AI+JVyUuIcVtd4ofvtrOr3HNtM2yxC9bnMbEdp3x01OhQNnjb8IJYi38VlTE3mBXwcfvywuSw==}
engines: {node: '>= 14'}
- dependencies:
- agent-base: 7.1.1
- debug: 4.3.4
- transitivePeerDependencies:
- - supports-color
- dev: false
- /human-signals@5.0.0:
- resolution: {integrity: sha512-AXcZb6vzzrFAUE61HnN4mpLqd/cSIwNQjtNWR0euPm6y0iqx3G4gOXaIDdtdDwZmhwe82LA6+zinmW4UBWVePQ==}
- engines: {node: '>=16.17.0'}
- dev: false
+ human-signals@8.0.0:
+ resolution: {integrity: sha512-/1/GPCpDUCCYwlERiYjxoczfP0zfvZMU/OWgQPMya9AbAE24vseigFdhAMObpc8Q4lc/kjutPfUddDYyAmejnA==}
+ engines: {node: '>=18.18.0'}
- /husky@9.0.10:
- resolution: {integrity: sha512-TQGNknoiy6bURzIO77pPRu+XHi6zI7T93rX+QnJsoYFf3xdjKOur+IlfqzJGMHIK/wXrLg+GsvMs8Op7vI2jVA==}
+ husky@9.1.7:
+ resolution: {integrity: sha512-5gs5ytaNjBrh5Ow3zrvdUUY+0VxIuWVL4i9irt6friV+BqdCfmV11CQTWMiBYWHbXhco+J1kHfTOUkePhCDvMA==}
engines: {node: '>=18'}
hasBin: true
- dev: false
- /iconv-lite@0.6.3:
+ iconv-lite@0.6.3:
resolution: {integrity: sha512-4fCk79wshMdzMp2rH06qWrJE4iolqLhCUH+OiuIgU++RB0+94NlDL81atO7GX55uUKueo0txHNtvEyI6D7WdMw==}
engines: {node: '>=0.10.0'}
- requiresBuild: true
- dependencies:
- safer-buffer: 2.1.2
- dev: false
- optional: true
- /ignore@5.3.1:
- resolution: {integrity: sha512-5Fytz/IraMjqpwfd34ke28PTVMjZjJG2MPn5t7OE4eUCUNf8BAa7b5WUS9/Qvr6mwOQS7Mk6vdsMno5he+T8Xw==}
+ ignore@5.3.2:
+ resolution: {integrity: sha512-hsBTNUqQTDwkWtcdYI2i06Y/nUBEsNEDJKjWdigLvegy8kDuJAS8uRlpkkcQpyEXL0Z/pjDy5HBmMjRCJ2gq+g==}
engines: {node: '>= 4'}
- dev: false
- /immutable@4.3.5:
- resolution: {integrity: sha512-8eabxkth9gZatlwl5TBuJnCsoTADlL6ftEr7A4qgdaTsPyreilDSnUk57SO+jfKcNtxPa22U5KK6DSeAYhpBJw==}
- dev: false
+ immutable@5.0.3:
+ resolution: {integrity: sha512-P8IdPQHq3lA1xVeBRi5VPqUm5HDgKnx0Ru51wZz5mjxHr5n3RWhjIpOFU7ybkUxfB+5IToy+OLaHYDBIWsv+uw==}
- /imurmurhash@0.1.4:
+ imurmurhash@0.1.4:
resolution: {integrity: sha512-JmXMZ6wuvDmLiHEml9ykzqO6lwFbof0GG4IkcGaENdCRDDmMVnny7s5HsIgHCbaq0w2MyPhDqkhTUgS2LU2PHA==}
engines: {node: '>=0.8.19'}
- dev: false
- /indent-string@4.0.0:
+ indent-string@4.0.0:
resolution: {integrity: sha512-EdDDZu4A2OyIK7Lr/2zG+w5jmbuk1DVBnEwREQvBzspBJkCEbRa8GxU1lghYcaGJCnRWibjDXlq779X1/y5xwg==}
engines: {node: '>=8'}
- dev: false
- /inflight@1.0.6:
+ inflight@1.0.6:
resolution: {integrity: sha512-k92I/b08q4wvFscXCLvqfsHCrjrF7yiXsQuIVvVE7N82W3+aqpzuUdBbfhWcy/FZR3/4IgflMgKLOsvPDrGCJA==}
- dependencies:
- once: 1.4.0
- wrappy: 1.0.2
- dev: false
+ deprecated: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
- /inherits@2.0.4:
+ inherits@2.0.4:
resolution: {integrity: sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==}
- dev: false
- /ip-address@9.0.5:
+ ip-address@9.0.5:
resolution: {integrity: sha512-zHtQzGojZXTwZTHQqra+ETKd4Sn3vgi7uBmlPoXVWZqYvuKmtI0l/VZTjqGmJY9x88GGOaZ9+G9ES8hC4T4X8g==}
engines: {node: '>= 12'}
- dependencies:
- jsbn: 1.1.0
- sprintf-js: 1.1.3
- dev: false
- /is-binary-path@2.1.0:
+ is-alphabetical@2.0.1:
+ resolution: {integrity: sha512-FWyyY60MeTNyeSRpkM2Iry0G9hpr7/9kD40mD/cGQEuilcZYS4okz8SN2Q6rLCJ8gbCt6fN+rC+6tMGS99LaxQ==}
+
+ is-alphanumerical@2.0.1:
+ resolution: {integrity: sha512-hmbYhX/9MUMF5uh7tOXyK/n0ZvWpad5caBA17GsC6vyuCqaWliRG5K1qS9inmUhEMaOBIW7/whAnSwveW/LtZw==}
+
+ is-binary-path@2.1.0:
resolution: {integrity: sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==}
engines: {node: '>=8'}
- dependencies:
- binary-extensions: 2.3.0
- dev: false
- /is-extendable@0.1.1:
+ is-decimal@2.0.1:
+ resolution: {integrity: sha512-AAB9hiomQs5DXWcRB1rqsxGUstbRroFOPPVAomNk/3XHR5JyEZChOyTWe2oayKnsSsr/kcGqF+z6yuH6HHpN0A==}
+
+ is-extendable@0.1.1:
resolution: {integrity: sha512-5BMULNob1vgFX6EjQw5izWDxrecWK9AM72rugNr0TFldMOi0fj6Jk+zeKIt0xGj4cEfQIJth4w3OKWOJ4f+AFw==}
engines: {node: '>=0.10.0'}
- dev: false
- /is-extglob@2.1.1:
+ is-extglob@2.1.1:
resolution: {integrity: sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ==}
engines: {node: '>=0.10.0'}
- dev: false
- /is-fullwidth-code-point@3.0.0:
+ is-fullwidth-code-point@3.0.0:
resolution: {integrity: sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==}
engines: {node: '>=8'}
- dev: false
- /is-glob@4.0.3:
+ is-glob@4.0.3:
resolution: {integrity: sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==}
engines: {node: '>=0.10.0'}
- dependencies:
- is-extglob: 2.1.1
- dev: false
- /is-interactive@2.0.0:
+ is-hexadecimal@2.0.1:
+ resolution: {integrity: sha512-DgZQp241c8oO6cA1SbTEWiXeoxV42vlcJxgH+B3hi1AiqqKruZR3ZGF8In3fj4+/y/7rHvlOZLZtgJ/4ttYGZg==}
+
+ is-interactive@2.0.0:
resolution: {integrity: sha512-qP1vozQRI+BMOPcjFzrjXuQvdak2pHNUMZoeG2eRbiSqyvbEf/wQtEOTOX1guk6E3t36RkaqiSt8A/6YElNxLQ==}
engines: {node: '>=12'}
- dev: false
- /is-lambda@1.0.1:
+ is-lambda@1.0.1:
resolution: {integrity: sha512-z7CMFGNrENq5iFB9Bqo64Xk6Y9sg+epq1myIcdHaGnbMTYOxvzsEtdYqQUylB7LxfkvgrrjP32T6Ywciio9UIQ==}
- dev: false
- /is-number@7.0.0:
+ is-number@7.0.0:
resolution: {integrity: sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==}
engines: {node: '>=0.12.0'}
- dev: false
- /is-stream@3.0.0:
- resolution: {integrity: sha512-LnQR4bZ9IADDRSkvpqMGvt/tEJWclzklNgSw48V5EAaAeDd6qGvN8ei6k5p0tvxSR171VmGyHuTiAOfxAbr8kA==}
- engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0}
- dev: false
+ is-plain-obj@4.1.0:
+ resolution: {integrity: sha512-+Pgi+vMuUNkJyExiMBt5IlFoMyKnr5zhJ4Uspz58WOhBF5QoIZkFyNHIbBAtHwzVAgk5RtndVNsDRN61/mmDqg==}
+ engines: {node: '>=12'}
+
+ is-stream@4.0.1:
+ resolution: {integrity: sha512-Dnz92NInDqYckGEUJv689RbRiTSEHCQ7wOVeALbkOz999YpqT46yMRIGtSNl2iCL1waAZSx40+h59NV/EwzV/A==}
+ engines: {node: '>=18'}
- /is-unicode-supported@1.3.0:
+ is-unicode-supported@1.3.0:
resolution: {integrity: sha512-43r2mRvz+8JRIKnWJ+3j8JtjRKZ6GmjzfaE/qiBJnikNnYv/6bagRJ1kUhNk8R5EX/GkobD+r+sfxCPJsiKBLQ==}
engines: {node: '>=12'}
- dev: false
- /is-unicode-supported@2.0.0:
- resolution: {integrity: sha512-FRdAyx5lusK1iHG0TWpVtk9+1i+GjrzRffhDg4ovQ7mcidMQ6mj+MhKPmvh7Xwyv5gIS06ns49CA7Sqg7lC22Q==}
+ is-unicode-supported@2.1.0:
+ resolution: {integrity: sha512-mE00Gnza5EEB3Ds0HfMyllZzbBrmLOX3vfWoj9A9PEnTfratQ/BcaJOuMhnkhjXvb2+FkY3VuHqtAGpTPmglFQ==}
engines: {node: '>=18'}
- dev: false
- /isexe@2.0.0:
+ is-what@4.1.16:
+ resolution: {integrity: sha512-ZhMwEosbFJkA0YhFnNDgTM4ZxDRsS6HqTo7qsZM08fehyRYIYa0yHu5R6mgo1n/8MgaPBXiPimPD77baVFYg+A==}
+ engines: {node: '>=12.13'}
+
+ isexe@2.0.0:
resolution: {integrity: sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw==}
- dev: false
- /isexe@3.1.1:
+ isexe@3.1.1:
resolution: {integrity: sha512-LpB/54B+/2J5hqQ7imZHfdU31OlgQqx7ZicVlkm9kzg9/w8GKLEcFfJl/t7DCEDueOyBAD6zCCwTO6Fzs0NoEQ==}
engines: {node: '>=16'}
- dev: false
- /jackspeak@2.3.6:
- resolution: {integrity: sha512-N3yCS/NegsOBokc8GAdM8UcmfsKiSS8cipheD/nivzr700H+nsMOxJjQnvwOcRYVuFkdH0wGUvW2WbXGmrZGbQ==}
- engines: {node: '>=14'}
- dependencies:
- '@isaacs/cliui': 8.0.2
- optionalDependencies:
- '@pkgjs/parseargs': 0.11.0
- dev: false
+ jackspeak@3.4.3:
+ resolution: {integrity: sha512-OGlZQpz2yfahA/Rd1Y8Cd9SIEsqvXkLVoSw/cgwhnhFMDbsQFeZYoJJ7bIZBS9BcamUW96asq/npPWugM+RQBw==}
- /js-yaml@3.14.1:
+ js-yaml@3.14.1:
resolution: {integrity: sha512-okMH7OXXJ7YrN9Ok3/SXrnu4iX9yOk+25nqX4imS2npuvTYDmo/QEZoqwZkYaIDk3jVvBOTOIEgEhaLOynBS9g==}
hasBin: true
- dependencies:
- argparse: 1.0.10
- esprima: 4.0.1
- dev: false
- /js-yaml@4.1.0:
+ js-yaml@4.1.0:
resolution: {integrity: sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==}
hasBin: true
- dependencies:
- argparse: 2.0.1
- dev: false
- /jsbn@1.1.0:
+ jsbn@1.1.0:
resolution: {integrity: sha512-4bYVV3aAMtDTTu4+xsDYa6sy9GyJ69/amsu9sYF2zqjiEoZA5xJi3BrfX3uY+/IekIu7MwdObdbDWpoZdBv3/A==}
- dev: false
- /jsonc-parser@3.2.0:
- resolution: {integrity: sha512-gfFQZrcTc8CnKXp6Y4/CBT3fTc0OVuDofpre4aEeEpSBPV5X5v4+Vmx+8snU7RLPrNHPKSgLxGo9YuQzz20o+w==}
- dev: false
+ jsonc-parser@3.3.1:
+ resolution: {integrity: sha512-HUgH65KyejrUFPvHFPbqOY0rsFip3Bo5wb4ngvdi1EpCYWUQDC5V+Y7mZws+DLkr4M//zQJoanu1SP+87Dv1oQ==}
- /jsonfile@6.1.0:
+ jsonfile@6.1.0:
resolution: {integrity: sha512-5dgndWOriYSm5cnYaJNhalLNDKOqFwyDB/rr1E9ZsGciGvKPs8R2xYGCacuf3z6K1YKDz182fd+fY3cn3pMqXQ==}
- dependencies:
- universalify: 2.0.1
- optionalDependencies:
- graceful-fs: 4.2.11
- dev: false
- /kind-of@6.0.3:
+ katex@0.16.20:
+ resolution: {integrity: sha512-jjuLaMGD/7P8jUTpdKhA9IoqnH+yMFB3sdAFtq5QdAqeP2PjiSbnC3EaguKPNtv6dXXanHxp1ckwvF4a86LBig==}
+ hasBin: true
+
+ kind-of@6.0.3:
resolution: {integrity: sha512-dcS1ul+9tmeD95T+x28/ehLgd9mENa3LsvDTtzm3vyBEO7RPptvAD+t44WVXaUjTBRcrpFeFlC8WCruUR456hw==}
engines: {node: '>=0.10.0'}
- dev: false
- /lilconfig@3.1.1:
- resolution: {integrity: sha512-O18pf7nyvHTckunPWCV1XUNXU1piu01y2b7ATJ0ppkUkk8ocqVWBrYjJBCwHDjD/ZWcfyrA0P4gKhzWGi5EINQ==}
+ lilconfig@3.1.3:
+ resolution: {integrity: sha512-/vlFKAoH5Cgt3Ie+JLhRbwOsCQePABiU3tJ1egGvyQ+33R/vcwM2Zl2QR/LzjsBeItPt3oSVXapn+m4nQDvpzw==}
engines: {node: '>=14'}
- dev: false
- /linkify-it@5.0.0:
+ linkify-it@5.0.0:
resolution: {integrity: sha512-5aHCbzQRADcdP+ATqnDuhhJ/MRIqDkZX5pyjFHRRysS8vZ5AbqGEoFIb6pYHPZ+L/OC2Lc+xT8uHVVR5CAK/wQ==}
- dependencies:
- uc.micro: 2.1.0
- dev: false
- /lit-element@4.0.4:
- resolution: {integrity: sha512-98CvgulX6eCPs6TyAIQoJZBCQPo80rgXR+dVBs61cstJXqtI+USQZAbA4gFHh6L/mxBx9MrgPLHLsUgDUHAcCQ==}
- dependencies:
- '@lit-labs/ssr-dom-shim': 1.2.0
- '@lit/reactive-element': 2.0.4
- lit-html: 3.1.2
- dev: false
+ lit-element@4.1.1:
+ resolution: {integrity: sha512-HO9Tkkh34QkTeUmEdNYhMT8hzLid7YlMlATSi1q4q17HE5d9mrrEHJ/o8O2D0cMi182zK1F3v7x0PWFjrhXFew==}
- /lit-html@3.1.2:
- resolution: {integrity: sha512-3OBZSUrPnAHoKJ9AMjRL/m01YJxQMf+TMHanNtTHG68ubjnZxK0RFl102DPzsw4mWnHibfZIBJm3LWCZ/LmMvg==}
- dependencies:
- '@types/trusted-types': 2.0.7
- dev: false
+ lit-html@3.2.1:
+ resolution: {integrity: sha512-qI/3lziaPMSKsrwlxH/xMgikhQ0EGOX2ICU73Bi/YHFvz2j/yMCIrw4+puF2IpQ4+upd3EWbvnHM9+PnJn48YA==}
- /lit@3.1.2:
- resolution: {integrity: sha512-VZx5iAyMtX7CV4K8iTLdCkMaYZ7ipjJZ0JcSdJ0zIdGxxyurjIn7yuuSxNBD7QmjvcNJwr0JS4cAdAtsy7gZ6w==}
- dependencies:
- '@lit/reactive-element': 2.0.4
- lit-element: 4.0.4
- lit-html: 3.1.2
- dev: false
+ lit@3.2.1:
+ resolution: {integrity: sha512-1BBa1E/z0O9ye5fZprPtdqnc0BFzxIxTTOO/tQFmyC/hj1O3jL4TfmLBw0WEwjAokdLwpclkvGgDJwTIh0/22w==}
- /locate-path@5.0.0:
+ locate-path@5.0.0:
resolution: {integrity: sha512-t7hw9pI+WvuwNJXwk5zVHpyhIqzg2qTlklJOf0mVxGSbe3Fp2VieZcduNYjaLDoy6p9uGpQEGWG87WpMKlNq8g==}
engines: {node: '>=8'}
- dependencies:
- p-locate: 4.1.0
- dev: false
- /log-symbols@6.0.0:
+ log-symbols@6.0.0:
resolution: {integrity: sha512-i24m8rpwhmPIS4zscNzK6MSEhk0DUWa/8iYQWxhffV8jkI4Phvs3F+quL5xvS0gdQR0FyTCMMH33Y78dDTzzIw==}
engines: {node: '>=18'}
- dependencies:
- chalk: 5.3.0
- is-unicode-supported: 1.3.0
- dev: false
- /lru-cache@10.2.0:
- resolution: {integrity: sha512-2bIM8x+VAf6JT4bKAljS1qUWgMsqZRPGJS6FSahIMPVvctcNhyVp7AJu7quxOW9jwkryBReKZY5tY5JYv2n/7Q==}
- engines: {node: 14 || >=16.14}
- dev: false
-
- /lru-cache@6.0.0:
- resolution: {integrity: sha512-Jo6dJ04CmSjuznwJSS3pUeWmd/H0ffTlkXXgwZi+eq1UCmqQwCh+eLsYOYCwY991i2Fah4h1BEMCx4qThGbsiA==}
- engines: {node: '>=10'}
- dependencies:
- yallist: 4.0.0
- dev: false
+ lru-cache@10.4.3:
+ resolution: {integrity: sha512-JNAzZcXrCt42VGLuYz0zfAzDfAvJWW6AfYlDBQyDV5DClI2m5sAmK+OIO7s59XfsRsWHp02jAJrRadPRGTt6SQ==}
- /magic-string@0.30.8:
- resolution: {integrity: sha512-ISQTe55T2ao7XtlAStud6qwYPZjE4GK1S/BeVPus4jrq6JuOnQ00YKQC581RWhR122W7msZV263KzVeLoqidyQ==}
- engines: {node: '>=12'}
- dependencies:
- '@jridgewell/sourcemap-codec': 1.4.15
- dev: false
+ magic-string@0.30.17:
+ resolution: {integrity: sha512-sNPKHvyjVf7gyjwS4xGTaW/mCnF8wnjtifKBEhxfZ7E/S8tQ0rssrwGNn6q8JH/ohItJfSQp9mBtQYuTlH5QnA==}
- /make-dir@3.1.0:
+ make-dir@3.1.0:
resolution: {integrity: sha512-g3FeP20LNwhALb/6Cz6Dd4F2ngze0jz7tbzrD2wAV+o9FeNHe4rL+yK2md0J/fiSf1sa1ADhXqi5+oVwOM/eGw==}
engines: {node: '>=8'}
- dependencies:
- semver: 6.3.1
- dev: false
- /make-fetch-happen@13.0.0:
- resolution: {integrity: sha512-7ThobcL8brtGo9CavByQrQi+23aIfgYU++wg4B87AIS8Rb2ZBt/MEaDqzA00Xwv/jUjAjYkLHjVolYuTLKda2A==}
+ make-fetch-happen@13.0.1:
+ resolution: {integrity: sha512-cKTUFc/rbKUd/9meOvgrpJ2WrNzymt6jfRDdwg5UCnVzv9dTpEj9JS5m3wtziXVCjluIXyL8pcaukYqezIzZQA==}
engines: {node: ^16.14.0 || >=18.0.0}
- dependencies:
- '@npmcli/agent': 2.2.1
- cacache: 18.0.2
- http-cache-semantics: 4.1.1
- is-lambda: 1.0.1
- minipass: 7.0.4
- minipass-fetch: 3.0.4
- minipass-flush: 1.0.5
- minipass-pipeline: 1.2.4
- negotiator: 0.6.3
- promise-retry: 2.0.1
- ssri: 10.0.5
- transitivePeerDependencies:
- - supports-color
- dev: false
- /markdown-it-anchor@8.6.7(@types/markdown-it@13.0.7)(markdown-it@14.1.0):
- resolution: {integrity: sha512-FlCHFwNnutLgVTflOYHPW2pPcl2AACqVzExlkGQNsi4CJgqOHN7YTgDd4LuhgN1BFO3TS0vLAruV1Td6dwWPJA==}
+ markdown-it-anchor@9.2.0:
+ resolution: {integrity: sha512-sa2ErMQ6kKOA4l31gLGYliFQrMKkqSO0ZJgGhDHKijPf0pNFM9vghjAh3gn26pS4JDRs7Iwa9S36gxm3vgZTzg==}
peerDependencies:
'@types/markdown-it': '*'
markdown-it: '*'
- dependencies:
- '@types/markdown-it': 13.0.7
- markdown-it: 14.1.0
- dev: false
- /markdown-it-emoji@3.0.0:
+ markdown-it-emoji@3.0.0:
resolution: {integrity: sha512-+rUD93bXHubA4arpEZO3q80so0qgoFJEKRkRbjKX8RTdca89v2kfyF+xR3i2sQTwql9tpPZPOQN5B+PunspXRg==}
- dev: false
-
- /markdown-it@14.0.0:
- resolution: {integrity: sha512-seFjF0FIcPt4P9U39Bq1JYblX0KZCjDLFFQPHpL5AzHpqPEKtosxmdq/LTVZnjfH7tjt9BxStm+wXcDBNuYmzw==}
- hasBin: true
- dependencies:
- argparse: 2.0.1
- entities: 4.5.0
- linkify-it: 5.0.0
- mdurl: 2.0.0
- punycode.js: 2.3.1
- uc.micro: 2.1.0
- dev: false
- /markdown-it@14.1.0:
+ markdown-it@14.1.0:
resolution: {integrity: sha512-a54IwgWPaeBCAAsv13YgmALOF1elABB08FxO9i+r4VFk5Vl4pKokRPeX8u5TCgSsPi6ec1otfLjdOpVcgbpshg==}
hasBin: true
- dependencies:
- argparse: 2.0.1
- entities: 4.5.0
- linkify-it: 5.0.0
- mdurl: 2.0.0
- punycode.js: 2.3.1
- uc.micro: 2.1.0
- dev: false
- /markdownlint-cli2-formatter-default@0.0.4(markdownlint-cli2@0.12.1):
- resolution: {integrity: sha512-xm2rM0E+sWgjpPn1EesPXx5hIyrN2ddUnUwnbCsD/ONxYtw3PX6LydvdH6dciWAoFDpwzbHM1TO7uHfcMd6IYg==}
+ markdownlint-cli2-formatter-default@0.0.5:
+ resolution: {integrity: sha512-4XKTwQ5m1+Txo2kuQ3Jgpo/KmnG+X90dWt4acufg6HVGadTUG5hzHF/wssp9b5MBYOMCnZ9RMPaU//uHsszF8Q==}
peerDependencies:
markdownlint-cli2: '>=0.0.4'
- dependencies:
- markdownlint-cli2: 0.12.1
- dev: false
- /markdownlint-cli2@0.12.1:
- resolution: {integrity: sha512-RcK+l5FjJEyrU3REhrThiEUXNK89dLYNJCYbvOUKypxqIGfkcgpz8g08EKqhrmUbYfYoLC5nEYQy53NhJSEtfQ==}
+ markdownlint-cli2@0.17.1:
+ resolution: {integrity: sha512-n1Im9lhKJJE12/u2N0GWBwPqeb0HGdylN8XpSFg9hbj35+QalY9Vi6mxwUQdG6wlSrrIq9ZDQ0Q85AQG9V2WOg==}
engines: {node: '>=18'}
hasBin: true
- dependencies:
- globby: 14.0.0
- jsonc-parser: 3.2.0
- markdownlint: 0.33.0
- markdownlint-cli2-formatter-default: 0.0.4(markdownlint-cli2@0.12.1)
- micromatch: 4.0.5
- yaml: 2.3.4
- dev: false
- /markdownlint-micromark@0.1.8:
- resolution: {integrity: sha512-1ouYkMRo9/6gou9gObuMDnvZM8jC/ly3QCFQyoSPCS2XV1ZClU0xpKbL1Ar3bWWRT1RnBZkWUEiNKrI2CwiBQA==}
- engines: {node: '>=16'}
- dev: false
-
- /markdownlint@0.33.0:
- resolution: {integrity: sha512-4lbtT14A3m0LPX1WS/3d1m7Blg+ZwiLq36WvjQqFGsX3Gik99NV+VXp/PW3n+Q62xyPdbvGOCfjPqjW+/SKMig==}
+ markdownlint@0.37.3:
+ resolution: {integrity: sha512-eoQqH0291YCCjd+Pe1PUQ9AmWthlVmS0XWgcionkZ8q34ceZyRI+pYvsWksXJJL8OBkWCPwp1h/pnXxrPFC4oA==}
engines: {node: '>=18'}
- dependencies:
- markdown-it: 14.0.0
- markdownlint-micromark: 0.1.8
- dev: false
- /mathjax-full@3.2.2:
+ mathjax-full@3.2.2:
resolution: {integrity: sha512-+LfG9Fik+OuI8SLwsiR02IVdjcnRCy5MufYLi0C3TdMT56L/pjB0alMVGgoWJF8pN9Rc7FESycZB9BMNWIid5w==}
- dependencies:
- esm: 3.2.25
- mhchemparser: 4.2.1
- mj-context-menu: 0.6.1
- speech-rule-engine: 4.0.7
- dev: false
- /mdurl@2.0.0:
- resolution: {integrity: sha512-Lf+9+2r+Tdp5wXDXC4PcIBjTDtq4UKjCPMQhKIuzpJNW0b96kVqSwW0bT7FhRSfmAiFYgP+SCRvdrDozfh0U5w==}
- dev: false
+ mdast-util-to-hast@13.2.0:
+ resolution: {integrity: sha512-QGYKEuUsYT9ykKBCMOEDLsU5JRObWQusAolFMeko/tYPufNkRffBAQjIE+99jbA87xv6FgmjLtwjh9wBWajwAA==}
- /merge-stream@2.0.0:
- resolution: {integrity: sha512-abv/qOcuPfk3URPfDzmZU1LKmuw8kT+0nIHvKrKgFrwifol/doWcdA4ZqsWQ8ENrFKkd67Mfpo/LovbIUsbt3w==}
- dev: false
+ mdurl@2.0.0:
+ resolution: {integrity: sha512-Lf+9+2r+Tdp5wXDXC4PcIBjTDtq4UKjCPMQhKIuzpJNW0b96kVqSwW0bT7FhRSfmAiFYgP+SCRvdrDozfh0U5w==}
- /merge2@1.4.1:
+ merge2@1.4.1:
resolution: {integrity: sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==}
engines: {node: '>= 8'}
- dev: false
- /mhchemparser@4.2.1:
+ mhchemparser@4.2.1:
resolution: {integrity: sha512-kYmyrCirqJf3zZ9t/0wGgRZ4/ZJw//VwaRVGA75C4nhE60vtnIzhl9J9ndkX/h6hxSN7pjg/cE0VxbnNM+bnDQ==}
- dev: false
- /micromatch@4.0.5:
- resolution: {integrity: sha512-DMy+ERcEW2q8Z2Po+WNXuw3c5YaUSFjAO5GsJqfEl7UjvtIuFKO6ZrKvcItdy98dwFI2N1tg3zNIdKaQT+aNdA==}
- engines: {node: '>=8.6'}
- dependencies:
- braces: 3.0.2
- picomatch: 2.3.1
- dev: false
+ micromark-core-commonmark@2.0.2:
+ resolution: {integrity: sha512-FKjQKbxd1cibWMM1P9N+H8TwlgGgSkWZMmfuVucLCHaYqeSvJ0hFeHsIa65pA2nYbes0f8LDHPMrd9X7Ujxg9w==}
- /mimic-fn@2.1.0:
- resolution: {integrity: sha512-OqbOk5oEQeAZ8WXWydlu9HJjz9WVdEIvamMCcXmuqUYjTknH/sqsWvhQ3vgwKFRR1HpjvNBKQ37nbJgYzGqGcg==}
- engines: {node: '>=6'}
- dev: false
+ micromark-extension-directive@3.0.2:
+ resolution: {integrity: sha512-wjcXHgk+PPdmvR58Le9d7zQYWy+vKEU9Se44p2CrCDPiLr2FMyiT4Fyb5UFKFC66wGB3kPlgD7q3TnoqPS7SZA==}
- /mimic-fn@4.0.0:
- resolution: {integrity: sha512-vqiC06CuhBTUdZH+RYl8sFrL096vA45Ok5ISO6sE/Mr1jRbGH4Csnhi8f3wKVl7x8mO4Au7Ir9D3Oyv1VYMFJw==}
- engines: {node: '>=12'}
- dev: false
+ micromark-extension-gfm-autolink-literal@2.1.0:
+ resolution: {integrity: sha512-oOg7knzhicgQ3t4QCjCWgTmfNhvQbDDnJeVu9v81r7NltNCVmhPy1fJRX27pISafdjL+SVc4d3l48Gb6pbRypw==}
+
+ micromark-extension-gfm-footnote@2.1.0:
+ resolution: {integrity: sha512-/yPhxI1ntnDNsiHtzLKYnE3vf9JZ6cAisqVDauhp4CEHxlb4uoOTxOCJ+9s51bIB8U1N1FJ1RXOKTIlD5B/gqw==}
+
+ micromark-extension-gfm-table@2.1.0:
+ resolution: {integrity: sha512-Ub2ncQv+fwD70/l4ou27b4YzfNaCJOvyX4HxXU15m7mpYY+rjuWzsLIPZHJL253Z643RpbcP1oeIJlQ/SKW67g==}
+
+ micromark-extension-math@3.1.0:
+ resolution: {integrity: sha512-lvEqd+fHjATVs+2v/8kg9i5Q0AP2k85H0WUOwpIVvUML8BapsMvh1XAogmQjOCsLpoKRCVQqEkQBB3NhVBcsOg==}
+
+ micromark-factory-destination@2.0.1:
+ resolution: {integrity: sha512-Xe6rDdJlkmbFRExpTOmRj9N3MaWmbAgdpSrBQvCFqhezUn4AHqJHbaEnfbVYYiexVSs//tqOdY/DxhjdCiJnIA==}
+
+ micromark-factory-label@2.0.1:
+ resolution: {integrity: sha512-VFMekyQExqIW7xIChcXn4ok29YE3rnuyveW3wZQWWqF4Nv9Wk5rgJ99KzPvHjkmPXF93FXIbBp6YdW3t71/7Vg==}
+
+ micromark-factory-space@2.0.1:
+ resolution: {integrity: sha512-zRkxjtBxxLd2Sc0d+fbnEunsTj46SWXgXciZmHq0kDYGnck/ZSGj9/wULTV95uoeYiK5hRXP2mJ98Uo4cq/LQg==}
+
+ micromark-factory-title@2.0.1:
+ resolution: {integrity: sha512-5bZ+3CjhAd9eChYTHsjy6TGxpOFSKgKKJPJxr293jTbfry2KDoWkhBb6TcPVB4NmzaPhMs1Frm9AZH7OD4Cjzw==}
+
+ micromark-factory-whitespace@2.0.1:
+ resolution: {integrity: sha512-Ob0nuZ3PKt/n0hORHyvoD9uZhr+Za8sFoP+OnMcnWK5lngSzALgQYKMr9RJVOWLqQYuyn6ulqGWSXdwf6F80lQ==}
+
+ micromark-util-character@2.1.1:
+ resolution: {integrity: sha512-wv8tdUTJ3thSFFFJKtpYKOYiGP2+v96Hvk4Tu8KpCAsTMs6yi+nVmGh1syvSCsaxz45J6Jbw+9DD6g97+NV67Q==}
+
+ micromark-util-chunked@2.0.1:
+ resolution: {integrity: sha512-QUNFEOPELfmvv+4xiNg2sRYeS/P84pTW0TCgP5zc9FpXetHY0ab7SxKyAQCNCc1eK0459uoLI1y5oO5Vc1dbhA==}
+
+ micromark-util-classify-character@2.0.1:
+ resolution: {integrity: sha512-K0kHzM6afW/MbeWYWLjoHQv1sgg2Q9EccHEDzSkxiP/EaagNzCm7T/WMKZ3rjMbvIpvBiZgwR3dKMygtA4mG1Q==}
+
+ micromark-util-combine-extensions@2.0.1:
+ resolution: {integrity: sha512-OnAnH8Ujmy59JcyZw8JSbK9cGpdVY44NKgSM7E9Eh7DiLS2E9RNQf0dONaGDzEG9yjEl5hcqeIsj4hfRkLH/Bg==}
+
+ micromark-util-decode-numeric-character-reference@2.0.2:
+ resolution: {integrity: sha512-ccUbYk6CwVdkmCQMyr64dXz42EfHGkPQlBj5p7YVGzq8I7CtjXZJrubAYezf7Rp+bjPseiROqe7G6foFd+lEuw==}
+
+ micromark-util-encode@2.0.1:
+ resolution: {integrity: sha512-c3cVx2y4KqUnwopcO9b/SCdo2O67LwJJ/UyqGfbigahfegL9myoEFoDYZgkT7f36T0bLrM9hZTAaAyH+PCAXjw==}
+
+ micromark-util-html-tag-name@2.0.1:
+ resolution: {integrity: sha512-2cNEiYDhCWKI+Gs9T0Tiysk136SnR13hhO8yW6BGNyhOC4qYFnwF1nKfD3HFAIXA5c45RrIG1ub11GiXeYd1xA==}
+
+ micromark-util-normalize-identifier@2.0.1:
+ resolution: {integrity: sha512-sxPqmo70LyARJs0w2UclACPUUEqltCkJ6PhKdMIDuJ3gSf/Q+/GIe3WKl0Ijb/GyH9lOpUkRAO2wp0GVkLvS9Q==}
+
+ micromark-util-resolve-all@2.0.1:
+ resolution: {integrity: sha512-VdQyxFWFT2/FGJgwQnJYbe1jjQoNTS4RjglmSjTUlpUMa95Htx9NHeYW4rGDJzbjvCsl9eLjMQwGeElsqmzcHg==}
+
+ micromark-util-sanitize-uri@2.0.1:
+ resolution: {integrity: sha512-9N9IomZ/YuGGZZmQec1MbgxtlgougxTodVwDzzEouPKo3qFWvymFHWcnDi2vzV1ff6kas9ucW+o3yzJK9YB1AQ==}
+
+ micromark-util-subtokenize@2.0.3:
+ resolution: {integrity: sha512-VXJJuNxYWSoYL6AJ6OQECCFGhIU2GGHMw8tahogePBrjkG8aCCas3ibkp7RnVOSTClg2is05/R7maAhF1XyQMg==}
+
+ micromark-util-symbol@2.0.1:
+ resolution: {integrity: sha512-vs5t8Apaud9N28kgCrRUdEed4UJ+wWNvicHLPxCa9ENlYuAY31M0ETy5y1vA33YoNPDFTghEbnh6efaE8h4x0Q==}
+
+ micromark-util-types@2.0.1:
+ resolution: {integrity: sha512-534m2WhVTddrcKVepwmVEVnUAmtrx9bfIjNoQHRqfnvdaHQiFytEhJoTgpWJvDEXCO5gLTQh3wYC1PgOJA4NSQ==}
+
+ micromark@4.0.1:
+ resolution: {integrity: sha512-eBPdkcoCNvYcxQOAKAlceo5SNdzZWfF+FcSupREAzdAh9rRmE239CEQAiTwIgblwnoM8zzj35sZ5ZwvSEOF6Kw==}
+
+ micromatch@4.0.8:
+ resolution: {integrity: sha512-PXwfBhYu0hBCPw8Dn0E+WDYb7af3dSLVWKi3HGv84IdF4TyFoC0ysxFd0Goxw7nSv4T/PzEJQxsYsEiFCKo2BA==}
+ engines: {node: '>=8.6'}
+
+ mimic-function@5.0.1:
+ resolution: {integrity: sha512-VP79XUPxV2CigYP3jWwAUFSku2aKqBH7uTAapFWCBqutsbmDo96KY5o8uh6U+/YSIn5OxJnXp73beVkpqMIGhA==}
+ engines: {node: '>=18'}
- /minimatch@3.1.2:
+ minimatch@3.1.2:
resolution: {integrity: sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==}
- dependencies:
- brace-expansion: 1.1.11
- dev: false
- /minimatch@9.0.4:
- resolution: {integrity: sha512-KqWh+VchfxcMNRAJjj2tnsSJdNbHsVgnkBhTNrW7AjVo6OvLtxw8zfT9oLw1JSohlFzJ8jCoTgaoXvJ+kHt6fw==}
+ minimatch@9.0.5:
+ resolution: {integrity: sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==}
engines: {node: '>=16 || 14 >=14.17'}
- dependencies:
- brace-expansion: 2.0.1
- dev: false
- /minipass-collect@2.0.1:
+ minipass-collect@2.0.1:
resolution: {integrity: sha512-D7V8PO9oaz7PWGLbCACuI1qEOsq7UKfLotx/C0Aet43fCUB/wfQ7DYeq2oR/svFJGYDHPr38SHATeaj/ZoKHKw==}
engines: {node: '>=16 || 14 >=14.17'}
- dependencies:
- minipass: 7.0.4
- dev: false
- /minipass-fetch@3.0.4:
- resolution: {integrity: sha512-jHAqnA728uUpIaFm7NWsCnqKT6UqZz7GcI/bDpPATuwYyKwJwW0remxSCxUlKiEty+eopHGa3oc8WxgQ1FFJqg==}
+ minipass-fetch@3.0.5:
+ resolution: {integrity: sha512-2N8elDQAtSnFV0Dk7gt15KHsS0Fyz6CbYZ360h0WTYV1Ty46li3rAXVOQj1THMNLdmrD9Vt5pBPtWtVkpwGBqg==}
engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
- dependencies:
- minipass: 7.0.4
- minipass-sized: 1.0.3
- minizlib: 2.1.2
- optionalDependencies:
- encoding: 0.1.13
- dev: false
- /minipass-flush@1.0.5:
+ minipass-flush@1.0.5:
resolution: {integrity: sha512-JmQSYYpPUqX5Jyn1mXaRwOda1uQ8HP5KAT/oDSLCzt1BYRhQU0/hDtsB1ufZfEEzMZ9aAVmsBw8+FWsIXlClWw==}
engines: {node: '>= 8'}
- dependencies:
- minipass: 3.3.6
- dev: false
- /minipass-pipeline@1.2.4:
+ minipass-pipeline@1.2.4:
resolution: {integrity: sha512-xuIq7cIOt09RPRJ19gdi4b+RiNvDFYe5JH+ggNvBqGqpQXcru3PcRmOZuHBKWK1Txf9+cQ+HMVN4d6z46LZP7A==}
engines: {node: '>=8'}
- dependencies:
- minipass: 3.3.6
- dev: false
- /minipass-sized@1.0.3:
+ minipass-sized@1.0.3:
resolution: {integrity: sha512-MbkQQ2CTiBMlA2Dm/5cY+9SWFEN8pzzOXi6rlM5Xxq0Yqbda5ZQy9sU75a673FE9ZK0Zsbr6Y5iP6u9nktfg2g==}
engines: {node: '>=8'}
- dependencies:
- minipass: 3.3.6
- dev: false
- /minipass@3.3.6:
+ minipass@3.3.6:
resolution: {integrity: sha512-DxiNidxSEK+tHG6zOIklvNOwm3hvCrbUrdtzY74U6HKTJxvIDfOUL5W5P2Ghd3DTkhhKPYGqeNUIh5qcM4YBfw==}
engines: {node: '>=8'}
- dependencies:
- yallist: 4.0.0
- dev: false
- /minipass@5.0.0:
+ minipass@5.0.0:
resolution: {integrity: sha512-3FnjYuehv9k6ovOEbyOswadCDPX1piCfhV8ncmYtHOjuPwylVWsghTLo7rabjC3Rx5xD4HDx8Wm1xnMF7S5qFQ==}
engines: {node: '>=8'}
- dev: false
- /minipass@7.0.4:
- resolution: {integrity: sha512-jYofLM5Dam9279rdkWzqHozUo4ybjdZmCsDHePy5V/PbBcVMiSZR97gmAy45aqi8CK1lG2ECd356FU86avfwUQ==}
+ minipass@7.1.2:
+ resolution: {integrity: sha512-qOOzS1cBTWYF4BH8fVePDBOO9iptMnGUEZwNc/cMWnTV2nVLZ7VoNWEPHkYczZA0pdoA7dl6e7FL659nX9S2aw==}
engines: {node: '>=16 || 14 >=14.17'}
- dev: false
- /minizlib@2.1.2:
+ minizlib@2.1.2:
resolution: {integrity: sha512-bAxsR8BVfj60DWXHE3u30oHzfl4G7khkSuPW+qvpd7jFRHm7dLxOjUk1EHACJ/hxLY8phGJ0YhYHZo7jil7Qdg==}
engines: {node: '>= 8'}
- dependencies:
- minipass: 3.3.6
- yallist: 4.0.0
- dev: false
- /mj-context-menu@0.6.1:
+ mitt@3.0.1:
+ resolution: {integrity: sha512-vKivATfr97l2/QBCYAkXYDbrIWPM2IIKEl7YPhjCvKlG3kE2gm+uBo6nEXK3M5/Ffh/FLpKExzOQ3JJoJGFKBw==}
+
+ mj-context-menu@0.6.1:
resolution: {integrity: sha512-7NO5s6n10TIV96d4g2uDpG7ZDpIhMh0QNfGdJw/W47JswFcosz457wqz/b5sAKvl12sxINGFCn80NZHKwxQEXA==}
- dev: false
- /mkdirp@1.0.4:
+ mkdirp@1.0.4:
resolution: {integrity: sha512-vVqVZQyf3WLx2Shd0qJ9xuvqgAyKPLAiqITEtqW0oIUjzo3PePDd6fW9iFz30ef7Ysp/oiWqbhszeGWW2T6Gzw==}
engines: {node: '>=10'}
hasBin: true
- dev: false
- /ms@2.1.2:
- resolution: {integrity: sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==}
- dev: false
+ ms@2.1.3:
+ resolution: {integrity: sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==}
- /nano-staged@0.8.0:
+ nano-staged@0.8.0:
resolution: {integrity: sha512-QSEqPGTCJbkHU2yLvfY6huqYPjdBrOaTMKatO1F8nCSrkQGXeKwtCiCnsdxnuMhbg3DTVywKaeWLGCE5oJpq0g==}
engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0}
hasBin: true
- dependencies:
- picocolors: 1.0.0
- dev: false
- /nanoid@3.3.7:
- resolution: {integrity: sha512-eSRppjcPIatRIMC1U6UngP8XFcz8MQWGQdt1MTBQ7NaAmvXDfvNxbvWV3x2y6CdEUciCSsDHDQZbhYaB8QEo2g==}
+ nanoid@3.3.8:
+ resolution: {integrity: sha512-WNLf5Sd8oZxOm+TzppcYk8gVOgP+l58xNy58D0nbUnOxOWRWvlcCV4kUF7ltmI6PsrLl/BgKEyS4mqsGChFN0w==}
engines: {node: ^10 || ^12 || ^13.7 || ^14 || >=15.0.1}
hasBin: true
- dev: false
- /negotiator@0.6.3:
- resolution: {integrity: sha512-+EUsqGPLsM+j/zdChZjsnX51g4XrHFOIXwfnCVPGlQk/k5giakcKsuxCObBRu6DSm9opw/O6slWbJdghQM4bBg==}
+ nanoid@5.0.9:
+ resolution: {integrity: sha512-Aooyr6MXU6HpvvWXKoVoXwKMs/KyVakWwg7xQfv5/S/RIgJMy0Ifa45H9qqYy7pTCszrHzP21Uk4PZq2HpEM8Q==}
+ engines: {node: ^18 || >=20}
+ hasBin: true
+
+ negotiator@0.6.4:
+ resolution: {integrity: sha512-myRT3DiWPHqho5PrJaIRyaMv2kgYf0mUVgBNOYMuCH5Ki1yEiQaf/ZJuQ62nvpc44wL5WDbTX7yGJi1Neevw8w==}
engines: {node: '>= 0.6'}
- dev: false
- /node-addon-api@7.1.0:
- resolution: {integrity: sha512-mNcltoe1R8o7STTegSOHdnJNN7s5EUvhoS7ShnTHDyOSd+8H+UdWODq6qSv67PjC8Zc5JRT8+oLAMCr0SIXw7g==}
- engines: {node: ^16 || ^18 || >= 20}
- dev: false
+ node-addon-api@8.3.0:
+ resolution: {integrity: sha512-8VOpLHFrOQlAH+qA0ZzuGRlALRA6/LVh8QJldbrC4DY0hXoMP0l4Acq8TzFC018HztWiRqyCEj2aTWY2UvnJUg==}
+ engines: {node: ^18 || ^20 || >= 21}
- /node-fetch@2.7.0:
+ node-fetch@2.7.0:
resolution: {integrity: sha512-c4FRfUm/dbcWZ7U+1Wq0AwCyFL+3nt2bEw05wfxSz+DWpWsitgmSgYmy2dQdWyKC1694ELPqMs/YzUSNozLt8A==}
engines: {node: 4.x || >=6.0.0}
peerDependencies:
@@ -2697,747 +1999,677 @@ packages:
peerDependenciesMeta:
encoding:
optional: true
- dependencies:
- whatwg-url: 5.0.0
- dev: false
- /node-gyp@10.1.0:
- resolution: {integrity: sha512-B4J5M1cABxPc5PwfjhbV5hoy2DP9p8lFXASnEN6hugXOa61416tnTZ29x9sSwAd0o99XNIcpvDDy1swAExsVKA==}
+ node-gyp@10.3.1:
+ resolution: {integrity: sha512-Pp3nFHBThHzVtNY7U6JfPjvT/DTE8+o/4xKsLQtBoU+j2HLsGlhcfzflAoUreaJbNmYnX+LlLi0qjV8kpyO6xQ==}
engines: {node: ^16.14.0 || >=18.0.0}
hasBin: true
- dependencies:
- env-paths: 2.2.1
- exponential-backoff: 3.1.1
- glob: 10.3.12
- graceful-fs: 4.2.11
- make-fetch-happen: 13.0.0
- nopt: 7.2.0
- proc-log: 3.0.0
- semver: 7.6.0
- tar: 6.2.1
- which: 4.0.0
- transitivePeerDependencies:
- - supports-color
- dev: false
- /node-releases@2.0.14:
- resolution: {integrity: sha512-y10wOWt8yZpqXmOgRo77WaHEmhYQYGNA6y421PKsKYWEK8aW+cqAphborZDhqfyKrbZEN92CN1X2KbafY2s7Yw==}
- dev: false
+ node-releases@2.0.19:
+ resolution: {integrity: sha512-xxOWJsBKtzAq7DY0J+DTzuz58K8e7sJbdgwkbMWQe8UYB6ekmsQ45q0M/tJDsGaZmbC+l7n57UV8Hl5tHxO9uw==}
- /nodejs-jieba@0.1.2:
- resolution: {integrity: sha512-VOBhc1muuH00apYn78bVJSPUn7xakyawJNTl+3jVu3038FpxKBp4qxfGkpb07DXWFf12IlcIT4UzmhqXzASKxg==}
- engines: {node: ^18.0.0 || ^20.0.0}
- requiresBuild: true
- dependencies:
- '@mapbox/node-pre-gyp': 1.0.11
- node-addon-api: 7.1.0
- node-gyp: 10.1.0
- transitivePeerDependencies:
- - encoding
- - supports-color
- dev: false
+ nodejs-jieba@0.2.1:
+ resolution: {integrity: sha512-211M6vWoXBZn9+3C6cBuiAXRmwnidbV4eK5O63VZb7kK0miNMkWknUS5Usv/n5gUrT99kHgps+4xL9g/r0F89A==}
+ engines: {node: ^18.0.0 || ^20.0.0 || ^22.0.0}
- /nopt@5.0.0:
+ nopt@5.0.0:
resolution: {integrity: sha512-Tbj67rffqceeLpcRXrT7vKAN8CwfPeIBgM7E6iBkmKLV7bEMwpGgYLGv0jACUsECaa/vuxP0IjEont6umdMgtQ==}
engines: {node: '>=6'}
hasBin: true
- dependencies:
- abbrev: 1.1.1
- dev: false
- /nopt@7.2.0:
- resolution: {integrity: sha512-CVDtwCdhYIvnAzFoJ6NJ6dX3oga9/HyciQDnG1vQDjSLMeKLJ4A93ZqYKDrgYSr1FBY5/hMYC+2VCi24pgpkGA==}
+ nopt@7.2.1:
+ resolution: {integrity: sha512-taM24ViiimT/XntxbPyJQzCG+p4EKOpgD3mxFwW38mGjVUrfERQOeY4EDHjdnptttfHuHQXFx+lTP08Q+mLa/w==}
engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
hasBin: true
- dependencies:
- abbrev: 2.0.0
- dev: false
- /normalize-path@3.0.0:
+ normalize-path@3.0.0:
resolution: {integrity: sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==}
engines: {node: '>=0.10.0'}
- dev: false
- /normalize-range@0.1.2:
+ normalize-range@0.1.2:
resolution: {integrity: sha512-bdok/XvKII3nUpklnV6P2hxtMNrCboOjAcyBuQnWEhO665FwrSNRxU+AqpsyvO6LgGYPspN+lu5CLtw4jPRKNA==}
engines: {node: '>=0.10.0'}
- dev: false
- /npm-run-path@5.3.0:
- resolution: {integrity: sha512-ppwTtiJZq0O/ai0z7yfudtBpWIoxM8yE6nHi1X47eFR2EWORqfbu6CnPlNsjeN683eT0qG6H/Pyf9fCcvjnnnQ==}
- engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0}
- dependencies:
- path-key: 4.0.0
- dev: false
+ npm-run-path@6.0.0:
+ resolution: {integrity: sha512-9qny7Z9DsQU8Ou39ERsPU4OZQlSTP47ShQzuKZ6PRXpYLtIFgl/DEBYEXKlvcEa+9tHVcK8CF81Y2V72qaZhWA==}
+ engines: {node: '>=18'}
- /npmlog@5.0.1:
+ npmlog@5.0.1:
resolution: {integrity: sha512-AqZtDUWOMKs1G/8lwylVjrdYgqA4d9nu8hc+0gzRxlDb1I10+FHBGMXs6aiQHFdCUUlqH99MUMuLfzWDNDtfxw==}
- dependencies:
- are-we-there-yet: 2.0.0
- console-control-strings: 1.1.0
- gauge: 3.0.2
- set-blocking: 2.0.0
- dev: false
+ deprecated: This package is no longer supported.
- /nth-check@2.1.1:
+ nth-check@2.1.1:
resolution: {integrity: sha512-lqjrjmaOoAnWfMmBPL+XNnynZh2+swxiX3WUE0s4yEHI6m+AwrK2UZOimIRl3X/4QctVqS8AiZjFqyOGrMXb/w==}
- dependencies:
- boolbase: 1.0.0
- dev: false
- /object-assign@4.1.1:
+ object-assign@4.1.1:
resolution: {integrity: sha512-rJgTQnkUnH1sFw8yT6VSU3zD3sWmu6sZhIseY8VX+GRu3P6F7Fu+JNDoXfklElbLJSnc3FUQHVe4cU5hj+BcUg==}
engines: {node: '>=0.10.0'}
- dev: false
- /once@1.4.0:
+ once@1.4.0:
resolution: {integrity: sha512-lNaJgI+2Q5URQBkccEKHTQOPaXdUxnZZElQTZY0MFUAuaEqe1E+Nyvgdz/aIyNi6Z9MzO5dv1H8n58/GELp3+w==}
- dependencies:
- wrappy: 1.0.2
- dev: false
- /onetime@5.1.2:
- resolution: {integrity: sha512-kbpaSSGJTWdAY5KPVeMOKXSrPtr8C8C7wodJbcsd51jRnmD+GZu8Y0VoU6Dm5Z4vWr0Ig/1NKuWRKf7j5aaYSg==}
- engines: {node: '>=6'}
- dependencies:
- mimic-fn: 2.1.0
- dev: false
+ onetime@7.0.0:
+ resolution: {integrity: sha512-VXJjc87FScF88uafS3JllDgvAm+c/Slfz06lorj2uAY34rlUu0Nt+v8wreiImcrgAjjIHp1rXpTDlLOGw29WwQ==}
+ engines: {node: '>=18'}
- /onetime@6.0.0:
- resolution: {integrity: sha512-1FlR+gjXK7X+AsAHso35MnyN5KqGwJRi/31ft6x0M194ht7S+rWAvd7PHss9xSKMzE0asv1pyIHaJYq+BbacAQ==}
- engines: {node: '>=12'}
- dependencies:
- mimic-fn: 4.0.0
- dev: false
+ oniguruma-to-es@1.0.0:
+ resolution: {integrity: sha512-kihvp0O4lFwf5tZMkfanwQLIZ9ORe9OeOFgZonH0BQeThgwfJiaZFeOfvvJVnJIM9TiVmx0RDD35hUJDR0++rQ==}
- /ora@8.0.1:
- resolution: {integrity: sha512-ANIvzobt1rls2BDny5fWZ3ZVKyD6nscLvfFRpQgfWsythlcsVUC9kL0zq6j2Z5z9wwp1kd7wpsD/T9qNPVLCaQ==}
+ ora@8.1.1:
+ resolution: {integrity: sha512-YWielGi1XzG1UTvOaCFaNgEnuhZVMSHYkW/FQ7UX8O26PtlpdM84c0f7wLPlkvx2RfiQmnzd61d/MGxmpQeJPw==}
engines: {node: '>=18'}
- dependencies:
- chalk: 5.3.0
- cli-cursor: 4.0.0
- cli-spinners: 2.9.2
- is-interactive: 2.0.0
- is-unicode-supported: 2.0.0
- log-symbols: 6.0.0
- stdin-discarder: 0.2.2
- string-width: 7.1.0
- strip-ansi: 7.1.0
- dev: false
- /p-limit@2.3.0:
+ p-limit@2.3.0:
resolution: {integrity: sha512-//88mFWSJx8lxCzwdAABTJL2MyWB12+eIY7MDL2SqLmAkeKU9qxRvWuSyTjm3FUmpBEMuFfckAIqEaVGUDxb6w==}
engines: {node: '>=6'}
- dependencies:
- p-try: 2.2.0
- dev: false
- /p-locate@4.1.0:
+ p-locate@4.1.0:
resolution: {integrity: sha512-R79ZZ/0wAxKGu3oYMlz8jy/kbhsNrS7SKZ7PxEHBgJ5+F2mtFW2fK2cOtBh1cHYkQsbzFV7I+EoRKe6Yt0oK7A==}
engines: {node: '>=8'}
- dependencies:
- p-limit: 2.3.0
- dev: false
- /p-map@4.0.0:
+ p-map@4.0.0:
resolution: {integrity: sha512-/bjOqmgETBYB5BoEeGVea8dmvHb2m9GLy1E9W43yeyfP6QQCZGFNa+XRceJEuDB6zqr+gKpIAmlLebMpykw/MQ==}
engines: {node: '>=10'}
- dependencies:
- aggregate-error: 3.1.0
- dev: false
- /p-try@2.2.0:
+ p-try@2.2.0:
resolution: {integrity: sha512-R4nPAVTAU0B9D35/Gk3uJf/7XYbQcyohSKdvAxIRSNghFl4e71hVoGnBNQz9cWaXxO2I10KTC+3jMdvvoKw6dQ==}
engines: {node: '>=6'}
- dev: false
- /parse5-htmlparser2-tree-adapter@7.0.0:
- resolution: {integrity: sha512-B77tOZrqqfUfnVcOrUvfdLbz4pu4RopLD/4vmu3HUPswwTA8OH0EMW9BlWR2B0RCoiZRAHEUu7IxeP1Pd1UU+g==}
- dependencies:
- domhandler: 5.0.3
- parse5: 7.1.2
- dev: false
+ package-json-from-dist@1.0.1:
+ resolution: {integrity: sha512-UEZIS3/by4OC8vL3P2dTXRETpebLI2NiI5vIrjaD/5UtrkFX/tNbwjTSRAGC/+7CAo2pIcBaRgWmcBBHcsaCIw==}
- /parse5@7.1.2:
- resolution: {integrity: sha512-Czj1WaSVpaoj0wbhMzLmWD69anp2WH7FXMB9n1Sy8/ZFF9jolSQVMu1Ij5WIyGmcBmhk7EOndpO4mIpihVqAXw==}
- dependencies:
- entities: 4.5.0
- dev: false
+ parse-entities@4.0.2:
+ resolution: {integrity: sha512-GG2AQYWoLgL877gQIKeRPGO1xF9+eG1ujIb5soS5gPvLQ1y2o8FL90w2QWNdf9I361Mpp7726c+lj3U0qK1uGw==}
+
+ parse-ms@4.0.0:
+ resolution: {integrity: sha512-TXfryirbmq34y8QBwgqCVLi+8oA3oWx2eAnSn62ITyEhEYaWRlVZ2DvMM9eZbMs/RfxPu/PK/aBLyGj4IrqMHw==}
+ engines: {node: '>=18'}
- /path-exists@4.0.0:
+ parse5-htmlparser2-tree-adapter@7.1.0:
+ resolution: {integrity: sha512-ruw5xyKs6lrpo9x9rCZqZZnIUntICjQAd0Wsmp396Ul9lN/h+ifgVV1x1gZHi8euej6wTfpqX8j+BFQxF0NS/g==}
+
+ parse5-parser-stream@7.1.2:
+ resolution: {integrity: sha512-JyeQc9iwFLn5TbvvqACIF/VXG6abODeB3Fwmv/TGdLk2LfbWkaySGY72at4+Ty7EkPZj854u4CrICqNk2qIbow==}
+
+ parse5@7.2.1:
+ resolution: {integrity: sha512-BuBYQYlv1ckiPdQi/ohiivi9Sagc9JG+Ozs0r7b/0iK3sKmrb0b9FdWdBbOdx6hBCM/F9Ir82ofnBhtZOjCRPQ==}
+
+ path-exists@4.0.0:
resolution: {integrity: sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==}
engines: {node: '>=8'}
- dev: false
- /path-is-absolute@1.0.1:
+ path-is-absolute@1.0.1:
resolution: {integrity: sha512-AVbw3UJ2e9bq64vSaS9Am0fje1Pa8pbGqTTsmXfaIiMpnr5DlDhfJOuLj9Sf95ZPVDAUerDfEk88MPmPe7UCQg==}
engines: {node: '>=0.10.0'}
- dev: false
- /path-key@3.1.1:
+ path-key@3.1.1:
resolution: {integrity: sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==}
engines: {node: '>=8'}
- dev: false
- /path-key@4.0.0:
+ path-key@4.0.0:
resolution: {integrity: sha512-haREypq7xkM7ErfgIyA0z+Bj4AGKlMSdlQE2jvJo6huWD1EdkKYV+G/T4nq0YEF2vgTT8kqMFKo1uHn950r4SQ==}
engines: {node: '>=12'}
- dev: false
- /path-scurry@1.10.2:
- resolution: {integrity: sha512-7xTavNy5RQXnsjANvVvMkEjvloOinkAjv/Z6Ildz9v2RinZ4SBKTWFOVRbaF8p0vpHnyjV/UwNDdKuUv6M5qcA==}
- engines: {node: '>=16 || 14 >=14.17'}
- dependencies:
- lru-cache: 10.2.0
- minipass: 7.0.4
- dev: false
+ path-scurry@1.11.1:
+ resolution: {integrity: sha512-Xa4Nw17FS9ApQFJ9umLiJS4orGjm7ZzwUrwamcGQuHSzDyth9boKDaycYdDcZDuqYATXw4HFXgaqWTctW/v1HA==}
+ engines: {node: '>=16 || 14 >=14.18'}
- /path-type@5.0.0:
+ path-type@5.0.0:
resolution: {integrity: sha512-5HviZNaZcfqP95rwpv+1HDgUamezbqdSYTyzjTvwtJSnIH+3vnbmWsItli8OFEndS984VT55M3jduxZbX351gg==}
engines: {node: '>=12'}
- dev: false
- /photoswipe@5.4.3:
- resolution: {integrity: sha512-9UC6oJBK4oXFZ5HcdlcvGkfEHsVrmE4csUdCQhEjHYb3PvPLO3PG7UhnPuOgjxwmhq5s17Un5NUdum01LgBDng==}
+ perfect-debounce@1.0.0:
+ resolution: {integrity: sha512-xCy9V055GLEqoFaHoC1SoLIaLmWctgCUaBaWxDZ7/Zx4CTyX7cJQLJOok/orfjZAh9kEYpjJa4d0KcJmCbctZA==}
+
+ photoswipe@5.4.4:
+ resolution: {integrity: sha512-WNFHoKrkZNnvFFhbHL93WDkW3ifwVOXSW3w1UuZZelSmgXpIGiZSNlZJq37rR8YejqME2rHs9EhH9ZvlvFH2NA==}
engines: {node: '>= 0.12.0'}
- dev: false
- /picocolors@1.0.0:
- resolution: {integrity: sha512-1fygroTLlHu66zi26VoTDv8yRgm0Fccecssto+MhsZ0D/DGW2sm8E8AjW7NU5VVTRt5GxbeZ5qBuJr+HyLYkjQ==}
- dev: false
+ picocolors@1.1.1:
+ resolution: {integrity: sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==}
- /picomatch@2.3.1:
+ picomatch@2.3.1:
resolution: {integrity: sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==}
engines: {node: '>=8.6'}
- dev: false
- /pngjs@5.0.0:
+ pngjs@5.0.0:
resolution: {integrity: sha512-40QW5YalBNfQo5yRYmiw7Yz6TKKVr3h6970B2YE+3fQpsWcrbj1PzJgxeJ19DRQjhMbKPIuMY8rFaXc8moolVw==}
engines: {node: '>=10.13.0'}
- dev: false
- /postcss-load-config@5.0.3(postcss@8.4.38):
- resolution: {integrity: sha512-90pBBI5apUVruIEdCxZic93Wm+i9fTrp7TXbgdUCH+/L+2WnfpITSpq5dFU/IPvbv7aNiMlQISpUkAm3fEcvgQ==}
+ postcss-load-config@6.0.1:
+ resolution: {integrity: sha512-oPtTM4oerL+UXmx+93ytZVN82RrlY/wPUV8IeDxFrzIjXOLF1pN+EmKPLbubvKHT2HC20xXsCAH2Z+CKV6Oz/g==}
engines: {node: '>= 18'}
peerDependencies:
jiti: '>=1.21.0'
postcss: '>=8.0.9'
+ tsx: ^4.8.1
+ yaml: ^2.4.2
peerDependenciesMeta:
jiti:
optional: true
postcss:
optional: true
- dependencies:
- lilconfig: 3.1.1
- postcss: 8.4.38
- yaml: 2.4.1
- dev: false
+ tsx:
+ optional: true
+ yaml:
+ optional: true
- /postcss-value-parser@4.2.0:
+ postcss-value-parser@4.2.0:
resolution: {integrity: sha512-1NNCs6uurfkVbeXG4S8JFT9t19m45ICnif8zWLd5oPSZ50QnwMfK+H3jv408d4jw/7Bttv5axS5IiHoLaVNHeQ==}
- dev: false
- /postcss@8.4.38:
- resolution: {integrity: sha512-Wglpdk03BSfXkHoQa3b/oulrotAkwrlLDRSOb9D0bN86FdRyE9lppSp33aHNPgBa0JKCoB+drFLZkQoRRYae5A==}
+ postcss@8.5.0:
+ resolution: {integrity: sha512-27VKOqrYfPncKA2NrFOVhP5MGAfHKLYn/Q0mz9cNQyRAKYi3VNHwYU2qKKqPCqgBmeeJ0uAFB56NumXZ5ZReXg==}
engines: {node: ^10 || ^12 || >=14}
- dependencies:
- nanoid: 3.3.7
- picocolors: 1.0.0
- source-map-js: 1.2.0
- dev: false
- /prettier@3.2.5:
- resolution: {integrity: sha512-3/GWa9aOC0YeD7LUfvOG2NiDyhOWRvt1k+rcKhOuYnMY24iiCphgneUfJDyFXd6rZCAnuLBv6UeAULtrhT/F4A==}
+ prettier@3.4.2:
+ resolution: {integrity: sha512-e9MewbtFo+Fevyuxn/4rrcDAaq0IYxPGLvObpQjiZBMAzB9IGmzlnG9RZy3FFas+eBMu2vA0CszMeduow5dIuQ==}
engines: {node: '>=14'}
hasBin: true
- dev: false
- /prismjs@1.29.0:
- resolution: {integrity: sha512-Kx/1w86q/epKcmte75LNrEoT+lX8pBpavuAbvJWRXar7Hz8jrtF+e3vY751p0R8H9HdArwaCTNDDzHg/ScJK1Q==}
- engines: {node: '>=6'}
- dev: false
+ pretty-ms@9.2.0:
+ resolution: {integrity: sha512-4yf0QO/sllf/1zbZWYnvWw3NxCQwLXKzIj0G849LSufP15BXKM0rbD2Z3wVnkMfjdn/CB0Dpp444gYAACdsplg==}
+ engines: {node: '>=18'}
- /proc-log@3.0.0:
- resolution: {integrity: sha512-++Vn7NS4Xf9NacaU9Xq3URUuqZETPsf8L4j5/ckhaRYsfPeRyzGw+iDjFhV/Jr3uNmTvvddEJFWh5R1gRgUH8A==}
+ proc-log@4.2.0:
+ resolution: {integrity: sha512-g8+OnU/L2v+wyiVK+D5fA34J7EH8jZ8DDlvwhRCMxmMj7UCBvxiO1mGeN+36JXIKF4zevU4kRBd8lVgG9vLelA==}
engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
- dev: false
- /promise-retry@2.0.1:
+ promise-retry@2.0.1:
resolution: {integrity: sha512-y+WKFlBR8BGXnsNlIHFGPZmyDf3DFMoLhaflAnyZgV6rG6xu+JwesTo2Q9R6XwYmtmwAFCkAk3e35jEdoeh/3g==}
engines: {node: '>=10'}
- dependencies:
- err-code: 2.0.3
- retry: 0.12.0
- dev: false
- /punycode.js@2.3.1:
+ property-information@6.5.0:
+ resolution: {integrity: sha512-PgTgs/BlvHxOu8QuEN7wi5A0OmXaBcHpmCSTehcs6Uuu9IkDIEo13Hy7n898RHfrQ49vKCoGeWZSaAK01nwVig==}
+
+ punycode.js@2.3.1:
resolution: {integrity: sha512-uxFIHU0YlHYhDQtV4R9J6a52SLx28BCjT+4ieh7IGbgwVJWO+km431c4yRlREUAsAmt/uMjQUyQHNEPf0M39CA==}
engines: {node: '>=6'}
- dev: false
- /qrcode@1.5.3:
- resolution: {integrity: sha512-puyri6ApkEHYiVl4CFzo1tDkAZ+ATcnbJrJ6RiBM1Fhctdn/ix9MTE3hRph33omisEbC/2fcfemsseiKgBPKZg==}
+ qrcode@1.5.4:
+ resolution: {integrity: sha512-1ca71Zgiu6ORjHqFBDpnSMTR2ReToX4l1Au1VFLyVeBTFavzQnv5JxMFr3ukHVKpSrSA2MCk0lNJSykjUfz7Zg==}
engines: {node: '>=10.13.0'}
hasBin: true
- dependencies:
- dijkstrajs: 1.0.3
- encode-utf8: 1.0.3
- pngjs: 5.0.0
- yargs: 15.4.1
- dev: false
- /queue-microtask@1.2.3:
+ queue-microtask@1.2.3:
resolution: {integrity: sha512-NuaNSa6flKT5JaSYQzJok04JzTL1CA6aGhv5rfLW3PgqA+M2ChpZQnAC8h8i4ZFkBS8X5RqkDBHA7r4hej3K9A==}
- dev: false
- /readable-stream@3.6.2:
+ readable-stream@3.6.2:
resolution: {integrity: sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA==}
engines: {node: '>= 6'}
- dependencies:
- inherits: 2.0.4
- string_decoder: 1.3.0
- util-deprecate: 1.0.2
- dev: false
- /readdirp@3.6.0:
+ readdirp@3.6.0:
resolution: {integrity: sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==}
engines: {node: '>=8.10.0'}
- dependencies:
- picomatch: 2.3.1
- dev: false
- /require-directory@2.1.1:
+ readdirp@4.1.1:
+ resolution: {integrity: sha512-h80JrZu/MHUZCyHu5ciuoI0+WxsCxzxJTILn6Fs8rxSnFPh+UVHYfeIxK1nVGugMqkfC4vJcBOYbkfkwYK0+gw==}
+ engines: {node: '>= 14.18.0'}
+
+ regex-recursion@5.1.1:
+ resolution: {integrity: sha512-ae7SBCbzVNrIjgSbh7wMznPcQel1DNlDtzensnFxpiNpXt1U2ju/bHugH422r+4LAVS1FpW1YCwilmnNsjum9w==}
+
+ regex-utilities@2.3.0:
+ resolution: {integrity: sha512-8VhliFJAWRaUiVvREIiW2NXXTmHs4vMNnSzuJVhscgmGav3g9VDxLrQndI3dZZVVdp0ZO/5v0xmX516/7M9cng==}
+
+ regex@5.1.1:
+ resolution: {integrity: sha512-dN5I359AVGPnwzJm2jN1k0W9LPZ+ePvoOeVMMfqIMFz53sSwXkxaJoxr50ptnsC771lK95BnTrVSZxq0b9yCGw==}
+
+ require-directory@2.1.1:
resolution: {integrity: sha512-fGxEI7+wsG9xrvdjsrlmL22OMTTiHRwAMroiEeMgq8gzoLC/PQr7RsRDSTLUg/bZAZtF+TVIkHc6/4RIKrui+Q==}
engines: {node: '>=0.10.0'}
- dev: false
- /require-main-filename@2.0.0:
+ require-main-filename@2.0.0:
resolution: {integrity: sha512-NKN5kMDylKuldxYLSUfrbo5Tuzh4hd+2E8NPPX02mZtn1VuREQToYe/ZdlJy+J3uCpfaiGF05e7B8W0iXbQHmg==}
- dev: false
- /restore-cursor@4.0.0:
- resolution: {integrity: sha512-I9fPXU9geO9bHOt9pHHOhOkYerIMsmVaWB0rA2AI9ERh/+x/i7MV5HKBNrg+ljO5eoPVgCcnFuRjJ9uH6I/3eg==}
- engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0}
- dependencies:
- onetime: 5.1.2
- signal-exit: 3.0.7
- dev: false
+ restore-cursor@5.1.0:
+ resolution: {integrity: sha512-oMA2dcrw6u0YfxJQXm342bFKX/E4sG9rbTzO9ptUcR/e8A33cHuvStiYOwH7fszkZlZ1z/ta9AAoPk2F4qIOHA==}
+ engines: {node: '>=18'}
- /retry@0.12.0:
+ retry@0.12.0:
resolution: {integrity: sha512-9LkiTwjUh6rT555DtE9rTX+BKByPfrMzEAtnlEtdEwr3Nkffwiihqe2bWADg+OQRjt9gl6ICdmB/ZFDCGAtSow==}
engines: {node: '>= 4'}
- dev: false
- /reusify@1.0.4:
+ reusify@1.0.4:
resolution: {integrity: sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==}
engines: {iojs: '>=1.0.0', node: '>=0.10.0'}
- dev: false
- /rimraf@3.0.2:
+ rfdc@1.4.1:
+ resolution: {integrity: sha512-q1b3N5QkRUWUl7iyylaaj3kOpIT0N2i9MqIEQXP73GVsN9cw3fdx8X63cEmWhJGi2PPCF23Ijp7ktmd39rawIA==}
+
+ rimraf@3.0.2:
resolution: {integrity: sha512-JZkJMZkAGFFPP2YqXZXPbMlMBgsxzE8ILs4lMIX/2o0L9UBw9O/Y3o6wFw/i9YLapcUJWwqbi3kdxIPdC62TIA==}
+ deprecated: Rimraf versions prior to v4 are no longer supported
hasBin: true
- dependencies:
- glob: 7.2.3
- dev: false
- /rollup@4.13.2:
- resolution: {integrity: sha512-MIlLgsdMprDBXC+4hsPgzWUasLO9CE4zOkj/u6j+Z6j5A4zRY+CtiXAdJyPtgCsc42g658Aeh1DlrdVEJhsL2g==}
+ rollup@4.30.1:
+ resolution: {integrity: sha512-mlJ4glW020fPuLi7DkM/lN97mYEZGWeqBnrljzN0gs7GLctqX3lNWxKQ7Gl712UAX+6fog/L3jh4gb7R6aVi3w==}
engines: {node: '>=18.0.0', npm: '>=8.0.0'}
hasBin: true
- dependencies:
- '@types/estree': 1.0.5
- optionalDependencies:
- '@rollup/rollup-android-arm-eabi': 4.13.2
- '@rollup/rollup-android-arm64': 4.13.2
- '@rollup/rollup-darwin-arm64': 4.13.2
- '@rollup/rollup-darwin-x64': 4.13.2
- '@rollup/rollup-linux-arm-gnueabihf': 4.13.2
- '@rollup/rollup-linux-arm64-gnu': 4.13.2
- '@rollup/rollup-linux-arm64-musl': 4.13.2
- '@rollup/rollup-linux-powerpc64le-gnu': 4.13.2
- '@rollup/rollup-linux-riscv64-gnu': 4.13.2
- '@rollup/rollup-linux-s390x-gnu': 4.13.2
- '@rollup/rollup-linux-x64-gnu': 4.13.2
- '@rollup/rollup-linux-x64-musl': 4.13.2
- '@rollup/rollup-win32-arm64-msvc': 4.13.2
- '@rollup/rollup-win32-ia32-msvc': 4.13.2
- '@rollup/rollup-win32-x64-msvc': 4.13.2
- fsevents: 2.3.3
- dev: false
- /run-parallel@1.2.0:
+ run-parallel@1.2.0:
resolution: {integrity: sha512-5l4VyZR86LZ/lDxZTR6jqL8AFE2S0IFLMP26AbjsLVADxHdhB/c0GUsH+y39UfCi3dzz8OlQuPmnaJOMoDHQBA==}
- dependencies:
- queue-microtask: 1.2.3
- dev: false
- /safe-buffer@5.2.1:
+ rxjs@7.8.1:
+ resolution: {integrity: sha512-AA3TVj+0A2iuIoQkWEK/tqFjBq2j+6PO6Y0zJcvzLAFhEFIO3HL0vls9hWLncZbAAbK0mar7oZ4V079I/qPMxg==}
+
+ safe-buffer@5.2.1:
resolution: {integrity: sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==}
- dev: false
- /safer-buffer@2.1.2:
+ safer-buffer@2.1.2:
resolution: {integrity: sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==}
- requiresBuild: true
- dev: false
- optional: true
- /sass@1.72.0:
- resolution: {integrity: sha512-Gpczt3WA56Ly0Mn8Sl21Vj94s1axi9hDIzDFn9Ph9x3C3p4nNyvsqJoQyVXKou6cBlfFWEgRW4rT8Tb4i3XnVA==}
+ sass-embedded-android-arm64@1.83.1:
+ resolution: {integrity: sha512-S63rlLPGCA9FCqYYOobDJrwcuBX0zbSOl7y0jT9DlfqeqNOkC6NIT1id6RpMFCs3uhd4gbBS2E/5WPv5J5qwbw==}
+ engines: {node: '>=14.0.0'}
+ cpu: [arm64]
+ os: [android]
+
+ sass-embedded-android-arm@1.83.1:
+ resolution: {integrity: sha512-FKfrmwDG84L5cfn8fmIew47qnCFFUdcoOTCzOw8ROItkRhLLH0hnIm6gEpG5T6OFf6kxzUxvE9D0FvYQUznZrw==}
+ engines: {node: '>=14.0.0'}
+ cpu: [arm]
+ os: [android]
+
+ sass-embedded-android-ia32@1.83.1:
+ resolution: {integrity: sha512-AGlY2vFLJhF2hN0qOz12f4eDs6x0b5BUapOpgfRrqQLHIfJhxkvi39bInsiBgQ57U0jb4I7AaS2e2e+sj7+Rqw==}
+ engines: {node: '>=14.0.0'}
+ cpu: [ia32]
+ os: [android]
+
+ sass-embedded-android-riscv64@1.83.1:
+ resolution: {integrity: sha512-OyU4AnfAUVd/wBaT60XvHidmQdaEsVUnxvI71oyPM/id1v97aWTZX3SmGkwGb7uA/q6Soo2uNalgvOSNJn7PwA==}
+ engines: {node: '>=14.0.0'}
+ cpu: [riscv64]
+ os: [android]
+
+ sass-embedded-android-x64@1.83.1:
+ resolution: {integrity: sha512-NY5rwffhF4TnhXVErZnfFIjHqU3MNoWxCuSHumRN3dDI8hp8+IF59W5+Qw9AARlTXvyb+D0u5653aLSea5F40w==}
+ engines: {node: '>=14.0.0'}
+ cpu: [x64]
+ os: [android]
+
+ sass-embedded-darwin-arm64@1.83.1:
+ resolution: {integrity: sha512-w1SBcSkIgIWgUfB7IKcPoTbSwnS3Kag5PVv3e3xfW6ZCsDweYZLQntUd2WGgaoekdm1uIbVuvPxnDH2t880iGQ==}
+ engines: {node: '>=14.0.0'}
+ cpu: [arm64]
+ os: [darwin]
+
+ sass-embedded-darwin-x64@1.83.1:
+ resolution: {integrity: sha512-RWrmLtUhEP5kvcGOAFdr99/ebZ/eW9z3FAktLldvgl2k96WSTC1Zr2ctL0E+Y+H3uLahEZsshIFk6RkVIRKIsA==}
+ engines: {node: '>=14.0.0'}
+ cpu: [x64]
+ os: [darwin]
+
+ sass-embedded-linux-arm64@1.83.1:
+ resolution: {integrity: sha512-HVIytzj8OO18fmBY6SVRIYErcJ+Nd9a5RNF6uArav/CqvwPLATlUV8dwqSyWQIzSsQUhDF/vFIlJIoNLKKzD3A==}
+ engines: {node: '>=14.0.0'}
+ cpu: [arm64]
+ os: [linux]
+
+ sass-embedded-linux-arm@1.83.1:
+ resolution: {integrity: sha512-y7rHuRgjg2YM284rin068PsEdthPljSGb653Slut5Wba4A2IP11UNVraSl6Je2AYTuoPRjQX0g7XdsrjXlzC3g==}
+ engines: {node: '>=14.0.0'}
+ cpu: [arm]
+ os: [linux]
+
+ sass-embedded-linux-ia32@1.83.1:
+ resolution: {integrity: sha512-/pc+jHllyvfaYYLTRCoXseRc4+V3Z7IDPqsviTcfVdICAoR9mgK2RtIuIZanhm1NP/lDylDOgvj1NtjcA2dNvg==}
engines: {node: '>=14.0.0'}
+ cpu: [ia32]
+ os: [linux]
+
+ sass-embedded-linux-musl-arm64@1.83.1:
+ resolution: {integrity: sha512-wjSIYYqdIQp3DjliSTYNFg04TVqQf/3Up/Stahol0Qf/TTjLkjHHtT2jnDaZI5GclHi2PVJqQF3wEGB8bGJMzQ==}
+ engines: {node: '>=14.0.0'}
+ cpu: [arm64]
+ os: [linux]
+
+ sass-embedded-linux-musl-arm@1.83.1:
+ resolution: {integrity: sha512-sFM8GXOVoeR91j9MiwNRcFXRpTA7u4185SaGuvUjcRMb84mHvtWOJPGDvgZqbWdVClBRJp6J7+CShliWngy/og==}
+ engines: {node: '>=14.0.0'}
+ cpu: [arm]
+ os: [linux]
+
+ sass-embedded-linux-musl-ia32@1.83.1:
+ resolution: {integrity: sha512-iwhTH5gwmoGt3VH6dn4WV8N6eWvthKAvUX5XPURq7e9KEsc7QP8YNHagwaAJh7TAPopb32buyEg6oaUmzxUI+Q==}
+ engines: {node: '>=14.0.0'}
+ cpu: [ia32]
+ os: [linux]
+
+ sass-embedded-linux-musl-riscv64@1.83.1:
+ resolution: {integrity: sha512-FjFNWHU1n0Q6GpK1lAHQL5WmzlPjL8DTVLkYW2A/dq8EsutAdi3GfpeyWZk9bte8kyWdmPUWG3BHlnQl22xdoA==}
+ engines: {node: '>=14.0.0'}
+ cpu: [riscv64]
+ os: [linux]
+
+ sass-embedded-linux-musl-x64@1.83.1:
+ resolution: {integrity: sha512-BUfYR5TIDvgGHWhxSIKwTJocXU88ECZ0BW89RJqtvr7m83fKdf5ylTFCOieU7BwcA7SORUeZzcQzVFIdPUM3BQ==}
+ engines: {node: '>=14.0.0'}
+ cpu: [x64]
+ os: [linux]
+
+ sass-embedded-linux-riscv64@1.83.1:
+ resolution: {integrity: sha512-KOBGSpMrJi8y+H+za3vAAVQImPUvQa5eUrvTbbOl+wkU7WAGhOu8xrxgmYYiz3pZVBBcfRjz4I2jBcDFKJmWSw==}
+ engines: {node: '>=14.0.0'}
+ cpu: [riscv64]
+ os: [linux]
+
+ sass-embedded-linux-x64@1.83.1:
+ resolution: {integrity: sha512-swUsMHKqlEU9dZQ/I5WADDaXz+QkmJS27x/Oeh+oz41YgZ0ppKd0l4Vwjn0LgOQn+rxH1zLFv6xXDycvj68F/w==}
+ engines: {node: '>=14.0.0'}
+ cpu: [x64]
+ os: [linux]
+
+ sass-embedded-win32-arm64@1.83.1:
+ resolution: {integrity: sha512-6lONEBN5TaFD5L/y68zUugryXqm4RAFuLdaOPeZQRu+7ay/AmfhtFYfE5gRssnIcIx1nlcoq7zA3UX+SN2jo1Q==}
+ engines: {node: '>=14.0.0'}
+ cpu: [arm64]
+ os: [win32]
+
+ sass-embedded-win32-ia32@1.83.1:
+ resolution: {integrity: sha512-HxZDkAE9n6Gb8Rz6xd67VHuo5FkUSQ4xPb7cHKa4pE0ndwH5Oc0uEhbqjJobpgmnuTm1rQYNU2nof1sFhy2MFA==}
+ engines: {node: '>=14.0.0'}
+ cpu: [ia32]
+ os: [win32]
+
+ sass-embedded-win32-x64@1.83.1:
+ resolution: {integrity: sha512-5Q0aPfUaqRek8Ee1AqTUIC0o6yQSA8QwyhCgh7upsnHG3Ltm8pkJOYjzm+UgYPJeoMNppDjdDlRGQISE7qzd4g==}
+ engines: {node: '>=14.0.0'}
+ cpu: [x64]
+ os: [win32]
+
+ sass-embedded@1.83.1:
+ resolution: {integrity: sha512-LdKG6nxLEzpXbMUt0if12PhUNonGvy91n7IWHOZRZjvA6AWm9oVdhpO+KEXN/Sc+jjGvQeQcav9+Z8DwmII/pA==}
+ engines: {node: '>=16.0.0'}
hasBin: true
- dependencies:
- chokidar: 3.6.0
- immutable: 4.3.5
- source-map-js: 1.2.0
- dev: false
- /sax@1.3.0:
- resolution: {integrity: sha512-0s+oAmw9zLl1V1cS9BtZN7JAd0cW5e0QH4W3LWEK6a4LaLEA2OTpGYWDY+6XasBLtz6wkm3u1xRw95mRuJ59WA==}
- dev: false
+ sax@1.4.1:
+ resolution: {integrity: sha512-+aWOz7yVScEGoKNd4PA10LZ8sk0A/z5+nXQG5giUO5rprX9jgYsTdov9qCchZiPIZezbZH+jRut8nPodFAX4Jg==}
- /section-matter@1.0.0:
+ section-matter@1.0.0:
resolution: {integrity: sha512-vfD3pmTzGpufjScBh50YHKzEu2lxBWhVEHsNGoEXmCmn2hKGfeNLYMzCJpe8cD7gqX7TJluOVpBkAequ6dgMmA==}
engines: {node: '>=4'}
- dependencies:
- extend-shallow: 2.0.1
- kind-of: 6.0.3
- dev: false
- /semver@6.3.1:
+ semver@6.3.1:
resolution: {integrity: sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==}
hasBin: true
- dev: false
- /semver@7.6.0:
- resolution: {integrity: sha512-EnwXhrlwXMk9gKu5/flx5sv/an57AkRplG3hTK68W7FRDN+k+OWBj65M7719OkA82XLBxrcX0KSHj+X5COhOVg==}
+ semver@7.6.3:
+ resolution: {integrity: sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==}
engines: {node: '>=10'}
hasBin: true
- dependencies:
- lru-cache: 6.0.0
- dev: false
- /set-blocking@2.0.0:
+ set-blocking@2.0.0:
resolution: {integrity: sha512-KiKBS8AnWGEyLzofFfmvKwpdPzqiy16LvQfK3yv/fVH7Bj13/wl3JSR1J+rfgRE9q7xUJK4qvgS8raSOeLUehw==}
- dev: false
- /shebang-command@2.0.0:
+ shebang-command@2.0.0:
resolution: {integrity: sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==}
engines: {node: '>=8'}
- dependencies:
- shebang-regex: 3.0.0
- dev: false
- /shebang-regex@3.0.0:
+ shebang-regex@3.0.0:
resolution: {integrity: sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==}
engines: {node: '>=8'}
- dev: false
- /signal-exit@3.0.7:
+ shiki@1.26.2:
+ resolution: {integrity: sha512-iP7u2NA9A6JwRRCkIUREEX2cMhlYV5EBmbbSlfSRvPThwca8HBRbVkWuNWW+kw9+i6BSUZqqG6YeUs5dC2SjZw==}
+
+ signal-exit@3.0.7:
resolution: {integrity: sha512-wnD2ZE+l+SPC/uoS0vXeE9L1+0wuaMqKlfz9AMUo38JsyLSBWSFcHR1Rri62LZc12vLr1gb3jl7iwQhgwpAbGQ==}
- dev: false
- /signal-exit@4.1.0:
+ signal-exit@4.1.0:
resolution: {integrity: sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==}
engines: {node: '>=14'}
- dev: false
- /sitemap@7.1.1:
- resolution: {integrity: sha512-mK3aFtjz4VdJN0igpIJrinf3EO8U8mxOPsTBzSsy06UtjZQJ3YY3o3Xa7zSc5nMqcMrRwlChHZ18Kxg0caiPBg==}
- engines: {node: '>=12.0.0', npm: '>=5.6.0'}
+ sitemap@8.0.0:
+ resolution: {integrity: sha512-+AbdxhM9kJsHtruUF39bwS/B0Fytw6Fr1o4ZAIAEqA6cke2xcoO2GleBw9Zw7nRzILVEgz7zBM5GiTJjie1G9A==}
+ engines: {node: '>=14.0.0', npm: '>=6.0.0'}
hasBin: true
- dependencies:
- '@types/node': 17.0.45
- '@types/sax': 1.2.7
- arg: 5.0.2
- sax: 1.3.0
- dev: false
- /slash@5.1.0:
+ slash@5.1.0:
resolution: {integrity: sha512-ZA6oR3T/pEyuqwMgAKT0/hAv8oAXckzbkmR0UkUosQ+Mc4RxGoJkRmwHgHufaenlyAgE1Mxgpdcrf75y6XcnDg==}
engines: {node: '>=14.16'}
- dev: false
- /smart-buffer@4.2.0:
+ smart-buffer@4.2.0:
resolution: {integrity: sha512-94hK0Hh8rPqQl2xXc3HsaBoOXKV20MToPkcXvwbISWLEs+64sBq5kFgn2kJDHb1Pry9yrP0dxrCI9RRci7RXKg==}
engines: {node: '>= 6.0.0', npm: '>= 3.0.0'}
- dev: false
- /socks-proxy-agent@8.0.3:
- resolution: {integrity: sha512-VNegTZKhuGq5vSD6XNKlbqWhyt/40CgoEw8XxD6dhnm8Jq9IEa3nIa4HwnM8XOqU0CdB0BwWVXusqiFXfHB3+A==}
+ socks-proxy-agent@8.0.5:
+ resolution: {integrity: sha512-HehCEsotFqbPW9sJ8WVYB6UbmIMv7kUUORIF2Nncq4VQvBfNBLibW9YZR5dlYCSUhwcD628pRllm7n+E+YTzJw==}
engines: {node: '>= 14'}
- dependencies:
- agent-base: 7.1.1
- debug: 4.3.4
- socks: 2.8.1
- transitivePeerDependencies:
- - supports-color
- dev: false
- /socks@2.8.1:
- resolution: {integrity: sha512-B6w7tkwNid7ToxjZ08rQMT8M9BJAf8DKx8Ft4NivzH0zBUfd6jldGcisJn/RLgxcX3FPNDdNQCUEMMT79b+oCQ==}
+ socks@2.8.3:
+ resolution: {integrity: sha512-l5x7VUUWbjVFbafGLxPWkYsHIhEvmF85tbIeFZWc8ZPtoMyybuEhL7Jye/ooC4/d48FgOjSJXgsF/AJPYCW8Zw==}
engines: {node: '>= 10.0.0', npm: '>= 3.0.0'}
- dependencies:
- ip-address: 9.0.5
- smart-buffer: 4.2.0
- dev: false
- /source-map-js@1.2.0:
- resolution: {integrity: sha512-itJW8lvSA0TXEphiRoawsCksnlf8SyvmFzIhltqAHluXd88pkCd+cXJVHTDwdCr0IzwptSm035IHQktUu1QUMg==}
+ source-map-js@1.2.1:
+ resolution: {integrity: sha512-UXWMKhLOwVKb728IUtQPXxfYU+usdybtUrK/8uGE8CQMvrhOpwvzDBwj0QhSL7MQc7vIsISBG8VQ8+IDQxpfQA==}
engines: {node: '>=0.10.0'}
- dev: false
- /speech-rule-engine@4.0.7:
- resolution: {integrity: sha512-sJrL3/wHzNwJRLBdf6CjJWIlxC04iYKkyXvYSVsWVOiC2DSkHmxsqOhEeMsBA9XK+CHuNcsdkbFDnoUfAsmp9g==}
- hasBin: true
- dependencies:
- commander: 9.2.0
- wicked-good-xpath: 1.3.0
- xmldom-sre: 0.1.31
- dev: false
+ space-separated-tokens@2.0.2:
+ resolution: {integrity: sha512-PEGlAwrG8yXGXRjW32fGbg66JAlOAwbObuqVoJpv/mRgoWDQfgH1wDPvtzWyUSNAXBGSk8h755YDbbcEy3SH2Q==}
+
+ speakingurl@14.0.1:
+ resolution: {integrity: sha512-1POYv7uv2gXoyGFpBCmpDVSNV74IfsWlDW216UPjbWufNf+bSU6GdbDsxdcxtfwb4xlI3yxzOTKClUosxARYrQ==}
+ engines: {node: '>=0.10.0'}
+
+ speech-rule-engine@4.0.7:
+ resolution: {integrity: sha512-sJrL3/wHzNwJRLBdf6CjJWIlxC04iYKkyXvYSVsWVOiC2DSkHmxsqOhEeMsBA9XK+CHuNcsdkbFDnoUfAsmp9g==}
+ hasBin: true
- /sprintf-js@1.0.3:
+ sprintf-js@1.0.3:
resolution: {integrity: sha512-D9cPgkvLlV3t3IzL0D0YLvGA9Ahk4PcvVwUbN0dSGr1aP0Nrt4AEnTUbuGvquEC0mA64Gqt1fzirlRs5ibXx8g==}
- dev: false
- /sprintf-js@1.1.3:
+ sprintf-js@1.1.3:
resolution: {integrity: sha512-Oo+0REFV59/rz3gfJNKQiBlwfHaSESl1pcGyABQsnnIfWOFt6JNj5gCog2U6MLZ//IGYD+nA8nI+mTShREReaA==}
- dev: false
- /ssri@10.0.5:
- resolution: {integrity: sha512-bSf16tAFkGeRlUNDjXu8FzaMQt6g2HZJrun7mtMbIPOddxt3GLMSz5VWUWcqTJUPfLEaDIepGxv+bYQW49596A==}
+ ssri@10.0.6:
+ resolution: {integrity: sha512-MGrFH9Z4NP9Iyhqn16sDtBpRRNJ0Y2hNa6D65h736fVSaPCHr4DM4sWUNvVaSuC+0OBGhwsrydQwmgfg5LncqQ==}
engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
- dependencies:
- minipass: 7.0.4
- dev: false
- /stdin-discarder@0.2.2:
+ stdin-discarder@0.2.2:
resolution: {integrity: sha512-UhDfHmA92YAlNnCfhmq0VeNL5bDbiZGg7sZ2IvPsXubGkiNa9EC+tUTsjBRsYUAz87btI6/1wf4XoVvQ3uRnmQ==}
engines: {node: '>=18'}
- dev: false
- /string-width@4.2.3:
+ string-width@4.2.3:
resolution: {integrity: sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==}
engines: {node: '>=8'}
- dependencies:
- emoji-regex: 8.0.0
- is-fullwidth-code-point: 3.0.0
- strip-ansi: 6.0.1
- dev: false
- /string-width@5.1.2:
+ string-width@5.1.2:
resolution: {integrity: sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==}
engines: {node: '>=12'}
- dependencies:
- eastasianwidth: 0.2.0
- emoji-regex: 9.2.2
- strip-ansi: 7.1.0
- dev: false
- /string-width@7.1.0:
- resolution: {integrity: sha512-SEIJCWiX7Kg4c129n48aDRwLbFb2LJmXXFrWBG4NGaRtMQ3myKPKbwrD1BKqQn74oCoNMBVrfDEr5M9YxCsrkw==}
+ string-width@7.2.0:
+ resolution: {integrity: sha512-tsaTIkKW9b4N+AEj+SVA+WhJzV7/zMhcSu78mLKWSk7cXMOSHsBKFWUs0fWwq8QyK3MgJBQRX6Gbi4kYbdvGkQ==}
engines: {node: '>=18'}
- dependencies:
- emoji-regex: 10.3.0
- get-east-asian-width: 1.2.0
- strip-ansi: 7.1.0
- dev: false
- /string_decoder@1.3.0:
+ string_decoder@1.3.0:
resolution: {integrity: sha512-hkRX8U1WjJFd8LsDJ2yQ/wWWxaopEsABU1XfkM8A+j0+85JAGppt16cr1Whg6KIbb4okU6Mql6BOj+uup/wKeA==}
- dependencies:
- safe-buffer: 5.2.1
- dev: false
- /strip-ansi@6.0.1:
+ stringify-entities@4.0.4:
+ resolution: {integrity: sha512-IwfBptatlO+QCJUo19AqvrPNqlVMpW9YEL2LIVY+Rpv2qsjCGxaDLNRgeGsQWJhfItebuJhsGSLjaBbNSQ+ieg==}
+
+ strip-ansi@6.0.1:
resolution: {integrity: sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==}
engines: {node: '>=8'}
- dependencies:
- ansi-regex: 5.0.1
- dev: false
- /strip-ansi@7.1.0:
+ strip-ansi@7.1.0:
resolution: {integrity: sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==}
engines: {node: '>=12'}
- dependencies:
- ansi-regex: 6.0.1
- dev: false
- /strip-bom-string@1.0.0:
+ strip-bom-string@1.0.0:
resolution: {integrity: sha512-uCC2VHvQRYu+lMh4My/sFNmF2klFymLX1wHJeXnbEJERpV/ZsVuonzerjfrGpIGF7LBVa1O7i9kjiWvJiFck8g==}
engines: {node: '>=0.10.0'}
- dev: false
- /strip-final-newline@3.0.0:
- resolution: {integrity: sha512-dOESqjYr96iWYylGObzd39EuNTa5VJxyvVAEm5Jnh7KGo75V43Hk1odPQkNDyXNmUR6k+gEiDVXnjB8HJ3crXw==}
- engines: {node: '>=12'}
- dev: false
+ strip-final-newline@4.0.0:
+ resolution: {integrity: sha512-aulFJcD6YK8V1G7iRB5tigAP4TsHBZZrOV8pjV++zdUwmeV8uzbY7yn6h9MswN62adStNZFuCIx4haBnRuMDaw==}
+ engines: {node: '>=18'}
- /tar@6.2.1:
- resolution: {integrity: sha512-DZ4yORTwrbTj/7MZYq2w+/ZFdI6OZ/f9SFHR+71gIVUZhOQPHzVCLpvRnPgyaMpfWxxk/4ONva3GQSyNIKRv6A==}
+ superjson@2.2.2:
+ resolution: {integrity: sha512-5JRxVqC8I8NuOUjzBbvVJAKNM8qoVuH0O77h4WInc/qC2q5IreqKxYwgkga3PfA22OayK2ikceb/B26dztPl+Q==}
+ engines: {node: '>=16'}
+
+ supports-color@8.1.1:
+ resolution: {integrity: sha512-MpUEN2OodtUzxvKQl72cUF7RQ5EiHsGvSsVG0ia9c5RbWGL2CI4C7EpPS8UTBIplnlzZiNuV56w+FuNxy3ty2Q==}
engines: {node: '>=10'}
- dependencies:
- chownr: 2.0.0
- fs-minipass: 2.1.0
- minipass: 5.0.0
- minizlib: 2.1.2
- mkdirp: 1.0.4
- yallist: 4.0.0
- dev: false
- /to-fast-properties@2.0.0:
- resolution: {integrity: sha512-/OaKK0xYrs3DmxRYqL/yDc+FxFUVYhDlXMhRmv3z915w2HF1tnN1omB354j8VUGO/hbRzyD6Y3sA7v7GS/ceog==}
- engines: {node: '>=4'}
- dev: false
+ sync-child-process@1.0.2:
+ resolution: {integrity: sha512-8lD+t2KrrScJ/7KXCSyfhT3/hRq78rC0wBFqNJXv3mZyn6hW2ypM05JmlSvtqRbeq6jqA94oHbxAr2vYsJ8vDA==}
+ engines: {node: '>=16.0.0'}
+
+ sync-message-port@1.1.3:
+ resolution: {integrity: sha512-GTt8rSKje5FilG+wEdfCkOcLL7LWqpMlr2c3LRuKt/YXxcJ52aGSbGBAdI4L3aaqfrBt6y711El53ItyH1NWzg==}
+ engines: {node: '>=16.0.0'}
- /to-regex-range@5.0.1:
+ tar@6.2.1:
+ resolution: {integrity: sha512-DZ4yORTwrbTj/7MZYq2w+/ZFdI6OZ/f9SFHR+71gIVUZhOQPHzVCLpvRnPgyaMpfWxxk/4ONva3GQSyNIKRv6A==}
+ engines: {node: '>=10'}
+
+ to-regex-range@5.0.1:
resolution: {integrity: sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==}
engines: {node: '>=8.0'}
- dependencies:
- is-number: 7.0.0
- dev: false
- /tr46@0.0.3:
+ tr46@0.0.3:
resolution: {integrity: sha512-N3WMsuqV66lT30CrXNbEjx4GEwlow3v6rr4mCcv6prnfwhS01rkgyFdjPNBYd9br7LpXV1+Emh01fHnq2Gdgrw==}
- dev: false
- /uc.micro@2.1.0:
+ trim-lines@3.0.1:
+ resolution: {integrity: sha512-kRj8B+YHZCc9kQYdWfJB2/oUl9rA99qbowYYBtr4ui4mZyAQ2JpvVBd/6U2YloATfqBhBTSMhTpgBHtU0Mf3Rg==}
+
+ tslib@2.8.1:
+ resolution: {integrity: sha512-oJFu94HQb+KVduSUQL7wnpmqnfmLsOA/nAh6b6EH0wCEoK0/mPeXU6c3wKDV83MkOuHPRHtSXKKU99IBazS/2w==}
+
+ uc.micro@2.1.0:
resolution: {integrity: sha512-ARDJmphmdvUk6Glw7y9DQ2bFkKBHwQHLi2lsaH6PPmz/Ka9sFOBsBluozhDltWmnv9u/cF6Rt87znRTPV+yp/A==}
- dev: false
- /undici-types@5.26.5:
- resolution: {integrity: sha512-JlCMO+ehdEIKqlFxk6IfVoAUVmgz7cU7zD/h9XZ0qzeosSHmUJVOzSQvvYSYWXkFXC+IfLKSIffhv0sVZup6pA==}
- dev: false
+ undici-types@6.20.0:
+ resolution: {integrity: sha512-Ny6QZ2Nju20vw1SRHe3d9jVu6gJ+4e3+MMpqu7pqE5HT6WsTSlce++GQmK5UXS8mzV8DSYHrQH+Xrf2jVcuKNg==}
+
+ undici@6.21.0:
+ resolution: {integrity: sha512-BUgJXc752Kou3oOIuU1i+yZZypyZRqNPW0vqoMPl8VaoalSfeR0D8/t4iAS3yirs79SSMTxTag+ZC86uswv+Cw==}
+ engines: {node: '>=18.17'}
- /unicorn-magic@0.1.0:
+ unicorn-magic@0.1.0:
resolution: {integrity: sha512-lRfVq8fE8gz6QMBuDM6a+LO3IAzTi05H6gCVaUpir2E1Rwpo4ZUog45KpNXKC/Mn3Yb9UDuHumeFTo9iV/D9FQ==}
engines: {node: '>=18'}
- dev: false
- /unique-filename@3.0.0:
+ unicorn-magic@0.3.0:
+ resolution: {integrity: sha512-+QBBXBCvifc56fsbuxZQ6Sic3wqqc3WWaqxs58gvJrcOuN83HGTCwz3oS5phzU9LthRNE9VrJCFCLUgHeeFnfA==}
+ engines: {node: '>=18'}
+
+ unique-filename@3.0.0:
resolution: {integrity: sha512-afXhuC55wkAmZ0P18QsVE6kp8JaxrEokN2HGIoIVv2ijHQd419H0+6EigAFcIzXeMIkcIkNBpB3L/DXB3cTS/g==}
engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
- dependencies:
- unique-slug: 4.0.0
- dev: false
- /unique-slug@4.0.0:
+ unique-slug@4.0.0:
resolution: {integrity: sha512-WrcA6AyEfqDX5bWige/4NQfPZMtASNVxdmWR76WESYQVAACSgWcR6e9i0mofqqBxYFtL4oAxPIptY73/0YE1DQ==}
engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
- dependencies:
- imurmurhash: 0.1.4
- dev: false
- /universalify@2.0.1:
+ unist-util-is@6.0.0:
+ resolution: {integrity: sha512-2qCTHimwdxLfz+YzdGfkqNlH0tLi9xjTnHddPmJwtIG9MGsdbutfTc4P+haPD7l7Cjxf/WZj+we5qfVPvvxfYw==}
+
+ unist-util-position@5.0.0:
+ resolution: {integrity: sha512-fucsC7HjXvkB5R3kTCO7kUjRdrS0BJt3M/FPxmHMBOm8JQi2BsHAHFsy27E0EolP8rp0NzXsJ+jNPyDWvOJZPA==}
+
+ unist-util-stringify-position@4.0.0:
+ resolution: {integrity: sha512-0ASV06AAoKCDkS2+xw5RXJywruurpbC4JZSm7nr7MOt1ojAzvyyaO+UxZf18j8FCF6kmzCZKcAgN/yu2gm2XgQ==}
+
+ unist-util-visit-parents@6.0.1:
+ resolution: {integrity: sha512-L/PqWzfTP9lzzEa6CKs0k2nARxTdZduw3zyh8d2NVBnsyvHjSX4TWse388YrrQKbvI8w20fGjGlhgT96WwKykw==}
+
+ unist-util-visit@5.0.0:
+ resolution: {integrity: sha512-MR04uvD+07cwl/yhVuVWAtw+3GOR/knlL55Nd/wAdblk27GCVt3lqpTivy/tkJcZoNPzTwS1Y+KMojlLDhoTzg==}
+
+ universalify@2.0.1:
resolution: {integrity: sha512-gptHNQghINnc/vTGIk0SOFGFNXw7JVrlRUtConJRlvaw6DuX0wO5Jeko9sWrMBhh+PsYAZ7oXAiOnf/UKogyiw==}
engines: {node: '>= 10.0.0'}
- dev: false
- /upath@2.0.1:
+ upath@2.0.1:
resolution: {integrity: sha512-1uEe95xksV1O0CYKXo8vQvN1JEbtJp7lb7C5U9HMsIp6IVwntkH/oNUzyVNQSd4S1sYk2FpSSW44FqMc8qee5w==}
engines: {node: '>=4'}
- dev: false
- /update-browserslist-db@1.0.13(browserslist@4.23.0):
- resolution: {integrity: sha512-xebP81SNcPuNpPP3uzeW1NYXxI3rxyJzF3pD6sH4jE7o/IX+WtSpwnVU+qIsDPyk0d3hmFQ7mjqc6AtV604hbg==}
+ update-browserslist-db@1.1.2:
+ resolution: {integrity: sha512-PPypAm5qvlD7XMZC3BujecnaOxwhrtoFR+Dqkk5Aa/6DssiH0ibKoketaj9w8LP7Bont1rYeoV5plxD7RTEPRg==}
hasBin: true
peerDependencies:
browserslist: '>= 4.21.0'
- dependencies:
- browserslist: 4.23.0
- escalade: 3.1.2
- picocolors: 1.0.0
- dev: false
- /util-deprecate@1.0.2:
+ util-deprecate@1.0.2:
resolution: {integrity: sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==}
- dev: false
- /vite@5.2.7:
- resolution: {integrity: sha512-k14PWOKLI6pMaSzAuGtT+Cf0YmIx12z9YGon39onaJNy8DLBfBJrzg9FQEmkAM5lpHBZs9wksWAsyF/HkpEwJA==}
- engines: {node: ^18.0.0 || >=20.0.0}
+ varint@6.0.0:
+ resolution: {integrity: sha512-cXEIW6cfr15lFv563k4GuVuW/fiwjknytD37jIOLSdSWuOI6WnO/oKwmP2FQTU2l01LP8/M5TSAJpzUaGe3uWg==}
+
+ vfile-message@4.0.2:
+ resolution: {integrity: sha512-jRDZ1IMLttGj41KcZvlrYAaI3CfqpLpfpf+Mfig13viT6NKvRzWZ+lXz0Y5D60w6uJIBAOGq9mSHf0gktF0duw==}
+
+ vfile@6.0.3:
+ resolution: {integrity: sha512-KzIbH/9tXat2u30jf+smMwFCsno4wHVdNmzFyL+T/L3UGqqk6JKfVqOFOZEpZSHADH1k40ab6NUIXZq422ov3Q==}
+
+ vite@6.0.7:
+ resolution: {integrity: sha512-RDt8r/7qx9940f8FcOIAH9PTViRrghKaK2K1jY3RaAURrEUbm9Du1mJ72G+jlhtG3WwodnfzY8ORQZbBavZEAQ==}
+ engines: {node: ^18.0.0 || ^20.0.0 || >=22.0.0}
hasBin: true
peerDependencies:
- '@types/node': ^18.0.0 || >=20.0.0
+ '@types/node': ^18.0.0 || ^20.0.0 || >=22.0.0
+ jiti: '>=1.21.0'
less: '*'
lightningcss: ^1.21.0
sass: '*'
+ sass-embedded: '*'
stylus: '*'
sugarss: '*'
- terser: ^5.4.0
+ terser: ^5.16.0
+ tsx: ^4.8.1
+ yaml: ^2.4.2
peerDependenciesMeta:
'@types/node':
optional: true
+ jiti:
+ optional: true
less:
optional: true
lightningcss:
optional: true
sass:
optional: true
+ sass-embedded:
+ optional: true
stylus:
optional: true
sugarss:
optional: true
terser:
optional: true
- dependencies:
- esbuild: 0.20.2
- postcss: 8.4.38
- rollup: 4.13.2
- optionalDependencies:
- fsevents: 2.3.3
- dev: false
-
- /vue-demi@0.14.7(vue@3.4.21):
- resolution: {integrity: sha512-EOG8KXDQNwkJILkx/gPcoL/7vH+hORoBaKgGe+6W7VFMvCYJfmF2dGbvgDroVnI8LU7/kTu8mbjRZGBU1z9NTA==}
- engines: {node: '>=12'}
- hasBin: true
- requiresBuild: true
- peerDependencies:
- '@vue/composition-api': ^1.0.0-rc.1
- vue: ^3.0.0-0 || ^2.6.0
- peerDependenciesMeta:
- '@vue/composition-api':
+ tsx:
+ optional: true
+ yaml:
optional: true
- dependencies:
- vue: 3.4.21
- dev: false
- /vue-router@4.3.0(vue@3.4.21):
- resolution: {integrity: sha512-dqUcs8tUeG+ssgWhcPbjHvazML16Oga5w34uCUmsk7i0BcnskoLGwjpa15fqMr2Fa5JgVBrdL2MEgqz6XZ/6IQ==}
+ vue-router@4.5.0:
+ resolution: {integrity: sha512-HDuk+PuH5monfNuY+ct49mNmkCRK4xJAV9Ts4z9UFc4rzdDnxQLyCMGGc8pKhZhHTVzfanpNwB/lwqevcBwI4w==}
peerDependencies:
vue: ^3.2.0
- dependencies:
- '@vue/devtools-api': 6.6.1
- vue: 3.4.21
- dev: false
- /vue@3.4.21:
- resolution: {integrity: sha512-5hjyV/jLEIKD/jYl4cavMcnzKwjMKohureP8ejn3hhEjwhWIhWeuzL2kJAjzl/WyVsgPY56Sy4Z40C3lVshxXA==}
+ vue@3.5.13:
+ resolution: {integrity: sha512-wmeiSMxkZCSc+PM2w2VRsOYAZC8GdipNFRTsLSfodVqI9mbejKeXEGr8SckuLnrQPGe3oJN5c3K0vpoU9q/wCQ==}
peerDependencies:
typescript: '*'
peerDependenciesMeta:
typescript:
optional: true
- dependencies:
- '@vue/compiler-dom': 3.4.21
- '@vue/compiler-sfc': 3.4.21
- '@vue/runtime-dom': 3.4.21
- '@vue/server-renderer': 3.4.21(vue@3.4.21)
- '@vue/shared': 3.4.21
- dev: false
- /vuepress-plugin-components@2.0.0-rc.32(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-ndu3lXnmS3AzYwqXn+mTJNItXux0MiPj2BzE8uH5HL473uAtzE8nS3q0gvcAt8CNbOSElJt+I5Hz4AO8/hbtAA==}
- engines: {node: '>=18.16.0', npm: '>=8', pnpm: '>=7', yarn: '>=2'}
+ vuepress-plugin-components@2.0.0-rc.68:
+ resolution: {integrity: sha512-JGll1AC40jMSvOlWNQUUN+ZTBFqgoOmuf2QAVWMPY3+D0a9xlBMxSsrK7Rvn0JrE+0txHyOlGJMNUT+f3/OMZQ==}
+ engines: {node: '>=18.19.0', npm: '>=8', pnpm: '>=7', yarn: '>=2'}
peerDependencies:
artplayer: ^5.0.0
dashjs: 4.7.4
hls.js: ^1.4.12
mpegts.js: ^1.7.3
- plyr: ^3.7.8
- sass-loader: ^14.0.0
- vidstack: ^1.9.0
- vuepress: 2.0.0-rc.9
+ sass: ^1.81.0
+ sass-embedded: ^1.81.0
+ sass-loader: ^16.0.2
+ vidstack: ^1.12.9
+ vuepress: 2.0.0-rc.19
peerDependenciesMeta:
artplayer:
optional: true
@@ -3447,51 +2679,34 @@ packages:
optional: true
mpegts.js:
optional: true
- plyr:
+ sass:
+ optional: true
+ sass-embedded:
optional: true
sass-loader:
optional: true
vidstack:
optional: true
- dependencies:
- '@stackblitz/sdk': 1.9.0
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vueuse/core': 10.9.0(vue@3.4.21)
- balloon-css: 1.2.0
- create-codepen: 1.0.1
- qrcode: 1.5.3
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- vuepress-plugin-sass-palette: 2.0.0-rc.32(vuepress@2.0.0-rc.9)
- vuepress-shared: 2.0.0-rc.32(vuepress@2.0.0-rc.9)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - typescript
- dev: false
- /vuepress-plugin-md-enhance@2.0.0-rc.32(markdown-it@14.1.0)(mathjax-full@3.2.2)(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-zZK8aEfbq26J5w8o9xGWXCHHrL3PYk25tloTPcx96nZWYPeD+5fMFAtVpHte0rXBWUf0MBtDQxddSeATteBE7Q==}
- engines: {node: '>=18.16.0', npm: '>=8', pnpm: '>=7', yarn: '>=2'}
+ vuepress-plugin-md-enhance@2.0.0-rc.68:
+ resolution: {integrity: sha512-fi0bkKIEAFihOqBDAYmrQRPImXhfRdx5mi2blX/lvSl7vCun+FZV6NHz8mvGQNh0DcT6vn5ksCNjyih7lkrtEw==}
+ engines: {node: '>=18.19.0', npm: '>=8', pnpm: '>=7', yarn: '>=2'}
peerDependencies:
- '@types/reveal.js': ^5.0.0
'@vue/repl': ^4.1.1
chart.js: ^4.0.0
echarts: ^5.0.0
- flowchart.ts: ^2.0.0 || ^3.0.0
- katex: ^0.16.0
+ flowchart.ts: ^3.0.0
kotlin-playground: ^1.23.0
- markmap-lib: ^0.15.5 || ^0.16.0
- markmap-toolbar: ^0.15.5 || ^0.16.0
- markmap-view: ^0.15.5 || ^0.16.0
- mathjax-full: ^3.2.2
- mermaid: ^10.8.0
- reveal.js: ^5.0.0
+ markmap-lib: ^0.18.5
+ markmap-toolbar: ^0.18.5
+ markmap-view: ^0.18.5
+ mermaid: ^11.2.0
sandpack-vue3: ^3.0.0
- sass-loader: ^14.0.0
- vuepress: 2.0.0-rc.9
+ sass: ^1.81.0
+ sass-embedded: ^1.81.0
+ sass-loader: ^16.0.2
+ vuepress: 2.0.0-rc.19
peerDependenciesMeta:
- '@types/reveal.js':
- optional: true
'@vue/repl':
optional: true
chart.js:
@@ -3500,8 +2715,6 @@ packages:
optional: true
flowchart.ts:
optional: true
- katex:
- optional: true
kotlin-playground:
optional: true
markmap-lib:
@@ -3510,340 +2723,3235 @@ packages:
optional: true
markmap-view:
optional: true
- mathjax-full:
- optional: true
mermaid:
optional: true
- reveal.js:
- optional: true
sandpack-vue3:
optional: true
+ sass:
+ optional: true
+ sass-embedded:
+ optional: true
sass-loader:
optional: true
- dependencies:
- '@mdit/plugin-alert': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-align': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-attrs': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-container': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-demo': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-figure': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-footnote': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-img-lazyload': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-img-mark': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-img-size': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-include': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-katex': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-mark': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-mathjax': 0.8.0(markdown-it@14.1.0)(mathjax-full@3.2.2)
- '@mdit/plugin-stylize': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-sub': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-sup': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-tab': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-tasklist': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-tex': 0.8.0(markdown-it@14.1.0)
- '@mdit/plugin-uml': 0.8.0(markdown-it@14.1.0)
- '@types/markdown-it': 13.0.7
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vueuse/core': 10.9.0(vue@3.4.21)
- balloon-css: 1.2.0
- js-yaml: 4.1.0
- mathjax-full: 3.2.2
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- vuepress-plugin-sass-palette: 2.0.0-rc.32(vuepress@2.0.0-rc.9)
- vuepress-shared: 2.0.0-rc.32(vuepress@2.0.0-rc.9)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - markdown-it
- - typescript
- dev: false
- /vuepress-plugin-sass-palette@2.0.0-rc.32(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-3tHHQU1E5cCo/udiZ4t0PL6OrWMxuP67+/tj3U5R9Zls6zM1aNE+Dw8I6/Of+HRTzctsQFxGPH0lZa05gS49UQ==}
- engines: {node: '>=18.16.0', npm: '>=8', pnpm: '>=7', yarn: '>=2'}
+ vuepress-shared@2.0.0-rc.68:
+ resolution: {integrity: sha512-wqKktaUUvEC6qMWNXuYo7uh5oEzYLhd7sY3ACvj+nu5JgXgQdk0sVoTN3vMp6PmVFmINjJfJB1zzn778hcOFGA==}
+ engines: {node: '>=18.19.0', npm: '>=8', pnpm: '>=7', yarn: '>=2'}
peerDependencies:
- sass-loader: ^14.0.0
- vuepress: 2.0.0-rc.9
- peerDependenciesMeta:
- sass-loader:
- optional: true
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- chokidar: 3.6.0
- sass: 1.72.0
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- vuepress-shared: 2.0.0-rc.32(vuepress@2.0.0-rc.9)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - typescript
- dev: false
+ vuepress: 2.0.0-rc.19
- /vuepress-shared@2.0.0-rc.32(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-wGPPUoP6rxy7QnulD0sNz3r7iEHwp+TJroNmI+AT6FuCo1WCD4ZWfnRnm3dVcAkobc3nuOvSmDTvM9pIDCaxsA==}
- engines: {node: '>=18.16.0', npm: '>=8', pnpm: '>=7', yarn: '>=2'}
+ vuepress-theme-hope@2.0.0-rc.68:
+ resolution: {integrity: sha512-4mMq/VACqkFZx/5gGp+5QnH9p3GYroj75rU7LGIuTIc1hCrsQMfdM/HTvfvoRnBoWUedT+KEAy17Z9ThNOSyDQ==}
+ engines: {node: '>=18.19.0', npm: '>=8', pnpm: '>=7', yarn: '>=2'}
peerDependencies:
- vuepress: 2.0.0-rc.9
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vueuse/core': 10.9.0(vue@3.4.21)
- cheerio: 1.0.0-rc.12
- dayjs: 1.11.10
- execa: 8.0.1
- fflate: 0.8.2
- gray-matter: 4.0.3
- semver: 7.6.0
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- transitivePeerDependencies:
- - '@vue/composition-api'
- - typescript
- dev: false
-
- /vuepress-theme-hope@2.0.0-rc.32(@vuepress/plugin-feed@2.0.0-rc.21)(@vuepress/plugin-search@2.0.0-rc.21)(markdown-it@14.1.0)(mathjax-full@3.2.2)(nodejs-jieba@0.1.2)(vuepress@2.0.0-rc.9):
- resolution: {integrity: sha512-5S5qg5xa0TErqVjpubhBN5oy0QmROd+ja5EQKfORUCKdXKQvx0soojQZnCPkXsUEXonwiZ12oCLN2+UGO03eng==}
- engines: {node: '>=18.16.0', npm: '>=8', pnpm: '>=7', yarn: '>=2'}
- peerDependencies:
- '@vuepress/plugin-docsearch': 2.0.0-rc.21
- '@vuepress/plugin-feed': 2.0.0-rc.21
- '@vuepress/plugin-pwa': 2.0.0-rc.21
- '@vuepress/plugin-redirect': 2.0.0-rc.21
- '@vuepress/plugin-search': 2.0.0-rc.21
- nodejs-jieba: ^0.1.2
- sass-loader: ^14.0.0
- vuepress: 2.0.0-rc.9
- vuepress-plugin-search-pro: 2.0.0-rc.32
+ '@vuepress/plugin-docsearch': 2.0.0-rc.70
+ '@vuepress/plugin-feed': 2.0.0-rc.70
+ '@vuepress/plugin-prismjs': 2.0.0-rc.70
+ '@vuepress/plugin-pwa': 2.0.0-rc.70
+ '@vuepress/plugin-revealjs': 2.0.0-rc.70
+ '@vuepress/plugin-search': 2.0.0-rc.70
+ '@vuepress/plugin-slimsearch': 2.0.0-rc.70
+ '@vuepress/plugin-watermark': 2.0.0-rc.70
+ nodejs-jieba: ^0.2.1
+ sass: ^1.81.0
+ sass-embedded: ^1.81.0
+ sass-loader: ^16.0.2
+ vuepress: 2.0.0-rc.19
peerDependenciesMeta:
'@vuepress/plugin-docsearch':
optional: true
'@vuepress/plugin-feed':
optional: true
+ '@vuepress/plugin-prismjs':
+ optional: true
'@vuepress/plugin-pwa':
optional: true
- '@vuepress/plugin-redirect':
+ '@vuepress/plugin-revealjs':
optional: true
'@vuepress/plugin-search':
optional: true
+ '@vuepress/plugin-slimsearch':
+ optional: true
+ '@vuepress/plugin-watermark':
+ optional: true
nodejs-jieba:
optional: true
+ sass:
+ optional: true
+ sass-embedded:
+ optional: true
sass-loader:
optional: true
- vuepress-plugin-search-pro:
- optional: true
- dependencies:
- '@vuepress/helper': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-active-header-links': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-back-to-top': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-blog': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-catalog': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-comment': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-copy-code': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-copyright': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-external-link-icon': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-feed': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-git': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-links-check': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-nprogress': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-photo-swipe': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-prismjs': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-reading-time': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-rtl': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-search': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-seo': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-sitemap': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vuepress/plugin-theme-data': 2.0.0-rc.21(vuepress@2.0.0-rc.9)
- '@vueuse/core': 10.9.0(vue@3.4.21)
- balloon-css: 1.2.0
- bcrypt-ts: 5.0.2
- cheerio: 1.0.0-rc.12
- chokidar: 3.6.0
- gray-matter: 4.0.3
- nodejs-jieba: 0.1.2
- vue: 3.4.21
- vuepress: 2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21)
- vuepress-plugin-components: 2.0.0-rc.32(vuepress@2.0.0-rc.9)
- vuepress-plugin-md-enhance: 2.0.0-rc.32(markdown-it@14.1.0)(mathjax-full@3.2.2)(vuepress@2.0.0-rc.9)
- vuepress-plugin-sass-palette: 2.0.0-rc.32(vuepress@2.0.0-rc.9)
- vuepress-shared: 2.0.0-rc.32(vuepress@2.0.0-rc.9)
- transitivePeerDependencies:
- - '@types/reveal.js'
- - '@vue/composition-api'
- - '@vue/repl'
- - '@waline/client'
- - artalk
- - artplayer
- - chart.js
- - dashjs
- - echarts
- - flowchart.ts
- - hls.js
- - katex
- - kotlin-playground
- - markdown-it
- - markmap-lib
- - markmap-toolbar
- - markmap-view
- - mathjax-full
- - mermaid
- - mpegts.js
- - plyr
- - reveal.js
- - sandpack-vue3
- - twikoo
- - typescript
- - vidstack
- dev: false
- /vuepress@2.0.0-rc.9(@vuepress/bundler-vite@2.0.0-rc.9)(vue@3.4.21):
- resolution: {integrity: sha512-jT1ln2lawdph+vVI6n2JfEUhQIcyc1RQWDdQu9DffhJGywJunFcumnUJudpqd1SNIES2Fz1hVCD6gdrE/rVKOQ==}
- engines: {node: '>=18.16.0'}
+ vuepress@2.0.0-rc.19:
+ resolution: {integrity: sha512-JDeuPTu14Kprdqx2geAryjFJvUzVaMnOLewlAgwVuZTygDWb8cgXhu9/p6rqzzdHETtIrvjbASBhH7JPyqmxmA==}
+ engines: {node: ^18.19.0 || >=20.4.0}
hasBin: true
peerDependencies:
- '@vuepress/bundler-vite': 2.0.0-rc.9
- '@vuepress/bundler-webpack': 2.0.0-rc.9
- vue: ^3.4.0
+ '@vuepress/bundler-vite': 2.0.0-rc.19
+ '@vuepress/bundler-webpack': 2.0.0-rc.19
+ vue: ^3.5.0
peerDependenciesMeta:
'@vuepress/bundler-vite':
optional: true
'@vuepress/bundler-webpack':
optional: true
- dependencies:
- '@vuepress/bundler-vite': 2.0.0-rc.9
- '@vuepress/cli': 2.0.0-rc.9
- '@vuepress/client': 2.0.0-rc.9
- '@vuepress/core': 2.0.0-rc.9
- '@vuepress/markdown': 2.0.0-rc.9
- '@vuepress/shared': 2.0.0-rc.9
- '@vuepress/utils': 2.0.0-rc.9
- vue: 3.4.21
- transitivePeerDependencies:
- - supports-color
- - typescript
- dev: false
- /webidl-conversions@3.0.1:
+ webidl-conversions@3.0.1:
resolution: {integrity: sha512-2JAn3z8AR6rjK8Sm8orRC0h/bcl/DqL7tRPdGZ4I1CjdF+EaMLmYxBHyXuKL849eucPFhvBoxMsflfOb8kxaeQ==}
- dev: false
- /whatwg-url@5.0.0:
+ whatwg-encoding@3.1.1:
+ resolution: {integrity: sha512-6qN4hJdMwfYBtE3YBTTHhoeuUrDBPZmbQaxWAqSALV/MeEnR5z1xd8UKud2RAkFoPkmB+hli1TZSnyi84xz1vQ==}
+ engines: {node: '>=18'}
+
+ whatwg-mimetype@4.0.0:
+ resolution: {integrity: sha512-QaKxh0eNIi2mE9p2vEdzfagOKHCcj1pJ56EEHGQOVxp8r9/iszLUUV7v89x9O1p/T+NlTM5W7jW6+cz4Fq1YVg==}
+ engines: {node: '>=18'}
+
+ whatwg-url@5.0.0:
resolution: {integrity: sha512-saE57nupxk6v3HY35+jzBwYa0rKSy0XR8JSxZPwgLr7ys0IBzhGviA1/TUGJLmSVqs8pb9AnvICXEuOHLprYTw==}
- dependencies:
- tr46: 0.0.3
- webidl-conversions: 3.0.1
- dev: false
- /which-module@2.0.1:
+ which-module@2.0.1:
resolution: {integrity: sha512-iBdZ57RDvnOR9AGBhML2vFZf7h8vmBjhoaZqODJBFWHVtKkDmKuHai3cx5PgVMrX5YDNp27AofYbAwctSS+vhQ==}
- dev: false
- /which@2.0.2:
+ which@2.0.2:
resolution: {integrity: sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==}
engines: {node: '>= 8'}
hasBin: true
- dependencies:
- isexe: 2.0.0
- dev: false
- /which@4.0.0:
+ which@4.0.0:
resolution: {integrity: sha512-GlaYyEb07DPxYCKhKzplCWBJtvxZcZMrL+4UkrTSJHHPyZU4mYYTv3qaOe77H7EODLSSopAUFAc6W8U4yqvscg==}
engines: {node: ^16.13.0 || >=18.0.0}
hasBin: true
- dependencies:
- isexe: 3.1.1
- dev: false
- /wicked-good-xpath@1.3.0:
+ wicked-good-xpath@1.3.0:
resolution: {integrity: sha512-Gd9+TUn5nXdwj/hFsPVx5cuHHiF5Bwuc30jZ4+ronF1qHK5O7HD0sgmXWSEgwKquT3ClLoKPVbO6qGwVwLzvAw==}
- dev: false
- /wide-align@1.1.5:
+ wide-align@1.1.5:
resolution: {integrity: sha512-eDMORYaPNZ4sQIuuYPDHdQvf4gyCF9rEEV/yPxGfwPkRodwEgiMUUXTx/dex+Me0wxx53S+NgUHaP7y3MGlDmg==}
- dependencies:
- string-width: 4.2.3
- dev: false
- /wrap-ansi@6.2.0:
+ wrap-ansi@6.2.0:
resolution: {integrity: sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA==}
engines: {node: '>=8'}
- dependencies:
- ansi-styles: 4.3.0
- string-width: 4.2.3
- strip-ansi: 6.0.1
- dev: false
- /wrap-ansi@7.0.0:
+ wrap-ansi@7.0.0:
resolution: {integrity: sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==}
engines: {node: '>=10'}
- dependencies:
- ansi-styles: 4.3.0
- string-width: 4.2.3
- strip-ansi: 6.0.1
- dev: false
- /wrap-ansi@8.1.0:
+ wrap-ansi@8.1.0:
resolution: {integrity: sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ==}
engines: {node: '>=12'}
- dependencies:
- ansi-styles: 6.2.1
- string-width: 5.1.2
- strip-ansi: 7.1.0
- dev: false
- /wrappy@1.0.2:
+ wrappy@1.0.2:
resolution: {integrity: sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==}
- dev: false
- /xml-js@1.6.11:
+ xml-js@1.6.11:
resolution: {integrity: sha512-7rVi2KMfwfWFl+GpPg6m80IVMWXLRjO+PxTq7V2CDhoGak0wzYzFgUY2m4XJ47OGdXd8eLE8EmwfAmdjw7lC1g==}
hasBin: true
- dependencies:
- sax: 1.3.0
- dev: false
- /xmldom-sre@0.1.31:
+ xmldom-sre@0.1.31:
resolution: {integrity: sha512-f9s+fUkX04BxQf+7mMWAp5zk61pciie+fFLC9hX9UVvCeJQfNHRHXpeo5MPcR0EUf57PYLdt+ZO4f3Ipk2oZUw==}
engines: {node: '>=0.1'}
- dev: false
- /y18n@4.0.3:
+ y18n@4.0.3:
resolution: {integrity: sha512-JKhqTOwSrqNA1NY5lSztJ1GrBiUodLMmIZuLiDaMRJ+itFd+ABVE8XBjOvIWL+rSqNDC74LCSFmlb/U4UZ4hJQ==}
- dev: false
- /yallist@4.0.0:
+ yallist@4.0.0:
resolution: {integrity: sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==}
- dev: false
-
- /yaml@2.3.4:
- resolution: {integrity: sha512-8aAvwVUSHpfEqTQ4w/KMlf3HcRdt50E5ODIQJBw1fQ5RL34xabzxtUlzTXVqc4rkZsPbvrXKWnABCD7kWSmocA==}
- engines: {node: '>= 14'}
- dev: false
-
- /yaml@2.4.1:
- resolution: {integrity: sha512-pIXzoImaqmfOrL7teGUBt/T7ZDnyeGBWyXQBvOVhLkWLN37GXv8NMLK406UY6dS51JfcQHsmcW5cJ441bHg6Lg==}
- engines: {node: '>= 14'}
- hasBin: true
- dev: false
- /yargs-parser@18.1.3:
+ yargs-parser@18.1.3:
resolution: {integrity: sha512-o50j0JeToy/4K6OZcaQmW6lyXXKhq7csREXcDwk2omFPJEwUNOVtJKvmDr9EI1fAJZUyZcRF7kxGBWmRXudrCQ==}
engines: {node: '>=6'}
- dependencies:
- camelcase: 5.3.1
- decamelize: 1.2.0
- dev: false
- /yargs@15.4.1:
+ yargs@15.4.1:
resolution: {integrity: sha512-aePbxDmcYW++PaqBsJ+HYUFwCdv4LVvdnhBy78E57PIor8/OVvhMrADFFEDh8DHDFRv/O9i3lPhsENjO7QX0+A==}
engines: {node: '>=8'}
+
+ yoctocolors@2.1.1:
+ resolution: {integrity: sha512-GQHQqAopRhwU8Kt1DDM8NjibDXHC8eoh1erhGAJPEyveY9qqVeXvVikNKrDz69sHowPMorbPUrH/mx8c50eiBQ==}
+ engines: {node: '>=18'}
+
+ zwitch@2.0.4:
+ resolution: {integrity: sha512-bXE4cR/kVZhKZX/RjPEflHaKVhUVl85noU3v6b8apfQEc1x4A+zBxjZ4lN8LqGd6WZ3dl98pY4o717VFmoPp+A==}
+
+snapshots:
+
+ '@babel/helper-string-parser@7.25.9': {}
+
+ '@babel/helper-validator-identifier@7.25.9': {}
+
+ '@babel/parser@7.26.5':
dependencies:
- cliui: 6.0.0
- decamelize: 1.2.0
- find-up: 4.1.0
- get-caller-file: 2.0.5
- require-directory: 2.1.1
- require-main-filename: 2.0.0
- set-blocking: 2.0.0
- string-width: 4.2.3
- which-module: 2.0.1
- y18n: 4.0.3
- yargs-parser: 18.1.3
- dev: false
+ '@babel/types': 7.26.5
+
+ '@babel/types@7.26.5':
+ dependencies:
+ '@babel/helper-string-parser': 7.25.9
+ '@babel/helper-validator-identifier': 7.25.9
+
+ '@bufbuild/protobuf@2.2.3': {}
+
+ '@esbuild/aix-ppc64@0.21.5':
+ optional: true
+
+ '@esbuild/aix-ppc64@0.24.2':
+ optional: true
+
+ '@esbuild/android-arm64@0.21.5':
+ optional: true
+
+ '@esbuild/android-arm64@0.24.2':
+ optional: true
+
+ '@esbuild/android-arm@0.21.5':
+ optional: true
+
+ '@esbuild/android-arm@0.24.2':
+ optional: true
+
+ '@esbuild/android-x64@0.21.5':
+ optional: true
+
+ '@esbuild/android-x64@0.24.2':
+ optional: true
+
+ '@esbuild/darwin-arm64@0.21.5':
+ optional: true
+
+ '@esbuild/darwin-arm64@0.24.2':
+ optional: true
+
+ '@esbuild/darwin-x64@0.21.5':
+ optional: true
+
+ '@esbuild/darwin-x64@0.24.2':
+ optional: true
+
+ '@esbuild/freebsd-arm64@0.21.5':
+ optional: true
+
+ '@esbuild/freebsd-arm64@0.24.2':
+ optional: true
+
+ '@esbuild/freebsd-x64@0.21.5':
+ optional: true
+
+ '@esbuild/freebsd-x64@0.24.2':
+ optional: true
+
+ '@esbuild/linux-arm64@0.21.5':
+ optional: true
+
+ '@esbuild/linux-arm64@0.24.2':
+ optional: true
+
+ '@esbuild/linux-arm@0.21.5':
+ optional: true
+
+ '@esbuild/linux-arm@0.24.2':
+ optional: true
+
+ '@esbuild/linux-ia32@0.21.5':
+ optional: true
+
+ '@esbuild/linux-ia32@0.24.2':
+ optional: true
+
+ '@esbuild/linux-loong64@0.21.5':
+ optional: true
+
+ '@esbuild/linux-loong64@0.24.2':
+ optional: true
+
+ '@esbuild/linux-mips64el@0.21.5':
+ optional: true
+
+ '@esbuild/linux-mips64el@0.24.2':
+ optional: true
+
+ '@esbuild/linux-ppc64@0.21.5':
+ optional: true
+
+ '@esbuild/linux-ppc64@0.24.2':
+ optional: true
+
+ '@esbuild/linux-riscv64@0.21.5':
+ optional: true
+
+ '@esbuild/linux-riscv64@0.24.2':
+ optional: true
+
+ '@esbuild/linux-s390x@0.21.5':
+ optional: true
+
+ '@esbuild/linux-s390x@0.24.2':
+ optional: true
+
+ '@esbuild/linux-x64@0.21.5':
+ optional: true
+
+ '@esbuild/linux-x64@0.24.2':
+ optional: true
+
+ '@esbuild/netbsd-arm64@0.24.2':
+ optional: true
+
+ '@esbuild/netbsd-x64@0.21.5':
+ optional: true
+
+ '@esbuild/netbsd-x64@0.24.2':
+ optional: true
+
+ '@esbuild/openbsd-arm64@0.24.2':
+ optional: true
+
+ '@esbuild/openbsd-x64@0.21.5':
+ optional: true
+
+ '@esbuild/openbsd-x64@0.24.2':
+ optional: true
+
+ '@esbuild/sunos-x64@0.21.5':
+ optional: true
+
+ '@esbuild/sunos-x64@0.24.2':
+ optional: true
+
+ '@esbuild/win32-arm64@0.21.5':
+ optional: true
+
+ '@esbuild/win32-arm64@0.24.2':
+ optional: true
+
+ '@esbuild/win32-ia32@0.21.5':
+ optional: true
+
+ '@esbuild/win32-ia32@0.24.2':
+ optional: true
+
+ '@esbuild/win32-x64@0.21.5':
+ optional: true
+
+ '@esbuild/win32-x64@0.24.2':
+ optional: true
+
+ '@isaacs/cliui@8.0.2':
+ dependencies:
+ string-width: 5.1.2
+ string-width-cjs: string-width@4.2.3
+ strip-ansi: 7.1.0
+ strip-ansi-cjs: strip-ansi@6.0.1
+ wrap-ansi: 8.1.0
+ wrap-ansi-cjs: wrap-ansi@7.0.0
+ optional: true
+
+ '@jridgewell/sourcemap-codec@1.5.0': {}
+
+ '@lit-labs/ssr-dom-shim@1.3.0': {}
+
+ '@lit/reactive-element@2.0.4':
+ dependencies:
+ '@lit-labs/ssr-dom-shim': 1.3.0
+
+ '@mapbox/node-pre-gyp@1.0.11(encoding@0.1.13)':
+ dependencies:
+ detect-libc: 2.0.3
+ https-proxy-agent: 5.0.1
+ make-dir: 3.1.0
+ node-fetch: 2.7.0(encoding@0.1.13)
+ nopt: 5.0.0
+ npmlog: 5.0.1
+ rimraf: 3.0.2
+ semver: 7.6.3
+ tar: 6.2.1
+ transitivePeerDependencies:
+ - encoding
+ - supports-color
+ optional: true
+
+ '@mdit-vue/plugin-component@2.1.3':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ markdown-it: 14.1.0
+
+ '@mdit-vue/plugin-frontmatter@2.1.3':
+ dependencies:
+ '@mdit-vue/types': 2.1.0
+ '@types/markdown-it': 14.1.2
+ gray-matter: 4.0.3
+ markdown-it: 14.1.0
+
+ '@mdit-vue/plugin-headers@2.1.3':
+ dependencies:
+ '@mdit-vue/shared': 2.1.3
+ '@mdit-vue/types': 2.1.0
+ '@types/markdown-it': 14.1.2
+ markdown-it: 14.1.0
+
+ '@mdit-vue/plugin-sfc@2.1.3':
+ dependencies:
+ '@mdit-vue/types': 2.1.0
+ '@types/markdown-it': 14.1.2
+ markdown-it: 14.1.0
+
+ '@mdit-vue/plugin-title@2.1.3':
+ dependencies:
+ '@mdit-vue/shared': 2.1.3
+ '@mdit-vue/types': 2.1.0
+ '@types/markdown-it': 14.1.2
+ markdown-it: 14.1.0
+
+ '@mdit-vue/plugin-toc@2.1.3':
+ dependencies:
+ '@mdit-vue/shared': 2.1.3
+ '@mdit-vue/types': 2.1.0
+ '@types/markdown-it': 14.1.2
+ markdown-it: 14.1.0
+
+ '@mdit-vue/shared@2.1.3':
+ dependencies:
+ '@mdit-vue/types': 2.1.0
+ '@types/markdown-it': 14.1.2
+ markdown-it: 14.1.0
+
+ '@mdit-vue/types@2.1.0': {}
+
+ '@mdit/helper@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-alert@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-align@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@mdit/plugin-container': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-attrs@0.16.2(markdown-it@14.1.0)':
+ dependencies:
+ '@mdit/helper': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-container@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-demo@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-figure@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-footnote@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-icon@0.16.5(markdown-it@14.1.0)':
+ dependencies:
+ '@mdit/helper': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-img-lazyload@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-img-mark@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-img-size@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-include@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@mdit/helper': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ upath: 2.0.1
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-katex-slim@0.16.2(katex@0.16.20)(markdown-it@14.1.0)':
+ dependencies:
+ '@mdit/helper': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-tex': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ katex: 0.16.20
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-mark@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-mathjax-slim@0.16.0(markdown-it@14.1.0)(mathjax-full@3.2.2)':
+ dependencies:
+ '@mdit/plugin-tex': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ upath: 2.0.1
+ optionalDependencies:
+ markdown-it: 14.1.0
+ mathjax-full: 3.2.2
+
+ '@mdit/plugin-plantuml@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@mdit/plugin-uml': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-spoiler@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-stylize@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-sub@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@mdit/helper': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-sup@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@mdit/helper': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-tab@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@mdit/helper': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-tasklist@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-tex@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@mdit/plugin-uml@0.16.0(markdown-it@14.1.0)':
+ dependencies:
+ '@mdit/helper': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ optionalDependencies:
+ markdown-it: 14.1.0
+
+ '@nodelib/fs.scandir@2.1.5':
+ dependencies:
+ '@nodelib/fs.stat': 2.0.5
+ run-parallel: 1.2.0
+
+ '@nodelib/fs.stat@2.0.5': {}
+
+ '@nodelib/fs.walk@1.2.8':
+ dependencies:
+ '@nodelib/fs.scandir': 2.1.5
+ fastq: 1.18.0
+
+ '@npmcli/agent@2.2.2':
+ dependencies:
+ agent-base: 7.1.3
+ http-proxy-agent: 7.0.2
+ https-proxy-agent: 7.0.6
+ lru-cache: 10.4.3
+ socks-proxy-agent: 8.0.5
+ transitivePeerDependencies:
+ - supports-color
+ optional: true
+
+ '@npmcli/fs@3.1.1':
+ dependencies:
+ semver: 7.6.3
+ optional: true
+
+ '@pkgjs/parseargs@0.11.0':
+ optional: true
+
+ '@rollup/rollup-android-arm-eabi@4.30.1':
+ optional: true
+
+ '@rollup/rollup-android-arm64@4.30.1':
+ optional: true
+
+ '@rollup/rollup-darwin-arm64@4.30.1':
+ optional: true
+
+ '@rollup/rollup-darwin-x64@4.30.1':
+ optional: true
+
+ '@rollup/rollup-freebsd-arm64@4.30.1':
+ optional: true
+
+ '@rollup/rollup-freebsd-x64@4.30.1':
+ optional: true
+
+ '@rollup/rollup-linux-arm-gnueabihf@4.30.1':
+ optional: true
+
+ '@rollup/rollup-linux-arm-musleabihf@4.30.1':
+ optional: true
+
+ '@rollup/rollup-linux-arm64-gnu@4.30.1':
+ optional: true
+
+ '@rollup/rollup-linux-arm64-musl@4.30.1':
+ optional: true
+
+ '@rollup/rollup-linux-loongarch64-gnu@4.30.1':
+ optional: true
+
+ '@rollup/rollup-linux-powerpc64le-gnu@4.30.1':
+ optional: true
+
+ '@rollup/rollup-linux-riscv64-gnu@4.30.1':
+ optional: true
+
+ '@rollup/rollup-linux-s390x-gnu@4.30.1':
+ optional: true
+
+ '@rollup/rollup-linux-x64-gnu@4.30.1':
+ optional: true
+
+ '@rollup/rollup-linux-x64-musl@4.30.1':
+ optional: true
+
+ '@rollup/rollup-win32-arm64-msvc@4.30.1':
+ optional: true
+
+ '@rollup/rollup-win32-ia32-msvc@4.30.1':
+ optional: true
+
+ '@rollup/rollup-win32-x64-msvc@4.30.1':
+ optional: true
+
+ '@sec-ant/readable-stream@0.4.1': {}
+
+ '@shikijs/core@1.26.2':
+ dependencies:
+ '@shikijs/engine-javascript': 1.26.2
+ '@shikijs/engine-oniguruma': 1.26.2
+ '@shikijs/types': 1.26.2
+ '@shikijs/vscode-textmate': 10.0.1
+ '@types/hast': 3.0.4
+ hast-util-to-html: 9.0.4
+
+ '@shikijs/engine-javascript@1.26.2':
+ dependencies:
+ '@shikijs/types': 1.26.2
+ '@shikijs/vscode-textmate': 10.0.1
+ oniguruma-to-es: 1.0.0
+
+ '@shikijs/engine-oniguruma@1.26.2':
+ dependencies:
+ '@shikijs/types': 1.26.2
+ '@shikijs/vscode-textmate': 10.0.1
+
+ '@shikijs/langs@1.26.2':
+ dependencies:
+ '@shikijs/types': 1.26.2
+
+ '@shikijs/themes@1.26.2':
+ dependencies:
+ '@shikijs/types': 1.26.2
+
+ '@shikijs/transformers@1.26.2':
+ dependencies:
+ shiki: 1.26.2
+
+ '@shikijs/types@1.26.2':
+ dependencies:
+ '@shikijs/vscode-textmate': 10.0.1
+ '@types/hast': 3.0.4
+
+ '@shikijs/vscode-textmate@10.0.1': {}
+
+ '@sindresorhus/merge-streams@2.3.0': {}
+
+ '@sindresorhus/merge-streams@4.0.0': {}
+
+ '@stackblitz/sdk@1.11.0': {}
+
+ '@types/debug@4.1.12':
+ dependencies:
+ '@types/ms': 0.7.34
+
+ '@types/estree@1.0.6': {}
+
+ '@types/fs-extra@11.0.4':
+ dependencies:
+ '@types/jsonfile': 6.1.4
+ '@types/node': 22.10.5
+
+ '@types/hash-sum@1.0.2': {}
+
+ '@types/hast@3.0.4':
+ dependencies:
+ '@types/unist': 3.0.3
+
+ '@types/jsonfile@6.1.4':
+ dependencies:
+ '@types/node': 22.10.5
+
+ '@types/katex@0.16.7': {}
+
+ '@types/linkify-it@5.0.0': {}
+
+ '@types/markdown-it-emoji@3.0.1':
+ dependencies:
+ '@types/markdown-it': 14.1.2
+
+ '@types/markdown-it@14.1.2':
+ dependencies:
+ '@types/linkify-it': 5.0.0
+ '@types/mdurl': 2.0.0
+
+ '@types/mdast@4.0.4':
+ dependencies:
+ '@types/unist': 3.0.3
+
+ '@types/mdurl@2.0.0': {}
+
+ '@types/ms@0.7.34': {}
+
+ '@types/node@17.0.45': {}
+
+ '@types/node@22.10.5':
+ dependencies:
+ undici-types: 6.20.0
+
+ '@types/sax@1.2.7':
+ dependencies:
+ '@types/node': 17.0.45
+
+ '@types/trusted-types@2.0.7': {}
+
+ '@types/unist@2.0.11': {}
+
+ '@types/unist@3.0.3': {}
+
+ '@types/web-bluetooth@0.0.20': {}
+
+ '@ungap/structured-clone@1.2.1': {}
+
+ '@vitejs/plugin-vue@5.2.1(vite@6.0.7(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)':
+ dependencies:
+ vite: 6.0.7(@types/node@22.10.5)(sass-embedded@1.83.1)
+ vue: 3.5.13
+
+ '@vue/compiler-core@3.5.13':
+ dependencies:
+ '@babel/parser': 7.26.5
+ '@vue/shared': 3.5.13
+ entities: 4.5.0
+ estree-walker: 2.0.2
+ source-map-js: 1.2.1
+
+ '@vue/compiler-dom@3.5.13':
+ dependencies:
+ '@vue/compiler-core': 3.5.13
+ '@vue/shared': 3.5.13
+
+ '@vue/compiler-sfc@3.5.13':
+ dependencies:
+ '@babel/parser': 7.26.5
+ '@vue/compiler-core': 3.5.13
+ '@vue/compiler-dom': 3.5.13
+ '@vue/compiler-ssr': 3.5.13
+ '@vue/shared': 3.5.13
+ estree-walker: 2.0.2
+ magic-string: 0.30.17
+ postcss: 8.5.0
+ source-map-js: 1.2.1
+
+ '@vue/compiler-ssr@3.5.13':
+ dependencies:
+ '@vue/compiler-dom': 3.5.13
+ '@vue/shared': 3.5.13
+
+ '@vue/devtools-api@6.6.4': {}
+
+ '@vue/devtools-api@7.7.0':
+ dependencies:
+ '@vue/devtools-kit': 7.7.0
+
+ '@vue/devtools-kit@7.7.0':
+ dependencies:
+ '@vue/devtools-shared': 7.7.0
+ birpc: 0.2.19
+ hookable: 5.5.3
+ mitt: 3.0.1
+ perfect-debounce: 1.0.0
+ speakingurl: 14.0.1
+ superjson: 2.2.2
+
+ '@vue/devtools-shared@7.7.0':
+ dependencies:
+ rfdc: 1.4.1
+
+ '@vue/reactivity@3.5.13':
+ dependencies:
+ '@vue/shared': 3.5.13
+
+ '@vue/runtime-core@3.5.13':
+ dependencies:
+ '@vue/reactivity': 3.5.13
+ '@vue/shared': 3.5.13
+
+ '@vue/runtime-dom@3.5.13':
+ dependencies:
+ '@vue/reactivity': 3.5.13
+ '@vue/runtime-core': 3.5.13
+ '@vue/shared': 3.5.13
+ csstype: 3.1.3
+
+ '@vue/server-renderer@3.5.13(vue@3.5.13)':
+ dependencies:
+ '@vue/compiler-ssr': 3.5.13
+ '@vue/shared': 3.5.13
+ vue: 3.5.13
+
+ '@vue/shared@3.5.13': {}
+
+ '@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1)':
+ dependencies:
+ '@vitejs/plugin-vue': 5.2.1(vite@6.0.7(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ '@vuepress/bundlerutils': 2.0.0-rc.19
+ '@vuepress/client': 2.0.0-rc.19
+ '@vuepress/core': 2.0.0-rc.19
+ '@vuepress/shared': 2.0.0-rc.19
+ '@vuepress/utils': 2.0.0-rc.19
+ autoprefixer: 10.4.20(postcss@8.5.0)
+ connect-history-api-fallback: 2.0.0
+ postcss: 8.5.0
+ postcss-load-config: 6.0.1(postcss@8.5.0)
+ rollup: 4.30.1
+ vite: 6.0.7(@types/node@22.10.5)(sass-embedded@1.83.1)
+ vue: 3.5.13
+ vue-router: 4.5.0(vue@3.5.13)
+ transitivePeerDependencies:
+ - '@types/node'
+ - jiti
+ - less
+ - lightningcss
+ - sass
+ - sass-embedded
+ - stylus
+ - sugarss
+ - supports-color
+ - terser
+ - tsx
+ - typescript
+ - yaml
+
+ '@vuepress/bundlerutils@2.0.0-rc.19':
+ dependencies:
+ '@vuepress/client': 2.0.0-rc.19
+ '@vuepress/core': 2.0.0-rc.19
+ '@vuepress/shared': 2.0.0-rc.19
+ '@vuepress/utils': 2.0.0-rc.19
+ vue: 3.5.13
+ vue-router: 4.5.0(vue@3.5.13)
+ transitivePeerDependencies:
+ - supports-color
+ - typescript
+
+ '@vuepress/cli@2.0.0-rc.19':
+ dependencies:
+ '@vuepress/core': 2.0.0-rc.19
+ '@vuepress/shared': 2.0.0-rc.19
+ '@vuepress/utils': 2.0.0-rc.19
+ cac: 6.7.14
+ chokidar: 3.6.0
+ envinfo: 7.14.0
+ esbuild: 0.21.5
+ transitivePeerDependencies:
+ - supports-color
+ - typescript
+
+ '@vuepress/client@2.0.0-rc.19':
+ dependencies:
+ '@vue/devtools-api': 7.7.0
+ '@vuepress/shared': 2.0.0-rc.19
+ vue: 3.5.13
+ vue-router: 4.5.0(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/core@2.0.0-rc.19':
+ dependencies:
+ '@vuepress/client': 2.0.0-rc.19
+ '@vuepress/markdown': 2.0.0-rc.19
+ '@vuepress/shared': 2.0.0-rc.19
+ '@vuepress/utils': 2.0.0-rc.19
+ vue: 3.5.13
+ transitivePeerDependencies:
+ - supports-color
+ - typescript
+
+ '@vuepress/helper@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vue/shared': 3.5.13
+ '@vueuse/core': 12.4.0
+ cheerio: 1.0.0
+ fflate: 0.8.2
+ gray-matter: 4.0.3
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/highlighter-helper@2.0.0-rc.70(@vueuse/core@12.4.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ optionalDependencies:
+ '@vueuse/core': 12.4.0
+
+ '@vuepress/markdown@2.0.0-rc.19':
+ dependencies:
+ '@mdit-vue/plugin-component': 2.1.3
+ '@mdit-vue/plugin-frontmatter': 2.1.3
+ '@mdit-vue/plugin-headers': 2.1.3
+ '@mdit-vue/plugin-sfc': 2.1.3
+ '@mdit-vue/plugin-title': 2.1.3
+ '@mdit-vue/plugin-toc': 2.1.3
+ '@mdit-vue/shared': 2.1.3
+ '@mdit-vue/types': 2.1.0
+ '@types/markdown-it': 14.1.2
+ '@types/markdown-it-emoji': 3.0.1
+ '@vuepress/shared': 2.0.0-rc.19
+ '@vuepress/utils': 2.0.0-rc.19
+ markdown-it: 14.1.0
+ markdown-it-anchor: 9.2.0(@types/markdown-it@14.1.2)(markdown-it@14.1.0)
+ markdown-it-emoji: 3.0.0
+ mdurl: 2.0.0
+ transitivePeerDependencies:
+ - supports-color
+
+ '@vuepress/plugin-active-header-links@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vueuse/core': 12.4.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-back-to-top@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-blog@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ chokidar: 3.6.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-catalog@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-comment@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ giscus: 1.6.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-copy-code@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-copyright@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-feed@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ xml-js: 1.6.11
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-git@2.0.0-rc.68(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ execa: 9.5.2
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+
+ '@vuepress/plugin-icon@2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@mdit/plugin-icon': 0.16.5(markdown-it@14.1.0)
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - markdown-it
+ - typescript
+
+ '@vuepress/plugin-links-check@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-markdown-ext@2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@mdit/plugin-container': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-footnote': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-tasklist': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ js-yaml: 4.1.0
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - markdown-it
+ - typescript
+
+ '@vuepress/plugin-markdown-hint@2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@mdit/plugin-alert': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-container': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - markdown-it
+ - typescript
+
+ '@vuepress/plugin-markdown-image@2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@mdit/plugin-figure': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-img-lazyload': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-img-mark': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-img-size': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - markdown-it
+ - typescript
+
+ '@vuepress/plugin-markdown-include@2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@mdit/plugin-include': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - markdown-it
+ - typescript
+
+ '@vuepress/plugin-markdown-math@2.0.0-rc.70(katex@0.16.20)(markdown-it@14.1.0)(mathjax-full@3.2.2)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@mdit/plugin-katex-slim': 0.16.2(katex@0.16.20)(markdown-it@14.1.0)
+ '@mdit/plugin-mathjax-slim': 0.16.0(markdown-it@14.1.0)(mathjax-full@3.2.2)
+ '@types/markdown-it': 14.1.2
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ optionalDependencies:
+ katex: 0.16.20
+ mathjax-full: 3.2.2
+ transitivePeerDependencies:
+ - markdown-it
+ - typescript
+
+ '@vuepress/plugin-markdown-stylize@2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@mdit/plugin-align': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-attrs': 0.16.2(markdown-it@14.1.0)
+ '@mdit/plugin-mark': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-spoiler': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-stylize': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-sub': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-sup': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - markdown-it
+ - typescript
+
+ '@vuepress/plugin-markdown-tab@2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@mdit/plugin-tab': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - markdown-it
+ - typescript
+
+ '@vuepress/plugin-notice@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-nprogress@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-photo-swipe@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ photoswipe: 5.4.4
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-reading-time@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-redirect@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ commander: 13.0.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-rtl@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-sass-palette@2.0.0-rc.70(sass-embedded@1.83.1)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ chokidar: 4.0.3
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ optionalDependencies:
+ sass-embedded: 1.83.1
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-search@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ chokidar: 3.6.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-seo@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-shiki@2.0.0-rc.70(@vueuse/core@12.4.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@shikijs/transformers': 1.26.2
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/highlighter-helper': 2.0.0-rc.70(@vueuse/core@12.4.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ nanoid: 5.0.9
+ shiki: 1.26.2
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - '@vueuse/core'
+ - typescript
+
+ '@vuepress/plugin-sitemap@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ sitemap: 8.0.0
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/plugin-theme-data@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))':
+ dependencies:
+ '@vue/devtools-api': 7.7.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ '@vuepress/shared@2.0.0-rc.19':
+ dependencies:
+ '@mdit-vue/types': 2.1.0
+
+ '@vuepress/utils@2.0.0-rc.19':
+ dependencies:
+ '@types/debug': 4.1.12
+ '@types/fs-extra': 11.0.4
+ '@types/hash-sum': 1.0.2
+ '@vuepress/shared': 2.0.0-rc.19
+ debug: 4.4.0
+ fs-extra: 11.2.0
+ globby: 14.0.2
+ hash-sum: 2.0.0
+ ora: 8.1.1
+ picocolors: 1.1.1
+ upath: 2.0.1
+ transitivePeerDependencies:
+ - supports-color
+
+ '@vueuse/core@12.4.0':
+ dependencies:
+ '@types/web-bluetooth': 0.0.20
+ '@vueuse/metadata': 12.4.0
+ '@vueuse/shared': 12.4.0
+ vue: 3.5.13
+ transitivePeerDependencies:
+ - typescript
+
+ '@vueuse/metadata@12.4.0': {}
+
+ '@vueuse/shared@12.4.0':
+ dependencies:
+ vue: 3.5.13
+ transitivePeerDependencies:
+ - typescript
+
+ abbrev@1.1.1:
+ optional: true
+
+ abbrev@2.0.0:
+ optional: true
+
+ agent-base@6.0.2:
+ dependencies:
+ debug: 4.4.0
+ transitivePeerDependencies:
+ - supports-color
+ optional: true
+
+ agent-base@7.1.3:
+ optional: true
+
+ aggregate-error@3.1.0:
+ dependencies:
+ clean-stack: 2.2.0
+ indent-string: 4.0.0
+ optional: true
+
+ ansi-regex@5.0.1: {}
+
+ ansi-regex@6.1.0: {}
+
+ ansi-styles@4.3.0:
+ dependencies:
+ color-convert: 2.0.1
+
+ ansi-styles@6.2.1:
+ optional: true
+
+ anymatch@3.1.3:
+ dependencies:
+ normalize-path: 3.0.0
+ picomatch: 2.3.1
+
+ aproba@2.0.0:
+ optional: true
+
+ are-we-there-yet@2.0.0:
+ dependencies:
+ delegates: 1.0.0
+ readable-stream: 3.6.2
+ optional: true
+
+ arg@5.0.2: {}
+
+ argparse@1.0.10:
+ dependencies:
+ sprintf-js: 1.0.3
+
+ argparse@2.0.1: {}
+
+ autoprefixer@10.4.20(postcss@8.5.0):
+ dependencies:
+ browserslist: 4.24.4
+ caniuse-lite: 1.0.30001692
+ fraction.js: 4.3.7
+ normalize-range: 0.1.2
+ picocolors: 1.1.1
+ postcss: 8.5.0
+ postcss-value-parser: 4.2.0
+
+ balanced-match@1.0.2:
+ optional: true
+
+ balloon-css@1.2.0: {}
+
+ bcrypt-ts@5.0.3: {}
+
+ binary-extensions@2.3.0: {}
+
+ birpc@0.2.19: {}
+
+ boolbase@1.0.0: {}
+
+ brace-expansion@1.1.11:
+ dependencies:
+ balanced-match: 1.0.2
+ concat-map: 0.0.1
+ optional: true
+
+ brace-expansion@2.0.1:
+ dependencies:
+ balanced-match: 1.0.2
+ optional: true
+
+ braces@3.0.3:
+ dependencies:
+ fill-range: 7.1.1
+
+ browserslist@4.24.4:
+ dependencies:
+ caniuse-lite: 1.0.30001692
+ electron-to-chromium: 1.5.80
+ node-releases: 2.0.19
+ update-browserslist-db: 1.1.2(browserslist@4.24.4)
+
+ buffer-builder@0.2.0: {}
+
+ cac@6.7.14: {}
+
+ cacache@18.0.4:
+ dependencies:
+ '@npmcli/fs': 3.1.1
+ fs-minipass: 3.0.3
+ glob: 10.4.5
+ lru-cache: 10.4.3
+ minipass: 7.1.2
+ minipass-collect: 2.0.1
+ minipass-flush: 1.0.5
+ minipass-pipeline: 1.2.4
+ p-map: 4.0.0
+ ssri: 10.0.6
+ tar: 6.2.1
+ unique-filename: 3.0.0
+ optional: true
+
+ camelcase@5.3.1: {}
+
+ caniuse-lite@1.0.30001692: {}
+
+ ccount@2.0.1: {}
+
+ chalk@5.4.1: {}
+
+ character-entities-html4@2.1.0: {}
+
+ character-entities-legacy@3.0.0: {}
+
+ character-entities@2.0.2: {}
+
+ character-reference-invalid@2.0.1: {}
+
+ cheerio-select@2.1.0:
+ dependencies:
+ boolbase: 1.0.0
+ css-select: 5.1.0
+ css-what: 6.1.0
+ domelementtype: 2.3.0
+ domhandler: 5.0.3
+ domutils: 3.2.2
+
+ cheerio@1.0.0:
+ dependencies:
+ cheerio-select: 2.1.0
+ dom-serializer: 2.0.0
+ domhandler: 5.0.3
+ domutils: 3.2.2
+ encoding-sniffer: 0.2.0
+ htmlparser2: 9.1.0
+ parse5: 7.2.1
+ parse5-htmlparser2-tree-adapter: 7.1.0
+ parse5-parser-stream: 7.1.2
+ undici: 6.21.0
+ whatwg-mimetype: 4.0.0
+
+ chokidar@3.6.0:
+ dependencies:
+ anymatch: 3.1.3
+ braces: 3.0.3
+ glob-parent: 5.1.2
+ is-binary-path: 2.1.0
+ is-glob: 4.0.3
+ normalize-path: 3.0.0
+ readdirp: 3.6.0
+ optionalDependencies:
+ fsevents: 2.3.3
+
+ chokidar@4.0.3:
+ dependencies:
+ readdirp: 4.1.1
+
+ chownr@2.0.0:
+ optional: true
+
+ clean-stack@2.2.0:
+ optional: true
+
+ cli-cursor@5.0.0:
+ dependencies:
+ restore-cursor: 5.1.0
+
+ cli-spinners@2.9.2: {}
+
+ cliui@6.0.0:
+ dependencies:
+ string-width: 4.2.3
+ strip-ansi: 6.0.1
+ wrap-ansi: 6.2.0
+
+ color-convert@2.0.1:
+ dependencies:
+ color-name: 1.1.4
+
+ color-name@1.1.4: {}
+
+ color-support@1.1.3:
+ optional: true
+
+ colorjs.io@0.5.2: {}
+
+ comma-separated-tokens@2.0.3: {}
+
+ commander@13.0.0: {}
+
+ commander@8.3.0: {}
+
+ commander@9.2.0: {}
+
+ concat-map@0.0.1:
+ optional: true
+
+ connect-history-api-fallback@2.0.0: {}
+
+ console-control-strings@1.1.0:
+ optional: true
+
+ copy-anything@3.0.5:
+ dependencies:
+ is-what: 4.1.16
+
+ create-codepen@2.0.0: {}
+
+ cross-spawn@7.0.6:
+ dependencies:
+ path-key: 3.1.1
+ shebang-command: 2.0.0
+ which: 2.0.2
+
+ css-select@5.1.0:
+ dependencies:
+ boolbase: 1.0.0
+ css-what: 6.1.0
+ domhandler: 5.0.3
+ domutils: 3.2.2
+ nth-check: 2.1.1
+
+ css-what@6.1.0: {}
+
+ csstype@3.1.3: {}
+
+ dayjs@1.11.13: {}
+
+ debug@4.4.0:
+ dependencies:
+ ms: 2.1.3
+
+ decamelize@1.2.0: {}
+
+ decode-named-character-reference@1.0.2:
+ dependencies:
+ character-entities: 2.0.2
+
+ delegates@1.0.0:
+ optional: true
+
+ dequal@2.0.3: {}
+
+ detect-libc@2.0.3:
+ optional: true
+
+ devlop@1.1.0:
+ dependencies:
+ dequal: 2.0.3
+
+ dijkstrajs@1.0.3: {}
+
+ dom-serializer@2.0.0:
+ dependencies:
+ domelementtype: 2.3.0
+ domhandler: 5.0.3
+ entities: 4.5.0
+
+ domelementtype@2.3.0: {}
+
+ domhandler@5.0.3:
+ dependencies:
+ domelementtype: 2.3.0
+
+ domutils@3.2.2:
+ dependencies:
+ dom-serializer: 2.0.0
+ domelementtype: 2.3.0
+ domhandler: 5.0.3
+
+ eastasianwidth@0.2.0:
+ optional: true
+
+ electron-to-chromium@1.5.80: {}
+
+ emoji-regex-xs@1.0.0: {}
+
+ emoji-regex@10.4.0: {}
+
+ emoji-regex@8.0.0: {}
+
+ emoji-regex@9.2.2:
+ optional: true
+
+ encoding-sniffer@0.2.0:
+ dependencies:
+ iconv-lite: 0.6.3
+ whatwg-encoding: 3.1.1
+
+ encoding@0.1.13:
+ dependencies:
+ iconv-lite: 0.6.3
+ optional: true
+
+ entities@4.5.0: {}
+
+ env-paths@2.2.1:
+ optional: true
+
+ envinfo@7.14.0: {}
+
+ err-code@2.0.3:
+ optional: true
+
+ esbuild@0.21.5:
+ optionalDependencies:
+ '@esbuild/aix-ppc64': 0.21.5
+ '@esbuild/android-arm': 0.21.5
+ '@esbuild/android-arm64': 0.21.5
+ '@esbuild/android-x64': 0.21.5
+ '@esbuild/darwin-arm64': 0.21.5
+ '@esbuild/darwin-x64': 0.21.5
+ '@esbuild/freebsd-arm64': 0.21.5
+ '@esbuild/freebsd-x64': 0.21.5
+ '@esbuild/linux-arm': 0.21.5
+ '@esbuild/linux-arm64': 0.21.5
+ '@esbuild/linux-ia32': 0.21.5
+ '@esbuild/linux-loong64': 0.21.5
+ '@esbuild/linux-mips64el': 0.21.5
+ '@esbuild/linux-ppc64': 0.21.5
+ '@esbuild/linux-riscv64': 0.21.5
+ '@esbuild/linux-s390x': 0.21.5
+ '@esbuild/linux-x64': 0.21.5
+ '@esbuild/netbsd-x64': 0.21.5
+ '@esbuild/openbsd-x64': 0.21.5
+ '@esbuild/sunos-x64': 0.21.5
+ '@esbuild/win32-arm64': 0.21.5
+ '@esbuild/win32-ia32': 0.21.5
+ '@esbuild/win32-x64': 0.21.5
+
+ esbuild@0.24.2:
+ optionalDependencies:
+ '@esbuild/aix-ppc64': 0.24.2
+ '@esbuild/android-arm': 0.24.2
+ '@esbuild/android-arm64': 0.24.2
+ '@esbuild/android-x64': 0.24.2
+ '@esbuild/darwin-arm64': 0.24.2
+ '@esbuild/darwin-x64': 0.24.2
+ '@esbuild/freebsd-arm64': 0.24.2
+ '@esbuild/freebsd-x64': 0.24.2
+ '@esbuild/linux-arm': 0.24.2
+ '@esbuild/linux-arm64': 0.24.2
+ '@esbuild/linux-ia32': 0.24.2
+ '@esbuild/linux-loong64': 0.24.2
+ '@esbuild/linux-mips64el': 0.24.2
+ '@esbuild/linux-ppc64': 0.24.2
+ '@esbuild/linux-riscv64': 0.24.2
+ '@esbuild/linux-s390x': 0.24.2
+ '@esbuild/linux-x64': 0.24.2
+ '@esbuild/netbsd-arm64': 0.24.2
+ '@esbuild/netbsd-x64': 0.24.2
+ '@esbuild/openbsd-arm64': 0.24.2
+ '@esbuild/openbsd-x64': 0.24.2
+ '@esbuild/sunos-x64': 0.24.2
+ '@esbuild/win32-arm64': 0.24.2
+ '@esbuild/win32-ia32': 0.24.2
+ '@esbuild/win32-x64': 0.24.2
+
+ escalade@3.2.0: {}
+
+ esm@3.2.25: {}
+
+ esprima@4.0.1: {}
+
+ estree-walker@2.0.2: {}
+
+ execa@9.5.2:
+ dependencies:
+ '@sindresorhus/merge-streams': 4.0.0
+ cross-spawn: 7.0.6
+ figures: 6.1.0
+ get-stream: 9.0.1
+ human-signals: 8.0.0
+ is-plain-obj: 4.1.0
+ is-stream: 4.0.1
+ npm-run-path: 6.0.0
+ pretty-ms: 9.2.0
+ signal-exit: 4.1.0
+ strip-final-newline: 4.0.0
+ yoctocolors: 2.1.1
+
+ exponential-backoff@3.1.1:
+ optional: true
+
+ extend-shallow@2.0.1:
+ dependencies:
+ is-extendable: 0.1.1
+
+ fast-glob@3.3.3:
+ dependencies:
+ '@nodelib/fs.stat': 2.0.5
+ '@nodelib/fs.walk': 1.2.8
+ glob-parent: 5.1.2
+ merge2: 1.4.1
+ micromatch: 4.0.8
+
+ fastq@1.18.0:
+ dependencies:
+ reusify: 1.0.4
+
+ fflate@0.8.2: {}
+
+ figures@6.1.0:
+ dependencies:
+ is-unicode-supported: 2.1.0
+
+ fill-range@7.1.1:
+ dependencies:
+ to-regex-range: 5.0.1
+
+ find-up@4.1.0:
+ dependencies:
+ locate-path: 5.0.0
+ path-exists: 4.0.0
+
+ foreground-child@3.3.0:
+ dependencies:
+ cross-spawn: 7.0.6
+ signal-exit: 4.1.0
+ optional: true
+
+ fraction.js@4.3.7: {}
+
+ fs-extra@11.2.0:
+ dependencies:
+ graceful-fs: 4.2.11
+ jsonfile: 6.1.0
+ universalify: 2.0.1
+
+ fs-minipass@2.1.0:
+ dependencies:
+ minipass: 3.3.6
+ optional: true
+
+ fs-minipass@3.0.3:
+ dependencies:
+ minipass: 7.1.2
+ optional: true
+
+ fs.realpath@1.0.0:
+ optional: true
+
+ fsevents@2.3.3:
+ optional: true
+
+ gauge@3.0.2:
+ dependencies:
+ aproba: 2.0.0
+ color-support: 1.1.3
+ console-control-strings: 1.1.0
+ has-unicode: 2.0.1
+ object-assign: 4.1.1
+ signal-exit: 3.0.7
+ string-width: 4.2.3
+ strip-ansi: 6.0.1
+ wide-align: 1.1.5
+ optional: true
+
+ get-caller-file@2.0.5: {}
+
+ get-east-asian-width@1.3.0: {}
+
+ get-stream@9.0.1:
+ dependencies:
+ '@sec-ant/readable-stream': 0.4.1
+ is-stream: 4.0.1
+
+ giscus@1.6.0:
+ dependencies:
+ lit: 3.2.1
+
+ glob-parent@5.1.2:
+ dependencies:
+ is-glob: 4.0.3
+
+ glob@10.4.5:
+ dependencies:
+ foreground-child: 3.3.0
+ jackspeak: 3.4.3
+ minimatch: 9.0.5
+ minipass: 7.1.2
+ package-json-from-dist: 1.0.1
+ path-scurry: 1.11.1
+ optional: true
+
+ glob@7.2.3:
+ dependencies:
+ fs.realpath: 1.0.0
+ inflight: 1.0.6
+ inherits: 2.0.4
+ minimatch: 3.1.2
+ once: 1.4.0
+ path-is-absolute: 1.0.1
+ optional: true
+
+ globby@14.0.2:
+ dependencies:
+ '@sindresorhus/merge-streams': 2.3.0
+ fast-glob: 3.3.3
+ ignore: 5.3.2
+ path-type: 5.0.0
+ slash: 5.1.0
+ unicorn-magic: 0.1.0
+
+ graceful-fs@4.2.11: {}
+
+ gray-matter@4.0.3:
+ dependencies:
+ js-yaml: 3.14.1
+ kind-of: 6.0.3
+ section-matter: 1.0.0
+ strip-bom-string: 1.0.0
+
+ has-flag@4.0.0: {}
+
+ has-unicode@2.0.1:
+ optional: true
+
+ hash-sum@2.0.0: {}
+
+ hast-util-to-html@9.0.4:
+ dependencies:
+ '@types/hast': 3.0.4
+ '@types/unist': 3.0.3
+ ccount: 2.0.1
+ comma-separated-tokens: 2.0.3
+ hast-util-whitespace: 3.0.0
+ html-void-elements: 3.0.0
+ mdast-util-to-hast: 13.2.0
+ property-information: 6.5.0
+ space-separated-tokens: 2.0.2
+ stringify-entities: 4.0.4
+ zwitch: 2.0.4
+
+ hast-util-whitespace@3.0.0:
+ dependencies:
+ '@types/hast': 3.0.4
+
+ hookable@5.5.3: {}
+
+ html-void-elements@3.0.0: {}
+
+ htmlparser2@9.1.0:
+ dependencies:
+ domelementtype: 2.3.0
+ domhandler: 5.0.3
+ domutils: 3.2.2
+ entities: 4.5.0
+
+ http-cache-semantics@4.1.1:
+ optional: true
+
+ http-proxy-agent@7.0.2:
+ dependencies:
+ agent-base: 7.1.3
+ debug: 4.4.0
+ transitivePeerDependencies:
+ - supports-color
+ optional: true
+
+ https-proxy-agent@5.0.1:
+ dependencies:
+ agent-base: 6.0.2
+ debug: 4.4.0
+ transitivePeerDependencies:
+ - supports-color
+ optional: true
+
+ https-proxy-agent@7.0.6:
+ dependencies:
+ agent-base: 7.1.3
+ debug: 4.4.0
+ transitivePeerDependencies:
+ - supports-color
+ optional: true
+
+ human-signals@8.0.0: {}
+
+ husky@9.1.7: {}
+
+ iconv-lite@0.6.3:
+ dependencies:
+ safer-buffer: 2.1.2
+
+ ignore@5.3.2: {}
+
+ immutable@5.0.3: {}
+
+ imurmurhash@0.1.4:
+ optional: true
+
+ indent-string@4.0.0:
+ optional: true
+
+ inflight@1.0.6:
+ dependencies:
+ once: 1.4.0
+ wrappy: 1.0.2
+ optional: true
+
+ inherits@2.0.4:
+ optional: true
+
+ ip-address@9.0.5:
+ dependencies:
+ jsbn: 1.1.0
+ sprintf-js: 1.1.3
+ optional: true
+
+ is-alphabetical@2.0.1: {}
+
+ is-alphanumerical@2.0.1:
+ dependencies:
+ is-alphabetical: 2.0.1
+ is-decimal: 2.0.1
+
+ is-binary-path@2.1.0:
+ dependencies:
+ binary-extensions: 2.3.0
+
+ is-decimal@2.0.1: {}
+
+ is-extendable@0.1.1: {}
+
+ is-extglob@2.1.1: {}
+
+ is-fullwidth-code-point@3.0.0: {}
+
+ is-glob@4.0.3:
+ dependencies:
+ is-extglob: 2.1.1
+
+ is-hexadecimal@2.0.1: {}
+
+ is-interactive@2.0.0: {}
+
+ is-lambda@1.0.1:
+ optional: true
+
+ is-number@7.0.0: {}
+
+ is-plain-obj@4.1.0: {}
+
+ is-stream@4.0.1: {}
+
+ is-unicode-supported@1.3.0: {}
+
+ is-unicode-supported@2.1.0: {}
+
+ is-what@4.1.16: {}
+
+ isexe@2.0.0: {}
+
+ isexe@3.1.1:
+ optional: true
+
+ jackspeak@3.4.3:
+ dependencies:
+ '@isaacs/cliui': 8.0.2
+ optionalDependencies:
+ '@pkgjs/parseargs': 0.11.0
+ optional: true
+
+ js-yaml@3.14.1:
+ dependencies:
+ argparse: 1.0.10
+ esprima: 4.0.1
+
+ js-yaml@4.1.0:
+ dependencies:
+ argparse: 2.0.1
+
+ jsbn@1.1.0:
+ optional: true
+
+ jsonc-parser@3.3.1: {}
+
+ jsonfile@6.1.0:
+ dependencies:
+ universalify: 2.0.1
+ optionalDependencies:
+ graceful-fs: 4.2.11
+
+ katex@0.16.20:
+ dependencies:
+ commander: 8.3.0
+
+ kind-of@6.0.3: {}
+
+ lilconfig@3.1.3: {}
+
+ linkify-it@5.0.0:
+ dependencies:
+ uc.micro: 2.1.0
+
+ lit-element@4.1.1:
+ dependencies:
+ '@lit-labs/ssr-dom-shim': 1.3.0
+ '@lit/reactive-element': 2.0.4
+ lit-html: 3.2.1
+
+ lit-html@3.2.1:
+ dependencies:
+ '@types/trusted-types': 2.0.7
+
+ lit@3.2.1:
+ dependencies:
+ '@lit/reactive-element': 2.0.4
+ lit-element: 4.1.1
+ lit-html: 3.2.1
+
+ locate-path@5.0.0:
+ dependencies:
+ p-locate: 4.1.0
+
+ log-symbols@6.0.0:
+ dependencies:
+ chalk: 5.4.1
+ is-unicode-supported: 1.3.0
+
+ lru-cache@10.4.3:
+ optional: true
+
+ magic-string@0.30.17:
+ dependencies:
+ '@jridgewell/sourcemap-codec': 1.5.0
+
+ make-dir@3.1.0:
+ dependencies:
+ semver: 6.3.1
+ optional: true
+
+ make-fetch-happen@13.0.1:
+ dependencies:
+ '@npmcli/agent': 2.2.2
+ cacache: 18.0.4
+ http-cache-semantics: 4.1.1
+ is-lambda: 1.0.1
+ minipass: 7.1.2
+ minipass-fetch: 3.0.5
+ minipass-flush: 1.0.5
+ minipass-pipeline: 1.2.4
+ negotiator: 0.6.4
+ proc-log: 4.2.0
+ promise-retry: 2.0.1
+ ssri: 10.0.6
+ transitivePeerDependencies:
+ - supports-color
+ optional: true
+
+ markdown-it-anchor@9.2.0(@types/markdown-it@14.1.2)(markdown-it@14.1.0):
+ dependencies:
+ '@types/markdown-it': 14.1.2
+ markdown-it: 14.1.0
+
+ markdown-it-emoji@3.0.0: {}
+
+ markdown-it@14.1.0:
+ dependencies:
+ argparse: 2.0.1
+ entities: 4.5.0
+ linkify-it: 5.0.0
+ mdurl: 2.0.0
+ punycode.js: 2.3.1
+ uc.micro: 2.1.0
+
+ markdownlint-cli2-formatter-default@0.0.5(markdownlint-cli2@0.17.1):
+ dependencies:
+ markdownlint-cli2: 0.17.1
+
+ markdownlint-cli2@0.17.1:
+ dependencies:
+ globby: 14.0.2
+ js-yaml: 4.1.0
+ jsonc-parser: 3.3.1
+ markdownlint: 0.37.3
+ markdownlint-cli2-formatter-default: 0.0.5(markdownlint-cli2@0.17.1)
+ micromatch: 4.0.8
+ transitivePeerDependencies:
+ - supports-color
+
+ markdownlint@0.37.3:
+ dependencies:
+ markdown-it: 14.1.0
+ micromark: 4.0.1
+ micromark-core-commonmark: 2.0.2
+ micromark-extension-directive: 3.0.2
+ micromark-extension-gfm-autolink-literal: 2.1.0
+ micromark-extension-gfm-footnote: 2.1.0
+ micromark-extension-gfm-table: 2.1.0
+ micromark-extension-math: 3.1.0
+ micromark-util-types: 2.0.1
+ transitivePeerDependencies:
+ - supports-color
+
+ mathjax-full@3.2.2:
+ dependencies:
+ esm: 3.2.25
+ mhchemparser: 4.2.1
+ mj-context-menu: 0.6.1
+ speech-rule-engine: 4.0.7
+
+ mdast-util-to-hast@13.2.0:
+ dependencies:
+ '@types/hast': 3.0.4
+ '@types/mdast': 4.0.4
+ '@ungap/structured-clone': 1.2.1
+ devlop: 1.1.0
+ micromark-util-sanitize-uri: 2.0.1
+ trim-lines: 3.0.1
+ unist-util-position: 5.0.0
+ unist-util-visit: 5.0.0
+ vfile: 6.0.3
+
+ mdurl@2.0.0: {}
+
+ merge2@1.4.1: {}
+
+ mhchemparser@4.2.1: {}
+
+ micromark-core-commonmark@2.0.2:
+ dependencies:
+ decode-named-character-reference: 1.0.2
+ devlop: 1.1.0
+ micromark-factory-destination: 2.0.1
+ micromark-factory-label: 2.0.1
+ micromark-factory-space: 2.0.1
+ micromark-factory-title: 2.0.1
+ micromark-factory-whitespace: 2.0.1
+ micromark-util-character: 2.1.1
+ micromark-util-chunked: 2.0.1
+ micromark-util-classify-character: 2.0.1
+ micromark-util-html-tag-name: 2.0.1
+ micromark-util-normalize-identifier: 2.0.1
+ micromark-util-resolve-all: 2.0.1
+ micromark-util-subtokenize: 2.0.3
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-extension-directive@3.0.2:
+ dependencies:
+ devlop: 1.1.0
+ micromark-factory-space: 2.0.1
+ micromark-factory-whitespace: 2.0.1
+ micromark-util-character: 2.1.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+ parse-entities: 4.0.2
+
+ micromark-extension-gfm-autolink-literal@2.1.0:
+ dependencies:
+ micromark-util-character: 2.1.1
+ micromark-util-sanitize-uri: 2.0.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-extension-gfm-footnote@2.1.0:
+ dependencies:
+ devlop: 1.1.0
+ micromark-core-commonmark: 2.0.2
+ micromark-factory-space: 2.0.1
+ micromark-util-character: 2.1.1
+ micromark-util-normalize-identifier: 2.0.1
+ micromark-util-sanitize-uri: 2.0.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-extension-gfm-table@2.1.0:
+ dependencies:
+ devlop: 1.1.0
+ micromark-factory-space: 2.0.1
+ micromark-util-character: 2.1.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-extension-math@3.1.0:
+ dependencies:
+ '@types/katex': 0.16.7
+ devlop: 1.1.0
+ katex: 0.16.20
+ micromark-factory-space: 2.0.1
+ micromark-util-character: 2.1.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-factory-destination@2.0.1:
+ dependencies:
+ micromark-util-character: 2.1.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-factory-label@2.0.1:
+ dependencies:
+ devlop: 1.1.0
+ micromark-util-character: 2.1.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-factory-space@2.0.1:
+ dependencies:
+ micromark-util-character: 2.1.1
+ micromark-util-types: 2.0.1
+
+ micromark-factory-title@2.0.1:
+ dependencies:
+ micromark-factory-space: 2.0.1
+ micromark-util-character: 2.1.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-factory-whitespace@2.0.1:
+ dependencies:
+ micromark-factory-space: 2.0.1
+ micromark-util-character: 2.1.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-util-character@2.1.1:
+ dependencies:
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-util-chunked@2.0.1:
+ dependencies:
+ micromark-util-symbol: 2.0.1
+
+ micromark-util-classify-character@2.0.1:
+ dependencies:
+ micromark-util-character: 2.1.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-util-combine-extensions@2.0.1:
+ dependencies:
+ micromark-util-chunked: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-util-decode-numeric-character-reference@2.0.2:
+ dependencies:
+ micromark-util-symbol: 2.0.1
+
+ micromark-util-encode@2.0.1: {}
+
+ micromark-util-html-tag-name@2.0.1: {}
+
+ micromark-util-normalize-identifier@2.0.1:
+ dependencies:
+ micromark-util-symbol: 2.0.1
+
+ micromark-util-resolve-all@2.0.1:
+ dependencies:
+ micromark-util-types: 2.0.1
+
+ micromark-util-sanitize-uri@2.0.1:
+ dependencies:
+ micromark-util-character: 2.1.1
+ micromark-util-encode: 2.0.1
+ micromark-util-symbol: 2.0.1
+
+ micromark-util-subtokenize@2.0.3:
+ dependencies:
+ devlop: 1.1.0
+ micromark-util-chunked: 2.0.1
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+
+ micromark-util-symbol@2.0.1: {}
+
+ micromark-util-types@2.0.1: {}
+
+ micromark@4.0.1:
+ dependencies:
+ '@types/debug': 4.1.12
+ debug: 4.4.0
+ decode-named-character-reference: 1.0.2
+ devlop: 1.1.0
+ micromark-core-commonmark: 2.0.2
+ micromark-factory-space: 2.0.1
+ micromark-util-character: 2.1.1
+ micromark-util-chunked: 2.0.1
+ micromark-util-combine-extensions: 2.0.1
+ micromark-util-decode-numeric-character-reference: 2.0.2
+ micromark-util-encode: 2.0.1
+ micromark-util-normalize-identifier: 2.0.1
+ micromark-util-resolve-all: 2.0.1
+ micromark-util-sanitize-uri: 2.0.1
+ micromark-util-subtokenize: 2.0.3
+ micromark-util-symbol: 2.0.1
+ micromark-util-types: 2.0.1
+ transitivePeerDependencies:
+ - supports-color
+
+ micromatch@4.0.8:
+ dependencies:
+ braces: 3.0.3
+ picomatch: 2.3.1
+
+ mimic-function@5.0.1: {}
+
+ minimatch@3.1.2:
+ dependencies:
+ brace-expansion: 1.1.11
+ optional: true
+
+ minimatch@9.0.5:
+ dependencies:
+ brace-expansion: 2.0.1
+ optional: true
+
+ minipass-collect@2.0.1:
+ dependencies:
+ minipass: 7.1.2
+ optional: true
+
+ minipass-fetch@3.0.5:
+ dependencies:
+ minipass: 7.1.2
+ minipass-sized: 1.0.3
+ minizlib: 2.1.2
+ optionalDependencies:
+ encoding: 0.1.13
+ optional: true
+
+ minipass-flush@1.0.5:
+ dependencies:
+ minipass: 3.3.6
+ optional: true
+
+ minipass-pipeline@1.2.4:
+ dependencies:
+ minipass: 3.3.6
+ optional: true
+
+ minipass-sized@1.0.3:
+ dependencies:
+ minipass: 3.3.6
+ optional: true
+
+ minipass@3.3.6:
+ dependencies:
+ yallist: 4.0.0
+ optional: true
+
+ minipass@5.0.0:
+ optional: true
+
+ minipass@7.1.2:
+ optional: true
+
+ minizlib@2.1.2:
+ dependencies:
+ minipass: 3.3.6
+ yallist: 4.0.0
+ optional: true
+
+ mitt@3.0.1: {}
+
+ mj-context-menu@0.6.1: {}
+
+ mkdirp@1.0.4:
+ optional: true
+
+ ms@2.1.3: {}
+
+ nano-staged@0.8.0:
+ dependencies:
+ picocolors: 1.1.1
+
+ nanoid@3.3.8: {}
+
+ nanoid@5.0.9: {}
+
+ negotiator@0.6.4:
+ optional: true
+
+ node-addon-api@8.3.0:
+ optional: true
+
+ node-fetch@2.7.0(encoding@0.1.13):
+ dependencies:
+ whatwg-url: 5.0.0
+ optionalDependencies:
+ encoding: 0.1.13
+ optional: true
+
+ node-gyp@10.3.1:
+ dependencies:
+ env-paths: 2.2.1
+ exponential-backoff: 3.1.1
+ glob: 10.4.5
+ graceful-fs: 4.2.11
+ make-fetch-happen: 13.0.1
+ nopt: 7.2.1
+ proc-log: 4.2.0
+ semver: 7.6.3
+ tar: 6.2.1
+ which: 4.0.0
+ transitivePeerDependencies:
+ - supports-color
+ optional: true
+
+ node-releases@2.0.19: {}
+
+ nodejs-jieba@0.2.1(encoding@0.1.13):
+ dependencies:
+ '@mapbox/node-pre-gyp': 1.0.11(encoding@0.1.13)
+ node-addon-api: 8.3.0
+ node-gyp: 10.3.1
+ transitivePeerDependencies:
+ - encoding
+ - supports-color
+ optional: true
+
+ nopt@5.0.0:
+ dependencies:
+ abbrev: 1.1.1
+ optional: true
+
+ nopt@7.2.1:
+ dependencies:
+ abbrev: 2.0.0
+ optional: true
+
+ normalize-path@3.0.0: {}
+
+ normalize-range@0.1.2: {}
+
+ npm-run-path@6.0.0:
+ dependencies:
+ path-key: 4.0.0
+ unicorn-magic: 0.3.0
+
+ npmlog@5.0.1:
+ dependencies:
+ are-we-there-yet: 2.0.0
+ console-control-strings: 1.1.0
+ gauge: 3.0.2
+ set-blocking: 2.0.0
+ optional: true
+
+ nth-check@2.1.1:
+ dependencies:
+ boolbase: 1.0.0
+
+ object-assign@4.1.1:
+ optional: true
+
+ once@1.4.0:
+ dependencies:
+ wrappy: 1.0.2
+ optional: true
+
+ onetime@7.0.0:
+ dependencies:
+ mimic-function: 5.0.1
+
+ oniguruma-to-es@1.0.0:
+ dependencies:
+ emoji-regex-xs: 1.0.0
+ regex: 5.1.1
+ regex-recursion: 5.1.1
+
+ ora@8.1.1:
+ dependencies:
+ chalk: 5.4.1
+ cli-cursor: 5.0.0
+ cli-spinners: 2.9.2
+ is-interactive: 2.0.0
+ is-unicode-supported: 2.1.0
+ log-symbols: 6.0.0
+ stdin-discarder: 0.2.2
+ string-width: 7.2.0
+ strip-ansi: 7.1.0
+
+ p-limit@2.3.0:
+ dependencies:
+ p-try: 2.2.0
+
+ p-locate@4.1.0:
+ dependencies:
+ p-limit: 2.3.0
+
+ p-map@4.0.0:
+ dependencies:
+ aggregate-error: 3.1.0
+ optional: true
+
+ p-try@2.2.0: {}
+
+ package-json-from-dist@1.0.1:
+ optional: true
+
+ parse-entities@4.0.2:
+ dependencies:
+ '@types/unist': 2.0.11
+ character-entities-legacy: 3.0.0
+ character-reference-invalid: 2.0.1
+ decode-named-character-reference: 1.0.2
+ is-alphanumerical: 2.0.1
+ is-decimal: 2.0.1
+ is-hexadecimal: 2.0.1
+
+ parse-ms@4.0.0: {}
+
+ parse5-htmlparser2-tree-adapter@7.1.0:
+ dependencies:
+ domhandler: 5.0.3
+ parse5: 7.2.1
+
+ parse5-parser-stream@7.1.2:
+ dependencies:
+ parse5: 7.2.1
+
+ parse5@7.2.1:
+ dependencies:
+ entities: 4.5.0
+
+ path-exists@4.0.0: {}
+
+ path-is-absolute@1.0.1:
+ optional: true
+
+ path-key@3.1.1: {}
+
+ path-key@4.0.0: {}
+
+ path-scurry@1.11.1:
+ dependencies:
+ lru-cache: 10.4.3
+ minipass: 7.1.2
+ optional: true
+
+ path-type@5.0.0: {}
+
+ perfect-debounce@1.0.0: {}
+
+ photoswipe@5.4.4: {}
+
+ picocolors@1.1.1: {}
+
+ picomatch@2.3.1: {}
+
+ pngjs@5.0.0: {}
+
+ postcss-load-config@6.0.1(postcss@8.5.0):
+ dependencies:
+ lilconfig: 3.1.3
+ optionalDependencies:
+ postcss: 8.5.0
+
+ postcss-value-parser@4.2.0: {}
+
+ postcss@8.5.0:
+ dependencies:
+ nanoid: 3.3.8
+ picocolors: 1.1.1
+ source-map-js: 1.2.1
+
+ prettier@3.4.2: {}
+
+ pretty-ms@9.2.0:
+ dependencies:
+ parse-ms: 4.0.0
+
+ proc-log@4.2.0:
+ optional: true
+
+ promise-retry@2.0.1:
+ dependencies:
+ err-code: 2.0.3
+ retry: 0.12.0
+ optional: true
+
+ property-information@6.5.0: {}
+
+ punycode.js@2.3.1: {}
+
+ qrcode@1.5.4:
+ dependencies:
+ dijkstrajs: 1.0.3
+ pngjs: 5.0.0
+ yargs: 15.4.1
+
+ queue-microtask@1.2.3: {}
+
+ readable-stream@3.6.2:
+ dependencies:
+ inherits: 2.0.4
+ string_decoder: 1.3.0
+ util-deprecate: 1.0.2
+ optional: true
+
+ readdirp@3.6.0:
+ dependencies:
+ picomatch: 2.3.1
+
+ readdirp@4.1.1: {}
+
+ regex-recursion@5.1.1:
+ dependencies:
+ regex: 5.1.1
+ regex-utilities: 2.3.0
+
+ regex-utilities@2.3.0: {}
+
+ regex@5.1.1:
+ dependencies:
+ regex-utilities: 2.3.0
+
+ require-directory@2.1.1: {}
+
+ require-main-filename@2.0.0: {}
+
+ restore-cursor@5.1.0:
+ dependencies:
+ onetime: 7.0.0
+ signal-exit: 4.1.0
+
+ retry@0.12.0:
+ optional: true
+
+ reusify@1.0.4: {}
+
+ rfdc@1.4.1: {}
+
+ rimraf@3.0.2:
+ dependencies:
+ glob: 7.2.3
+ optional: true
+
+ rollup@4.30.1:
+ dependencies:
+ '@types/estree': 1.0.6
+ optionalDependencies:
+ '@rollup/rollup-android-arm-eabi': 4.30.1
+ '@rollup/rollup-android-arm64': 4.30.1
+ '@rollup/rollup-darwin-arm64': 4.30.1
+ '@rollup/rollup-darwin-x64': 4.30.1
+ '@rollup/rollup-freebsd-arm64': 4.30.1
+ '@rollup/rollup-freebsd-x64': 4.30.1
+ '@rollup/rollup-linux-arm-gnueabihf': 4.30.1
+ '@rollup/rollup-linux-arm-musleabihf': 4.30.1
+ '@rollup/rollup-linux-arm64-gnu': 4.30.1
+ '@rollup/rollup-linux-arm64-musl': 4.30.1
+ '@rollup/rollup-linux-loongarch64-gnu': 4.30.1
+ '@rollup/rollup-linux-powerpc64le-gnu': 4.30.1
+ '@rollup/rollup-linux-riscv64-gnu': 4.30.1
+ '@rollup/rollup-linux-s390x-gnu': 4.30.1
+ '@rollup/rollup-linux-x64-gnu': 4.30.1
+ '@rollup/rollup-linux-x64-musl': 4.30.1
+ '@rollup/rollup-win32-arm64-msvc': 4.30.1
+ '@rollup/rollup-win32-ia32-msvc': 4.30.1
+ '@rollup/rollup-win32-x64-msvc': 4.30.1
+ fsevents: 2.3.3
+
+ run-parallel@1.2.0:
+ dependencies:
+ queue-microtask: 1.2.3
+
+ rxjs@7.8.1:
+ dependencies:
+ tslib: 2.8.1
+
+ safe-buffer@5.2.1:
+ optional: true
+
+ safer-buffer@2.1.2: {}
+
+ sass-embedded-android-arm64@1.83.1:
+ optional: true
+
+ sass-embedded-android-arm@1.83.1:
+ optional: true
+
+ sass-embedded-android-ia32@1.83.1:
+ optional: true
+
+ sass-embedded-android-riscv64@1.83.1:
+ optional: true
+
+ sass-embedded-android-x64@1.83.1:
+ optional: true
+
+ sass-embedded-darwin-arm64@1.83.1:
+ optional: true
+
+ sass-embedded-darwin-x64@1.83.1:
+ optional: true
+
+ sass-embedded-linux-arm64@1.83.1:
+ optional: true
+
+ sass-embedded-linux-arm@1.83.1:
+ optional: true
+
+ sass-embedded-linux-ia32@1.83.1:
+ optional: true
+
+ sass-embedded-linux-musl-arm64@1.83.1:
+ optional: true
+
+ sass-embedded-linux-musl-arm@1.83.1:
+ optional: true
+
+ sass-embedded-linux-musl-ia32@1.83.1:
+ optional: true
+
+ sass-embedded-linux-musl-riscv64@1.83.1:
+ optional: true
+
+ sass-embedded-linux-musl-x64@1.83.1:
+ optional: true
+
+ sass-embedded-linux-riscv64@1.83.1:
+ optional: true
+
+ sass-embedded-linux-x64@1.83.1:
+ optional: true
+
+ sass-embedded-win32-arm64@1.83.1:
+ optional: true
+
+ sass-embedded-win32-ia32@1.83.1:
+ optional: true
+
+ sass-embedded-win32-x64@1.83.1:
+ optional: true
+
+ sass-embedded@1.83.1:
+ dependencies:
+ '@bufbuild/protobuf': 2.2.3
+ buffer-builder: 0.2.0
+ colorjs.io: 0.5.2
+ immutable: 5.0.3
+ rxjs: 7.8.1
+ supports-color: 8.1.1
+ sync-child-process: 1.0.2
+ varint: 6.0.0
+ optionalDependencies:
+ sass-embedded-android-arm: 1.83.1
+ sass-embedded-android-arm64: 1.83.1
+ sass-embedded-android-ia32: 1.83.1
+ sass-embedded-android-riscv64: 1.83.1
+ sass-embedded-android-x64: 1.83.1
+ sass-embedded-darwin-arm64: 1.83.1
+ sass-embedded-darwin-x64: 1.83.1
+ sass-embedded-linux-arm: 1.83.1
+ sass-embedded-linux-arm64: 1.83.1
+ sass-embedded-linux-ia32: 1.83.1
+ sass-embedded-linux-musl-arm: 1.83.1
+ sass-embedded-linux-musl-arm64: 1.83.1
+ sass-embedded-linux-musl-ia32: 1.83.1
+ sass-embedded-linux-musl-riscv64: 1.83.1
+ sass-embedded-linux-musl-x64: 1.83.1
+ sass-embedded-linux-riscv64: 1.83.1
+ sass-embedded-linux-x64: 1.83.1
+ sass-embedded-win32-arm64: 1.83.1
+ sass-embedded-win32-ia32: 1.83.1
+ sass-embedded-win32-x64: 1.83.1
+
+ sax@1.4.1: {}
+
+ section-matter@1.0.0:
+ dependencies:
+ extend-shallow: 2.0.1
+ kind-of: 6.0.3
+
+ semver@6.3.1:
+ optional: true
+
+ semver@7.6.3:
+ optional: true
+
+ set-blocking@2.0.0: {}
+
+ shebang-command@2.0.0:
+ dependencies:
+ shebang-regex: 3.0.0
+
+ shebang-regex@3.0.0: {}
+
+ shiki@1.26.2:
+ dependencies:
+ '@shikijs/core': 1.26.2
+ '@shikijs/engine-javascript': 1.26.2
+ '@shikijs/engine-oniguruma': 1.26.2
+ '@shikijs/langs': 1.26.2
+ '@shikijs/themes': 1.26.2
+ '@shikijs/types': 1.26.2
+ '@shikijs/vscode-textmate': 10.0.1
+ '@types/hast': 3.0.4
+
+ signal-exit@3.0.7:
+ optional: true
+
+ signal-exit@4.1.0: {}
+
+ sitemap@8.0.0:
+ dependencies:
+ '@types/node': 17.0.45
+ '@types/sax': 1.2.7
+ arg: 5.0.2
+ sax: 1.4.1
+
+ slash@5.1.0: {}
+
+ smart-buffer@4.2.0:
+ optional: true
+
+ socks-proxy-agent@8.0.5:
+ dependencies:
+ agent-base: 7.1.3
+ debug: 4.4.0
+ socks: 2.8.3
+ transitivePeerDependencies:
+ - supports-color
+ optional: true
+
+ socks@2.8.3:
+ dependencies:
+ ip-address: 9.0.5
+ smart-buffer: 4.2.0
+ optional: true
+
+ source-map-js@1.2.1: {}
+
+ space-separated-tokens@2.0.2: {}
+
+ speakingurl@14.0.1: {}
+
+ speech-rule-engine@4.0.7:
+ dependencies:
+ commander: 9.2.0
+ wicked-good-xpath: 1.3.0
+ xmldom-sre: 0.1.31
+
+ sprintf-js@1.0.3: {}
+
+ sprintf-js@1.1.3:
+ optional: true
+
+ ssri@10.0.6:
+ dependencies:
+ minipass: 7.1.2
+ optional: true
+
+ stdin-discarder@0.2.2: {}
+
+ string-width@4.2.3:
+ dependencies:
+ emoji-regex: 8.0.0
+ is-fullwidth-code-point: 3.0.0
+ strip-ansi: 6.0.1
+
+ string-width@5.1.2:
+ dependencies:
+ eastasianwidth: 0.2.0
+ emoji-regex: 9.2.2
+ strip-ansi: 7.1.0
+ optional: true
+
+ string-width@7.2.0:
+ dependencies:
+ emoji-regex: 10.4.0
+ get-east-asian-width: 1.3.0
+ strip-ansi: 7.1.0
+
+ string_decoder@1.3.0:
+ dependencies:
+ safe-buffer: 5.2.1
+ optional: true
+
+ stringify-entities@4.0.4:
+ dependencies:
+ character-entities-html4: 2.1.0
+ character-entities-legacy: 3.0.0
+
+ strip-ansi@6.0.1:
+ dependencies:
+ ansi-regex: 5.0.1
+
+ strip-ansi@7.1.0:
+ dependencies:
+ ansi-regex: 6.1.0
+
+ strip-bom-string@1.0.0: {}
+
+ strip-final-newline@4.0.0: {}
+
+ superjson@2.2.2:
+ dependencies:
+ copy-anything: 3.0.5
+
+ supports-color@8.1.1:
+ dependencies:
+ has-flag: 4.0.0
+
+ sync-child-process@1.0.2:
+ dependencies:
+ sync-message-port: 1.1.3
+
+ sync-message-port@1.1.3: {}
+
+ tar@6.2.1:
+ dependencies:
+ chownr: 2.0.0
+ fs-minipass: 2.1.0
+ minipass: 5.0.0
+ minizlib: 2.1.2
+ mkdirp: 1.0.4
+ yallist: 4.0.0
+ optional: true
+
+ to-regex-range@5.0.1:
+ dependencies:
+ is-number: 7.0.0
+
+ tr46@0.0.3:
+ optional: true
+
+ trim-lines@3.0.1: {}
+
+ tslib@2.8.1: {}
+
+ uc.micro@2.1.0: {}
+
+ undici-types@6.20.0: {}
+
+ undici@6.21.0: {}
+
+ unicorn-magic@0.1.0: {}
+
+ unicorn-magic@0.3.0: {}
+
+ unique-filename@3.0.0:
+ dependencies:
+ unique-slug: 4.0.0
+ optional: true
+
+ unique-slug@4.0.0:
+ dependencies:
+ imurmurhash: 0.1.4
+ optional: true
+
+ unist-util-is@6.0.0:
+ dependencies:
+ '@types/unist': 3.0.3
+
+ unist-util-position@5.0.0:
+ dependencies:
+ '@types/unist': 3.0.3
+
+ unist-util-stringify-position@4.0.0:
+ dependencies:
+ '@types/unist': 3.0.3
+
+ unist-util-visit-parents@6.0.1:
+ dependencies:
+ '@types/unist': 3.0.3
+ unist-util-is: 6.0.0
+
+ unist-util-visit@5.0.0:
+ dependencies:
+ '@types/unist': 3.0.3
+ unist-util-is: 6.0.0
+ unist-util-visit-parents: 6.0.1
+
+ universalify@2.0.1: {}
+
+ upath@2.0.1: {}
+
+ update-browserslist-db@1.1.2(browserslist@4.24.4):
+ dependencies:
+ browserslist: 4.24.4
+ escalade: 3.2.0
+ picocolors: 1.1.1
+
+ util-deprecate@1.0.2:
+ optional: true
+
+ varint@6.0.0: {}
+
+ vfile-message@4.0.2:
+ dependencies:
+ '@types/unist': 3.0.3
+ unist-util-stringify-position: 4.0.0
+
+ vfile@6.0.3:
+ dependencies:
+ '@types/unist': 3.0.3
+ vfile-message: 4.0.2
+
+ vite@6.0.7(@types/node@22.10.5)(sass-embedded@1.83.1):
+ dependencies:
+ esbuild: 0.24.2
+ postcss: 8.5.0
+ rollup: 4.30.1
+ optionalDependencies:
+ '@types/node': 22.10.5
+ fsevents: 2.3.3
+ sass-embedded: 1.83.1
+
+ vue-router@4.5.0(vue@3.5.13):
+ dependencies:
+ '@vue/devtools-api': 6.6.4
+ vue: 3.5.13
+
+ vue@3.5.13:
+ dependencies:
+ '@vue/compiler-dom': 3.5.13
+ '@vue/compiler-sfc': 3.5.13
+ '@vue/runtime-dom': 3.5.13
+ '@vue/server-renderer': 3.5.13(vue@3.5.13)
+ '@vue/shared': 3.5.13
+
+ vuepress-plugin-components@2.0.0-rc.68(sass-embedded@1.83.1)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)):
+ dependencies:
+ '@stackblitz/sdk': 1.11.0
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-sass-palette': 2.0.0-rc.70(sass-embedded@1.83.1)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ balloon-css: 1.2.0
+ create-codepen: 2.0.0
+ qrcode: 1.5.4
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ vuepress-shared: 2.0.0-rc.68(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ optionalDependencies:
+ sass-embedded: 1.83.1
+ transitivePeerDependencies:
+ - typescript
+
+ vuepress-plugin-md-enhance@2.0.0-rc.68(markdown-it@14.1.0)(sass-embedded@1.83.1)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)):
+ dependencies:
+ '@mdit/plugin-container': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-demo': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-plantuml': 0.16.0(markdown-it@14.1.0)
+ '@mdit/plugin-uml': 0.16.0(markdown-it@14.1.0)
+ '@types/markdown-it': 14.1.2
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-sass-palette': 2.0.0-rc.70(sass-embedded@1.83.1)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ balloon-css: 1.2.0
+ js-yaml: 4.1.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ vuepress-shared: 2.0.0-rc.68(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ optionalDependencies:
+ sass-embedded: 1.83.1
+ transitivePeerDependencies:
+ - markdown-it
+ - typescript
+
+ vuepress-shared@2.0.0-rc.68(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)):
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ dayjs: 1.11.13
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ transitivePeerDependencies:
+ - typescript
+
+ vuepress-theme-hope@2.0.0-rc.68(@vuepress/plugin-feed@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)))(@vuepress/plugin-search@2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)))(katex@0.16.20)(markdown-it@14.1.0)(mathjax-full@3.2.2)(nodejs-jieba@0.2.1(encoding@0.1.13))(sass-embedded@1.83.1)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)):
+ dependencies:
+ '@vuepress/helper': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-active-header-links': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-back-to-top': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-blog': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-catalog': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-comment': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-copy-code': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-copyright': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-git': 2.0.0-rc.68(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-icon': 2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-links-check': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-markdown-ext': 2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-markdown-hint': 2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-markdown-image': 2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-markdown-include': 2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-markdown-math': 2.0.0-rc.70(katex@0.16.20)(markdown-it@14.1.0)(mathjax-full@3.2.2)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-markdown-stylize': 2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-markdown-tab': 2.0.0-rc.70(markdown-it@14.1.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-notice': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-nprogress': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-photo-swipe': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-reading-time': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-redirect': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-rtl': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-sass-palette': 2.0.0-rc.70(sass-embedded@1.83.1)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-seo': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-shiki': 2.0.0-rc.70(@vueuse/core@12.4.0)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-sitemap': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-theme-data': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vueuse/core': 12.4.0
+ balloon-css: 1.2.0
+ bcrypt-ts: 5.0.3
+ chokidar: 3.6.0
+ vue: 3.5.13
+ vuepress: 2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13)
+ vuepress-plugin-components: 2.0.0-rc.68(sass-embedded@1.83.1)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vuepress-plugin-md-enhance: 2.0.0-rc.68(markdown-it@14.1.0)(sass-embedded@1.83.1)(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ vuepress-shared: 2.0.0-rc.68(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ optionalDependencies:
+ '@vuepress/plugin-feed': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ '@vuepress/plugin-search': 2.0.0-rc.70(vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13))
+ nodejs-jieba: 0.2.1(encoding@0.1.13)
+ sass-embedded: 1.83.1
+ transitivePeerDependencies:
+ - '@vue/repl'
+ - '@waline/client'
+ - artalk
+ - artplayer
+ - chart.js
+ - dashjs
+ - echarts
+ - flowchart.ts
+ - hls.js
+ - katex
+ - kotlin-playground
+ - markdown-it
+ - markmap-lib
+ - markmap-toolbar
+ - markmap-view
+ - mathjax-full
+ - mermaid
+ - mpegts.js
+ - sandpack-vue3
+ - twikoo
+ - typescript
+ - vidstack
+
+ vuepress@2.0.0-rc.19(@vuepress/bundler-vite@2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1))(vue@3.5.13):
+ dependencies:
+ '@vuepress/cli': 2.0.0-rc.19
+ '@vuepress/client': 2.0.0-rc.19
+ '@vuepress/core': 2.0.0-rc.19
+ '@vuepress/markdown': 2.0.0-rc.19
+ '@vuepress/shared': 2.0.0-rc.19
+ '@vuepress/utils': 2.0.0-rc.19
+ vue: 3.5.13
+ optionalDependencies:
+ '@vuepress/bundler-vite': 2.0.0-rc.19(@types/node@22.10.5)(sass-embedded@1.83.1)
+ transitivePeerDependencies:
+ - supports-color
+ - typescript
+
+ webidl-conversions@3.0.1:
+ optional: true
+
+ whatwg-encoding@3.1.1:
+ dependencies:
+ iconv-lite: 0.6.3
+
+ whatwg-mimetype@4.0.0: {}
+
+ whatwg-url@5.0.0:
+ dependencies:
+ tr46: 0.0.3
+ webidl-conversions: 3.0.1
+ optional: true
+
+ which-module@2.0.1: {}
+
+ which@2.0.2:
+ dependencies:
+ isexe: 2.0.0
+
+ which@4.0.0:
+ dependencies:
+ isexe: 3.1.1
+ optional: true
+
+ wicked-good-xpath@1.3.0: {}
+
+ wide-align@1.1.5:
+ dependencies:
+ string-width: 4.2.3
+ optional: true
+
+ wrap-ansi@6.2.0:
+ dependencies:
+ ansi-styles: 4.3.0
+ string-width: 4.2.3
+ strip-ansi: 6.0.1
+
+ wrap-ansi@7.0.0:
+ dependencies:
+ ansi-styles: 4.3.0
+ string-width: 4.2.3
+ strip-ansi: 6.0.1
+ optional: true
+
+ wrap-ansi@8.1.0:
+ dependencies:
+ ansi-styles: 6.2.1
+ string-width: 5.1.2
+ strip-ansi: 7.1.0
+ optional: true
+
+ wrappy@1.0.2:
+ optional: true
+
+ xml-js@1.6.11:
+ dependencies:
+ sax: 1.4.1
+
+ xmldom-sre@0.1.31: {}
+
+ y18n@4.0.3: {}
+
+ yallist@4.0.0:
+ optional: true
+
+ yargs-parser@18.1.3:
+ dependencies:
+ camelcase: 5.3.1
+ decamelize: 1.2.0
+
+ yargs@15.4.1:
+ dependencies:
+ cliui: 6.0.0
+ decamelize: 1.2.0
+ find-up: 4.1.0
+ get-caller-file: 2.0.5
+ require-directory: 2.1.1
+ require-main-filename: 2.0.0
+ set-blocking: 2.0.0
+ string-width: 4.2.3
+ which-module: 2.0.1
+ y18n: 4.0.3
+ yargs-parser: 18.1.3
+
+ yoctocolors@2.1.1: {}
+
+ zwitch@2.0.4: {}
-
+
+这句话表面上看似有道理，但实际上却暴露了一个人的**无知和偏执**。
+
+**知识越贫乏的人，相信的东西就越绝对**，因为他们从未认真了解过与自己观点相对立的角度，也缺乏对技术发展的全局认识。
+
+举个例子，我刚开始学习 Java 后端开发的时候，完全没什么经验，就随便买了一本书开始看。当时看的是**《Java Web 整合开发王者归来》**这本书（梦开始的地方）。
+
+在我上大学那会儿，这本书的很多内容其实已经过时了，比如它花了大量篇幅介绍 JSP、Struts、Hibernate、EJB 和 SVN 等技术。不过，直到现在，我依然非常感谢这本书，带我走进了 Java 后端开发的大门。
+
+
+
+这本书一共 **1010** 页，我当时可以说是废寝忘食地学，花了很长时间才把整本书完全“啃”下来。
+
+回头来看，我如果能有意识地避免学习这些已经淘汰的技术，真的可以节省大量时间去学习更加主流和实用的内容。
+
+那么，这些被淘汰的技术有用吗？说句实话，**屁用没有，纯粹浪费时间**。
+
+**既然都要花时间学习，为什么不去学那些更主流、更有实际价值的技术呢？**
+
+现在本身就很卷，不管是 Java 方向还是其他技术方向，要学习的技术都很多。
+
+想要理解所谓的“底层思想”，与其浪费时间在 JSP 这种已经不具备实际应用价值的技术上，不如深入学习一下 Servlet，研究 Spring 的 AOP 和 IoC 原理，从源码角度理解 Spring MVC 的工作机制。
+
+这些内容，不仅能帮助你掌握核心的思想，还能在实际开发中真正派上用场，这难道不比花大量时间在 JSP 上更有意义吗？
+
+## 还有公司在用的技术就要学吗？
+
+我把这篇文章的相关言论发表在我的[公众号](https://mp.weixin.qq.com/s/lf2dXHcrUSU1pn28Ercj0w)之后，又收到另外一类在我看来非常傻叉的言论：
+
+- “虽然 JSP 很老了，但还是得学学，会用就行，因为我们很多老项目还在用。”
+- “很多央企和国企的老项目还在用，肯定得学学啊！”
+
+这种观点完全是钻牛角尖！如果按这种逻辑，那你还需要去学 Struts2、SVN、JavaFX 等过时技术，因为它们也还有公司在用。我有一位大学同学毕业后去了武汉的一家国企，写了一年 JavaFX 就受不了跑了。他在之前从来没有接触过 JavaFX，招聘时也没被问过相关问题。
+
+一定不要假设自己要面对的是过时技术栈的项目。你要找工作肯定要用主流技术栈去找，还要尽量找能让自己技术有成长，干着也舒服点。真要是找不到合适的工作，去维护老项目，那都是后话，现学现卖就行了。
+
+**对于初学者来说别人劝了还非要学习淘汰的技术，多少脑子有点不够用，基本可以告别这一行了！**
diff --git a/docs/about-the-author/internet-addiction-teenager.md b/docs/about-the-author/internet-addiction-teenager.md
index d4a34b8fc27..78f94e2a483 100644
--- a/docs/about-the-author/internet-addiction-teenager.md
+++ b/docs/about-the-author/internet-addiction-teenager.md
@@ -5,7 +5,7 @@ tag:
- 个人经历
---
-> 这篇文章写入 2021 年高考前夕。
+> 这篇文章写于 2021 年高考前夕。
聊到高考，无数人都似乎有很多话说。今天就假借高考的名义，简单来聊聊我的高中求学经历吧！
@@ -19,7 +19,11 @@ tag:
最开始接触电脑是在我刚上五年级的时候，那时候家里没电脑，刚开始上网都是在黑网吧玩的。
-在黑网吧上网的经历也是一波三折，经常会遇到警察来检查或者碰到大孩子骚扰。在黑网吧上网的一年多中，我一共两次碰到警察来检查，主要是看有没有未成年人（当时黑网吧里几乎全是未成年人），实际感觉像是要问黑网吧老板要点好处。碰到大孩子骚扰的次数就比较多，大孩子经常抢我电脑，还威胁我把身上所有的钱给他们。我当时一个人也比较怂，被打了几次之后，就尽量避开大孩子来玩的时间去黑网吧，身上也只带很少的钱。小时候的性格就比较独立，在外遇到事情我一般也不会给家里人说。
+黑网吧大概就是下面这样式儿的，一个没有窗户的房间里放了很多台老式电脑，非常拥挤。
+
+
+
+在黑网吧上网的经历也是一波三折，经常会遇到警察来检查或者碰到大孩子骚扰。在黑网吧上网的一年多中，我一共两次碰到警察来检查，主要是看有没有未成年人（当时黑网吧里几乎全是未成年人），实际感觉像是要问黑网吧老板要点好处。碰到大孩子骚扰的次数就比较多，大孩子经常抢我电脑，还威胁我把身上所有的钱给他们。我当时一个人也比较怂，被打了几次之后，就尽量避开大孩子来玩的时间去黑网吧，身上也只带很少的钱。小时候的性格就比较独立，在外遇到事情我一般也不会给家里人说（因为说了也没什么用，家人给我的安全感很少）。
我现在已经记不太清当时是被我哥还是我姐带进网吧的，好像是我姐。
@@ -57,6 +61,10 @@ QQ 飞车这款戏当时还挺火的，很多 90 后的小伙伴应该比较熟
我的最终军衔停留在了两个钻石，玩过的小伙伴应该清楚这在当时要玩多少把（现在升级比较简单）。
+
+
+ps: 回坑 CF 快一年了，目前的军衔是到了两颗星中校 3 了。
+
那时候成绩挺差的。这样说吧！我当时在很普通的一个县级市的高中，全年级有 500 来人，我基本都是在 280 名左右。而且，整个初二我都没有学物理，上物理课就睡觉，考试就交白卷。
为什么对物理这么抵触呢？这是因为开学不久的一次物理课，物理老师误会我在上课吃东西还狡辩，扇了我一巴掌。那时候心里一直记仇到大学，想着以后自己早晚有时间把这个物理老师暴打一顿。
@@ -81,6 +89,8 @@ QQ 飞车这款戏当时还挺火的，很多 90 后的小伙伴应该比较熟
## 高中从小班掉到平行班
+
+
由于参加了高中提前招生考试，我提前 4 个月就来到了高中，进入了小班，开始学习高中的课程。
上了高中的之后，我上课就偷偷看小说，神印王座、斗罗大陆、斗破苍穹很多小说都是当时看的。中午和晚上回家之后，就在家里玩几把 DNF。当时家里也买了电脑，姥爷给买的，是对自己顺利进入二中的奖励。到我卸载 DNF 的时候，已经练了 4 个满级的号，两个接近满级的号。
@@ -117,9 +127,11 @@ QQ 飞车这款戏当时还挺火的，很多 90 后的小伙伴应该比较熟
-高考那几天的失眠，我觉得可能和我喝了老师推荐的安神补脑液有关系，又或者是我自己太过于紧张了。因为那几天睡觉总会感觉有很多蚂蚁在身上爬一样，身上还起了一些小痘痘。
+高考那几天的失眠，我觉得可能和我喝了老师推荐的安神补脑液有关系，又或者是我自己太过于紧张了。因为那几天睡觉总会感觉有很多蚂蚁在身上爬一样，身上还起了一些小痘痘（有点像是过敏）。
+
+这里要格外说明一点，避免引起误导：**睡不着本身就是自身的问题，上述言论并没有责怪这个补脑液的意思。** 另外， 这款安神补脑液我去各个平台都查了一下，发现大家对他的评价都挺好，和我们老师当时推荐的理由差不多。如果大家需要改善睡眠的话，可以咨询相关医生之后尝试一下。
-然后，这里要格外说明一点，避免引起误导：**睡不着本身就是自身的问题，上述言论并没有责怪这个补脑液的意思。** 另外， 这款安神补脑液我去各个平台都查了一下，发现大家对他的评价都挺好，和我们老师当时推荐的理由差不多。如果大家需要改善睡眠的话，可以咨询相关医生之后尝试一下。
+高考也确实没发挥好，整个人在考场都是懵的状态。高考成绩出来之后，比我自己预估的还低了几十分，最后只上了一个双非一本。不过，好在专业选的好，吃了一些计算机专业的红利，大学期间也挺努力的。
## 大学生活
diff --git a/docs/about-the-author/zhishixingqiu-two-years.md b/docs/about-the-author/zhishixingqiu-two-years.md
index 77b0c5c1ceb..644478b455a 100644
--- a/docs/about-the-author/zhishixingqiu-two-years.md
+++ b/docs/about-the-author/zhishixingqiu-two-years.md
@@ -1,20 +1,18 @@
---
-title: 我的知识星球快 3 岁了！
+title: 我的知识星球 4 岁了！
category: 知识星球
star: 2
---
-截止到今天，我认真维护了接近四年的星球已经有 **2.3w+** 的同学加入了，也算是达成了自己当初的目标。虽然比不上很多大佬，但这于我来说也算是小有成就了，真的很满足了！我确信自己是一个普通人，能做成这些，也不过是在兴趣和运气的加持下赶上了时代而已。
-
-
-
-在 **2019 年 12 月 29 号**，经过了大概一年左右的犹豫期，我正式确定要开始做一个自己的星球，帮助学习 Java 和准备 Java 面试的同学。一转眼，马上快要四年了。感谢大家一路陪伴，我会信守承诺，继续认真维护这个纯粹的 Java 知识星球，不让信任我的读者失望。
+在 **2019 年 12 月 29 号**，经过了大概一年左右的犹豫期，我正式确定要开始做一个自己的星球，帮助学习 Java 和准备 Java 面试的同学。一转眼，已经四年多了。感谢大家一路陪伴，我会信守承诺，继续认真维护这个纯粹的 Java 知识星球，不让信任我的读者失望。
-我应该是最早一批做星球的技术号主，最开始的一两年，纯粹靠爱发电。当初定价非常低（一顿饭钱），加上刚工作的时候比较忙，提供的服务也没有现在这么多。
+我是比较早一批做星球的技术号主，也是坚持做下来的那一少部人（大部分博主割一波韭菜就不维护星球了）。最开始的一两年，纯粹靠爱发电。当初定价非常低（一顿饭钱），加上刚工作的时候比较忙，提供的服务也没有现在这么多。
+
+慢慢的价格提上来，星球的收入确实慢慢也上来了。不过，考虑到我的受众主要是学生，定价依然比同类星球低很多。另外，我也没有弄训练营的打算，虽然训练营对于我这个流量来说可以赚到更多钱。
**我有自己的原则，不割韭菜，用心做内容，真心希望帮助到他人！**
@@ -30,7 +28,7 @@ star: 2
1. 6 个高质量的专栏永久阅读，内容涵盖面试，源码解析，项目实战等内容！
2. 多本原创 PDF 版本面试手册免费领取。
-3. 免费的简历修改服务（已经累计帮助 5000+ 位球友修改简历）。
+3. 免费的简历修改服务（已经累计帮助 7000+ 位球友修改简历）。
4. 一对一免费提问交流（专属建议，走心回答）。
5. 专属求职指南和建议，让你少走弯路，效率翻倍！
6. 海量 Java 优质面试资源分享。
@@ -58,7 +56,7 @@ star: 2
### PDF 面试手册
-免费赠送多本优质 PDF 面试手册。
+进入星球就免费赠送多本优质 PDF 面试手册。
@@ -84,7 +82,7 @@ JavaGuide 知识星球优质主题汇总传送门：
@@ -167,4 +192,10 @@ MySQL 中时间到底怎么存储才好？Datetime?Timestamp?还是数值时间
| TIMESTAMP | 4~7 字节 | YYYY-MM-DD hh:mm:ss[.fraction] | 1970-01-01 00:00:01[.000000] ～ 2038-01-19 03:14:07[.999999] | 是 |
| 数值型时间戳 | 4 字节 | 全数字如 1578707612 | 1970-01-01 00:00:01 之后的时间 | 否 |
+**选择建议小结：**
+
+- `TIMESTAMP` 的核心优势在于其内建的时区处理能力。数据库负责 UTC 存储和基于会话时区的自动转换，简化了需要处理多时区应用的开发。如果应用需要处理多时区，或者希望数据库能自动管理时区转换，`TIMESTAMP` 是自然的选择（注意其时间范围限制，也就是 2038 年问题）。
+- 如果应用场景不涉及时区转换，或者希望应用程序完全控制时区逻辑，并且需要表示 2038 年之后的时间，`DATETIME` 是更稳妥的选择。
+- 如果极度关注比较性能，或者需要频繁跨系统传递时间数据，并且可以接受可读性的牺牲（或总是在应用层转换），数值时间戳是一个强大的选项。
+
diff --git a/docs/database/mysql/transaction-isolation-level.md b/docs/database/mysql/transaction-isolation-level.md
index 52ad40f4a47..8b706640ea6 100644
--- a/docs/database/mysql/transaction-isolation-level.md
+++ b/docs/database/mysql/transaction-isolation-level.md
@@ -11,43 +11,46 @@ tag:
## 事务隔离级别总结
-SQL 标准定义了四个隔离级别：
+SQL 标准定义了四种事务隔离级别，用来平衡事务的隔离性（Isolation）和并发性能。级别越高，数据一致性越好，但并发性能可能越低。这四个级别是：
-- **READ-UNCOMMITTED(读取未提交)** ：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
-- **READ-COMMITTED(读取已提交)** ：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
-- **REPEATABLE-READ(可重复读)** ：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
+- **READ-UNCOMMITTED(读取未提交)** ：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。这种级别在实际应用中很少使用，因为它对数据一致性的保证太弱。
+- **READ-COMMITTED(读取已提交)** ：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。这是大多数数据库（如 Oracle, SQL Server）的默认隔离级别。
+- **REPEATABLE-READ(可重复读)** ：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。MySQL InnoDB 存储引擎的默认隔离级别正是 REPEATABLE READ。并且，InnoDB 在此级别下通过 MVCC（多版本并发控制） 和 Next-Key Locks（间隙锁+行锁） 机制，在很大程度上解决了幻读问题。
- **SERIALIZABLE(可串行化)** ：最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
----
+| 隔离级别 | 脏读 (Dirty Read) | 不可重复读 (Non-Repeatable Read) | 幻读 (Phantom Read) |
+| ---------------- | ----------------- | -------------------------------- | ---------------------- |
+| READ UNCOMMITTED | √ | √ | √ |
+| READ COMMITTED | × | √ | √ |
+| REPEATABLE READ | × | × | √ (标准) / ≈× (InnoDB) |
+| SERIALIZABLE | × | × | × |
-| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
-| :--------------: | :--: | :--------: | :--: |
-| READ-UNCOMMITTED | √ | √ | √ |
-| READ-COMMITTED | × | √ | √ |
-| REPEATABLE-READ | × | × | √ |
-| SERIALIZABLE | × | × | × |
+**默认级别查询：**
-MySQL InnoDB 存储引擎的默认支持的隔离级别是 **REPEATABLE-READ（可重读）**。我们可以通过`SELECT @@tx_isolation;`命令来查看，MySQL 8.0 该命令改为`SELECT @@transaction_isolation;`
+MySQL InnoDB 存储引擎的默认隔离级别是 **REPEATABLE READ**。可以通过以下命令查看：
-```sql
-MySQL> SELECT @@tx_isolation;
-+-----------------+
-| @@tx_isolation |
-+-----------------+
-| REPEATABLE-READ |
-+-----------------+
+- MySQL 8.0 之前：`SELECT @@tx_isolation;`
+- MySQL 8.0 及之后：`SELECT @@transaction_isolation;`
+
+```bash
+mysql> SELECT @@transaction_isolation;
++-------------------------+
+| @@transaction_isolation |
++-------------------------+
+| REPEATABLE-READ |
++-------------------------+
```
-从上面对 SQL 标准定义了四个隔离级别的介绍可以看出，标准的 SQL 隔离级别定义里，REPEATABLE-READ(可重复读)是不可以防止幻读的。
+**InnoDB 的 REPEATABLE READ 对幻读的处理：**
-但是！InnoDB 实现的 REPEATABLE-READ 隔离级别其实是可以解决幻读问题发生的，主要有下面两种情况：
+标准的 SQL 隔离级别定义里，REPEATABLE READ 是无法防止幻读的。但 InnoDB 的实现通过以下机制很大程度上避免了幻读：
-- **快照读**：由 MVCC 机制来保证不出现幻读。
-- **当前读**：使用 Next-Key Lock 进行加锁来保证不出现幻读，Next-Key Lock 是行锁（Record Lock）和间隙锁（Gap Lock）的结合，行锁只能锁住已经存在的行，为了避免插入新行，需要依赖间隙锁。
+- **快照读 (Snapshot Read)**:普通的 SELECT 语句，通过 **MVCC** 机制实现。事务启动时创建一个数据快照，后续的快照读都读取这个版本的数据，从而避免了看到其他事务新插入的行（幻读）或修改的行（不可重复读）。
+- **当前读 (Current Read)**:像 `SELECT ... FOR UPDATE`, `SELECT ... LOCK IN SHARE MODE`, `INSERT`, `UPDATE`, `DELETE` 这些操作。InnoDB 使用 **Next-Key Lock** 来锁定扫描到的索引记录及其间的范围（间隙），防止其他事务在这个范围内插入新的记录，从而避免幻读。Next-Key Lock 是行锁（Record Lock）和间隙锁（Gap Lock）的组合。
-因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 **READ-COMMITTED** ，但是你要知道的是 InnoDB 存储引擎默认使用 **REPEATABLE-READ** 并不会有任何性能损失。
+值得注意的是，虽然通常认为隔离级别越高、并发性越差，但 InnoDB 存储引擎通过 MVCC 机制优化了 REPEATABLE READ 级别。对于许多常见的只读或读多写少的场景，其性能**与 READ COMMITTED 相比可能没有显著差异**。不过，在写密集型且并发冲突较高的场景下，RR 的间隙锁机制可能会比 RC 带来更多的锁等待。
-InnoDB 存储引擎在分布式事务的情况下一般会用到 SERIALIZABLE 隔离级别。
+此外，在某些特定场景下，如需要严格一致性的分布式事务（XA Transactions），InnoDB 可能要求或推荐使用 SERIALIZABLE 隔离级别来确保全局数据的一致性。
《MySQL 技术内幕：InnoDB 存储引擎(第 2 版)》7.7 章这样写到：
diff --git a/docs/database/redis/redis-cluster.md b/docs/database/redis/redis-cluster.md
index 60cd7dda858..e3ef2efd04c 100644
--- a/docs/database/redis/redis-cluster.md
+++ b/docs/database/redis/redis-cluster.md
@@ -7,7 +7,7 @@ tag:
**Redis 集群** 相关的面试题为我的 [知识星球](../../about-the-author/zhishixingqiu-two-years.md)（点击链接即可查看详细介绍以及加入方法）专属内容，已经整理到了[《Java 面试指北》](../../zhuanlan/java-mian-shi-zhi-bei.md)中。
-
+
diff --git a/docs/database/redis/redis-data-structures-01.md b/docs/database/redis/redis-data-structures-01.md
index 9dfb0c3eaa5..7d993752138 100644
--- a/docs/database/redis/redis-data-structures-01.md
+++ b/docs/database/redis/redis-data-structures-01.md
@@ -182,7 +182,7 @@ Redis 中的 List 其实就是链表数据结构的实现。我在 [线性数据
"value3"
```
-我专门画了一个图方便大家理解 `RPUSH` , `LPOP` , `lpush` , `RPOP` 命令：
+我专门画了一个图方便大家理解 `RPUSH` , `LPOP` , `LPUSH` , `RPOP` 命令：
diff --git a/docs/database/redis/redis-data-structures-02.md b/docs/database/redis/redis-data-structures-02.md
index 9961acbacaa..9e5fbcee59b 100644
--- a/docs/database/redis/redis-data-structures-02.md
+++ b/docs/database/redis/redis-data-structures-02.md
@@ -36,7 +36,7 @@ Bitmap 存储的是连续的二进制数字（0 和 1），通过 Bitmap, 只需
| ------------------------------------- | ---------------------------------------------------------------- |
| SETBIT key offset value | 设置指定 offset 位置的值 |
| GETBIT key offset | 获取指定 offset 位置的值 |
-| BITCOUNT key start end | 获取 start 和 end 之前值为 1 的元素个数 |
+| BITCOUNT key start end | 获取 start 和 end 之间值为 1 的元素个数 |
| BITOP operation destkey key1 key2 ... | 对一个或多个 Bitmap 进行运算，可用运算符有 AND, OR, XOR 以及 NOT |
**Bitmap 基本操作演示**：
@@ -123,9 +123,9 @@ HyperLogLog 相关的命令非常少，最常用的也就 3 个。
### 应用场景
-**数量量巨大（百万、千万级别以上）的计数场景**
+**数量巨大（百万、千万级别以上）的计数场景**
-- 举例：热门网站每日/每周/每月访问 ip 数统计、热门帖子 uv 统计、
+- 举例：热门网站每日/每周/每月访问 ip 数统计、热门帖子 uv 统计。
- 相关命令：`PFADD`、`PFCOUNT` 。
## Geospatial (地理位置)
diff --git a/docs/database/redis/redis-delayed-task.md b/docs/database/redis/redis-delayed-task.md
index bd95cb46bbb..35f9304321f 100644
--- a/docs/database/redis/redis-delayed-task.md
+++ b/docs/database/redis/redis-delayed-task.md
@@ -33,7 +33,7 @@ Redis 中有很多默认的 channel，这些 channel 是由 Redis 本身向它
我们只需要监听这个 channel，就可以拿到过期的 key 的消息，进而实现了延时任务功能。
-这个功能被 Redis 官方称为 **keyspace notifications** ，作用是实时监控实时监控 Redis 键和值的变化。
+这个功能被 Redis 官方称为 **keyspace notifications** ，作用是实时监控 Redis 键和值的变化。
### Redis 过期事件监听实现延时任务功能有什么缺陷？
@@ -72,7 +72,7 @@ Redisson 是一个开源的 Java 语言 Redis 客户端，提供了很多开箱
Redisson 的延迟队列 RDelayedQueue 是基于 Redis 的 SortedSet 来实现的。SortedSet 是一个有序集合，其中的每个元素都可以设置一个分数，代表该元素的权重。Redisson 利用这一特性，将需要延迟执行的任务插入到 SortedSet 中，并给它们设置相应的过期时间作为分数。
-Redisson 使用 `zrangebyscore` 命令扫描 SortedSet 中过期的元素，然后将这些过期元素从 SortedSet 中移除，并将它们加入到就绪消息列表中。就绪消息列表是一个阻塞队列，有消息进入就会被监听到。这样做可以避免对整个 SortedSet 进行轮询，提高了执行效率。
+Redisson 定期使用 `zrangebyscore` 命令扫描 SortedSet 中过期的元素，然后将这些过期元素从 SortedSet 中移除，并将它们加入到就绪消息列表中。就绪消息列表是一个阻塞队列，有消息进入就会被消费者监听到。这样做可以避免消费者对整个 SortedSet 进行轮询，提高了执行效率。
相比于 Redis 过期事件监听实现延时任务功能，这种方式具备下面这些优势：
diff --git a/docs/database/redis/redis-persistence.md b/docs/database/redis/redis-persistence.md
index 1e51df93448..c17fe7db316 100644
--- a/docs/database/redis/redis-persistence.md
+++ b/docs/database/redis/redis-persistence.md
@@ -153,9 +153,27 @@ Redis 7.0 版本之后，AOF 重写机制得到了优化改进。下面这段内
### AOF 校验机制了解吗？
-AOF 校验机制是 Redis 在启动时对 AOF 文件进行检查，以判断文件是否完整，是否有损坏或者丢失的数据。这个机制的原理其实非常简单，就是通过使用一种叫做 **校验和（checksum）** 的数字来验证 AOF 文件。这个校验和是通过对整个 AOF 文件内容进行 CRC64 算法计算得出的数字。如果文件内容发生了变化，那么校验和也会随之改变。因此，Redis 在启动时会比较计算出的校验和与文件末尾保存的校验和（计算的时候会把最后一行保存校验和的内容给忽略点），从而判断 AOF 文件是否完整。如果发现文件有问题，Redis 就会拒绝启动并提供相应的错误信息。AOF 校验机制十分简单有效，可以提高 Redis 数据的可靠性。
+纯 AOF 模式下，Redis 不会对整个 AOF 文件使用校验和（如 CRC64），而是通过逐条解析文件中的命令来验证文件的有效性。如果解析过程中发现语法错误（如命令不完整、格式错误），Redis 会终止加载并报错，从而避免错误数据载入内存。
-类似地，RDB 文件也有类似的校验机制来保证 RDB 文件的正确性，这里就不重复进行介绍了。
+在 **混合持久化模式**（Redis 4.0 引入）下，AOF 文件由两部分组成：
+
+- **RDB 快照部分**：文件以固定的 `REDIS` 字符开头，存储某一时刻的内存数据快照，并在快照数据末尾附带一个 CRC64 校验和（位于 RDB 数据块尾部、AOF 增量部分之前）。
+- **AOF 增量部分**：紧随 RDB 快照部分之后，记录 RDB 快照生成后的增量写命令。这部分增量命令以 Redis 协议格式逐条记录，无整体或全局校验和。
+
+RDB 文件结构的核心部分如下：
+
+| **字段** | **解释** |
+| ----------------- | ---------------------------------------------- |
+| `"REDIS"` | 固定以该字符串开始 |
+| `RDB_VERSION` | RDB 文件的版本号 |
+| `DB_NUM` | Redis 数据库编号，指明数据需要存放到哪个数据库 |
+| `KEY_VALUE_PAIRS` | Redis 中具体键值对的存储 |
+| `EOF` | RDB 文件结束标志 |
+| `CHECK_SUM` | 8 字节确保 RDB 完整性的校验和 |
+
+Redis 启动并加载 AOF 文件时，首先会校验文件开头 RDB 快照部分的数据完整性，即计算该部分数据的 CRC64 校验和，并与紧随 RDB 数据之后、AOF 增量部分之前存储的 CRC64 校验和值进行比较。如果 CRC64 校验和不匹配，Redis 将拒绝启动并报告错误。
+
+RDB 部分校验通过后，Redis 随后逐条解析 AOF 部分的增量命令。如果解析过程中出现错误（如不完整的命令或格式错误），Redis 会停止继续加载后续命令，并报告错误，但此时 Redis 已经成功加载了 RDB 快照部分的数据。
## Redis 4.0 对于持久化机制做了什么优化？
diff --git a/docs/database/redis/redis-questions-01.md b/docs/database/redis/redis-questions-01.md
index 15ad9207619..7102985b9a5 100644
--- a/docs/database/redis/redis-questions-01.md
+++ b/docs/database/redis/redis-questions-01.md
@@ -30,39 +30,50 @@ Redis 没有外部依赖，Linux 和 OS X 是 Redis 开发和测试最多的两
-全世界有非常多的网站使用到了 Redis ，[techstacks.io](https://techstacks.io/) 专门维护了一个[使用 Redis 的热门站点列表](https://techstacks.io/tech/redis) ，感兴趣的话可以看看。
+全世界有非常多的网站使用到了 Redis，[techstacks.io](https://techstacks.io/) 专门维护了一个[使用 Redis 的热门站点列表](https://techstacks.io/tech/redis)，感兴趣的话可以看看。
### Redis 为什么这么快？
-Redis 内部做了非常多的性能优化，比较重要的有下面 3 点：
+Redis 内部做了非常多的性能优化，比较重要的有下面 4 点：
-1. Redis 基于内存，内存的访问速度比磁盘快很多；
-2. Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型，主要是单线程事件循环和 IO 多路复用（Redis 线程模式后面会详细介绍到）；
-3. Redis 内置了多种优化过后的数据类型/结构实现，性能非常高。
-4. Redis 通信协议实现简单且解析高效。
+1. **纯内存操作 (Memory-Based Storage)** ：这是最主要的原因。Redis 数据读写操作都发生在内存中，访问速度是纳秒级别，而传统数据库频繁读写磁盘的速度是毫秒级别，两者相差数个数量级。
+2. **高效的 I/O 模型 (I/O Multiplexing & Single-Threaded Event Loop)** ：Redis 使用单线程事件循环配合 I/O 多路复用技术，让单个线程可以同时处理多个网络连接上的 I/O 事件（如读写），避免了多线程模型中的上下文切换和锁竞争问题。虽然是单线程，但结合内存操作的高效性和 I/O 多路复用，使得 Redis 能轻松处理大量并发请求（Redis 线程模型会在后文中详细介绍到）。
+3. **优化的内部数据结构 (Optimized Data Structures)** ：Redis 提供多种数据类型（如 String, List, Hash, Set, Sorted Set 等），其内部实现采用高度优化的编码方式（如 ziplist, quicklist, skiplist, hashtable 等）。Redis 会根据数据大小和类型动态选择最合适的内部编码，以在性能和空间效率之间取得最佳平衡。
+4. **简洁高效的通信协议 (Simple Protocol - RESP)** ：Redis 使用的是自己设计的 RESP (REdis Serialization Protocol) 协议。这个协议实现简单、解析性能好，并且是二进制安全的。客户端和服务端之间通信的序列化/反序列化开销很小，有助于提升整体的交互速度。
-> 下面这张图片总结的挺不错的，分享一下，出自 [Why is Redis so fast?](https://twitter.com/alexxubyte/status/1498703822528544770) 。
+> 下面这张图片总结的挺不错的，分享一下，出自 [Why is Redis so fast?](https://twitter.com/alexxubyte/status/1498703822528544770)。
-那既然都这么快了，为什么不直接用 Redis 当主数据库呢？主要是因为内存成本太高且 Redis 提供的数据持久化仍然有数据丢失的风险。
+那既然都这么快了，为什么不直接用 Redis 当主数据库呢？主要是因为内存成本太高，并且 Redis 提供的数据持久化仍然有数据丢失的风险。
-### 分布式缓存常见的技术选型方案有哪些？
+### 除了 Redis，你还知道其他分布式缓存方案吗？
+
+如果面试中被问到这个问题的话，面试官主要想看看：
+
+1. 你在选择 Redis 作为分布式缓存方案时，是否是经过严谨的调研和思考，还是只是因为 Redis 是当前的“热门”技术。
+2. 你在分布式缓存方向的技术广度。
+
+如果你了解其他方案，并且能解释为什么最终选择了 Redis（更进一步！），这会对你面试表现加分不少！
+
+下面简单聊聊常见的分布式缓存技术选型。
分布式缓存的话，比较老牌同时也是使用的比较多的还是 **Memcached** 和 **Redis**。不过，现在基本没有看过还有项目使用 **Memcached** 来做缓存，都是直接用 **Redis**。
Memcached 是分布式缓存最开始兴起的那会，比较常用的。后来，随着 Redis 的发展，大家慢慢都转而使用更加强大的 Redis 了。
-有一些大厂也开源了类似于 Redis 的分布式高性能 KV 存储数据库，例如，腾讯开源的 [Tendis](https://github.com/Tencent/Tendis) 。Tendis 基于知名开源项目 [RocksDB](https://github.com/facebook/rocksdb) 作为存储引擎 ，100% 兼容 Redis 协议和 Redis4.0 所有数据模型。关于 Redis 和 Tendis 的对比，腾讯官方曾经发过一篇文章：[Redis vs Tendis：冷热混合存储版架构揭秘](https://mp.weixin.qq.com/s/MeYkfOIdnU6LYlsGb24KjQ) ，可以简单参考一下。
+有一些大厂也开源了类似于 Redis 的分布式高性能 KV 存储数据库，例如，腾讯开源的 [**Tendis**](https://github.com/Tencent/Tendis)。Tendis 基于知名开源项目 [RocksDB](https://github.com/facebook/rocksdb) 作为存储引擎 ，100% 兼容 Redis 协议和 Redis4.0 所有数据模型。关于 Redis 和 Tendis 的对比，腾讯官方曾经发过一篇文章：[Redis vs Tendis：冷热混合存储版架构揭秘](https://mp.weixin.qq.com/s/MeYkfOIdnU6LYlsGb24KjQ)，可以简单参考一下。
不过，从 Tendis 这个项目的 Github 提交记录可以看出，Tendis 开源版几乎已经没有被维护更新了，加上其关注度并不高，使用的公司也比较少。因此，不建议你使用 Tendis 来实现分布式缓存。
目前，比较业界认可的 Redis 替代品还是下面这两个开源分布式缓存（都是通过碰瓷 Redis 火的）：
- [Dragonfly](https://github.com/dragonflydb/dragonfly)：一种针对现代应用程序负荷需求而构建的内存数据库，完全兼容 Redis 和 Memcached 的 API，迁移时无需修改任何代码，号称全世界最快的内存数据库。
-- [KeyDB](https://github.com/Snapchat/KeyDB)： Redis 的一个高性能分支，专注于多线程、内存效率和高吞吐量。
+- [KeyDB](https://github.com/Snapchat/KeyDB)：Redis 的一个高性能分支，专注于多线程、内存效率和高吞吐量。
-不过，个人还是建议分布式缓存首选 Redis ，毕竟经过这么多年的生考验，生态也这么优秀，资料也很全面。
+不过，个人还是建议分布式缓存首选 Redis，毕竟经过了这么多年的考验，生态非常优秀，资料也很全面！
+
+PS：篇幅问题，我这并没有对上面提到的分布式缓存选型做详细介绍和对比，感兴趣的话，可以自行研究一下。
### 说一下 Redis 和 Memcached 的区别和共同点
@@ -76,10 +87,10 @@ Memcached 是分布式缓存最开始兴起的那会，比较常用的。后来
**区别**：
-1. **数据类型**：Redis 支持更丰富的数据类型（支持更复杂的应用场景）。Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。Memcached 只支持最简单的 k/v 数据类型。
-2. **数据持久化**：Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用，而 Memcached 把数据全部存在内存之中。也就是说，Redis 有灾难恢复机制而 Memcached 没有。
-3. **集群模式支持**：Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 Redis 自 3.0 版本起是原生支持集群模式的。
-4. **线程模型**：Memcached 是多线程，非阻塞 IO 复用的网络模型；Redis 使用单线程的多路 IO 复用模型。 （Redis 6.0 针对网络数据的读写引入了多线程）
+1. **数据类型**：Redis 支持更丰富的数据类型（支持更复杂的应用场景）。Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list、set、zset、hash 等数据结构的存储；而 Memcached 只支持最简单的 k/v 数据类型。
+2. **数据持久化**：Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用；而 Memcached 把数据全部存在内存之中。也就是说，Redis 有灾难恢复机制，而 Memcached 没有。
+3. **集群模式支持**：Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；而 Redis 自 3.0 版本起是原生支持集群模式的。
+4. **线程模型**：Memcached 是多线程、非阻塞 IO 复用的网络模型；而 Redis 使用单线程的多路 IO 复用模型（Redis 6.0 针对网络数据的读写引入了多线程）。
5. **特性支持**：Redis 支持发布订阅模型、Lua 脚本、事务等功能，而 Memcached 不支持。并且，Redis 支持更多的编程语言。
6. **过期数据删除**：Memcached 过期数据的删除策略只用了惰性删除，而 Redis 同时使用了惰性删除与定期删除。
@@ -93,7 +104,7 @@ Memcached 是分布式缓存最开始兴起的那会，比较常用的。后来
**2、高并发**
-一般像 MySQL 这类的数据库的 QPS 大概都在 4k 左右（4 核 8g） ，但是使用 Redis 缓存之后很容易达到 5w+，甚至能达到 10w+（就单机 Redis 的情况，Redis 集群的话会更高）。
+一般像 MySQL 这类的数据库的 QPS 大概都在 4k 左右（4 核 8g），但是使用 Redis 缓存之后很容易达到 5w+，甚至能达到 10w+（就单机 Redis 的情况，Redis 集群的话会更高）。
> QPS（Query Per Second）：服务器每秒可以执行的查询次数；
@@ -103,9 +114,19 @@ Memcached 是分布式缓存最开始兴起的那会，比较常用的。后来
Redis 除了可以用作缓存之外，还可以用于分布式锁、限流、消息队列、延时队列等场景，功能强大！
+### 为什么用 Redis 而不用本地缓存呢？
+
+| 特性 | 本地缓存 | Redis |
+| ------------ | ------------------------------------ | -------------------------------- |
+| 数据一致性 | 多服务器部署时存在数据不一致问题 | 数据一致 |
+| 内存限制 | 受限于单台服务器内存 | 独立部署，内存空间更大 |
+| 数据丢失风险 | 服务器宕机数据丢失 | 可持久化，数据不易丢失 |
+| 管理维护 | 分散，管理不便 | 集中管理，提供丰富的管理工具 |
+| 功能丰富性 | 功能有限，通常只提供简单的键值对存储 | 功能丰富，支持多种数据结构和功能 |
+
### 常见的缓存读写策略有哪些？
-关于常见的缓存读写策略的详细介绍，可以看我写的这篇文章：[3 种常用的缓存读写策略详解](https://javaguide.cn/database/redis/3-commonly-used-cache-read-and-write-strategies.html) 。
+关于常见的缓存读写策略的详细介绍，可以看我写的这篇文章：[3 种常用的缓存读写策略详解](https://javaguide.cn/database/redis/3-commonly-used-cache-read-and-write-strategies.html)。
### 什么是 Redis Module？有什么用？
@@ -130,17 +151,17 @@ Redis 从 4.0 版本开始，支持通过 Module 来扩展其功能以满足特
### Redis 除了做缓存，还能做什么？
-- **分布式锁**：通过 Redis 来做分布式锁是一种比较常见的方式。通常情况下，我们都是基于 Redisson 来实现分布式锁。关于 Redis 实现分布式锁的详细介绍，可以看我写的这篇文章：[分布式锁详解](https://javaguide.cn/distributed-system/distributed-lock.html) 。
+- **分布式锁**：通过 Redis 来做分布式锁是一种比较常见的方式。通常情况下，我们都是基于 Redisson 来实现分布式锁。关于 Redis 实现分布式锁的详细介绍，可以看我写的这篇文章：[分布式锁详解](https://javaguide.cn/distributed-system/distributed-lock.html)。
- **限流**：一般是通过 Redis + Lua 脚本的方式来实现限流。如果不想自己写 Lua 脚本的话，也可以直接利用 Redisson 中的 `RRateLimiter` 来实现分布式限流，其底层实现就是基于 Lua 代码+令牌桶算法。
- **消息队列**：Redis 自带的 List 数据结构可以作为一个简单的队列使用。Redis 5.0 中增加的 Stream 类型的数据结构更加适合用来做消息队列。它比较类似于 Kafka，有主题和消费组的概念，支持消息持久化以及 ACK 机制。
- **延时队列**：Redisson 内置了延时队列（基于 Sorted Set 实现的）。
-- **分布式 Session** ：利用 String 或者 Hash 数据类型保存 Session 数据，所有的服务器都可以访问。
-- **复杂业务场景**：通过 Redis 以及 Redis 扩展（比如 Redisson）提供的数据结构，我们可以很方便地完成很多复杂的业务场景比如通过 Bitmap 统计活跃用户、通过 Sorted Set 维护排行榜。
+- **分布式 Session**：利用 String 或者 Hash 数据类型保存 Session 数据，所有的服务器都可以访问。
+- **复杂业务场景**：通过 Redis 以及 Redis 扩展（比如 Redisson）提供的数据结构，我们可以很方便地完成很多复杂的业务场景，比如通过 Bitmap 统计活跃用户、通过 Sorted Set 维护排行榜、通过 HyperLogLog 统计网站 UV 和 PV。
- ……
### 如何基于 Redis 实现分布式锁？
-关于 Redis 实现分布式锁的详细介绍，可以看我写的这篇文章：[分布式锁详解](https://javaguide.cn/distributed-system/distributed-lock-implementations.html) 。
+关于 Redis 实现分布式锁的详细介绍，可以看我写的这篇文章：[分布式锁详解](https://javaguide.cn/distributed-system/distributed-lock-implementations.html)。
### Redis 可以做消息队列么？
@@ -150,7 +171,7 @@ Redis 从 4.0 版本开始，支持通过 Module 来扩展其功能以满足特
**Redis 2.0 之前，如果想要使用 Redis 来做消息队列的话，只能通过 List 来实现。**
-通过 `RPUSH/LPOP` 或者 `LPUSH/RPOP`即可实现简易版消息队列：
+通过 `RPUSH/LPOP` 或者 `LPUSH/RPOP` 即可实现简易版消息队列：
```bash
# 生产者生产消息
@@ -163,7 +184,7 @@ Redis 从 4.0 版本开始，支持通过 Module 来扩展其功能以满足特
"msg1"
```
-不过，通过 `RPUSH/LPOP` 或者 `LPUSH/RPOP`这样的方式存在性能问题，我们需要不断轮询去调用 `RPOP` 或 `LPOP` 来消费消息。当 List 为空时，大部分的轮询的请求都是无效请求，这种方式大量浪费了系统资源。
+不过，通过 `RPUSH/LPOP` 或者 `LPUSH/RPOP` 这样的方式存在性能问题，我们需要不断轮询去调用 `RPOP` 或 `LPOP` 来消费消息。当 List 为空时，大部分的轮询的请求都是无效请求，这种方式大量浪费了系统资源。
因此，Redis 还提供了 `BLPOP`、`BRPOP` 这种阻塞式读取的命令（带 B-Blocking 的都是阻塞式），并且还支持一个超时参数。如果 List 为空，Redis 服务端不会立刻返回结果，它会等待 List 中有新数据后再返回或者是等待最多一个超时时间后返回空。如果将超时时间设置为 0 时，即可无限等待，直到弹出消息
@@ -195,11 +216,11 @@ pub/sub 既能单播又能广播，还支持 channel 的简单正则匹配。不
为此，Redis 5.0 新增加的一个数据结构 `Stream` 来做消息队列。`Stream` 支持：
-- 发布 / 订阅模式
-- 按照消费者组进行消费（借鉴了 Kafka 消费者组的概念）
-- 消息持久化（ RDB 和 AOF）
-- ACK 机制（通过确认机制来告知已经成功处理了消息）
-- 阻塞式获取消息
+- 发布 / 订阅模式；
+- 按照消费者组进行消费（借鉴了 Kafka 消费者组的概念）；
+- 消息持久化（ RDB 和 AOF）；
+- ACK 机制（通过确认机制来告知已经成功处理了消息）；
+- 阻塞式获取消息。
`Stream` 的结构如下：
@@ -209,7 +230,7 @@ pub/sub 既能单播又能广播，还支持 channel 的简单正则匹配。不
这里再对图中涉及到的一些概念，进行简单解释：
-- `Consumer Group`：消费者组用于组织和管理多个消费者。消费者组本身不处理消息，而是再将消息分发给消费者，由消费者进行真正的消费
+- `Consumer Group`：消费者组用于组织和管理多个消费者。消费者组本身不处理消息，而是再将消息分发给消费者，由消费者进行真正的消费。
- `last_delivered_id`：标识消费者组当前消费位置的游标，消费者组中任意一个消费者读取了消息都会使 last_delivered_id 往前移动。
- `pending_ids`：记录已经被客户端消费但没有 ack 的消息的 ID。
@@ -224,25 +245,25 @@ pub/sub 既能单播又能广播，还支持 channel 的简单正则匹配。不
- `XTRIM`：修剪流的长度，可以指定修建策略（`MAXLEN`/`MINID`）。
- `XLEN`：获取流的长度。
- `XGROUP CREATE`：创建消费者组。
-- `XGROUP DESTROY` ： 删除消费者组
+- `XGROUP DESTROY`：删除消费者组。
- `XGROUP DELCONSUMER`：从消费者组中删除一个消费者。
-- `XGROUP SETID`：为消费者组设置新的最后递送消息 ID
+- `XGROUP SETID`：为消费者组设置新的最后递送消息 ID。
- `XACK`：确认消费组中的消息已被处理。
- `XPENDING`：查询消费组中挂起（未确认）的消息。
- `XCLAIM`：将挂起的消息从一个消费者转移到另一个消费者。
-- `XINFO`：获取流(`XINFO STREAM`)、消费组(`XINFO GROUPS`)或消费者(`XINFO CONSUMERS`)的详细信息。
+- `XINFO`：获取流（`XINFO STREAM`）、消费组（`XINFO GROUPS`）或消费者（`XINFO CONSUMERS`）的详细信息。
`Stream` 使用起来相对要麻烦一些，这里就不演示了。
-总的来说，`Stream` 已经可以满足一个消息队列的基本要求了。不过，`Stream` 在实际使用中依然会有一些小问题不太好解决比如在 Redis 发生故障恢复后不能保证消息至少被消费一次。
+总的来说，`Stream` 已经可以满足一个消息队列的基本要求了。不过，`Stream` 在实际使用中依然会有一些小问题不太好解决，比如在 Redis 发生故障恢复后不能保证消息至少被消费一次。
-综上，和专业的消息队列相比，使用 Redis 来实现消息队列还是有很多欠缺的地方比如消息丢失和堆积问题不好解决。因此，我们通常建议不要使用 Redis 来做消息队列，你完全可以选择市面上比较成熟的一些消息队列比如 RocketMQ、Kafka。不过，如果你就是想要用 Redis 来做消息队列的话，那我建议你优先考虑 `Stream`，这是目前相对最优的 Redis 消息队列实现。
+综上，和专业的消息队列相比，使用 Redis 来实现消息队列还是有很多欠缺的地方，比如消息丢失和堆积问题不好解决。因此，我们通常建议不要使用 Redis 来做消息队列，你完全可以选择市面上比较成熟的一些消息队列，比如 RocketMQ、Kafka。不过，如果你就是想要用 Redis 来做消息队列的话，那我建议你优先考虑 `Stream`，这是目前相对最优的 Redis 消息队列实现。
相关阅读：[Redis 消息队列发展历程 - 阿里开发者 - 2022](https://mp.weixin.qq.com/s/gCUT5TcCQRAxYkTJfTRjJw)。
### Redis 可以做搜索引擎么？
-Redis 是可以实现全文搜索引擎功能的，需要借助 **RediSearch** ，这是一个基于 Redis 的搜索引擎模块。
+Redis 是可以实现全文搜索引擎功能的，需要借助 **RediSearch**，这是一个基于 Redis 的搜索引擎模块。
RediSearch 支持中文分词、聚合统计、停用词、同义词、拼写检查、标签查询、向量相似度查询、多关键词搜索、分页搜索等功能，算是一个功能比较完善的全文搜索引擎了。
@@ -253,7 +274,7 @@ RediSearch 支持中文分词、聚合统计、停用词、同义词、拼写检
对于小型项目的简单搜索场景来说，使用 RediSearch 来作为搜索引擎还是没有问题的（搭配 RedisJSON 使用）。
-对于比较复杂或者数据规模较大的搜索场景还是不太建议使用 RediSearch 来作为搜索引擎，主要是因为下面这些限制和问题：
+对于比较复杂或者数据规模较大的搜索场景，还是不太建议使用 RediSearch 来作为搜索引擎，主要是因为下面这些限制和问题：
1. 数据量限制：Elasticsearch 可以支持 PB 级别的数据量，可以轻松扩展到多个节点，利用分片机制提高可用性和性能。RedisSearch 是基于 Redis 实现的，其能存储的数据量受限于 Redis 的内存容量，不太适合存储大规模的数据（内存昂贵，扩展能力较差）。
2. 分布式能力较差：Elasticsearch 是为分布式环境设计的，可以轻松扩展到多个节点。虽然 RedisSearch 支持分布式部署，但在实际应用中可能会面临一些挑战，如数据分片、节点间通信、数据一致性等问题。
@@ -271,10 +292,10 @@ Elasticsearch 适用于全文搜索、复杂查询、实时数据分析和聚合
基于 Redis 实现延时任务的功能无非就下面两种方案：
-1. Redis 过期事件监听
-2. Redisson 内置的延时队列
+1. Redis 过期事件监听。
+2. Redisson 内置的延时队列。
-Redis 过期事件监听的存在时效性较差、丢消息、多服务实例下消息重复消费等问题，不被推荐使用。
+Redis 过期事件监听存在时效性较差、丢消息、多服务实例下消息重复消费等问题，不被推荐使用。
Redisson 内置的延时队列具备下面这些优势：
@@ -285,7 +306,7 @@ Redisson 内置的延时队列具备下面这些优势：
## Redis 数据类型
-关于 Redis 5 种基础数据类型和 3 种特殊数据类型的详细介绍请看下面这两篇文章以及 [Redis 官方文档](https://redis.io/docs/data-types/) ：
+关于 Redis 5 种基础数据类型和 3 种特殊数据类型的详细介绍请看下面这两篇文章以及 [Redis 官方文档](https://redis.io/docs/data-types/)：
- [Redis 5 种基本数据类型详解](https://javaguide.cn/database/redis/redis-data-structures-01.html)
- [Redis 3 种特殊数据类型详解](https://javaguide.cn/database/redis/redis-data-structures-02.html)
@@ -307,25 +328,32 @@ String 的常见应用场景如下：
- 常规数据（比如 Session、Token、序列化后的对象、图片的路径）的缓存；
- 计数比如用户单位时间的请求数（简单限流可以用到）、页面单位时间的访问数；
-- 分布式锁(利用 `SETNX key value` 命令可以实现一个最简易的分布式锁)；
+- 分布式锁（利用 `SETNX key value` 命令可以实现一个最简易的分布式锁）；
- ……
关于 String 的详细介绍请看这篇文章：[Redis 5 种基本数据类型详解](https://javaguide.cn/database/redis/redis-data-structures-01.html)。
### String 还是 Hash 存储对象数据更好呢？
-- String 存储的是序列化后的对象数据，存放的是整个对象。Hash 是对对象的每个字段单独存储，可以获取部分字段的信息，也可以修改或者添加部分字段，节省网络流量。如果对象中某些字段需要经常变动或者经常需要单独查询对象中的个别字段信息，Hash 就非常适合。
-- String 存储相对来说更加节省内存，缓存相同数量的对象数据，String 消耗的内存约是 Hash 的一半。并且，存储具有多层嵌套的对象时也方便很多。如果系统对性能和资源消耗非常敏感的话，String 就非常适合。
+简单对比一下二者：
+
+- **对象存储方式**：String 存储的是序列化后的对象数据，存放的是整个对象，操作简单直接。Hash 是对对象的每个字段单独存储，可以获取部分字段的信息，也可以修改或者添加部分字段，节省网络流量。如果对象中某些字段需要经常变动或者经常需要单独查询对象中的个别字段信息，Hash 就非常适合。
+- **内存消耗**：Hash 通常比 String 更节省内存，特别是在字段较多且字段长度较短时。Redis 对小型 Hash 进行优化（如使用 ziplist 存储），进一步降低内存占用。
+- **复杂对象存储**：String 在处理多层嵌套或复杂结构的对象时更方便，因为无需处理每个字段的独立存储和操作。
+- **性能**：String 的操作通常具有 O(1) 的时间复杂度，因为它存储的是整个对象，操作简单直接，整体读写的性能较好。Hash 由于需要处理多个字段的增删改查操作，在字段较多且经常变动的情况下，可能会带来额外的性能开销。
-在绝大部分情况，我们建议使用 String 来存储对象数据即可！
+总结：
+
+- 在绝大多数情况下，**String** 更适合存储对象数据，尤其是当对象结构简单且整体读写是主要操作时。
+- 如果你需要频繁操作对象的部分字段或节省内存，**Hash** 可能是更好的选择。
### String 的底层实现是什么？
-Redis 是基于 C 语言编写的，但 Redis 的 String 类型的底层实现并不是 C 语言中的字符串（即以空字符 `\0` 结尾的字符数组），而是自己编写了 [SDS](https://github.com/antirez/sds)（Simple Dynamic String，简单动态字符串） 来作为底层实现。
+Redis 是基于 C 语言编写的，但 Redis 的 String 类型的底层实现并不是 C 语言中的字符串（即以空字符 `\0` 结尾的字符数组），而是自己编写了 [SDS](https://github.com/antirez/sds)（Simple Dynamic String，简单动态字符串）来作为底层实现。
SDS 最早是 Redis 作者为日常 C 语言开发而设计的 C 字符串，后来被应用到了 Redis 上，并经过了大量的修改完善以适合高性能操作。
-Redis7.0 的 SDS 的部分源码如下（
可以看出，AOT 的主要优势在于启动时间、内存占用和打包体积。JIT 的主要优势在于具备更高的极限处理能力，可以降低请求的最大延迟。
@@ -203,8 +215,6 @@ JDK 9 引入了一种新的编译模式 **AOT(Ahead of Time Compilation)** 。
Java 中的注释有三种：
-
-
1. **单行注释**：通常用于解释方法内某单行代码的作用。
2. **多行注释**：通常用于解释一段代码的作用。
@@ -274,9 +284,26 @@ Java 中的注释有三种：
### 自增自减运算符
-在写代码的过程中，常见的一种情况是需要某个整数类型变量增加 1 或减少 1，Java 提供了一种特殊的运算符，用于这种表达式，叫做自增运算符（++)和自减运算符（--）。
+在写代码的过程中，常见的一种情况是需要某个整数类型变量增加 1 或减少 1。Java 提供了自增运算符 (`++`) 和自减运算符 (`--`) 来简化这种操作。
+
+`++` 和 `--` 运算符可以放在变量之前，也可以放在变量之后：
-++ 和 -- 运算符可以放在变量之前，也可以放在变量之后，当运算符放在变量之前时(前缀)，先自增/减，再赋值；当运算符放在变量之后时(后缀)，先赋值，再自增/减。例如，当 `b = ++a` 时，先自增（自己增加 1），再赋值（赋值给 b）；当 `b = a++` 时，先赋值(赋值给 b)，再自增（自己增加 1）。也就是，++a 输出的是 a+1 的值，a++输出的是 a 值。用一句口诀就是：“符号在前就先加/减，符号在后就后加/减”。
+- **前缀形式**（例如 `++a` 或 `--a`）：先自增/自减变量的值，然后再使用该变量，例如，`b = ++a` 先将 `a` 增加 1，然后把增加后的值赋给 `b`。
+- **后缀形式**（例如 `a++` 或 `a--`）：先使用变量的当前值，然后再自增/自减变量的值。例如，`b = a++` 先将 `a` 的当前值赋给 `b`，然后再将 `a` 增加 1。
+
+为了方便记忆，可以使用下面的口诀：**符号在前就先加/减，符号在后就后加/减**。
+
+下面来看一个考察自增自减运算符的高频笔试题：执行下面的代码后，`a` 、`b` 、 `c` 、`d`和`e`的值是？
+
+```java
+int a = 9;
+int b = a++;
+int c = ++a;
+int d = c--;
+int e = --d;
+```
+
+答案：`a = 11` 、`b = 9` 、 `c = 10` 、 `d = 10` 、 `e = 10`。
### 移位运算符
@@ -295,18 +322,29 @@ static final int hash(Object key) {
```
-在 Java 代码里使用 `<<`、 `>>` 和`>>>`转换成的指令码运行起来会更高效些。
+**使用移位运算符的主要原因**：
+
+1. **高效**：移位运算符直接对应于处理器的移位指令。现代处理器具有专门的硬件指令来执行这些移位操作，这些指令通常在一个时钟周期内完成。相比之下，乘法和除法等算术运算在硬件层面上需要更多的时钟周期来完成。
+2. **节省内存**：通过移位操作，可以使用一个整数（如 `int` 或 `long`）来存储多个布尔值或标志位，从而节省内存。
+
+移位运算符最常用于快速乘以或除以 2 的幂次方。除此之外，它还在以下方面发挥着重要作用：
+
+- **位字段管理**：例如存储和操作多个布尔值。
+- **哈希算法和加密解密**：通过移位和与、或等操作来混淆数据。
+- **数据压缩**：例如霍夫曼编码通过移位运算符可以快速处理和操作二进制数据，以生成紧凑的压缩格式。
+- **数据校验**：例如 CRC（循环冗余校验）通过移位和多项式除法生成和校验数据完整性。
+- **内存对齐**：通过移位操作，可以轻松计算和调整数据的对齐地址。
掌握最基本的移位运算符知识还是很有必要的，这不光可以帮助我们在代码中使用，还可以帮助我们理解源码中涉及到移位运算符的代码。
Java 中有三种移位运算符：
-
-
-- `<<` :左移运算符，向左移若干位，高位丢弃，低位补零。`x << 1`,相当于 x 乘以 2(不溢出的情况下)。
-- `>>` :带符号右移，向右移若干位，高位补符号位，低位丢弃。正数高位补 0,负数高位补 1。`x >> 1`,相当于 x 除以 2。
+- `<<` :左移运算符，向左移若干位，高位丢弃，低位补零。`x << n`,相当于 x 乘以 2 的 n 次方(不溢出的情况下)。
+- `>>` :带符号右移，向右移若干位，高位补符号位，低位丢弃。正数高位补 0,负数高位补 1。`x >> n`,相当于 x 除以 2 的 n 次方。
- `>>>` :无符号右移，忽略符号位，空位都以 0 补齐。
+虽然移位运算本质上可以分为左移和右移，但在实际应用中，右移操作需要考虑符号位的处理方式。
+
由于 `double`，`float` 在二进制中的表现比较特殊，因此不能来进行移位操作。
移位操作符实际上支持的类型只有`int`和`long`，编译器在对`short`、`byte`、`char`类型进行移位前，都会将其转换为`int`类型再操作。
@@ -365,31 +403,31 @@ System.out.println("左移 10 位后的数据对应的二进制字符 " + Intege
思考一下：下列语句的运行结果是什么？
```java
- public static void main(String[] args) {
- boolean flag = false;
- for (int i = 0; i <= 3; i++) {
- if (i == 0) {
- System.out.println("0");
- } else if (i == 1) {
- System.out.println("1");
- continue;
- } else if (i == 2) {
- System.out.println("2");
- flag = true;
- } else if (i == 3) {
- System.out.println("3");
- break;
- } else if (i == 4) {
- System.out.println("4");
- }
- System.out.println("xixi");
- }
- if (flag) {
- System.out.println("haha");
- return;
+public static void main(String[] args) {
+ boolean flag = false;
+ for (int i = 0; i <= 3; i++) {
+ if (i == 0) {
+ System.out.println("0");
+ } else if (i == 1) {
+ System.out.println("1");
+ continue;
+ } else if (i == 2) {
+ System.out.println("2");
+ flag = true;
+ } else if (i == 3) {
+ System.out.println("3");
+ break;
+ } else if (i == 4) {
+ System.out.println("4");
}
- System.out.println("heihei");
+ System.out.println("xixi");
+ }
+ if (flag) {
+ System.out.println("haha");
+ return;
}
+ System.out.println("heihei");
+}
```
运行结果：
@@ -438,14 +476,13 @@ Java 中有 8 种基本数据类型，分别为：
**注意：**
1. Java 里使用 `long` 类型的数据一定要在数值后面加上 **L**，否则将作为整型解析。
-2. `char a = 'h'`char :单引号，`String a = "hello"` :双引号。
+2. Java 里使用 `float` 类型的数据一定要在数值后面加上 **f 或 F**，否则将无法通过编译。
+3. `char a = 'h'`char :单引号，`String a = "hello"` :双引号。
这八种基本类型都有对应的包装类分别为：`Byte`、`Short`、`Integer`、`Long`、`Float`、`Double`、`Character`、`Boolean` 。
### 基本类型和包装类型的区别？
-
-
- **用途**：除了定义一些常量和局部变量之外，我们在其他地方比如方法参数、对象属性中很少会使用基本类型来定义变量。并且，包装类型可用于泛型，而基本类型不可以。
- **存储方式**：基本数据类型的局部变量存放在 Java 虚拟机栈中的局部变量表中，基本数据类型的成员变量（未被 `static` 修饰 ）存放在 Java 虚拟机的堆中。包装类型属于对象类型，我们知道几乎所有对象实例都存在于堆中。
- **占用空间**：相比于包装类型（对象类型）， 基本数据类型占用的空间往往非常小。
@@ -454,14 +491,14 @@ Java 中有 8 种基本数据类型，分别为：
**为什么说是几乎所有对象实例都存在于堆中呢？** 这是因为 HotSpot 虚拟机引入了 JIT 优化之后，会对对象进行逃逸分析，如果发现某一个对象并没有逃逸到方法外部，那么就可能通过标量替换来实现栈上分配，而避免堆上分配内存
-⚠️ 注意：**基本数据类型存放在栈中是一个常见的误区！** 基本数据类型的存储位置取决于它们的作用域和声明方式。如果它们是局部变量，那么它们会存放在栈中；如果它们是成员变量，那么它们会存放在堆中。
+⚠️ 注意：**基本数据类型存放在栈中是一个常见的误区！** 基本数据类型的存储位置取决于它们的作用域和声明方式。如果它们是局部变量，那么它们会存放在栈中；如果它们是成员变量，那么它们会存放在堆/方法区/元空间中。
```java
public class Test {
// 成员变量，存放在堆中
int a = 10;
- // 被 static 修饰，也存放在堆中，但属于类，不属于对象
- // JDK1.7 静态变量从永久代移动了 Java 堆中
+ // 被 static 修饰的成员变量，JDK 1.7 及之前位于方法区，1.8 后存放于元空间，均不存放于堆中。
+ // 变量属于类，不属于对象。
static int b = 20;
public void method() {
@@ -476,7 +513,11 @@ public class Test {
Java 基本数据类型的包装类型的大部分都用到了缓存机制来提升性能。
-`Byte`,`Short`,`Integer`,`Long` 这 4 种包装类默认创建了数值 **[-128，127]** 的相应类型的缓存数据，`Character` 创建了数值在 **[0,127]** 范围的缓存数据，`Boolean` 直接返回 `True` or `False`。
+`Byte`,`Short`,`Integer`,`Long` 这 4 种包装类默认创建了数值 **[-128，127]** 的相应类型的缓存数据，`Character` 创建了数值在 **[0,127]** 范围的缓存数据，`Boolean` 直接返回 `TRUE` or `FALSE`。
+
+对于 `Integer`，可以通过 JVM 参数 `-XX:AutoBoxCacheMax=
### SPI 和 API 有什么区别？
**那 SPI 和 API 有啥区别？**
-说到 SPI 就不得不说一下 API 了，从广义上来说它们都属于接口，而且很容易混淆。下面先用一张图说明一下：
-
-
+说到 SPI 就不得不说一下 API（Application Programming Interface） 了，从广义上来说它们都属于接口，而且很容易混淆。下面先用一张图说明一下：
-一般模块之间都是通过接口进行通讯，那我们在服务调用方和服务实现方（也称服务提供者）之间引入一个“接口”。
+
-当实现方提供了接口和实现，我们可以通过调用实现方的接口从而拥有实现方给我们提供的能力，这就是 API ，这种接口和实现都是放在实现方的。
+一般模块之间都是通过接口进行通讯，因此我们在服务调用方和服务实现方（也称服务提供者）之间引入一个“接口”。
-当接口存在于调用方这边时，就是 SPI ，由接口调用方确定接口规则，然后由不同的厂商去根据这个规则对这个接口进行实现，从而提供服务。
+- 当实现方提供了接口和实现，我们可以通过调用实现方的接口从而拥有实现方给我们提供的能力，这就是 **API**。这种情况下，接口和实现都是放在实现方的包中。调用方通过接口调用实现方的功能，而不需要关心具体的实现细节。
+- 当接口存在于调用方这边时，这就是 **SPI** 。由接口调用方确定接口规则，然后由不同的厂商根据这个规则对这个接口进行实现，从而提供服务。
举个通俗易懂的例子：公司 H 是一家科技公司，新设计了一款芯片，然后现在需要量产了，而市面上有好几家芯片制造业公司，这个时候，只要 H 公司指定好了这芯片生产的标准（定义好了接口标准），那么这些合作的芯片公司（服务提供者）就按照标准交付自家特色的芯片（提供不同方案的实现，但是给出来的结果是一样的）。
@@ -452,8 +459,8 @@ SPI 将服务接口和具体的服务实现分离开来，将服务调用方和
简单来说：
-- **序列化**：将数据结构或对象转换成二进制字节流的过程
-- **反序列化**：将在序列化过程中所生成的二进制字节流转换成数据结构或者对象的过程
+- **序列化**：将数据结构或对象转换成可以存储或传输的形式，通常是二进制字节流，也可以是 JSON, XML 等文本格式
+- **反序列化**：将在序列化过程中所生成的数据转换为原始数据结构或者对象的过程
对于 Java 这种面向对象编程语言来说，我们序列化的都是对象（Object）也就是实例化后的类(Class)，但是在 C++这种半面向对象的语言中，struct(结构体)定义的是数据结构类型，而 class 对应的是对象类型。
diff --git a/docs/java/basis/java-keyword-summary.md b/docs/java/basis/java-keyword-summary.md
index daf13c9ec14..1d21e2467ed 100644
--- a/docs/java/basis/java-keyword-summary.md
+++ b/docs/java/basis/java-keyword-summary.md
@@ -54,7 +54,7 @@ super 关键字用于从子类访问父类的变量和方法。 例如：
```java
public class Super {
protected int number;
- protected showNumber() {
+ protected void showNumber() {
System.out.println("number = " + number);
}
}
@@ -199,7 +199,7 @@ public class Singleton {
```java
//将Math中的所有静态资源导入，这时候可以直接使用里面的静态方法，而不用通过类名进行调用
//如果只想导入单一某个静态方法，只需要将*换成对应的方法名即可
-import static java.lang.Math.*;//换成import static java.lang.Math.max;具有一样的效果
+import static java.lang.Math.*;//换成import static java.lang.Math.max;即可指定单一静态方法max导入
public class Demo {
public static void main(String[] args) {
int max = max(1,2);
@@ -250,7 +250,7 @@ bar.method2();
不同点：静态代码块在非静态代码块之前执行(静态代码块 -> 非静态代码块 -> 构造方法)。静态代码块只在第一次 new 执行一次，之后不再执行，而非静态代码块在每 new 一次就执行一次。 非静态代码块可在普通方法中定义(不过作用不大)；而静态代码块不行。
> **🐛 修正（参见：[issue #677](https://github.com/Snailclimb/JavaGuide/issues/677)）**：静态代码块可能在第一次 new 对象的时候执行，但不一定只在第一次 new 的时候执行。比如通过 `Class.forName("ClassDemo")`创建 Class 对象的时候也会执行，即 new 或者 `Class.forName("ClassDemo")` 都会执行静态代码块。
-> 一般情况下,如果有些代码比如一些项目最常用的变量或对象必须在项目启动的时候就执行的时候,需要使用静态代码块,这种代码是主动执行的。如果我们想要设计不需要创建对象就可以调用类中的方法，例如：`Arrays` 类，`Character` 类，`String` 类等，就需要使用静态方法, 两者的区别是 静态代码块是自动执行的而静态方法是被调用的时候才执行的.
+> 一般情况下,如果有些代码比如一些项目最常用的变量或对象必须在项目启动的时候就执行,需要使用静态代码块,这种代码是主动执行的。如果我们想要设计不需要创建对象就可以调用类中的方法，例如：`Arrays` 类，`Character` 类，`String` 类等，就需要使用静态方法, 两者的区别是 静态代码块是自动执行的而静态方法是被调用的时候才执行的.
Example：
diff --git a/docs/java/basis/reflection.md b/docs/java/basis/reflection.md
index 769d85e620f..3ce8ccab9a9 100644
--- a/docs/java/basis/reflection.md
+++ b/docs/java/basis/reflection.md
@@ -116,7 +116,7 @@ public class TargetObject {
}
```
-2. 使用反射操作这个类的方法以及参数
+2. 使用反射操作这个类的方法以及属性
```java
package cn.javaguide;
@@ -177,7 +177,7 @@ I love JavaGuide
value is JavaGuide
```
-**注意** : 有读者提到上面代码运行会抛出 `ClassNotFoundException` 异常,具体原因是你没有下面把这段代码的包名替换成自己创建的 `TargetObject` 所在的包 。
+**注意** : 有读者提到上面代码运行会抛出 `ClassNotFoundException` 异常，具体原因是你没有下面把这段代码的包名替换成自己创建的 `TargetObject` 所在的包 。
可以参考：