`EXPLAIN` 是一个用于分析和优化 SQL 查询的 MySQL 命令。它提供了关于查询的执行计划的详细信息，帮助你了解查询是如何被执行的，以及是否存在性能问题。下面是 `EXPLAIN` 命令输出的主要字段以及它们的含义：

1. **id：** 查询中每个操作的唯一标识符。对于复杂查询，id 将按顺序递增。

2. **select_type：** 查询的类型，例如 `SIMPLE`（简单查询）、`PRIMARY`（主查询）、`SUBQUERY`（子查询）、`DERIVED`（派生表查询）等。



3. **table：** 正在访问的表名。

4. **partitions：** 表分区的信息。

5. **type：** 表示查询的访问类型，它衡量了查询需要扫描多少数据行，常见的类型包括：
 - system： 表示只有一行的表。这通常是在 WHERE 子句中使用了常量条件时出现的情况。
 - const： 表示在查询中使用了主键或唯一索引进行常量查找。在这种情况下，MySQL 将只从表中读取一行数据。
 - eq_ref： 表示在查询中使用了连接操作，且连接条件使用了唯一索引。每个连接的结果最多只有一行。
 - ref： 表示在查询中使用了非唯一索引来查找值。可能会返回多行数据。
 - fulltext： 表示在全文搜索操作中使用了全文索引。
 - ref_or_null： 类似于 ref，但还包括了对 NULL 值的查找。
 - index_merge： 表示在查询中使用了多个索引，并且 MySQL 使用了索引合并优化策略。
 - unique_subquery： 表示在子查询中使用了唯一索引。
 - index_subquery： 表示在子查询中使用了非唯一索引。
 - range： 表示在查询中使用了范围查找，通常会使用在大于、小于等条件中。
 - index： 表示在查询中使用了索引来扫描整个索引树，这通常发生在没有更好的索引可用时。
 - ALL： 表示全表扫描，即需要扫描整个表的数据。
6. **possible_keys：** 可能用于查询的索引列表。

7. **key：** 实际选择使用的索引。

8. **key_len：** 使用的索引的长度。

9. **ref：** 表示哪个列或常量与 key 进行的比较。

10. **rows：** 估计将扫描的行数，表示操作需要遍历的数据行数。

11. **filtered：** 表示操作后的行数占原始行数的百分比，用于过滤不满足条件的行。

12. **Extra：** 字段提供了关于查询执行计划中的额外信息，在进行 SQL 查询性能优化时，务必关注 `Extra` 字段，以便更好地理解查询的执行过程，常见的值的含义：
 - **Using index：** 表示查询中使用了覆盖索引（Covering Index）。即查询所需的数据可以从索引中直接获取，而无需访问实际的数据行。这是一种性能优化，可以减少对表数据的访问次数。
 - **Using where：** 表示在查询中使用了 `WHERE` 条件进行过滤。这通常意味着查询并没有使用索引，而是对所有数据进行了扫描，并在内存中进行过滤。
 - **Using temporary：** 表示查询使用了临时表来保存中间结果。通常在排序、分组或连接操作中出现。使用临时表可能会导致性能开销，需要特别注意。
 - **Using filesort：** 表示在排序操作中使用了文件排序而不是索引排序。这可能会导致额外的磁盘 I/O，影响性能。
 - **Range checked for each record：** 表示在执行范围查询时，对每条记录都进行了范围检查，可能导致性能下降。
 - **Full scan on NULL key：** 表示查询中进行了对 NULL 值的全表扫描。避免全表扫描，特别是在大表上，可以提高性能。
 - **Distinct：** 表示查询使用了 `DISTINCT` 关键字，这可能需要对结果集进行排序和去重操作。
 - **Not exists：** 表示查询使用了 `NOT EXISTS` 子查询，通常会导致内连接的效果，可能需要额外的计算。
 - **Select tables optimized away：** 表示查询优化器优化掉了某些不必要的表，可能是因为查询条件总是为假，或者使用了覆盖索引等情况。
 - **Impossible where：** 表示查询的 `WHERE` 条件总是为假，优化器可以直接返回空结果集。
 - **No tables used：** 表示查询没有涉及到表的访问，可能只是一个常量表达式或者函数计算。
 - **Using join buffer：** 表示在连接操作中使用了连接缓冲区。

通过分析 `EXPLAIN` 输出，你可以获得关于查询性能的一些信息，例如是否使用了索引、是否存在全表扫描、是否使用了临时表等。这有助于你进行 SQL 查询的性能优化。

例如，如果查询执行计划中存在全表扫描或使用临时表，可能需要考虑优化查询的条件、索引或表结构，以减少性能开销。此外，通过选择更合适的索引，可以显著提升查询性能。

总之，`EXPLAIN` 命令是优化 SQL 查询的重要工具，它可以帮助你深入了解查询的执行过程，从而做出有针对性的性能优化。

mysql的explain执行计划详解

## JVM详解

### JVM定义
- JVM(Java Virtual Machine)即Java虚拟机,它是一个抽象的计算机,是运行Java字节码的虚拟执行引擎，JVM为Java的跨平台性提供了runtime环境,屏蔽了底层系统的差异,让Java程序只需要面向JVM编程就可以在不同系统上运行。它为Java程序管理内存,保证安全,提供线程支持等功能。



### JVM详细介绍
1. JVM是一个规范,定义了一台抽象计算机的工作方式,描述了这台计算机如何加载类文件,如何执行字节码,如何进行内存管理等。不同的JVM实现需要遵循这个规范,从而保证Java的“一次编写,到处运行”。
2. JVM是一个虚拟机,它屏蔽了各种硬件平台和操作系统的差异,Java程序只需要针对JVM进行编译和运行,就可以在不同平台上运行,不需要重新编译。
3. JVM负责执行Java字节码。Java源代码先被编译成字节码,字节码再在JVM上运行。JVM包含类加载器、运行时数据区、执行引擎、垃圾回收器等组件来支持字节码的运行。
4. JVM为Java程序提供了内存管理、安全管理和线程管理等功能。它负责自动分配和回收内存,降低内存操作的复杂度;负责程序的字节码验证,确保代码安全;负责创建和调度线程等。
5. 主流的JVM实现有Oracle HotSpot JVM、OpenJDK JVM、IBM JVM等。不同的JVM实现可以有自己的优化手段,但对外需要符合JVM规范。

### JVM内存模型

![image.png](/static/img/3d21bda7426929e8ae99f936cd60be66.image.webp)
&emsp;&emsp;JVM包含以下三大部分：`类加载器(Class Loader)`、`执行引擎(Execution Engine)`、`运行时数据区(Runtime Data Area)`。

#### 类加载器（Class Loader）
&emsp;&emsp;类加载器是JVM的一个重要组成部分，负责将Java类加载到内存中并进行初始化。类加载器具有层次结构，分为不同的类加载器，每个加载器负责加载特定的类。以下是对JVM类加载器的详细解释：

**Bootstrap Class Loader（启动类加载器）：**
 - Bootstrap Class Loader是JVM内置的类加载器，负责加载Java核心类库，如`java.lang`包中的类。
 - 由于Bootstrap Class Loader是用本地代码实现的，因此在Java代码中无法直接获取对其的引用。

**Extension Class Loader（扩展类加载器）：**
 - Extension Class Loader负责加载JRE扩展目录（`jre/lib/ext`）中的JAR包和类。
 - 它是由`sun.misc.Launcher$ExtClassLoader`实现的，并继承自`java.net.URLClassLoader`。

**Application Class Loader（应用类加载器）：**
 - Application Class Loader（也称为System Class Loader）负责加载应用程序类路径（CLASSPATH）下的类。
 - 它是由`sun.misc.Launcher$AppClassLoader`实现的，并继承自`java.net.URLClassLoader`。

**自定义类加载器：**
 - 除了上述三种标准类加载器，JVM还允许用户自定义类加载器。自定义类加载器可以实现特定的加载需求，如从非标准位置加载类、实现类隔离等。

**类加载过程：**
1. **加载（Loading）：** 类加载器根据类的全限定名找到类文件，将其加载到内存中。这个过程不包括类的实例化，只是将类的元数据加载到JVM中。

2. **链接（Linking）：** 将已加载的类与其他类和资源连接起来。链接分为三个阶段：验证（Verification）、准备（Preparation）和解析（Resolution）。

3. **初始化（Initialization）：** 对类进行初始化，执行类构造器 `<clinit>` 方法的过程。在初始化阶段，静态成员变量会被赋初始值，静态代码块会被执行。

**双亲委派模型：**
JVM的类加载器采用了双亲委派模型，即在加载一个类时，会首先尝试由父加载器加载，如果父加载器无法加载，则由子加载器加载。这种模型保证了类的一致性和安全性。

类加载器在Java中具有重要作用，它使得Java应用程序能够动态加载类，实现了类的隔离和版本管理，同时也有助于确保类的安全性和合规性。

#### 执行引擎（Execution Engine）
&emsp;&emsp;执行引擎是Java虚拟机（JVM）的一个重要组成部分，负责将编译后的字节码文件转化为机器代码并执行。它是实现Java程序运行的核心引擎，控制着程序的执行流程。以下是对执行引擎的详细解释：

1. **字节码解释器（Bytecode Interpreter）：**
 - 字节码解释器是执行引擎的一种常见实现方式，它逐条解释字节码指令，将其转化为底层机器代码并执行。
 - 解释器的优势是可以实现跨平台的特性，但由于逐条解释的性能较低，可能会导致程序的执行效率相对较低。

2. **即时编译器（Just-In-Time Compiler，JIT Compiler）：**
 - 即时编译器是执行引擎的另一种实现方式，它将字节码转化为本地机器代码，并在运行时进行编译，以提高程序的执行效率。
 - JIT编译器将热点代码（经常执行的代码块）编译成本地代码，从而减少解释执行的开销。
 - JIT编译器有两种模式：客户端模式和服务器模式，分别针对不同的应用场景进行优化。

3. **执行流程：**
 - 执行引擎从方法区中获取字节码指令，解释器或JIT编译器将其转化为机器代码。
 - 解释器逐条执行字节码指令，将其翻译为机器指令并执行。
 - JIT编译器会将热点代码编译为机器代码，并将其存储在本地代码缓存区（Native Method Stack）中，以供重复执行。
 - 执行引擎根据解释器或编译器生成的代码执行程序逻辑，实现方法调用、数据操作等功能。

执行引擎在Java虚拟机中扮演了至关重要的角色，它是将高级Java程序转化为底层机器代码的关键环节。字节码解释器和即时编译器在执行引擎中的共同作用，可以在保证跨平台特性的同时提供高效的执行性能。

#### 运行时数据区(Runtime Data Area)
&emsp;&emsp;运行时数据区（Runtime Data Area）是Java虚拟机（JVM）在运行Java程序时用来存储数据的区域，它包含了多个不同的内存区域，每个区域负责不同的任务和数据存储。以下是对运行时数据区各个区域的详细解释：

1. **方法区（Method Area）：**
 - 方法区用于存储已加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
 - 类信息包括类的结构、方法、字段、父类、接口等。它是所有线程共享的内存区域。
 - 在HotSpot虚拟机中，方法区又称为永久代（Permanent Generation），但在较新的版本中已经被元空间（Metaspace）取代。

2. **堆（Heap）：**
 - 堆是用于存储对象实例和数组的区域，它是Java程序中最主要的内存区域。
 - 堆在JVM启动时创建，用于存放所有通过new关键字创建的对象。
 - 堆可以分为新生代（Young Generation）和老年代（Old Generation），以及可选的永久代（在较早的JVM版本中存在）或元空间。

3. **虚拟机栈（Java Virtual Machine Stacks）：**
 - 每个线程都有自己的虚拟机栈，用于存储方法调用和局部变量。
 - 每个方法在调用时都会创建一个栈帧，栈帧包含局部变量表、操作数栈、方法返回地址等。
 - 虚拟机栈可能会出现栈溢出异常，当递归调用过深或者栈帧过多时会发生。

4. **本地方法栈（Native Method Stacks）：**
 - 本地方法栈用于存储调用本地方法（由本地代码实现的方法）时的栈帧。
 - 类似于虚拟机栈，但用于执行本地方法调用。

5. **程序计数器（Program Counter）：**
 - 程序计数器是一个较小的内存区域，用于存储当前线程正在执行的字节码指令地址。
 - 每个线程都有一个程序计数器，用于记录线程的执行位置，以支持线程切换和恢复执行。

运行时数据区是Java虚拟机运行程序时的重要组成部分，各个区域的功能和作用紧密相连，它们一起支持了Java程序的执行和管理。不同区域的管理和分配在不同的JVM实现中可能有所不同，但总体上符合Java虚拟机规范。

### JVM堆内存模型

![image.png](/static/img/4904360d3849b5c27145a31e77d5e2e5.image.webp)
&emsp;&emsp;Java虚拟机（JVM）的堆内存是存储对象实例和数组的主要区域，它在运行时动态分配和管理内存。堆内存模型由新生代、老年代和持久代（或元空间）组成，每个区域负责不同类型的对象和垃圾回收。以下是对JVM堆内存模型各个区域的详细解释：

1. **新生代（Young Generation）：**
 - 新生代是堆内存中的一个较小的区域，用于存放新创建的对象。
 - 新生代又分为Eden空间和两个Survivor空间（通常称为S0和S1）。
 - 大部分对象在Eden空间分配，经过一次垃圾回收后，仍然存活的对象会被移动到Survivor空间。
 - 年轻代使用的垃圾回收算法主要是复制算法，通过将存活的对象从一个Survivor空间复制到另一个Survivor空间，然后清理掉不再存活的对象。

2. **老年代（Old Generation）：**
 - 老年代用于存储经过多次垃圾回收仍然存活的对象，它的内存较大。
 - 老年代中的对象寿命较长，可能会在程序的整个生命周期中存在。
 - 老年代使用的垃圾回收算法主要是标记-清除算法和标记-整理算法，它们会在堆内存中进行大规模的垃圾回收。

3. **持久代（Permanent Generation）或元空间（Metaspace）：**
 - 持久代在较早的JVM版本中存在，用于存储类的元数据、方法信息等。
 - 元空间是取代持久代的概念，在较新的JVM版本中出现。元空间将类的元数据存储在本地内存中，无需手动设置大小，可以根据需要自动调整。

堆内存模型中的各个区域之间有对象的流动，对象从新生代的Eden空间开始分配，经过多次垃圾回收后，如果仍然存活，会晋升到老年代。垃圾回收的主要目标是清理无用的对象，以便为新对象的分配腾出空间，同时也是为了避免堆内存溢出。

不同的JVM实现可能在堆内存管理方面有所不同，但总体上遵循类似的内存模型，以支持Java程序的运行和内存管理。

### 垃圾回收器和垃圾回收算法

垃圾回收（Garbage Collection）是Java虚拟机（JVM）自动管理内存的重要机制，它可以识别和清理不再被使用的对象，以回收内存并防止内存泄漏。垃圾回收器（Garbage Collector）负责执行垃圾回收的操作，而垃圾回收算法决定了具体如何标识和回收垃圾对象。以下是对垃圾回收器和垃圾回收算法的详细解释：

**垃圾回收器：** 
&emsp;&emsp;垃圾回收器是执行垃圾回收操作的模块，负责找到不再使用的对象并将其释放以回收内存。不同的JVM实现可能有不同类型的垃圾回收器，以适应不同的应用场景。以下是常见的垃圾回收器：

1. **Serial Garbage Collector：**
 - 单线程垃圾回收器，适用于简单的单线程应用。
 - 使用“新生代-老年代”的内存布局，新生代使用复制算法，老年代使用标记-整理算法。
 - 主要用于客户端应用和开发/测试环境。

2. **Parallel Garbage Collector：**
 - 多线程垃圾回收器，用于多核CPU的应用。
 - 也使用“新生代-老年代”的内存布局，新生代和老年代都使用复制算法和标记-整理算法。
 - 常用于需要更好垃圾回收性能的服务器应用。

3. **Concurrent Mark-Sweep (CMS) Garbage Collector：**
 - 并发垃圾回收器，主要用于减少垃圾回收对应用线程的影响。
 - 使用“新生代-老年代”布局，老年代使用标记-清除算法。
 - 进行标记和清除的阶段尽量与应用线程并发执行，以减少停顿时间。

4. **G1 Garbage Collector：**
 - 一款面向服务端应用的垃圾回收器，旨在提供高吞吐量和低停顿时间。
 - 使用“多区域”内存布局，将堆内存划分为多个小区域，进行混合垃圾回收。
 - G1通过智能地选择需要回收的区域，以达到更好的性能和可预测的停顿时间。

5. **ZGC收集器：** 
&emsp;&emsp;ZGC（Z Garbage Collector）收集器是oracle出版的一种低延迟的垃圾回收器，它的目标是将垃圾回收的停顿时间控制在10毫秒以内。ZGC收集器适用于对低延迟有较高要求的应用程序。
 - 低停顿时间： ZGC的主要目标是实现低停顿时间。它通过在垃圾回收过程中与应用线程并发执行，减少了长时间的STW（Stop-The-World）暂停。大部分的垃圾回收操作都是并发执行的，最大的STW暂停时间通常只在几毫秒到十几毫秒之间。

 - 分代内存布局： ZGC使用分代内存布局，分为新生代和老年代。新生代使用可并发复制算法，而老年代使用标记-整理算法。

 - 压缩： 为了减少堆空间的碎片，ZGC回收器会在标记-整理阶段对存活对象进行压缩，使得内存空间更加连续。

 - 可预测性： ZGC回收器设计时强调可预测性，尽量保证回收的时间是可控的，不会导致应用出现长时间的停顿。

 - 适应大堆： ZGC适用于大内存堆环境，可以有效管理几个字节到数TB的内存，ZGC在JDK 11中引入，并在后续版本中逐渐得到改进和优化。

6. **Shenandoah收集器：** 
&emsp;&emsp;Shenandoah收集器是Red Hat公司出版的一种并发垃圾回收器，它通过将垃圾回收的工作分散到多个线程中，实现了低停顿时间。Shenandoah垃圾回收器具有以下特点：

 - **低停顿时间：** Shenandoah的主要目标是实现非常低的停顿时间。它通过在大部分垃圾回收阶段与应用线程并发执行，最大程度地减少了长时间的STW（Stop-The-World）暂停。

 - **并发性：** Shenandoah回收器在许多阶段中与应用线程并发执行，这意味着应用线程可以在回收过程中继续工作，减少了应用的停顿。

 - **分代内存布局：** Shenandoah使用了分代内存布局，分为新生代和老年代。它使用并发复制算法来处理新生代，使用标记-整理算法来处理老年代。

 - **堆压缩：** Shenandoah回收器采用了堆压缩技术，以减少内存碎片，提高内存使用效率。

 - **适用大堆：** Shenandoah适用于大型的Java应用，可以有效管理数十GB甚至数百GB的堆内存,Shenandoah最早在JDK 12中以实验特性引入，在后续版本中继续得到改进和优化。

**垃圾回收算法：** 
&emsp;&emsp;垃圾回收算法决定了如何标识和回收不再使用的对象，不同的算法有不同的策略和特点。

1. **引用计数算法（Reference Counting）：**
 - 通过维护对象的引用计数，当引用数为0时，说明对象不再被引用，可以回收。
 - 但无法解决循环引用问题，对于循环引用的对象，引用计数不会为0，导致内存泄漏。

2. **可达性分析算法（Reachability Analysis）：**
 - 通过从一组根对象出发，沿着引用链追踪，将可以被访问到的对象视为“存活”，不可访问的对象即为“垃圾”。
 - 常见的可达性分析算法有标记-清除算法、标记-整理算法、复制算法等。

3. **分代收集算法（Generational Collection）：**
 - 基于“年轻代-老年代”内存布局，假设大部分对象在短时间内会变为垃圾，只有一小部分对象会存活较长时间。
 - 使用不同的垃圾回收策略和算法，如新生代使用复制算法，老年代使用标记-整理算法。

垃圾回收器和垃圾回收算法的选择取决于应用的性能需求、停顿时间要求、内存规模等因素。不同的应用可能需要不同的垃圾回收策略，以平衡性能和资源消耗。

### CMS垃圾回收过程
&emsp;&emsp;CMS（Concurrent Mark-Sweep）垃圾回收器是Java虚拟机（JVM）中的一种并发垃圾回收器，它的主要目标是减少垃圾回收对应用线程的影响，以降低应用的停顿时间。CMS回收器的工作过程可以分为以下阶段：

1. **初始标记（Initial Mark）：**
 - 初始标记是一次短暂的STW（Stop-The-World）暂停，用于标记老年代中的所有直接可达对象。
 - 在这个阶段，JVM会从根对象出发，标记所有在根对象直接可达的对象，并将这些对象的标记位设置为已标记。

2. **并发标记（Concurrent Mark）：**
 - 在初始标记之后，CMS回收器会与应用线程并发执行，进行标记阶段。应用线程可以继续执行，而垃圾回收线程则在后台标记不可达的对象。
 - 在这个阶段，CMS会通过Tracing算法追踪并标记可达对象。由于并发执行，可能会存在一些对象在标记时发生变化，因此标记阶段结束时会有一些漏标的对象。

3. **重新标记（Remark）：**
 - 重新标记是一次短暂的STW暂停，用于修正在并发标记阶段中发生的漏标问题。
 - 在这个阶段，CMS回收器会重新标记那些在并发标记阶段发生变化的对象，以确保所有的可达对象都被正确标记。

4. **并发清除（Concurrent Sweep）：**
 - 在重新标记之后，CMS回收器再次与应用线程并发执行，进行清除阶段。这个阶段主要是清理被标记为垃圾的对象。
 - 被清除的内存空间不会被立即回收，而是被放入空闲列表中，以备将来使用。

5. **并发重置（Concurrent Reset）：**
 - 并发重置是最后一个阶段，用于清除CMS回收器的一些内部数据结构，使其准备好下一次垃圾回收。

总体来说，CMS垃圾回收器通过并发执行的方式，在标记和清除阶段尽量减少应用的停顿时间。但是，CMS回收器也存在一些缺点，如在标记和清除阶段会产生一些附加的内存开销，可能会导致碎片问题。为了解决这些问题，一些新的垃圾回收器，如G1（Garbage-First）回收器，已经在较新的JVM版本中出现。

JVM详解

# 需求的通用三要素

### 驱动：
&emsp;&emsp;驱动是需求出现的原因或动机，它推动着需求的产生和存在。驱动可以是人的意愿、需求的发现、问题的出现，也可以是自动化系统的触发条件。例如，人们对特定产品或服务的需求可以是因为改善生活质量，满足某种欲望，或者解决某个问题。



### 实例：
&emsp;&emsp;实例是需求所涉及的具体对象或目标。它可以是实际的物体、抽象的概念，或者需要被实现的目标。在满足需求的过程中，实例是需求关注的焦点，是人们希望达到或改变的具体内容。

### 过程：
&emsp;&emsp;过程是驱动和实例之间的衔接和实现手段。它描述了满足需求的步骤、方法或操作。过程通常是一系列有序的活动，以达到满足需求的目标。这些活动可能包括规划、执行、监控和反馈等。


:::tip{title="提示"}
对于复杂的需求，拆解是一个很好的方法，通过将需求拆分成更小的子需求，可以更好地理解和管理需求。然后，将每个子需求与三要素：驱动、实例和过程相关联，可以帮助我们更系统地分析和解决问题。这种方法有助于清晰地定义需求，确定满足需求的关键步骤，并确保最终的实现与初衷相符。
:::

需求的通用三要素

# 小谈线程并发工具

&emsp;&emsp;Java 并发包提供了许多线程并发工具，用于在多线程环境下管理和控制线程的执行，下面就详细介绍`CountDownLatch`、`CyclicBarrier`、`Semaphore`和`Exchanger`的原理和使用。

## CountDownLatch
### 简介
CountDownLatch 是 Java 并发编程中的一个工具类，它用于实现线程间的等待。它的作用是让某个线程等待其他线程完成操作后再继续执行



### 简单使用
***运行代码***

:::tip{title="温馨提示"}
复制下面代码，在idea指定包下粘贴会自动生成`Example.java`类
:::
```java
import java.util.concurrent.CountDownLatch;

public class Example {
 public static void main(String[] args) throws InterruptedException {
 int workerCount = 3;
 CountDownLatch latch = new CountDownLatch(workerCount);
 
 // 创建并启动多个工作线程
 for (int i = 0; i < workerCount; i++) {
 WorkerThread worker = new WorkerThread(latch);
 worker.start();
 }
 
 System.out.println("等待工作线程完成...");
 
 // 主线程等待所有工作线程完成
 latch.await();
 
 System.out.println("所有工作线程已完成，继续执行主线程操作");
 }
}

class WorkerThread extends Thread {
 private final CountDownLatch latch;
 
 public WorkerThread(CountDownLatch latch) {
 this.latch = latch;
 }
 
 @Override
 public void run() {
 // 模拟工作线程执行操作
 try {
 Thread.sleep(1000); // 假设操作耗时 1 秒
 System.out.println("工作线程执行完成");
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 
 // 操作完成后调用 countDown()
 latch.countDown();
 }
}
```
***执行结果***
```shell
等待工作线程完成...
工作线程执行完成
工作线程执行完成
工作线程执行完成
所有工作线程已完成，继续执行主线程操作
```
### 基本原理
&emsp;&emsp;当某个线程完成了一定的操作后，调用`countDown()`方法可以将 CountDownLatch 的计数器减一。每次调用该方法，计数器都会减少一次。当计数器减到零时，所有被阻塞的线程将被释放，可以继续执行。
1. 将 CountDownLatch 内部计数器的值减一。
2. 检查计数器的值，如果减一后计数器的值为零，则唤醒所有因调用`await()`方法而阻塞的线程。
- `countDown()`方法通常由多个工作线程并行调用，每个线程完成一定的操作后调用该方法。通过调用`countDown()`方法，工作线程告知主线程它已经完成了一部分工作，在`countDown()`方法内部，会对计数器进行原子操作，保证多个线程同时调用`countDown()`方法时，不会出现竞态条件。
- 一旦计数器减到零，主线程将被唤醒，可以继续执行后续操作。这样就实现了主线程等待多个子线程完成某个任务后再继续执行的效果。
- 在每次调用`countDown()`方法后，都会检查计数器的值，如果计数器的值减到零，就会唤醒所有因调用 await() 方法而阻塞的线程。唤醒操作也是通过`AQS（AbstractQueuedSynchronizer）`同步器来实现的，以确保被阻塞的线程能够被正确地唤醒。
:::warning{title="注意"}
在使用 CountDownLatch 时，`countDown()`方法的调用次数必须与 CountDownLatch 的初始计数器值相匹配。如果`countDown()`方法的调用次数超过了初始值，计数器的值将保持为零，并且对后续调用不产生任何影响。一旦计数器达到零，后续的`countDown()`调用将被忽略。
:::

## CyclicBarrier
`CyclicBarrier` 是 Java 并发包中的一个同步工具，用于等待一组线程达到一个同步点（barrier point）。它可以用于在多个线程之间创建一个同步点，当所有线程都到达这个同步点时，它们可以继续执行。

`CyclicBarrier` 适用于这样的场景：多个线程在不同的子任务中执行，需要在某个点上等待其他所有线程完成自己的子任务，然后再继续执行下一阶段的任务。

`CyclicBarrier` 的主要特点包括：

1. **同步点：** `CyclicBarrier` 允许多个线程在同一个同步点上等待。当所有线程都到达同步点时，它们将继续执行。

2. **可重用性：** `CyclicBarrier` 可以被重复使用。一旦所有线程都到达同步点并释放了屏障，`CyclicBarrier` 又可以重新用于下一轮的同步。

3. **可选的回调动作：** 你可以在所有线程都达到同步点时执行一个可选的回调动作。

4. **计数器重置：** 在所有线程都到达同步点后，计数器会自动重置，从而可以用于下一轮的同步。

以下是一个简单的示例，展示了如何使用 `CyclicBarrier` 进行线程同步：

```java
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

public class CyclicBarrierExample {
 public static void main(String[] args) {
 int numThreads = 3;
 Runnable barrierAction = () -> System.out.println("All threads have reached the barrier.");

 CyclicBarrier cyclicBarrier = new CyclicBarrier(numThreads, barrierAction);

 for (int i = 0; i < numThreads; i++) {
 Thread thread = new Thread(() -> {
 try {
 System.out.println("Thread " + Thread.currentThread().getId() + " is waiting at the barrier.");
 cyclicBarrier.await(); // 等待所有线程达到同步点
 System.out.println("Thread " + Thread.currentThread().getId() + " has passed the barrier.");
 } catch (InterruptedException | BrokenBarrierException e) {
 e.printStackTrace();
 }
 });
 thread.start();
 }
 }
}
```

在这个示例中，我们创建了一个 `CyclicBarrier`，并指定了需要等待的线程数量（`numThreads`）。每个线程执行到 `cyclicBarrier.await()` 时会等待其他线程到达同步点。一旦所有线程都到达同步点，就会执行可选的回调动作（在本例中是打印信息）并继续执行后续操作。

## Semaphore
`Semaphore` 是 Java 并发包中的一个同步工具，用于控制同时访问某个资源的线程数量。它可以看作是一个计数器，用于管理许可（permit）的分发。`Semaphore` 主要用于限制同时访问某一资源的线程数量，从而控制并发度。

`Semaphore` 的主要方法包括：

1. **`Semaphore(int permits)`：** 构造方法，指定初始许可数量。

2. **`void acquire()`：** 获取一个许可，如果没有可用的许可，则会阻塞。

3. **`void acquire(int permits)`：** 获取指定数量的许可，如果没有足够的可用许可，则会阻塞。

4. **`void release()`：** 释放一个许可。

5. **`void release(int permits)`：** 释放指定数量的许可。

6. **`int availablePermits()`：** 获取当前可用的许可数量。

`Semaphore` 的经典应用之一是限制对有限资源的访问。例如，假设有一个数据库连接池，你可以使用 `Semaphore` 来控制同时可用的连接数。

以下是一个简单的示例，展示了如何使用 `Semaphore` 控制线程的并发访问数量：

```java
import java.util.concurrent.Semaphore;

public class SemaphoreExample {
 public static void main(String[] args) {
 int numThreads = 5;
 int numPermits = 2; // 同时允许的线程数

 Semaphore semaphore = new Semaphore(numPermits);

 for (int i = 0; i < numThreads; i++) {
 Thread thread = new Thread(() -> {
 try {
 semaphore.acquire(); // 获取许可
 System.out.println("Thread " + Thread.currentThread().getId() + " acquired a permit.");
 // 模拟线程执行一些操作
 Thread.sleep(1000);
 semaphore.release(); // 释放许可
 System.out.println("Thread " + Thread.currentThread().getId() + " released a permit.");
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 });
 thread.start();
 }
 }
}
```

在此示例中，我们创建了一个有限数量的许可（`numPermits`），然后启动多个线程。每个线程在执行之前通过 `acquire()` 方法获取许可，执行一些操作后再通过 `release()` 方法释放许可。通过这种方式，我们可以限制同时访问的线程数量，从而控制并发度。

## Exchanger
在 Java 并发包中，`Exchanger` 是一个用于两个线程之间交换数据的同步工具。它提供了一个点，允许两个线程在此点上交换数据。当两个线程都到达交换点时，它们可以交换数据，并继续执行。

`Exchanger` 提供了以下主要方法：

1. **`exchange(V x)`：** 该方法用于交换数据。当某个线程调用此方法时，它将阻塞，直到另一个线程也调用了相同的 `exchange()` 方法。然后两个线程交换数据，并继续执行。

2. **`exchange(V x, long timeout, TimeUnit unit)`：** 类似于上面的方法，但允许设置一个超时时间。如果超过指定的时间，交换操作还未完成，则会解除阻塞。

`Exchanger` 主要用于两个线程之间的数据传输，可以用于解决生产者-消费者模型等问题。例如，一个线程可以用于生成数据，另一个线程用于处理数据，它们可以通过 `Exchanger` 在合适的时间点进行数据交换。

下面是一个简单的示例，展示了如何使用 `Exchanger` 进行数据交换：

```java
import java.util.concurrent.Exchanger;

public class ExchangerExample {
 public static void main(String[] args) {
 Exchanger<String> exchanger = new Exchanger<>();

 Thread producerThread = new Thread(() -> {
 try {
 String data = "Hello from Producer";
 System.out.println("Producer is producing: " + data);
 exchanger.exchange(data);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 });

 Thread consumerThread = new Thread(() -> {
 try {
 String receivedData = exchanger.exchange(null);
 System.out.println("Consumer received: " + receivedData);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 });

 producerThread.start();
 consumerThread.start();

 try {
 producerThread.join();
 consumerThread.join();
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 }
}
```

在此示例中，生产者线程生成数据并调用 `exchange()` 方法，然后阻塞。消费者线程调用 `exchange()` 方法等待交换，一旦生产者线程调用了 `exchange()`，两个线程会交换数据并继续执行。

## AQS（AbstractQueuedSynchronizer）同步器

`AbstractQueuedSynchronizer`（简称为AQS）是Java中用于实现同步器的抽象基类。它为实现各种同步机制（如ReentrantLock、CountDownLatch、Semaphore等）提供了基础框架。AQS通过内部维护一个FIFO的等待队列来管理线程的等待和唤醒，使得开发者能够相对容易地实现自定义的同步机制。

以下是关于`AbstractQueuedSynchronizer`的详细解释：

1. **同步器基础：** AQS 提供了一个底层的框架，用于实现各种同步器。它通过提供一组状态变量和操作来管理线程的访问权限和等待状态。

2. **状态变量：** AQS 的核心是状态变量，通过维护不同的状态来表示不同的同步状态。这个状态变量的具体含义和使用方式是由子类去定义和实现的。

3. **队列管理：** AQS 内部维护了一个等待队列，用于存放等待获取同步状态的线程。这个队列是一个FIFO队列，也就是先等待的线程先被唤醒。

4. **模板方法：** AQS 提供了一些模板方法，这些方法在子类中可以被覆写以实现特定的同步逻辑。这些方法包括`tryAcquire`、`tryRelease`、`tryAcquireShared`、`tryReleaseShared`等。

5. **独占和共享模式：** AQS 支持两种同步模式，独占模式（exclusive）和共享模式（shared）。独占模式是一次只能有一个线程获取同步状态，而共享模式允许多个线程同时获取同步状态。

6. **独占模式实现：** 如果一个子类希望实现独占模式的同步，需要覆写`tryAcquire`和`tryRelease`方法。这些方法负责获取和释放同步状态。

7. **共享模式实现：** 如果一个子类希望实现共享模式的同步，需要覆写`tryAcquireShared`和`tryReleaseShared`方法。这些方法负责获取和释放共享的同步状态。

8. **阻塞与唤醒：** AQS 提供了方法用于线程的阻塞和唤醒，这些方法包括`acquire`、`release`、`acquireShared`、`releaseShared`等。

9. **CAS（比较并交换）操作：** AQS 使用CAS操作来更新状态变量，确保线程之间的原子性操作。

等待队列是 AbstractQueuedSynchronizer (AQS) 中的一个重要数据结构，用于管理等待获取同步资源的线程。等待队列通常采用双向链表的形式来组织，它包括以下关键部分：
### FIFO等待队列的数据结构

1. **Node 节点**：等待队列中的每个线程都被封装成一个 Node 节点。Node 节点通常包含以下几个字段：

 - `Thread` 对象：表示等待线程的引用。
 - `int waitStatus`：表示节点的等待状态，用于标识节点的状态。等待状态的值可以表示不同的含义，例如，表示线程是否被取消、是否需要排队、是否已经获取锁等。
 - `Node prev`：指向前一个节点的引用，用于构成双向链表。
 - `Node next`：指向下一个节点的引用，也用于构成双向链表。

2. **头节点（Head）**：等待队列中的头节点通常是一个虚拟节点，不代表任何一个等待线程，主要用于简化队列操作。头节点的 `prev` 字段指向自己，`next` 字段指向队列中的第一个等待线程节点。

3. **尾节点（Tail）**：等待队列中的尾节点是一个指向队列中最后一个等待线程节点的引用。

4. **入队操作**：线程在等待获取同步资源时，会通过入队操作将自己封装成一个节点添加到等待队列的尾部。这通常是一个原子操作，确保线程被正确地添加到队列中。

5. **出队操作**：当线程获取到同步资源时，会执行出队操作，将自己从等待队列中移除。这同样是一个原子操作，确保线程的状态正确地变为已获取锁。

6. **等待与唤醒机制**：等待队列还包括了线程等待和唤醒的机制。当一个线程无法获取同步资源时，它会被阻塞并加入到等待队列中，等待其他线程释放资源或者唤醒它。唤醒操作通常由持有资源的线程执行。

7. **队列的顺序**：队列的顺序通常是先进先出（FIFO）的，也就是等待时间最长的线程在队列的前面。但在非公平锁的情况下，队列顺序可能会更灵活，等待时间短的线程有可能先被唤醒。


:::info{title="相关信息"}
等待队列是 AQS 中用于管理等待线程的数据结构，它采用双向链表的形式，每个节点代表一个等待线程。等待队列的操作是 AQS 实现同步的关键之一，通过合理管理等待队列，AQS 可以实现多种同步器，如独占锁、共享锁、信号量等。
:::

总的来说，`AbstractQueuedSynchronizer`为实现自定义同步器提供了一个强大的框架。虽然它的理解和使用可能相对复杂，但它为开发者提供了在多线程环境下构建高效同步机制的基础工具。同时，Java并发包中的许多同步类，如`ReentrantLock`、`CountDownLatch`、`Semaphore`等，都是基于AQS实现的。

小谈线程并发工具

# Spring Bean生命周期
### 流程图

```mermaid
graph TD
Bean在SpringBean应用上下文中的生命周期 --> 实例化
1.ApplicationContext\n2.scope=singleton --> 实例化
实例化 --> 设置属性
setXXX --> 设置属性
设置属性 --> 执行setBeanName方法
可选,bean类继承BeabNameAware接口\n可选,bean类继承BeanFactoryAware接口 --> 执行setBeanName方法
```



```mermaid
graph TD
可选,bean类继承了ApplicationContextAware接口 --> 执行setApplicationContext方法
执行setApplicationContext方法 --> 执行postProcessBeanforeInitialization方法
可选,bean类继承了BeanPostProcessor接口 --> 执行postProcessBeanforeInitialization方法
执行postProcessBeanforeInitialization方法 --> 执行afterPropertiesSet方法
可选,bean类继承了InitializingBean接口 --> 执行afterPropertiesSet方法
执行afterPropertiesSet方法 --> 执行自定义bean的初始化方法
可选,bean标签中init-methond方法 --> 执行自定义bean的初始化方法
执行自定义bean的初始化方法 --> 执行postProcessAfterInitialization方法
可选,bean类继承了BeanPostProcessor接口 --> 执行postProcessAfterInitialization方法
执行postProcessAfterInitialization方法 --> 使用自定义bean
```
```mermaid
graph TD
可选,bean类实现了DisposableBean --> 执行destory
bean标签中destory-method方法 --> 调用定制的销毁方法
执行destory --> 调用定制的销毁方法
```
### 过程描述
1. 实例化一个Bean，也就是我们常说的new
2. 按照Spring上线文对实例化的Bean进行配置，也就是IOC注入
3. 如果这个Bean已经实现了BeanNameAware接口，会调用它实现的setBeanName(String s)方法，此处传递的就是Spring配置文件中的Bean的id值
4. 如果这个版已经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory，setBeanFactory(BeanFactory bf)传递的是Spring工厂自身（可以用这个方式来获取其他Bean，只需在Spring配置文件中配置一个普通的Bean就可以）。
5. 如果这个Bean已实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext ac)方法，传入Spring上下文（同样这个方式也可以实现步骤4的内容，但比4更好，因为ApplicationContext是BeanFactory的子接口，有更多的实现方法）
6. 如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessBeforeInitialization(Object obj, String s)方法，BeanPostProcessor经常被用作是Bean内容的更改，并且由于这个是在Bean初始化结束时调用的那个的方法，就可以被应用于内存或缓存技术。
7. 如果Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法。
8. 如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法。 
注：以上工作完成以后就可以应用这个Bean了，那这个Bean是一个Singleton的，所以一般情况下我们调用同一个id的Bean会是在内容地址相同的实例，当然在Spring配置文件中也可以配置非Singleton。
9. 当bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean这个接口，会调用那个其实现的destory()方法。
10. 最后，如果这个Bean的Spring配置中配置了destory-method属性，会自动调用其配置的销毁方法。
11. bean标签有两个重要的属性（init-method和destory-method）。用它们可以自定义初始化和注销方法。他们也有相应的注解（@PostContruct和@PreDestory）。 
< bean id="" class="" init-method="初始化方法" destory-method="销毁方法" />