java八股文第四章：Java 虚拟机

超、凢脫俗 2023-01-08 02:06 116阅读 0赞

#### 1、Java 内存结构 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70]

*  堆内存  
    由线程共享，存放 new 出来的对象，是垃圾回收器的主要工作区域。
 *  栈内存  
    线程私有，分为 Java 虚拟机栈和本地方法栈，存放局部变量表、操作栈、动态链接、方法出口等信息，方法的执行对应着入栈到出栈的过程。
 *  方法区（元数据区）  
    线程共享，存放已被加载的类信息、常量、静态变量、即时编译器编译后的代码等信息，JDK 1.8 中方法区被元空间取代，使用直接内存。
 *  程序计数器 每个线程都会有自己的一个程序计数器，专门记录当前这个线程目前执行到了哪一条字节码指令了。

> 注意：方法区和堆是所有线程共享的内存区域；而java栈、本地方法栈和程序计数器是运行是线程私有的内存区域。

#### 2、Java 类加载机制 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 1]

*  加载
    
     *  加载字节码文件。
 *  链接
    
     *  验证 验证字节码文件的正确性。
     *  准备 为静态变量分配内存。
     *  解析 将符号引用（如类的全限定名）解析为直接引用（类在实际内存中的地址）。
 *  初始化
    
     *  为静态变量赋初值。

> 双亲委派模式
> 
> 当一个类需要加载时，判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，首先会把该请求委派该父类加载器的  
> loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader  
> 中。当父类加载器无法处理时，才由自己来处理。当父类加载器为 null 时，会使用启动类加载器 BootstrapClassLoader  
> 作为父类加载器。

#### 3、JVM常用内存设置 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 2]

> 注意：jdk1.8后PrmSize替换为MetaSpaceSize

#### 4、JVM垃圾回收机制 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 3]

*  优先在Eden区分配。当Eden区没有足够空间分配时,JVM发起一次Minor GC（Young GC），将Eden区和其中一块Survivor区（from）内尚存活的对象放入另一块Survivor区域（to）。如Minor GC（Young GC）时survivor空间不够，对象提前进入老年代，老年代空间不够时进行Full GC。
 *  大对象直接进入老年代，避免在Eden区和Survivor区之间产生大量的内存复制, 此外大对象容易导致还有不少空闲内存就提前触发GC以获取足够的连续空间。

#### 5、垃圾回收算法 ####

> 引用计数法
> 
> 引用计数法实现简单，效率较高，在大部分情况下是一个不错的算法。其原理是：给对象添加一个引用计数器，每当有一个地方引用该对象时，计数器加1，当引用失效时，计数器减1，当计数器值为0时表示该对象不再被使用。需要注意的是：引用计数法很难解决对象之间相互循环引用的问题，主流Java虚拟机没有选用引用计数法来管理内存。

##### 5.1 标记-清除算法（Mark-Sweep） #####

这是最基础的垃圾回收算法，之所以说它是最基础的是因为它最容易实现，思想也是最简单的。标记-清除算法分为两个阶段：标记阶段和清除阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。具体过程如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 4]

从图中可以很容易看出标记-清除算法实现起来比较容易，但是有一个比较严重的问题就是容易产生内存碎片，碎片太多可能会导致后续过程中需要为大对象分配空间时无法找到足够的空间而提前触发新的一次垃圾收集动作。

**标记-清除算法**采用从 **根集合(GC Roots)** 进行扫描，对存活的对象进行标记，标记完毕后，再扫描整个空间中未被标记的对象，进行回收，如下图所示。标记-清除算法不需要进行对象的移动，只需对不存活的对象进行处理，在存活对象比较多的情况下极为高效，但由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 5]

##### 5.2 复制算法(Copying) #####

为了解决Mark-Sweep算法的缺陷，Copying算法就被提了出来。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。具体过程如下图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 6]  
这种算法虽然实现简单，运行高效且不容易产生内存碎片，但是却对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。

很显然，Copying算法的效率跟存活对象的数目多少有很大的关系，如果存活对象很多，那么Copying算法的效率将会大大降低。

复制算法的提出是为了克服句柄的开销和解决内存碎片的问题。它开始时把堆分成 一个对象 面和多个空闲面， 程序从对象面为对象分配空间，当对象满了，基于copying算法的垃圾 收集就从根集合（GC Roots）中扫描活动对象，并将每个 活动对象复制到空闲面(使得活动对象所占的内存之间没有空闲洞)，这样空闲面变成了对象面，原来的对象面变成了空闲面，程序会在新的对象面中分配内存。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 7]

##### 5.3 标记-整理算法(Mark-compact) #####

为了解决Copying算法的缺陷，充分利用内存空间，提出了Mark-Compact算法。该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动(美团面试题目，记住是完成标记之后，先不清理，先移动再清理回收对象)，然后清理掉端边界以外的内存(美团问过)

标记-整理算法采用标记-清除算法一样的方式进行对象的标记，但在清除时不同，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题。具体流程见下图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 8]

##### 5.4 分代收集算法 Generational Collection（分代收集）算法 #####

分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。

目前大部分垃圾收集器对于新生代都采取Copying算法，因为新生代中每次垃圾回收都要回收大部分对象，也就是说需要复制的操作次数较少，但是实际中并不是按照1：1的比例来划分新生代的空间的，一般来说是将新生代划分为一块较大的Eden空间和两块较小的Survivor空间（一般为8:1:1），每次使用Eden空间和其中的一块Survivor空间，当进行回收时，将Eden和Survivor中还存活的对象复制到另一块Survivor空间中，然后清理掉Eden和刚才使用过的Survivor空间。

而由于老年代的特点是每次回收都只回收少量对象，一般使用的是Mark-Compact算法。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 9]

###### 5.4.1 年轻代（Young Generation）的回收算法 (回收主要以Copying为主) ######

1.  所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。
2.  新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空(美团面试，问的太细，为啥保持survivor1为空，答案：为了让eden和survivor0 交换存活对象)， 如此往复。当Eden没有足够空间的时候就会 触发jvm发起一次Minor GC
3.  当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC(Major GC)，也就是新生代、老年代都进行回收。
4.  新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。

###### 5.4.2 年老代（Old Generation）的回收算法（回收主要以Mark-Compact为主） ######

a) 在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

b) 内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。

###### 5.4.3 持久代（Permanent Generation）(也就是方法区)的回收算法 ######

用于存放静态文件，如Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate 等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代也称方法区,**1.8 称之为数据区。**

#### 6、垃圾回收器 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 10]  
图中展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，则说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代还是老年代收集器。

*  新生代收集器：Serial、ParNew、Parallel Scavenge
 *  老年代收集器：CMS、Serial Old、Parallel Old
 *  整堆收集器： G1

几个相关概念：

*  并行收集：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。
 *  并发收集：指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。用户程序在继续运行，而垃圾收集程序运行在另一个CPU上。
 *  吞吐量：即CPU用于运行用户代码的时间与CPU总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )）。例如：虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%

##### 6.1 Serial 收集器 #####

Serial收集器是最基本的、发展历史最悠久的收集器。

*  特点：单线程、简单高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程手机效率。收集器进行垃圾回收时，必须暂停其他所有的工作线程，直到它结束（Stop The World）。
 *  
 *  应用场景：适用于Client模式下的虚拟机。

Serial/Serial Old收集器运行示意图  
![在这里插入图片描述][20210119144908773.png]

##### 6.2 ParNew收集器 #####

ParNew收集器其实就是Serial收集器的**多线程版本**。

除了使用多线程外其余行为均和Serial收集器一模一样（参数控制、收集算法、Stop The World、对象分配规则、回收策略等）。

*  特点：多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，可以使用`-XX:ParallelGCThreads`参数来`限制垃圾收集的线程数`。和Serial收集器一样存在Stop The World问题
 *  应用场景：ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了Serial收集器外，唯一一个能与CMS收集器配合工作的。

ParNew/Serial Old组合收集器运行示意图如下：  
![在这里插入图片描述][20210119145021868.png]

##### 6.3 Parallel Scavenge 收集器 #####

与吞吐量关系密切，故也称为**吞吐量优先收集器**。

*  特点：属于新生代收集器也是采用复制算法的收集器，又是并行的多线程收集器（与ParNew收集器类似）。

该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：GC自适应调节策略（与ParNew收集器最重要的一个区别）

*  GC自适应调节策略：Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。

Parallel Scavenge收集器使用两个参数控制吞吐量：

*  XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间。
 *  XX:GCRatio 直接设置吞吐量的大小。

##### 6.4 Serial Old 收集器 #####

Serial Old是Serial收集器的老年代版本。

*  特点：同样是单线程收集器，采用标记-整理算法。
 *  应用场景：主要也是使用在Client模式下的虚拟机中。也可在Server模式下使用。

Server模式下主要的两大用途：

1.  在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用。
2.  作为CMS收集器的后备方案，在并发收集Concurent Mode Failure时使用。

Serial / Serial Old收集器工作过程图（Serial收集器图示相同）：

![在这里插入图片描述][20210119145428231.png]

##### 6.5 Parallel Old 收集器 #####

是Parallel Scavenge收集器的老年代版本。

*  特点：多线程，采用标记-整理算法。
 *  应用场景：注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old 收集器。

Parallel Scavenge/Parallel Old收集器工作过程图：

![在这里插入图片描述][2021011914552297.png]

##### 6.6 CMS收集器 #####

一种以获取**最短回收停顿时间**为目标的收集器。

*  特点：基于标记-清除算法实现。并发收集、低停顿。
 *  应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务。

CMS收集器的运行过程分为下列4步：

*  初始标记：标记GC Roots能直接到的对象。速度很快但是仍存在Stop The World问题。
 *  并发标记：进行GC Roots Tracing 的过程，找出存活对象且用户线程可并发执行。
 *  重新标记：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题。
 *  并发清除：对标记的对象进行清除回收。

**CMS收集器的内存回收过程是与用户线程一起并发执行的。**

CMS收集器的工作过程图：  
![在这里插入图片描述][20210119145731338.png]  
CMS收集器的缺点：

*  对CPU资源非常敏感。
 *  无法处理浮动垃圾，可能出现Concurrent Model Failure失败而导致另一次Full GC的产生。
 *  因为采用标记-清除算法所以会存在空间碎片的问题，导致大对象无法分配空间，不得不提前触发一次Full GC。

##### 6.7 G1收集器 #####

一款**面向服务端应用**的垃圾收集器。

*  特点：

**并行与并发**：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿时间。部分收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让Java程序继续运行。

**分代收集**：G1能够独自管理整个Java堆，并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

**空间整合**：G1运作期间不会产生空间碎片，收集后能提供规整的可用内存。

**可预测的停顿**：G1除了追求低停顿外，还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。

*  G1为什么能建立可预测的停顿时间模型？

因为它有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这样就保证了在有限的时间内可以获取尽可能高的收集效率。

*  G1与其他收集器的区别：

其他收集器的工作范围是整个新生代或者老年代、G1收集器的工作范围是整个Java堆。在使用G1收集器时，它将整个Java堆划分为多个大小相等的独立区域（Region）。虽然也保留了新生代、老年代的概念，但新生代和老年代不再是相互隔离的，他们都是一部分Region（不需要连续）的集合。

*  G1收集器存在的问题：

Region不可能是孤立的，分配在Region中的对象可以与Java堆中的任意对象发生引用关系。在采用可达性分析算法来判断对象是否存活时，得扫描整个Java堆才能保证准确性。其他收集器也存在这种问题（G1更加突出而已）。会导致Minor GC效率下降。

*  G1收集器是如何解决上述问题的？

采用`Remembered Set`来避免整堆扫描。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用对象是否处于多个Region中（即检查老年代中是否引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆进行扫描也不会有遗漏。

如果不计算维护 Remembered Set 的操作，G1收集器大致可分为如下步骤：

**初始标记**：仅标记GC Roots能直接到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象。（需要线程停顿，但耗时很短。）

**并发标记**：从GC Roots开始对堆中对象进行可达性分析，找出存活对象。（耗时较长，但可与用户程序并发执行）

**最终标记**：为了修正在并发标记期间因用户程序执行而导致标记产生变化的那一部分标记记录。且对象的变化记录在线程Remembered Set Logs里面，把Remembered Set Logs里面的数据合并到Remembered Set中。（需要线程停顿，但可并行执行。）

**筛选回收**：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。（可并发执行）

G1收集器运行示意图：

![在这里插入图片描述][20210119150132849.png]

#### 7. JVM优化目标 ####

*  调整堆内存的比例，尽量避免或减少FULL GC。
 *  选择合适的垃圾回收器。
 *  增加日志信息，用于应用出问题后还原事故现场。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70]: /images/20221119/221f0281d8894ddeb72bdba998d9321c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 1]: /images/20221119/c779dc25c19c488197036127d39b0917.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 2]: /images/20221119/1e958cfa12fb494499873670fd2ee6b1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 3]: /images/20221119/7b0921018e9b4b938f96638e8108657d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 4]: /images/20221119/aead6e87106d49ad8b083fda13dc594c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 5]: /images/20221119/d7488037f96445668a317f15ef9ff25e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 6]: /images/20221119/8f6aec24cf5849cb8d2c5721d211bee5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 7]: /images/20221119/b22131dd49364c47854aa8beaf0cd069.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 8]: /images/20221119/a1bc8fb96668412d878dea0357f90e35.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 9]: /images/20221119/35577360f3aa43918d3cd73565a2823b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAwNDY5MDg_size_16_color_FFFFFF_t_70 10]: /images/20221119/611cffd3f3b8420b8a674bd87f0cb469.png
[20210119144908773.png]: /images/20221119/598ab518a90c41e3ba88f6705f4d442e.png
[20210119145021868.png]: /images/20221119/51b131ec4cca437c95df737d35bd9a61.png
[20210119145428231.png]: /images/20221119/1ee5edd6fda6443fa2f4a627df3c453e.png
[2021011914552297.png]: /images/20221119/1c11fb6afed046baa404bf4d37dae25b.png
[20210119145731338.png]: /images/20221119/a225657f39a046a8b4bf1bd345b9bf09.png
[20210119150132849.png]: /images/20221119/7e2d4053604448eda5f7f81bc2e41347.png