可是偏偏幸运又再一次垂青了你，在飘零半生之后向你又一次地抛出了橄榄枝。只是，如今的你却不在似年少般的意气风发，只留下了岁月打磨过的沧桑。一路上又是如同故事一般，过五关斩六将，艰难险阻但是却一个接一个地克服，来到最终的舞台时。却又是宿命般，再一次倒在了2：3这个已经PTSD的比分前。

为什么是Ame？为什么又一次是决赛2：3？为什么偏偏是CNDOTA无缘决赛的四年后？为什么是在 CNDOTA 黄昏的一年里？为什么是在Ame最颠沛流离的一年里？

如果这是 TI8 ，又或是 TI10 。我不会难过，也不会悲伤，更不会流泪。只是，偏偏是在这落花时节，在这飘零半生之后，在CNDOTA的黄昏时刻，在CNDOTA连续四年无缘决赛之后，在艰难险阻后，又一次如梦初醒地回到了这个舞台，却戏谑般地2：3倒在了最后一步上。

只是不再似少年时候，在这 CNDOTA 的黄昏时刻，在 Ame 职业生涯的终点站，再也很难有机会再一次见证 CNDOTA 和 Ame 捧起冠军盾了。想起社区常言的一句话：“究竟是怎样的结局，才能配得上这一路上的颠沛流离”。

这样的结局太残忍。

少一个BUFF都不会哭，关于TI14

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是通过泊松分布用概率学计算出来的最佳装填因子大小，如果过小会导致数组使用率过低浪费内存，过大则会导致哈希冲突频繁