小码哥《恋上数据结构与算法》笔记（十五）：哈希表（Hash Table）

深碍√TFBOYSˉ_ 2022-12-27 14:10 44阅读 0赞

# 目录 #

*  一、哈希表（Hash Table）
    
     *  0、TreeMap分析
     *  1、概念
     *  2、哈希冲突
     *  3、JDK1.8的哈希冲突解决方案
     *  4、哈希函数
     *  5、如何生成hash\_code(key)
        
         *  5.1、整数的哈希值
         *  5.2、浮点数的哈希值
         *  5.2、Long和Double的哈希值
         *  5.3、字符串的哈希值
         *  5.4、`自定义对象的哈希值 (重点)`
     *  6、`hashCode和equals方法 (重点)`

--------------------

# 一、哈希表（Hash Table） #

## 0、TreeMap分析 ##

*  使用 **`红黑树`** 实现的`TreeMap`: **添加，删除，搜索的时间复杂度是`O(logn)`**
 *  特点
    
     *  `key`必须具备`可比较性`。
     *  元素的分布是有顺序的（key大的在右边，小的在左边）。
 *  在实际应用中：
    
     *  **map中的存储的元素不需要讲究顺序。**
     *  **map中的key一般不需要具备可比较性。**
 *  不考虑`顺序`和`key`的可比较性，map有`更优`的实现方案，`平均时间复杂度可达到O(1)`，**那就是采取`哈希表`来实现`map`。**

## 1、概念 ##

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

*  哈希表也叫做`散列表`。
 *  哈希表的**原理**：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 1]
 *  利用`哈希函数`生成`key`对应的`索引`，时间复杂度`O(1)`。
 *  根据`index(索引)`操作定位`数组元素`，时间复杂度`O(1)`。
 *  **哈希表的`空间换时间`的典型应用。**
 *  **哈希表内部的`数组元素`, 上图的`数据`，很多地方也叫 `Bucket（桶）`，整个数组叫 Buckets 或者 Bucket Array**

## 2、哈希冲突 ##

*  哈希冲突也叫做`哈希碰撞`。
 *  2个不同的key，经过`哈希函数`计算出`哈希值相同`, 就发生了`哈希冲突`。(因为哈希值相同, 与数组长度-1 作 & 运算 得到的哈希表的索引 一定是一样的)
    
     *  key1 != key2，hash(key1) = hash(key2)
 *  解决**哈希冲突**的常见方法
    
     *  按照一定规则（线性探测，平方探测）向**其他地址探测，直到遇到空桶**。`（开放定址法）`  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 2]
     *  设计多个哈希函数。`（再哈希法）`
     *  通过`链表`将**相同索引的元素串起来**。`（链地址法/拉链法）`
    
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 3]

## 3、JDK1.8的哈希冲突解决方案 ##

*  使用的是`链地址法`  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 4]
 *  默认使用`单向链表`将`元素串起来`。
 *  **当单向链表的`节点数量`大于`8`时，将转为`红黑树`来存储元素。在调整容量时，如果`树节点数量小于8`，又会转为`单向链表`。**
 *  为什么不使用双向链表，而是单向链表？(发生哈希冲突的前提下)
    
     *  每次`查找`都要从`单向链表头节点`开始遍历，首先确认链表中是否已有该元素`(equals)`, 若没有则`插入链表尾部`。
     *  **单向链表比双向链表少一个指针，可以`节省内存空间`。**

## 4、哈希函数 ##

*  哈希表中哈希函数的实现步骤：  
    1、 生成`key`的`哈希值`（`必须是整数`）。  
    2、 **再让`key的哈希值`跟`数组的大小/长度`进行相关`运算`，生成一个索引值 (哈希表中的位置)。**  
    ![在这里插入图片描述][20201211221835330.png]
 *  为了`提高效率`，可以使用`&`运算取代`%`运算 **（前提将`数组的长度`设计为`2^n`）**。

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

& 运算 :
    	哈希值 :	  1001010
    	数组长度-1:  & 1101101
    	      		----------
    	        	  1001000
    	    
    数组长度设计为 2^n :
    	二进制:		十进制:
    	00000001 	   2^0
    	00000010       2^1
    	00000100       2^2
    	00001000       2^3
    	00010000       2^4
    
    	01				2^1-1
    	011				2^2-1
    	0111			2^3-1
    	01111			2^4-1
    	011111			2^5-1
    
    由上可见: 
    	2^n - 1对应的二进制全部都是1, 也就是说, 当通过hash(key)计算出来的哈希值, 和全都是1的二进制数做 & 运算,结果就还是hash(key)的值
    	
    		1001010
    	  & 1111111
    	  ----------
    	    1001010
    上面的运算还有一个规律, 也就是说, 无论哈希值是多少, 和(1111111) &运算的结果, 都不会大于(1111111), 也就是说它的范围就是 0000000 ~ 1111111 (2^n - 1)的范围

*  通过上面分析, `hash_code(key) & (table.length - 1)` 的范围就是`0 ~ table.length -1`, 这正好是`数组`的`索引`.

>  *  **因为数组长度为为2^n**，转换为二进制是10000或100之类的值，table.length - 1的结果转换成二进制即为01111或011之类的值。
>  *  将hash\_code(key)和01111做与运算，比如10100&00111，结果为00101，值肯定小于00111，且最小为00000，最大为00111。
>  *  结论就是无论hash\_code(key)有多大，当它与上table.length - 1，**它的值都是在0到table.length - 1之间**。

*  **`良好的哈希函数`是让`哈希值`更加`均匀的分布`**，**减少哈希冲突次数，提升哈希表的性能。**

## 5、如何生成hash\_code(key) ##

hash值int整数的原因: 因为哈希表底层就是一个数组, 我们需要获取一个整形的哈希值, 通过&数组的长度, 计算出索引位置。

*  key的常见种类可能是有`整数`，`浮点数`，`字符串`，`自定义对象`。
 *  不同种类的key，哈希值的生成方式不一样，但目标是一致的(都是`整形数据`)：
    
     *  尽量让`每个key`的`哈希值`是`唯一`的。
     *  尽量让`key的所有信息参与运算`。

#### 5.1、整数的哈希值 ####

*  `整数`的`哈希值`则直接为它的值，比如`10的哈希值`就是`10`。
    
        // 计算整形的哈希值
        public static int hashCode(int value) { 
           return value;
        }

#### 5.2、浮点数的哈希值 ####

*  `浮点数`的`哈希值`是将存储的浮点数的`二进制格式`的值转为`十进制的整数值`。
 *  比如10.6在内存中是100001010010101，那么将100001010010101转为整数即为1093245338, 该值就是10.6的哈希值。
    
        // 计算浮点数的哈希值
        public static int hashCode(float value) { 
           return floatToIntBits(value);
        }

#### 5.2、Long和Double的哈希值 ####

*  Java中的`hash值`必须是`int类型`，即是`32位`。
 *  `Long`和`Double`都是`64位`，可以将`value`的`高32位`和`低32位`混合计算出32位的值，(因为尽量key的所有信息都要参与运算), 然后再用`value的值`与这个`32位值`做`异或运算`（相同为0，不同为1）。
 *  `异或运算`之后再将`64位`的结果**强制转换为32位**。
    
        public static int hashCode(long value) { 
            return (int)(value ^ (value >>> 32));
        }
        
        public static int hashCode(double value) { 
        	long bits = doubleToLongBits(value);
        	return (int)(bits ^ (bits >>> 32));
        }

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

*  最终获取的值是`橙色`部分。
 *  这样即**充分利用所有信息**计算出了**哈希值**。

#### 5.3、字符串的哈希值 ####

*  整数 `5489` 是如何计算出来的？
    
     *  **5∗10^3 + 4∗10^2 + 8∗10^1 + 9∗10^0**
 *  字符串是由若干个字符组成的
    
     *  比如字符串`jack`，由 j、a、c、k 四个字符组成（`字符`的本质就是一个整数`(ascll码)`）
     *  因此，**jack 的哈希值**可以表示为 `j ∗ n^3 + a ∗ n^2 + c ∗ n^1 + k ∗ n^0`，等价于`[ ( j ∗ n + a ) ∗ n + c ] ∗ n + k`
     *  在JDK中，乘数 n 为 `31`，为什么使用 31？ 因为通过`观测分布`, **`31`是一个`奇素数`**
     *  `JVM会将 31 * i 优化成 (i << 5) – i`

@Test
    public void test() { 
        String str = "jack";
        int length = str.length();
        int hashCode = 0;
        for (int i = 0; i < length; i++) { 
            char c = str.charAt(i);
            hashCode = hashCode * 31 + c;
        }
        // hashCode = ((j * 31 + a) * 31 + c) * 31 + k
        System.out.println(hashCode);   // 3254239
    
        // Java官方String的hashCode
        int hashCode2 = str.hashCode();
        System.out.println(hashCode2);  // 3254239
    }
    
    // --------------JDK中String的hashCode方法--------------
    
    private final char value[];
    private int hash; // Default to 0
    
    public int hashCode() { 
        int h = hash;
        if (h == 0 && value.length > 0) { 
            char val[] = value;
    
            for (int i = 0; i < value.length; i++) { 
                h = 31 * h + val[i];
            }
            hash = h;
        }
        return h;
    }

#### 5.4、自定义对象的哈希值(`很重要`) ####

*  **默认情况下，`自定义对象的哈希值`是跟`内存地址`有关系的。**
    
     *  所以两个对象即使各个属性值都相同，但他们的`哈希值是不同的`，如果用一个Map保存这两个对象，Map内会有两个对象。

为什么要重写hashcode方法?

*  如何能让Map中只保存相同对象中的一个呢？这就需要我们`重写hashCode方法`。

public class Person { 
        private int age;
        private float height;
        private String name;
    
        public Person(int age, float height, String name) { 
            this.age = age;
            this.height = height;
            this.name = name;
        }
    }

*  **`重点:`** 当我们自定义类没有重写`hashCode`方法时, 当Person没有重写hashCode()方法. 它们的哈希值是根据`内存地址`算的.它们**哈希值肯定是不同**的, 当`它们的哈希值 & 数组长度 -1`, 生成在`哈希表`中的`索引`可能是不同的.
    
     *  (`注意:`哈希值不同, 进行 & 运算后, 可能在哈希表中的索引是相同的)

@Test
    public void test2() { 
        Person p1 = new Person(10, 1.67f, "jack");
        Person p2 = new Person(10, 1.67f, "jack");
        // 当Person没有重写hashCode()方法. 它们的哈希值是根据内存地址算的
        System.out.println(p1.hashCode());
        System.out.println(p2.hashCode());
    
        Map<Object, Object> map = new HashMap<>();
        // 这里我们没有重写Person的hashCode方法, p1, p2的hashCode是根据内存地址生成的, 他们的哈希值肯定是不同的.
        // 所以, p1,p2的哈希值不一样, 它们 & 数组长度-1, 生成的在哈希表中的索引可能也是不同的.(也可能相同)
        map.put(p1, "abc");
        map.put(p2, "bcd");
    }

> 现在的需求:
> 
>  *  **需求:** 当Person的age,height,name都相同的时候, 就认定p1,p2是同一个`key`, 进行hash(p1), hash(p2)生成的`hash值`就是`相同`的, **所以它们在哈希表中的索引位置也是相同的**. 此时他们就出现了哈希冲突, 将p2的"bcd"覆盖掉p1的"abc"
> 
>  *  **解决:** 想要解决"当Person的age,height,name都相同的时候, 就认定p1,p2是同一个key", 我们就要在Person类中`重写hashCode方法`,然后在该方法中对Person的属性进行充分利用. 通过"计算字符串的方式计算 hashCode = ((j \* 31 + a) \* 31 + c) \* 31 + k"

// 这样只要Person对象的age,height,name相同, 它们的hashCode值必然相同
    @Override
    public int hashCode() { 
        int hash = Integer.hashCode(age);
        hash = hash * 31 + Float.hashCode(height);
        hash = hash * 31 + (name != null ? name.hashCode() : 0);
        return hash;
    }

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

*  重写的`hashCode`方法，我们将**对象所有属性都计算进来**，这样即充分利用所有信息计算出了`哈希值`。
 *  `注意:`
    
     *  两个对象的哈希值相同，它们不一定相等 (因为hash(“str”)和hash(new Person())计算出来的哈希值是相同的, 显然 str 和 person对象是不等的)，
     *  只能说两个对象通过hashCode算出的哈希值相同。它们在哈希表中的索引是相同的。 (哈希值不一样, 可能在哈希表中的索引位置是一样的(**因为哈希值还要对数组长度-1进行 & 运算**)。

### 重写equals方法 ###

*  当一个对象`没有重写equals方法`, 默认调用`equals`和`==`比较的是`内存地址`。

**作用**

*  当发生`哈希冲突`的时候, 比较链表中`两个key`是否相等, 相同则使用`value`去覆盖, 不同则`插入到链表尾部`(尾插法)。
 *  当`哈希冲突`的时候，使用`链地址法`将每一个`(key, value)`链起来形成一个`链表`, 我们会调用`对象`的`equals方法`进行`对象(map中的key)间的比较`, (HashMap的键值对,比较的是`key`)。如果`两个对象相同`，则`覆盖value`，如果不同，则加入到`链表尾部`。所以要`重写equals方法`。

// Person对象的age,height,name相同, 就认为他们是同一个对象(放到hashMap里面同一个key)
    @Override
    public boolean equals(Object obj) { 
        // 传进来的obj 和 调用当前方法的对象 内存地址相同
        if (this == obj) return true;
        // 当前对象肯定不为空, 因为要调用equals方法, 若obj为null, obj和当前对象类型不同, 直接false
        if (obj == null || obj.getClass() != this.getClass()) return false;
        // 能到这里, 说明obj和this同一类型,且obj也不为空: 此时比较成员变量, 若他们的成员变量都是相同的, 返回true
        Person person = (Person) obj;
        return person.age == age
                && person.height == height
                && (person.name == null ? name == null : person.name.equals(name));
    }

## 6、hashCode和equals方法 (`很重要`) ##

#### 6.1、同时实现hashCode和equals方法 ####

*  **假设** 我们创建`三个对象`存入map中，并且`p1`和`test`的`哈希值`相同：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 6]
 *  当存入`p1`和`test`时，map中的结构如下：(为什么test的ccc没有覆盖p1的abc呢,因为重写了equals方法, `test`对象会调用equals和p1作比较, 进入equals方法, 类型(getClass())都不一样, 肯定不同)  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 7]
 *  当存入`p2`时，因为我们重写了`hashCode`方法, 说明`p1,p2的哈希值是一样的, 所以他们在哈希表中的索引位置肯定一样`,会调用`equals`方法比较`p1`和`p2`，因为重写了`equals方法`，所以会返回`true`，在map中，当确认两个对象相等时，则会执行替换  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 8]

#### 6.1、不实现hashCode和equals方法 ####

*  自定义的对象都没有实现hashCode和equals方法的情况

Person p1 = new Person(10, 1.67f, "jack");
    Person p2 = new Person(10, 1.67f, "jack");
    
    Map<Object, Object> map = new HashMap<>();
    map.put(p1, "abc");
    map.put("test", "ccc");
    map.put(p2, "bcd");
    System.out.println(map.size());

*  因为没有重写`hashCode`方法, 说明p1, p2的哈希值是根据内存地址来的, 他们的哈希值不同; 但是哈希值不同, 不代表他们的哈希值和(数组长度-1)做完&运算后, 他们在哈希表中的索引不同. 有两种可能: `哈希值不同, 哈希表中的索引位置不相同; 哈希值不同, 哈希值中的索引位置相同。`
    
     *  假如哈希值不同, 生成的`索引位置不相同`的情况:
        
         *  p1, p2, test在哈希表中的不同索引位置, 所以map.size() 为 3  
            ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 9]
     *  假如哈希值不同, 生成的`索引位置相同`的情况:
        
         *  这种情况则说明p1,p2,p3发生了哈希冲突, **首先p1先添加完, 添加test,首先会判断test.equals(p1), 类型不同, 肯定不相等; test被链到p1的下面, 添加p2, 首先会判断p2.equals(p1), 因为没有重写`equals`方法, 所以默认比较的`内存地址`, 所以equals为false; 再判断p2.equals(test), 类型不同, 所以p2会被链接到test的下面**  
            ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 10]

#### 6.2、只实现equals方法 ####

*  因为没有重写`hashCode`方法, 说明p1, p2的哈希值是根据内存地址来的, 他们的哈希值不同;  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 11]
 *  假如`哈希值`不同, 生成的`p1, p2索引位置相同`的情况:
    
     *  此时p1, p2在哈希表中的索引是相同的, 添加p1直接就添加进去了, 当添加p2的时候, p2.equals(p1), 因为`重写了equals方法`, 此时p2就会覆盖掉p1的值. 所以此时只存储了两个`key-value`, map.size() 为 2  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 12]

#### 6.3、只实现hashCode方法 ####

*  因为重写了hashCode方法,p1,p2哈希值肯定相同, 所以p1,p2在哈希表中的索引位置肯定相同. 因为没有重写`equals方法`, 所以他们调用equals比较的是内存地址, 所以不会p2不会覆盖掉p1的内容。
 *  (test虽然哈希值不同,也可能和p1,p2在同一哈希表索引位置, 这里就当他们没在同一个索引位置)  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 13]

**`注意`** : 所以`equals方法`和`hashCode方法` 它们要同时重写。

*  自定义对象作为key, 最好同时重写`hashCode`和`equals`方法
 *  equals : 用以判断2个key是否为同一个key
 *  hashCode : 必须保证equals为`true`的2个key的哈希值一样
 *  hashCode相等的key, 只能说明它们的哈希值相同, 它们的equals也不一定相等
    
     *  首先hashCode相同, 表示它们在哈希表中的`索引`是肯定相同的, 但这并不代表它们就是相同(equals)对象, 因为此时造成哈希冲突.使用`拉链法`来解决冲突. 这条链上的对象, 他们的哈希值可能相同也可能不相同, 因为(还需要 & 数组.length -1的运算). `因为不同对象计算出来的哈希值可能是相同的, 看下面代码即可!`
    
        @Test
        public void test5() { 
            String str1 = "NB";
            String str2 = "Ma";
            boolean b = str1.hashCode() == str2.hashCode();
            boolean c = str1.equals(str2);
        
            System.out.println("b = " + b); // true
            System.out.println("c = " + c); // false
        }

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70]: /images/20221120/80e2dac0c81f42febddf33a2ec237703.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 1]: /images/20221120/f396cab8fdd3490b899a32ba7ecedec1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 2]: /images/20221120/d3ef23e0c50a4b9ca58bc6bc45fc7912.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 3]: /images/20221120/2521e9bb58494645b154b56b98bae647.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 4]: /images/20221120/5f74dbb1162946fdbe6cb5e9d7be732a.png
[20201211221835330.png]: /images/20221120/322589ff991d4b3d8829a746748f323b.png
[20201211223110357.png]: /images/20221120/9e8dccd37c3a497383cebc706de9d558.png
[2020121123064921.png]: /images/20221120/9a9c775d3beb4ad6b97f96e5d1488cd6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 5]: /images/20221120/211aa00faf6a4a7aaf43f6a55907df6e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 6]: /images/20221120/f0797ae42b8a43239e9e86c3e15bd334.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 7]: /images/20221120/0de2799258874ad6bab22682dafe3ca5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 8]: /images/20221120/683689ce5d5b49819046f61d304e6213.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 9]: /images/20221120/c377b77a06ae49ccad2f107ebb61b4df.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 10]: /images/20221120/0e347f25b0054ef7868aec9fe8fc1a42.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 11]: /images/20221120/abb0975f9f8449dc8d9f6e9a629031fc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 12]: /images/20221120/958caacb89f24df48468b6e42bd7cce9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3OTg5OTgw_size_16_color_FFFFFF_t_70 13]: /images/20221120/1f514faaf9624807ac33090f6f5ce783.png