PaiSmart BUG，捎带MD文档内容调用DeepSeek API时，发生Unicode字符十六进制转义错误

本文主要串联动态代理中的知识点，并梳理一下代理模式的发展史，进而映出其如何**迭代**和**实现**现在开发中常用的代理模式，如Spring AOP、MyBatis等框架。



# 思路
## 知识点串联
这里面主要涉及到了这几个技术：字节码操作、类加载、反射、动态代理。

JVM 基于**类加载器**和**方法区**支撑实现了`java.lang.reflect`**反射API**。

通过使用**反射**，对设计原则**代理模式**的实现**静态代理**进行改进，基于反射实现了**动态代理**。

> - **JVM 角色**：JVM 的类加载器和方法区（元空间）为 Java 反射提供了**必要的运行时数据基础**，但反射本身是通过 `java.lang.reflect` 这套 API 实现的。
> - **反射与动态代理**：**JDK 动态代理**的实现**核心依赖于 Java 反射机制**（特别是 `Proxy` 类的生成和 `Method.invoke()` 的调用）。反射使得在运行时动态创建代理类和动态调用目标方法成为可能，从而克服了静态代理的局限性，实现了更灵活的代理模式。
> - **改进关系**：可以说，**利用反射技术**，对传统的静态代理模式进行了改进，实现了更加灵活和通用的**动态代理**。

## 概要
本质上动态代理只是对静态代理中，代理对象的生成从编写固定的代理类代码实现到采取的动态生成代理对象的改进。从而实现一个类似的代理对象，来对目标对象包装进行内部调用。

根据实现动态代理的方式不同，主要分为**基于接口实现**的JDK动态代理和**基于子类实现**的CGLIB。

JDK 动态代理，通过代理对象实现目标对象的相同接口，用多态实现代理，对目标对象进行包裹然后内部调用，通过接口可以保证代理对象和目标对象的类同；

CGLIB则是通过继承代理，通过字节码生成代理子类对象包装目标对象，重写和super调用父类原方法进行代理）

# 代理模式的由来，有什么用？
在我们平常的代码中，会有一些重复的功能（比如日志记录、事务管理、权限验证等）。在传统的编程方式中，如果我们要为一个类添加这些功能，通常有两种选择：一种是在类代码中直接添加`before()`和`after()`这样的函数调用，并在这些函数中实现相应的逻辑；另一种是通过组合方式引入功能类，将这些功能作为参数传递给目标类。但无论采用哪种方式，都会导致代码冗余或耦合度增加的问题。

**如果在类中直接实现这些功能，会导致代码冗余**。例如，当多个类都需要添加日志功能时，每个类都需要重复编写相同的日志记录代码，这不仅违反了"不要重复自己"(DRY)原则，还增加了维护成本。如果日志格式需要变更，就需要修改所有包含日志代码的类，容易出错且效率低下。

**如果通过组合方式引入功能类，会导致耦合入侵**。例如，为实现事务管理功能，目标类需要持有事务管理器的引用，并在方法执行前后调用事务管理器的开始和提交方法。这种做法虽然避免了代码重复，但目标类却被迫知晓事务管理的实现细节，破坏了单一职责原则，增加了类之间的依赖关系。

**代理模式正是为了解决这一矛盾而诞生的设计模式**。它提供了一种既不造成代码冗余，又不引入耦合的方式，实现横切关注点的集中管理。通过代理对象，可以在不修改目标类代码的情况下，为其添加额外功能，使目标类专注于核心业务逻辑。

# 代理模式的实现
在开始讨论代理模式的具体实现之前，我们先通过一幅图片来简单抽象地描述代理模式中各个部分：

![file-20250828012154590.png](https://www.blog.aeside.top/static/img/78e417aa55bdd9c44e3b7b9f734ec402.file-20250828012154590.webp)
## 静态代理
静态代理是最基础的代理模式实现方式，它通过预先编写代理类来实现代理功能。静态代理的实现需要三个关键组件：

**1. 接口定义**：定义客户端与目标对象交互的契约。
```java
public interface Service {
    void execute();
}
```

**2. 被代理类实现**：实现接口，提供核心业务逻辑。
```java
public class RealService implements Service {
    @Override
    public void execute() {
        System.out.println("执行核心业务逻辑");
    }
}
```

**3. 代理类实现**：实现同一接口，内部持有目标对象引用，并在方法调用前后添加额外逻辑。
```java
public class ProxyService implements Service {
    private Service realService;

    public ProxyService(Service realService) {
        this.realService = realService;
    }

    @Override
    public void execute() {
        before();  // 添加额外逻辑（如日志记录）
        realService.execute();  // 调用目标对象方法
        after();   // 添加额外逻辑（如事务提交）
    }

    private void before() {
        System.out.println("代理方法前的额外操作");
    }

    private void after() {
        System.out.println("代理方法后的额外操作");
    }
}
```

---
### 小结
**静态代理的核心优势在于简单直观**。它通过接口保证类型兼容性，使客户端无需修改即可使用代理对象。代理类通过持有目标对象的引用，可以在调用目标方法前后添加额外功能。

**但静态代理也存在明显的局限性**：
- **代码冗余**：每个需要代理的接口都需要单独编写代理类，当系统中存在大量接口时，代码量会急剧增加。
- **维护困难**：如果接口方法发生变化，所有相关的代理类都需要同步修改，容易遗漏或出错。
- **扩展性差**：无法在运行时动态决定是否代理某个对象，也无法灵活地添加或移除代理功能。

## 动态代理
动态代理是对静态代理的革命性改进，它通过**运行时自动生成代理类**的方式，解决了静态代理的上述局限性。动态代理主要有两种实现方式：

> 多态实现（JDK 动态代理）和子类实现（CGLIB/Byte Buddy）这两种技术路径，其核心目标是为了解决动态代理模式中的一个**根本性问题**：**类型兼容性 (Type Compatibility)** 或 **无缝替换 (Seamless Substitution)**。

### JDK动态代理——基于接口实现
JDK动态代理基于接口实现，利用反射机制在运行时动态生成代理类。其核心组件包括：

**1. 接口定义**：与静态代理相同，定义客户端与目标对象交互的契约。
```java
public interface Service {
    void execute();
}
```

**2. 被代理类实现**：实现接口，提供核心业务逻辑。
```java
public class RealService implements Service {
    @Override
    public void execute() {
        System.out.println("执行核心业务逻辑");
    }
}
```

**3. 代理处理器**：实现`InvocationHandler`接口，定义代理逻辑。
```java
public class ServiceProxy implementsInvocationHandler {
    private Object target;

    public ServiceProxy(Object target) {
        this.target = target;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        before();  // 添加额外逻辑（如日志记录）
        Object result = method.invoke(target, args);  // 反射调用目标方法
        after();   // 添加额外逻辑（如事务提交）
        return result;
    }

    private void before() {
        System.out.println("代理方法前的额外操作");
    }

    private void after() {
        System.out.println("代理方法后的额外操作");
    }

    public static Object getProxy(Object target) {
        return Proxy.newProxyInstance(
            target.getClass().getClassLoader(),
            target.getClass().getInterfaces(),
            new ServiceProxy(target)
        );
    }
}
```

---
#### 小结
**JDK动态代理的核心原理**：
- 在运行时，通过`Proxy.newProxyInstance()`方法动态生成代理类。
- 生成的代理类实现了目标对象的所有接口。
- 代理对象通过`InvocationHandler`接口的`invoke()`方法实现对目标方法的拦截和增强。

**JDK动态代理的优势**：
- **简洁性**：只需编写一个`InvocationHandler`实现类，即可代理所有实现特定接口的类。
- **类型安全**：通过接口保证类型兼容性，确保代理对象可以无缝替换目标对象。
- **支持多接口**：可以代理实现多个接口的目标对象。

**JDK动态代理的局限性**：
- **依赖接口**：必须要有接口才能使用JDK动态代理，无法代理没有接口的普通类。
- **性能开销**：反射调用比直接方法调用有更高的性能开销。
- **功能受限**：无法代理`final`方法。

### CGLIB动态代理——基于继承实现
CGLIB（Code Generation Library）是一种基于继承的动态代理技术，它直接通过字节码操作生成目标类的子类实现代理功能。其核心原理如下：

**1. 目标类定义**：普通Java类，无需实现特定接口。
```java
public class RealService {
    public void execute() {
        System.out.println("执行核心业务逻辑");
    }
}
```

**2. 方法拦截器**：实现`MethodInterceptor`接口，定义代理逻辑。
```java
public class ServiceInterceptor implements MethodInterceptor {
    @Override
    public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
        before();  // 添加额外逻辑（如日志记录）
        Object result = methodProxy.invokeSuper(proxy, args);  // 调用父类方法
        after();   // 添加额外逻辑（如事务提交）
        return result;
    }

    private void before() {
        System.out.println("代理方法前的额外操作");
    }

    private void after() {
        System.out.println("代理方法后的额外操作");
    }
}
```

**3. 代理对象创建**：使用`Enhancer`类动态生成代理对象。
```java
public static RealService getProxy() {
    Enhancer enhancer = new Enhancer();
    enhancer.set Superclass(RealService.class);
    enhancer.setCallback(new ServiceInterceptor());
    return (RealService) enhancer.create();
}
```

---
#### 小结
**CGLIB动态代理的核心原理**：
- 在运行时，通过字节码操作技术（基于ASM框架）动态生成目标类的子类。
- 生成的子类重写目标类的所有非`final`方法。
- 在重写的方法中，插入对拦截器的调用，实现对目标方法的拦截和增强。

**CGLIB动态代理的优势**：
- **无接口限制**：可以代理没有实现接口的普通类。
- **性能更好**：基于字节码生成的代理，性能优于JDK的反射机制。
- **灵活性更高**：可以代理类的方法，而不仅仅是接口方法。

**CGLIB动态代理的局限性**：
- **无法代理final类或方法**：Java的`final`关键字限制了类或方法的继承和重写，因此CGLIB无法代理这些内容。
- **依赖字节码操作**：需要引入额外的依赖库（如ASM）。
- **复杂性更高**：实现和理解比JDK动态代理更复杂。

### 静态代理与动态代理的对比

| 对比维度 | 静态代理 | JDK动态代理 | CGLIB动态代理 |
|---------|---------|------------|--------------|
| **生成方式** | 手动编写代理类 | 运行时基于接口生成代理类 | 运行时基于类生成子类 |
| **依赖要求** | 依赖接口或继承 | 必须依赖接口 | 可代理普通类，但不能代理`final`类 |
| **维护成本** | 高（接口变更需同步修改所有代理类） | 低（只需修改`InvocationHandler`） | 低（只需修改拦截器） |
| **扩展性** | 差（需手动修改代理类） | 好（支持多接口，可动态代理） | 更好（无接口限制，可动态代理） |
| **性能开销** | 无 | 高（反射调用） | 中（字节码生成） |
| **代码量** | 大（每个接口需一个代理类） | 小（一个处理器代理多个接口） | 最小（一个拦截器代理多个类） |

### 代理模式的意义
到最后我们再重新从一个整体的视角去对代理模式意义进行一个审视总结：

**1. 解耦与复用**：通过代理对象，可以将核心业务逻辑与横切关注点（如日志、事务、安全等）分离，避免代码冗余和入侵式修改。例如，一个系统中有多个服务类需要添加日志功能，通过代理模式，只需在代理对象中实现日志逻辑，而无需在每个服务类中重复编写。

**2. 灵活性**：动态代理支持运行时生成代理对象，可以根据需要动态决定是否代理某个对象，以及代理哪些方法。例如，在Spring框架中，可以通过配置决定哪些Bean需要事务管理，而无需修改这些Bean的代码。

**3. 扩展性**：动态代理使得系统更容易扩展新功能。例如，当需要为系统添加新的横切关注点（如性能监控）时，只需修改代理逻辑，而无需修改所有目标类。

**4. 框架基石**：动态代理是许多主流框架的核心技术。例如：
- **Spring AOP**：通过动态代理实现面向切面编程，支持声明式事务管理、安全控制等功能。
- **Hibernate**：使用动态代理实现延迟加载、属性访问控制等功能。
- **RPC框架**：通过动态代理实现远程方法调用，隐藏网络通信细节。

**总之，动态代理是代理模式的重要演进**。它通过将代理类的生成从编译时转移到运行时，解决了静态代理的维护困难和扩展性差的问题，使代理模式成为解决横切关注点的标准方案。在现代软件开发中，动态代理已成为实现松耦合、高内聚系统架构的关键技术之一。

漫谈代理模式，静态代理到 JDK 和 CGLIB 动态代理

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**数据段**

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

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

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

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



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

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

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

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

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

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

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

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

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

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

HashMap梳理

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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