JVM解密: 解构类加载与GC垃圾回收机制

怼烎@ 2024-04-26 10:56 3阅读 0赞

#### 文章目录 ####

*  一. JVM内存划分
 *  二. 类加载机制
 *   *  1. 类加载过程
     *  2. 双亲委派模型
 *  三. GC垃圾回收机制
 *   *  1. 找到需要回收的内存
     *   *  1.1 哪些内存需要回收？
         *  1.2 基于引用计数找垃圾(Java不采取该方案)
         *  1.3 基于可达性分析找垃圾(Java采取方案)
     *  2. 垃圾回收算法
     *   *  2.1 标记-清除算法
         *  2.2 标记-复制算法
         *  2.3 标记-整理算法
         *  2.4 分代回收

## 一. JVM内存划分 ##

JVM 其实是一个 Java 进程，该进程会从操作系统中申请一大块内存区域，提供给 Java 代码使用，申请的内存区域会进一步做出划分，给出不同的用途。

其中最核心的是栈，堆，方法区这几个区域：

1.  堆，用来放置 new 出来的对象，类成员变量。
2.  栈，维护方法之间的调用关系，放置局部变量。
3.  方法区(旧)/元数据区(新)：放的是类加载之后的类对象（`.class`文件），静态变量，二进制指令（方法）。

细分下来 JVM 的内存区域包括以下几个：程序计数器，栈，堆，方法区，图中的元数据区可以理解为方法区。  
![img][]

🍂**程序计数器**：内存最小的一块区域，保存了下一条要执行的指令（字节码）的地址，**每个线程都有一份**。

🍂**栈**：储存局部变量与方法之间的调用信息，**每一个线程都有一份**，但要注意“栈是线程私有的”这种说法是不准确的，私有的意思是我的你是用不了的，但实际上，一个线程栈上的内容，是可以被另一个线程使用到的。

![img][img 1]

栈在 JVM 区域划分中分为两种，一种是 **Java 虚拟机栈**，另外一种是**本地方法栈**，这两种栈功能非常类似，当方法被调用时，都会同步创建栈帧来存储局部变量表、操作数栈、动态连接、方法出口等信息。

只不过虚拟机栈是为虚拟机执行 Java 方法（也就是字节码）服务，而本地方法栈则是给 JVM 内部的本地（Native）方法服务的（JVM 内部通过 C++ 代码实现的方法）。  
![img][img 2]

🍂**堆**：储存对象以及对象的成员变量，**一个 JVM 进程只有一个，多个线程共用一个堆，是内存中空间最大的区域**，Java 堆是垃圾回收器管理的内存区域，后文介绍 GC 的时候细说。

🍂**方法区**： JDK 1.8 开始，叫做元数据区，存储了类对象，常量池，静态成员变量，即时编译器编译后的代码缓存等数据；所谓的“类对象”，就是被`static`修饰的变量或方法就成了类属性，`.java`文件会被编译成`.class`文件，`.class`会被加载到内存中，也就被 JVM 构造成类对象了，类对象描述了类的信息，如类名，类有哪些成员，每个成员叫什么名字，权限是什么，方法名等；**同样一个 JVM 进程只有一个元数据区，多个线程共用一块元数据区内存。**

![img][img 3]

要注意 **JVM 的线程和操作系统的线程是一对一的关系**，每次在 Java 代码中创建的线程，必然会在系统中有一个对应的线程。

## 二. 类加载机制 ##

### 1. 类加载过程 ###

类加载就是把`.java`文件使用`javac`编译为`.class`文件，从文件（硬盘）被加载到内存中（元数据区），得到类对象的过程。（程序要想运行，就需要把依赖的“指令和数据”加载到内存中）。

![img][img 4]  
这个图片所示的类加载过程来自官方文档，类加载包括三个步骤：`Loading`， `Linking`， `Initialization`。  
官方文档：[https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html][https_docs.oracle.com_javase_specs_jvms_se8_html_jvms-5.html]  
![img][img 5]

下面就来了解一下这三步是在干什么：

第一步，**加载**（`Loading`），找到对应的`.class`文件，打开并读取文件到内存中，同时通过解析文件初步生成一个代表这个类的 java.lang.Class 对象。

第二步，**连接**（`Linking`），作用是建立多个实体之间的联系，该过程有包含三个小过程：

*  **验证**（`Verification`），主要就是验证读取到的内容是不是和规范中规定的格式完全匹配，如果不匹配，那么类加载失败，并且会抛出异常；一个`.class`文件的格式如下：![img][img 6]通过观察`.class`文件结构，其实`.class`文件把`.java`文件的核心信息都保留了下来，只不过是使用二进制的方式重新进行组织了，`.class`文件是二进制文件，这里的格式有严格说明的，哪几个字节表示什么，java官方文档都有明确规定。 来自官方文档：[https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html\#jvms-4.1][https_docs.oracle.com_javase_specs_jvms_se8_html_jvms-4.html_jvms-4.1]
 *  **准备**（`Preparation`），给类对象分配内存空间（先在元数据区占个位置），并为类中定义的静态变量分配内存，此时类变量初始值也就都为 0 值了。
 *  **解析**（`Resolution`），**针对字符串常量初始化，将符号引用转为直接引用**；字符串常量，得有一块内存空间，存这个字符的实际内容，还得有一个引用来保存这个内存空间的起始地址；在类加载之前，字符串常量是在`.class`文件中的，此时这个引用记录的并非是字符串常量真正的地址，而是它在文件的偏移量/占位符（符号引用），也就是说，此时常量之间只是知道它们彼此之间的相对位置，不知道自己在内存中的实际地址；在类加载之后，才会真正的把这个字符串常量给填充到特定的内存地址上中，这个引用才能被真正赋值成指定内存地址（直接引用），此时字符串常量之间相对位置还是一样的；这个场景可以想象你看电影时拿着电影票入场入座。

第三步，**初始化**（Initialization），这里是真正地对类对象进行初始化，特别是静态成员，调用构造方法，进行成员初始化，执行代码块，静态代码块，加载父类…

🎯**类加载的时机**：

类加载并不是 Java 程序（JVM）一运行就把所有类都加载了，而是真正用到哪个类才加载哪个；整体是一个“懒加载”的策略；只有需要用的时候才加载（非必要，不加载），就会触发以下的加载：

1.  构造类的实例
2.  调用这个类的静态方法/使用静态属性
3.  加载子类就会先加载其父类

一旦加载过后后续使用就不必加载了。

### 2. 双亲委派模型 ###

双亲委派模型是类加载中的一个环节，属于加载阶段，它是描述如何根据类的全限定名找到`.class`文件的过程。

在 JVM 里面提供了一组专门的对象，用来进行类的加载，即类加载器，当然既然双亲委派模型是类加载中的一部分，所以其所描述找`.class`文件的过程也是类加载器来负责的。

但是想要找全`.class`文件可不容易，毕竟`.class`文件可能在 jdk 目录里面，可能在项目的目录里面，还可能在其他特定的位置，因此 JVM 提供了多个类加载器，每一个类加载器负责在一个片区里面找。

默认的类加载器主要有三个:

*  BootStrapClassLoader，负责加载 Java 标准库里面的类，如 String，Random，Scanner 等。
 *  ExtensionClassLoader，负责加载 JVM 扩展库中的类，是规范之外，由实现 JVM 的组织（Sun/Oracle），提供的额外的功能。
 *  ApplicationClassLoader，负责加载当前项目目录中自己写的类以及第三方库中的类。

除了默认的几个类加载器，程序员还可以自定义类加载器，来加载其他目录的类，此时也不是非要遵守双亲委派模型，如 Tomcat 就自定义了类加载器，用来专门加载`webapps`目录中的`.class`文件就没有遵守。

![img][img 7]

双亲委派模型就描述了类加载过程中的找目录的环节，它的过程如下：

如果一个类加载器收到了类加载的请求，首先需要先给定一个类的全限定类名，如：“java.lang.String”。

根据类的全限定名找的过程中它不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此。

因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载（去自己的片区搜索）。

举个例子：我们要去找标准库里面的`String.class`文件，它的过程大致如下：

*  首先`ApplicationClassLoader`类收到类加载请求，但是它先询问父类加载器是否加载过，即询问`ExtensionClassLoader`类是否加载过。
 *  如果`ExtensionClassLoader`类没有加载过，请求就会向上传递到`ExtensionClassLoader`类，然后同理，询问它的父加载器`BootstrapClassLoader`是否加载过。
 *  如果`BootstrapClassLoader`没有加载过，则加载请求就会到`BootstrapClassLoader`加载器这里，由于`BootstrapClassLoader`加载器是最顶层的加载器，它就会去标准库进行搜索，看是否有`String`类，我们知道`String`是在标准库中的，因此可以找到，请求的加载任务完成，这个过程也就结束了。

![img][img 8]  
再比如，这里要加载我自己写的的`Test`类，过程如下：

*  首先`ApplicationClassLoader`类收到类加载请求，但是它先询问父类加载器是否加载过，即询问`ExtensionClassLoader`类是否加载过。
 *  如果`ExtensionClassLoader`类没有加载过，请求就会向上传递到`ExtensionClassLoader`类，然后同理，询问它的父加载器`BootstrapClassLoader`是否加载过。
 *  如果`BootstrapClassLoader`没有加载过，则加载请求就会到`BootstrapClassLoader`加载器这里，由于`BootstrapClassLoader`加载器是最顶层的加载器，它就会去标准库进行搜索，看是否有`Test`类，我们知道Test类不在标准库，所以会回到子加载器里面搜索。
 *  同理，`ExtensionClassLoader`加载器也没有`Test`类，会继续向下，到`ApplicationClassLoader`加载器中寻找，由于`ApplicationClassLoader`加载器搜索的就是项目目录，因此可以找到`Test`类，全过程结束。

如果在`ApplicationClassLoader`还没有找到，就会抛出异常。  
![img][img 9]  
总的来说，双亲委派模型就是找`.class`文件的过程，其实也没啥，就是名字挺哄人。

![img][img 10]

之所以有上述的查找顺序，大概是因为 JVM 代码是按照类似于递归的方式来实现的，就导致了从下到上，又从上到下过程，这个顺序，最主要的目的，就是为了保证 Bootstrap 能够先加载，Application 能够后加载，这就可以避免说因为用户创建了一些奇怪的类，引起不必要的 bug。

## 三. GC垃圾回收机制 ##

在 C/C++ 中内存空间是需要进行手动释放，如果没有手动去释放那么这块内存空间就会持续存在，一直到进程结束，并且堆的内存生命周期比较长，不像栈随着方法执行结束自动销毁释放，堆默认是不能自动释放的，这就可能导致内存泄露的问题，进一步导致后续的内存申请操作失败。

而在 Java 中引入了 GC 垃圾回收机制，垃圾指的是我们不再使用的内存，垃圾回收就是把我们不用的内存自动释放了。

GC的好处：

*  非常省心，使程序员写代码更简单一些，不容易出错。

GC的坏处：

*  需要消耗额外的系统资源，也有额外的性能开销。
 *  GC 这里还有一个严重的 STW（stop the world）问题，如果有时候，内存中的垃圾已经很多了，这个时候触发一次 GC 就会消耗大量系统资源，其他程序可能就无法正常执行了；GC 可能会涉及一些锁操作，就可能导致业务代码无法正常执行；极端情况下可会卡顿几十毫秒甚至上百毫秒。

GC 的实际工作过程包含两部分：

1.  找到/判定垃圾。
2.  再进行垃圾的释放。

### 1. 找到需要回收的内存 ###

#### 1.1 哪些内存需要回收？ ####

Java 程序运行时，内存分为四个区，分别是程序计数器，栈，堆，方法区。  
对于程序计数器，它占据固定大小的内存，它是随着线程一起销毁的，不涉及释放，那么也就用不到 GC；对于栈空间，函数执行完毕，对应的栈帧自动销毁释放了，也不需要 GC；对于方法区，主要进行类加载，虽然需要进行“类卸载”，此时需要释放内存，但是这个操作的频率是非常低的；最后对于堆空间，经常需要释放内存，GC 也是主要针对堆进行释放的。

在堆空间，内存的分布有三种，一是正在使用的内存，二是不用了但未回收的内存，三是未分配的内存，那内存中的对象，也有三种情况，对象内存全部在使用（相当于对象整体全部在使用），对象的内存部分在使用（相当于对象的一部分在使用），对象的内存不使用（对象也就使用完毕了），对于这三类对象，前两类不需要回收，只有最后一类是需要回收的。  
![img][img 11]  
所以，**垃圾回收的基本单位是对象**，而不是字节，对于如何找到垃圾，常用有引用计数法与可达性分析法两种方式，关键思路是，抓住这个对象，看看到底有没有“引用”指向它，没有引用了，它就是需要被释放的垃圾。

#### 1.2 基于引用计数找垃圾(Java不采取该方案) ####

所谓基于引用计数判断垃圾，就是给每一个对象分配一个计数器（整数），来记录该对象被多少个引用变量所指，每次创建一个引用指向该对，,计数器就`+1`，每次该引用被销毁了计数器就`–1`，如果这个计数器的值为`0`则表示该对象需要回收，比如有一个Test对象，它被三个引用所指，所以这个 Test 对象所带计数器的值就是`3`。

//伪代码：
    Test t1 = new Test();
    Test t2 = t1;
    Test t3 = t1;

![img][img 12]

如果上述的伪代码是在一个方法中，待方法执行完毕，方法中的局部引用变量被销毁，那么Test对象的引用计数变为`0`，此时就会被回收。

由此可见，基于引用计数的方案非常简单高效并且可靠，但是它拥有两个致命缺陷：

1.  内存空间浪费较多（利用率低）， 需要给每个对象分配一个计数器，如果按照4个字节来算；代码中的对象非常少时无所谓，但如果对象特别多了，占用的额外空间就会很多，尤其是每个对象都比较小的情况下。
2.  存在循环引用的问题，会出现对象既不使用也不释放的情况，看下面举例子来分析一下。

有以下一段伪代码：

class Test {
        
    	Test t = null;
    }
    
    //main方法中:
    Test t1 = new Test(); // 1号对象, 引用计数是1
    Test t2 = new Test(); // 2号对象, 引用计数是1
    t1.t = t2;            // t1.t指向2号对象, 此时2号对象引用计数是2
    t2.t = t1;            // t1.t指向1号对象, 此时1号对象引用计数是2

执行上述伪代码，运行时内存图如下：

![img][img 13]

然后，我们把变量`t1`与t2置为`null`，伪代码如下：

//伪代码:
    t1 = null;
    t2 = null;

执行完上面伪代码，运行时内存图如下：  
![img][img 14]  
此时 t1 和 t2 引用销毁了，一号对象和二号对象的引用计数都`-1`，但由于两个对象的属性相互指向另一个对象，计数器结果都是`1`而不是`0`造成对象无法及时得到释放，而实际上这个两个对象已经获取不到了（应该销毁了）。

#### 1.3 基于可达性分析找垃圾(Java采取方案) ####

Java 中的对象都是通过引用来指向并访问的，一个引用指向一个对象，对象里的成员又指向别的对象。

所谓可达性分析，就是通过额外的线程，将整个 Java 程序中的对象用链式/树形结构把所有对象串起来，从根节点出发去遍历这个树结构，所有能访问到的对象，标记成“可达”，不能访问到的，就是“不可达”，JVM 有一个所有对象的名单（每 new 一个对象，JVM 都会记录下来，JVM 就会知道一共有哪些对象，每个对象的地址是什么），通过上述遍历，将可达的标记出来，剩下的不可达的（未标记的）就可以作为垃圾进行回收了。

可达性分析的起点称为`GC Roots`（就是一个Java对象），一个代码中有很多这样的起点，把每个起点都遍历一遍就完成了一次扫描。  
![img][img 15]

对于这个`GCRoots`，一般很难被回收，它来源可以分为以下几种：

*  在虚拟机栈（栈帧中的本地变量表）中引用的对象，例如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
 *  在本地方法栈中 JNI（即通常所说的Native方法）引用的对象。
 *  常量池中引用所指向的对象。
 *  方法区中静态成员所指向的对象。
 *  所有被同步锁（synchronized 关键字）持有的对象。

可达性分析克服了引用计数的两个缺点，但它有自己的问题：

1.  需要进行类似于 “树遍历”的过程，消耗更多的时间，但可达性分析操作并不需要一直执行，只需要隔一段时间执行一次寻找不可达对象，确定垃圾就可以，所以，慢一下点也是没关系的，虽迟，但到。
2.  可达性分析过程，当前代码中的对象的引用关系发生变化了，还比较麻烦，所以为了准确的完成这个过程，就需要让其他的业务暂停工作（STW问题），但 Java 发展这么多年，垃圾回收机制也在不断的更新优化，STW 这个问题，现在已经能够比较好的应对了，虽不能完全消除，但也已经可以让 STW 的时间尽量短了。

### 2. 垃圾回收算法 ###

垃圾回收的算法最常见的有以下几种：

1.  标记-清除算法
2.  标记-复制算法
3.  标记-整理算法
4.  分代回收算法（本质就是综合上述算法，在堆的不同区采取不同的策略）

#### 2.1 标记-清除算法 ####

标记其实就是可达性分析的过程，在可达性分析的过程中，会标记可达的对象，其不可达的对象，都会被视为垃圾进行回收。

比如经过一轮标记后，标记状态和回收后状态如图：

![img][img 16]  
我们发现，内存是释放了，但是回收后，未分配的内存空间是零散的不是连续的，我们知道申请内存的时候得到的内存得是连续的，虽然内存释放后总的空闲空间很大，但由于未分配的内存是碎片化的，就有可能申请内存失败；假设你的主机有 1GB 空闲内存，但是这些内存是碎片形式存在的，当申请 500MB 内存的时候，也可能会申请失败，毕竟不能保证有一块大于 500MB 的连续内存空间，这也是标记-清除算法的缺陷（内存碎片问题）。

#### 2.2 标记-复制算法 ####

为了解决标记-清除算法所带来的内存碎片化的问题，引入了复制算法。

它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块，每次清理，就将还存活着的对象复制到另外一块上面，然后再把已使用过的这一块内存空间一次清理掉。

复制算法的第一步还是要通过可达性分析进行标记，得到哪一部分需要进行回收，哪一部分需要保留，不能回收。

标记完成后，会将还在使用的内存连续复制到另外一块等大的内存上，这样得到的未分配内存一直都是连续的，而不是碎片化的。

![img][img 17]  
但是，复制算法也有缺陷：

*  空间利用率低。
 *  如果垃圾少，有效对象多，复制成本就比较大。

#### 2.3 标记-整理算法 ####

标记-整理算法针对复制算法做出进一步改进，其中的标记过程仍然与“标记-清除”算法一致，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。

![img][img 18]  
回收时是将存活对象按照某一顺序（比如从左到右，从上到下的顺序）拷贝到非存活对象的内存区域，类似于顺序表的删除操作，会将后面的元素搬运到前面。  
解决了标记-复制算法空间利用率低的问题，也没有内存碎片的问题，但是复制的开销问题并没有得到解决。

#### 2.4 分代回收 ####

上述的回收算法都有一定的缺陷，分代回收就是将上述三种算法结合起来分区使用，分代回收会针对对象进行分类，**以熬过的 GC 扫描轮数作为“年龄”，然后针对不同年龄采取不同的方案**。

分代是基于一个经验规律，如果一个东西存在时间长了，那么接下来大概率也会存在（要没有早就没有了）。

我们知道 GC 主要是回收堆上的无用内存，我们先来了解一下堆的划分，堆包括新生代（Young）、老年代（Old），而新生代包括一个伊甸区（Eden）与两个幸存区（Survivor），分代回收算法就会根据不同的代去采取不同的标记-xx算法。

![img][img 19]  
在新生代，包括一个伊甸区与两个幸存区，伊甸区存储的是未经受 GC 扫描的对象（年龄为 0），也就是刚刚 new 出来的对象。

幸存区存储了经过若干轮 GC 扫描的对象，通过实际经验得出，大部分的 Java 对象具有“朝生夕灭”的特点，生命周期非常短，也就是说只有少部分的伊甸区对象才能熬过第一轮的 GC 扫描到幸存区，所以到幸存区的对象相比于伊甸区少的多，正因为大部分新生代的对象熬不过 GC 第一轮扫描，所以伊甸区与幸存区的分配比例并不是`1:1`的关系，HotSpot 虚拟机默认一个 Eden 和一个 Survivor 的大小比例是 8∶1，正因为新生代的存活率较小，所以**新生代使用的垃圾回收算法为标记-复制算法最优**，毕竟存活率越小，对于标记-复制算法，复制的开销也就很小。

不妨我们将第一个 Survivor 称为活动空间，第二个 Survivor 称为空闲空间，一旦发生 GC，会将 10% 的活动区间与另外 80% 伊甸区中存活的对象复制到 10% 的空闲空间，接下来，将之前 90% 的内存全部释放，以此类推。

在后续几轮 GC 中，**幸存区对象在两个 Survivor 中进行标记-复制算法**，此处由于幸存区体积不大，浪费的空间也是可以接受的。

在继续持续若干轮 GC 后（这个对象已经再两个幸存区中来回考贝很多次了），幸存区的对象就会被转移到老年代，老年代中都是年龄较老的对象，根据经验，一个对象越老，继续存活的可能性就越大（要挂早挂了），因此老年代的 GC 扫描频率远低于新生代，所以老年代采用标记-整理的算法进行内存回收，毕竟老年代存活率高，对于**标记-整理算法**，复制转移的开销很低。

还要注意一个特殊情况，**如果对象非常大，就直接进入老年代**，因为大对象进行复制算法，成本比较高，而且大对象也不会很多。

[img]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/10b46f8a84224ba8a0b510cb5434b306.png
[img 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/81cdcf7b48814076af3781132662dc02.png
[img 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/e4014028ce78443c99a14a447a954334.png
[img 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/614310477b644e8d87009303cc182e7e.png
[img 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/10be01cd5fa843379617a5102cc1cd1d.png
[https_docs.oracle.com_javase_specs_jvms_se8_html_jvms-5.html]: https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html
[img 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/3ad62d093ed84291ada0292d274c8ee1.png
[img 6]: https://img-blog.csdnimg.cn/img_convert/743cfd3f0703426fcaa4afa3a0e1f9df.png
[https_docs.oracle.com_javase_specs_jvms_se8_html_jvms-4.html_jvms-4.1]: https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.1
[img 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/fb07a197972b4d6bb62c7d9454c0acbb.png
[img 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/b87a6b50800d4a3ca00bc8d539e4d987.png
[img 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/07fb1ee913db4e95bcb6ab8fc6377941.png
[img 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/bb146abdc1d64109b77fcefe27537ee9.png
[img 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/8c0a4275175f43a5a6f85942e109ebc6.png
[img 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/ebc80751f130438d8adf39cb2c2d7081.png
[img 13]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/234aeadfcc724dd9bb86a52f6242ef59.png
[img 14]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/6e878c060645421e9bac4ff831f1771c.png
[img 15]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/aa89177b898b41b38dba5d2d7a98c7c1.png
[img 16]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/67f1835dfd61482eb540f05d204c204c.png
[img 17]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/e6840f465646417d8d942085a2238c95.png
[img 18]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/36126263b7d34aa4b41643ab756b114f.png
[img 19]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/26/07404e02be264ef19a6107554c48d3e1.png