JVM中 Java 语法糖及实现原理（二十二）

本是古典何须时尚 2022-12-11 02:28 144阅读 0赞

今天分析 Java 语法糖及实现原理：

**一、Java**  **中的泛型**

**1、泛型是什么**

泛型，即“参数化类型”，最熟悉的就是定义方法时有形参，然后调用此方法时传递实参。 引入一个类型变量 T （其他大写字母都可以，不过常用的就是  T ， E ， K ， V  等等），并且用 <> 括起来，并放在类名的后面。泛型类 是允许有多个类型变量的。 按照约定，类型参数名称命名为单个大写字母，以便可以在使用普通类或接口名称时能够容易地区分类型参数。以下是常用的类

型参数名称列表：

E -  元素，主要由  Java  集合 (Collections) 框架使用。

K -  键，主要用于表示映射中的键的参数类型。

V -  值，主要用于表示映射中的值的参数类型。

N -  数字，主要用于表示数字。

T -  类型，主要用于表示第一类通用型参数。

S -  类型，主要用于表示第二类通用类型参数。

U -  类型，主要用于表示第三类通用类型参数。

V -  类型，主要用于表示第四个通用类型参数。

**泛型类和泛型接口**

可以为任何类、接口增加泛型声明

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

泛型接口与泛型类的定义基本相同。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

**3、泛型类和接口的使用**

而实现泛型接口的类，有两种实现方法：

1）未传入泛型实参时：

![20200928191859810.png][]

在  new  出类的实例时，需要指定具体类型：

![20200928191915283.png][]

2） 、传入泛型实参

![20200928191956525.png][]

在  new  出类的实例时，和普通的类没区别。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

泛型方法，是在调用方法的时候指明泛型的具体类型 ，泛型方法可以在任何地方和任何场景中使用，包括普通类和泛型类。

**4、为什么我们需要泛型？**

通过两段代码我们就可以知道为何我们需要泛型

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3][]

![20200928192036863.png][]

实际开发中，经常有数值类型求和的需求，例如实现  int  类型的加法 , 有时候还需要实现  long  类型的求和 , 如果还需要  double  类型

的求和，需要重新在重载一个输入是  double  类型的  add  方法。所以泛型的好处就是：  适用于多种数据类型执行相同的代码 ；泛型中的类型在使用时指定，不需要强制类型转换

**二、虚拟机是如何实现泛型的？**

**1、泛型擦除**

Java  语言中的泛型，它只在程序源码中存在，在编译后的字节码文件中，就已经替换为原来的原生类型（ Raw Type ，也称为裸类 型）了，并且在相应的地方插入了强制转型代码，因此，对于运行期的 Java  语言来说， ArrayList ＜ int ＞与  ArrayList ＜ String ＞就是同一 个类，所以泛型技术实际上是 Java  语言的一颗语法糖， Java  语言中的泛型实现方法称为类型擦除，基于这种方法实现的泛型称为伪泛 型。将一段 Java  代码编译成  Class  文件，然后再用字节码反编译工具进行反编译后，将会发现泛型都不见了，程序又变回了  Java  泛型 出现之前的写法，泛型类型都变回了原生类型（因为）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5][]

**使用泛型注意事项（小甜点，了解即可** **）**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6][]

上面这段代码是不能被编译的，因为参数  List ＜ Integer ＞和  List ＜ String ＞编译之后都被擦除了，变成了一样的原生类型  List ＜ E ＞，擦除动作导致这两种方法的特征签名变得一模一样（注意在 IDEA 中是不行的，但是 jdk 的编译器是可以，因为 jdk 是根据方法返回值+ 方法名+ 参数）。

**2、弱记忆**

JVM  版本兼容性问题： JDK1.5  以前，为了确保泛型的兼容性， JVM  除了擦除，其实还是保留了泛型信息 (Signature  是其中最重要的 一项属性，它的作用就是存储一个方法在字节码层面的特征签名，这个属性中保存的参数类型并不是原生类型，而是包括了参数化类 型的信息)---- 弱记忆 另外，从 Signature  属性的出现我们还可以得出结论，擦除法所谓的擦除，仅仅是对方法的  Code  属性中的字节码进行擦除，实际 上元数据中还是保留了泛型信息，这也是我们能通过反射手段取得参数化类型的根本依据。

**三、Stream**

**1、什么是**  **Stream** **？**

Java8  中， Collection  新增了两个流方法，分别是  Stream()  和  parallelStream() ，Java8 中添加了一个新的接口类  Stream ，相当于高级版的  Iterator ，它可以通过  Lambda  表达式对集合进行 **大批量** 数据操作，或 者各种非常便利、高效的**聚合** 数据操作。

**2、为什么要使用**  **Stream** **？**

在  Java8  之前，我们通常是通过  for  循环或者  Iterator  迭代来重新排序合并数据，又或者通过重新定义  Collections.sorts  的

Comparator  方法来实现，这两种方式对于 **大数据量系统** 来说，效率并不是很理想。

Stream 的聚合操作与数据库  SQL  的聚合操作  sorted 、 filter 、 map  等类似。我们在应用层就可以高效地实现类似数据库  SQL  的

聚合操作了，而在数据操作方面， Stream  不仅可以通过串行的方式实现数据操作，还可以通过并行的方式处理大批量数据， 提高数据  的处理效率 。

**3、Stream**  **使用入门**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7][]

可以看到，如果实现同样的功能，那么使用循环的方式，代码行数将达到  6  行。

![20200928192228811.png][]

**4、Stream**  **操作分类**

官方将  Stream  中的操作分为两大类：终结操作（ Terminal operations ）和中间操作（ Intermediate operations ）。

**1）中间操作** 会返回一个新的流，一个流可以后面跟随 **零个或多个中间操作** 。其目的主要是打开流，做出某种程度的数据映射 / 过滤， 然后会返回一个新的流，交给下一个操作使用。**这类操作都是惰性化的（** **lazy** **）** ，就是说，仅仅调用到这类方法，并没有真正开始流的 遍历。而是在终结操作开始的时候才真正开始执行。  **中间操作** 又可以分为 **无状态** （ Stateless ）与 **有状态** （ Stateful ）操作，无状态是指元素的处理不受之前元素的影响，有状态是指该 操作只有拿到所有元素之后才能继续下去。

**2）终结操作** 是指返回最终的结果。一个流只能有一个终结操作，当这个操作执行后，这个流就被使用 “ 光 ” 了，无法再被操作。所以 这必定这个流的最后一个操作。**终结操作** 的执行才会真正开始流的遍历，并且会生成一个结果。  **终结操作** 又可以分为 **短路** （ Short-circuiting ）与 **非短路** （ Unshort-circuiting ）操作，  **短路** 是指遇到某些符合条件的元素就可以得到最终结果，

**非短路** 是指必须处理完所有元素才能得到最终结果。操作分类详情如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 8][]

**演示案例**

见代码 StuWithStream

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 9][]

因为  Stream  操作类型非常多，总结一下常用的

map(): 将流中的元素进行再次加工形成一个新流，流中的每一个元素映射为另外的元素。

filter():  返回结果生成新的流中只包含满足筛选条件的数据

limit() ：返回指定数量的元素的流。返回的是  Stream  里前面的  n  个元素。

skip() ：和  limit() 相反，将前几个元素跳过（取出）再返回一个流，如果流中的元素小于或者等于  n ，就会返回一个空的流。

sorted() ：将流中的元素按照自然排序方式进行排序。

distinct()：将流中的元素去重之后输出。

peek() ：对流中每个元素执行操作，并返回一个新的流，返回的流还是包含原来流中的元素。

**四、Stream**  **的底层实现**

**1、Stream**  **操作叠加**

一个  Stream  的各个操作是由处理管道组装，并统一完成数据处理的。 我们知道 Stream  有中间操作和终结操作，那么对于一个写好的  Stream  处理代码来说，中间操作是通过  AbstractPipeline  生成了一个中间操作  Sink  链表 当我们调用终结操作时，会生成一个最终的 ReducingSink ，通过这个  ReducingSink  触发之前的中间操作，从最后一个  ReducingSink  开始，递归产生一个  Sink

链。如下图所示：

![20200928192321641.png][]

**2、Stream**  **源码实现（不重要）**

**stream**  **方法**

因为  names  是  ArrayList  集合，所以  names.stream()  方法将会调用集合类基础接口  Collection  的  Stream  方法

![20200928192334923.png][]

然后， Stream  方法就会调用  StreamSupport  类的  Stream  方法，

![2020092819235138.png][]

Stream 方法中初始化了一个 ReferencePipeline 的 Head 内部类对象：

![20200928192408448.png][]

**filter**  **方法**

再调用  filter ，这个方法都是无状态的中间操作，所以执行  filter  时，并没有进行任何的操作，而是分别创建了一个  Stage  来标识用

户的每一次操作。

而通常情况下  Stream  的操作又需要一个回调函数，所以一个完整的  Stage  是由数据来源、操作、回调函数组成的三元组来表示。

如下图所示，分别是  ReferencePipeline  的  filter  方法和  map  方法：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 10][]

**max**  **方法**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 11][]

![20200928192445427.png][]

![20200928192451147.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 12][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 13][]

![20200928192512583.png][]

当  Sink  链表生成完成后， Stream  开始执行，通过  spliterator  迭代集合，执行  Sink  链表中的具体操作。 java8 中的  Spliterator  的  forEachRemaining  会迭代集合，每迭代一次，都会执行一次  filter  操作，如果  filter  操作通过，就会触发  map 操作，然后将结果放入到临时数组 object  中，再进行下一次的迭代。完成中间操作后，就会触发终结操作  max 。

![20200928192527407.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 14][]

![20200928192539711.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 15][]

**Stream**  **并发**  **Stream**  **源码实现（不重要）**

并发的处理函数对比 parallelStream()方法

![20200928192609246.png][]

![20200928192616623.png][]

这里的并行处理指的是， **Stream**  **结合了**  **ForkJoin**  **框架** ，对  Stream  处理进行了分片， Splititerator  中的  estimateSize  方法会估算出分 片的数据量。 通过预估的数据量获取最小处理单元的阈值，如果当前分片大小大于最小处理单元的阈值，就继续切分集合。每个分片将会生成一个 Sink 链表，当所有的分片操作完成后， ForkJoin  框架将会合并分片任何结果集。

**3、Stream**  **的性能**

**常规数据迭代 ，** **100**  **的性能对比**

![20200928193445426.png][]

![20200928193453302.png][]

**常规的迭代**  **> Stream**  **并行迭代** **> Stream**  **串行迭代**

**为什么这样：**

1 、常规迭代代码简单，越简单的代码执行效率越高。

2 、 Stream  串行迭代，使用了复杂的设计，导致执行速度偏低。所以是性能最低的。

3 、 Stream  并行迭代 使用了  Fork-Join  线程池 , 所以效率比  Stream  串行迭代快，但是对比常规迭代还是要慢（毕竟设计和代码复杂）

**大数据迭代**

**一亿的数组性能对比（默认线程池）**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 16][]

![20200928193520628.png][]

**为什么这样：**

**1** **、** Stream  并行迭代 使用了  Fork-Join  线程池 ,  而线程池线程数为  cpu  的核心数（我的电脑为  12  核），大数据场景下，能够利用多线 程机制，所以效率比 Stream  串行迭代快，同时多线程机制切换带来的开销相对来说还不算多，所以对比常规迭代还是要快（虽然设计 和代码复杂）

2 、常规迭代代码简单，越简单的代码执行效率越高。

3 、 Stream  串行迭代，使用了复杂的设计，导致执行速度偏低。所以是性能最低的。

**一亿的数组性能对比（线程池数量** **=2** **）**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 17][]

![20200928193540594.png][]

**为什么这样：**

Stream  并行迭代 使用了  Fork-Join  线程池 , 大数据场景下，虽然利用多线程机制，但是线程池线程数为  2 ，所以多个请求争抢着执行任 务，想象对请求来说任务是被交替执行完成，所以对比常规迭代还是要慢（虽然用到了多线程技术）

**一亿的数组性能对比（线程池数量** **=240** **）**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 18][]

![20200928193606173.png][]

**为什么这样：**

Stream  并行迭代 使用了  Fork-Join  线程池 ,  而线程池线程数为  240 ，大数据场景下，虽然利用多线程机制，但是线程太多，线程的上下 文切换成本过高，所以导致了执行效率反而没有常规迭代快。

**如何合理使用**  **Stream** **？**

我们可以看到：在循环迭代次数较少的情况下，常规的迭代方式性能反而更好；而在大数据循环迭代中，  parallelStream （合理的线程 池数上）有一定的优势。 但是由于所有使用并行流 parallelStream  的地方都是使用同一个  Fork-Join  线程池，而线程池线程数仅为  cpu  的核心数。 切记，如果对底层不太熟悉的话请不要乱用并行流 parallerStream （尤其是你的服务器核心数比较少的情况下）

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221123/653e162b7dd142e3b3d03ab31c609a4c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221123/af6d476f571f4b0983b770f753acbcdf.png
[20200928191859810.png]: /images/20221123/da21a454ccbe469385a1f653881093d7.png
[20200928191915283.png]: /images/20221123/a19b3341243d40efb1b9df0b6644c6cf.png
[20200928191956525.png]: /images/20221123/c3ef083c2f0b4936adfea45546403a4b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221123/f11c5fe2fc2b47978fd2c0eddcd9f441.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3]: /images/20221123/7785baf2efb74d558ae52461d9379808.png
[20200928192036863.png]: /images/20221123/84f7e47048de4b259ba4368bee056b98.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4]: /images/20221123/23e208ce4b164345b0942457d0b22a1d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5]: /images/20221123/437172175db44f3da18c5f61d5a67a52.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6]: /images/20221123/e1a13c9977a64154a909045cddbb1a58.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7]: /images/20221123/764b304ac5f146d1af1f34644fade934.png
[20200928192228811.png]: /images/20221123/94f62f31edda4c7fb4389a26655b1c46.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 8]: /images/20221123/151547a985c743bab78cc157cb827392.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 9]: /images/20221123/2f6ca6480f02412bbc67f6981c6da9cf.png
[20200928192321641.png]: /images/20221123/2111d84bf2644d14b1c493b4598d20a7.png
[20200928192334923.png]: /images/20221123/60b108e2cc604c1eb7b820dc408aaf4b.png
[2020092819235138.png]: /images/20221123/cd5f87483b3f49d89a76a6126ebc3cc2.png
[20200928192408448.png]: /images/20221123/bc416c928e9041ffa1378bcee593e114.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 10]: /images/20221123/6dcf80a0e3884dd4bd5a7853f5b1dfb3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 11]: /images/20221123/d682e65fd2c048f2a39d7659520b006d.png
[20200928192445427.png]: /images/20221123/926862552ac049fda427eeb44ff16276.png
[20200928192451147.png]: /images/20221123/8c4a4bc9ce5f492eaf022f97f2d83e2d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 12]: /images/20221123/b2c0fa48ab0541b2ba6fb16777896074.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 13]: /images/20221123/b47a11b7ad5442d793b5291d23ccc950.png
[20200928192512583.png]: /images/20221123/f74dbee630eb44b59996b219ea9ec190.png
[20200928192527407.png]: /images/20221123/940aad6f303e4f31a7322a2ee399aecd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 14]: /images/20221123/685ff0df57564ff6bf16da735e02f2cd.png
[20200928192539711.png]: /images/20221123/ef8a049e0c234eb3b5dac733830072f4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 15]: /images/20221123/2b4a22b327054a998be83fad163b144a.png
[20200928192609246.png]: /images/20221123/2870640672aa4b9891106bdace3ac259.png
[20200928192616623.png]: /images/20221123/c1927b22d264448bba76707e4aa6166c.png
[20200928193445426.png]: /images/20221123/2708432e1e224206adb95390994a0193.png
[20200928193453302.png]: /images/20221123/b589e532064e4f7bb8d8ed8471fe6535.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 16]: /images/20221123/68e68bdc809546c4a856fa77ce4fff24.png
[20200928193520628.png]: /images/20221123/22962328daaa4d6883cc3a9b27cc5a7c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 17]: /images/20221123/139b6ddda32c4246b83618f9dee4c0c5.png
[20200928193540594.png]: /images/20221123/74fb70b641cd4236a447f068b364ff37.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 18]: /images/20221123/75838f2c236d495cab9d0cacdd9f9731.png
[20200928193606173.png]: /images/20221123/f2029b5c945444b3a965429a2877def0.png