基于jdk1.8的HashMap(2)

超、凢脫俗 2022-01-28 05:23 219阅读 0赞

参考博客：https://www.jianshu.com/p/8324a34577a0?utm\_source=oschina-app

分析2：putVal(hash(key), key, value, false, true);  
主要讲解点1：计算完存储位置后，具体该如何存放数据到哈希表中  
源码分析：

/**
         * 分析2：putVal(hash(key), key, value, false, true)
         */
         final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
                Node<K,V>[] tab; Node<K,V> p; int n, i;
            // 1. 若哈希表的数组tab为空，则 通过resize() 创建
            // 所以，初始化哈希表的时机 = 第1次调用put函数时，即调用resize() 初始化创建
            // 关于resize（）的源码分析将在下面讲解扩容时详细分析，此处先跳过
            if ((tab = table) == null || (n = tab.length) == 0)
            n = (tab = resize()).length;
            
            // 2. 计算插入存储的数组索引i：根据键值key计算的hash值 得到
            // 此处的数组下标计算方式 = i = (n - 1) & hash，同JDK 1.7中的indexFor（），上面已详细描述
    
            // 3. 插入时，需判断是否存在Hash冲突：
            // 若不存在（即当前table[i] == null），则直接在该数组位置新建节点，插入完毕
            // 否则，代表存在Hash冲突，即当前存储位置已存在节点，则依次往下判断：a. 当前位置的key是否与需插入的key相同、b. 判断需插入的数据结构是否为红黑树 or 链表
            if ((p = tab[i = (n - 1) & hash]) == null)
            tab[i] = newNode(hash, key, value, null);  // newNode(hash, key, value, null)的源码 = new Node<>(hash, key, value, next)
        else {
            Node<K,V> e; K k;
            // a. 判断 table[i]的元素的key是否与 需插入的key一样，若相同则 直接用新value 覆盖 旧value
            // 判断原则：equals（）
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p;
            // b. 继续判断：需插入的数据结构是否为红黑树 or 链表
            // 若是红黑树，则直接在树中插入 or 更新键值对
            else if (p instanceof TreeNode)
                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value); ->>分析3
            // 若是链表,则在链表中插入 or 更新键值对
            // i.  遍历table[i]，判断Key是否已存在：采用equals（） 对比当前遍历节点的key 与 需插入数据的key：若已存在，则直接用新value 覆盖 旧value
            // ii. 遍历完毕后仍无发现上述情况，则直接在链表尾部插入数据
            // 注：新增节点后，需判断链表长度是否>8（8 = 桶的树化阈值）：若是，则把链表转换为红黑树
            else {
                for (int binCount = 0; ; ++binCount) {
                    // 对于ii：若数组的下1个位置，表示已到表尾也没有找到key值相同节点，则新建节点 = 插入节点
                    // 注：此处是从链表尾插入，与JDK 1.7不同（从链表头插入，即永远都是添加到数组的位置，原来数组位置的数据则往后移）
                    if ((e = p.next) == null) {
                        p.next = newNode(hash, key, value, null);
                        // 插入节点后，若链表节点>数阈值，则将链表转换为红黑树
                        if (binCount >= TREEIFY_THRESHOLD - 1) 
                            treeifyBin(tab, hash); // 树化操作
                        break;
                    }
                    // 对于i
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        break;
                    // 更新p指向下一个节点，继续遍历
                    p = e;
                }
            }
    
            // 对i情况的后续操作：发现key已存在，直接用新value 覆盖 旧value & 返回旧value
            if (e != null) { 
                V oldValue = e.value;
                if (!onlyIfAbsent || oldValue == null)
                    e.value = value;
                afterNodeAccess(e); // 替换旧值时会调用的方法（默认实现为空）
                return oldValue;
            }
        }
        ++modCount;
        // 插入成功后，判断实际存在的键值对数量size > 最大容量threshold
        // 若 > ，则进行扩容 ->>分析4（但单独讲解，请直接跳出该代码块）
        if (++size > threshold)
            resize();
        afterNodeInsertion(evict);// 插入成功时会调用的方法（默认实现为空）
        return null;
    }

分析3：

/**
         * 分析3：putTreeVal(this, tab, hash, key, value)
         * 作用：向红黑树插入 or 更新数据（键值对）
         * 过程：遍历红黑树判断该节点的key是否与需插入的key 相同：
         *      a. 若相同，则新value覆盖旧value
         *      b. 若不相同，则插入
         */
         final TreeNode<K,V> putTreeVal(HashMap<K,V> map, Node<K,V>[] tab,
                                           int h, K k, V v) {
                Class<?> kc = null;
                boolean searched = false;
                TreeNode<K,V> root = (parent != null) ? root() : this;
                for (TreeNode<K,V> p = root;;) {
                    int dir, ph; K pk;
                    if ((ph = p.hash) > h)
                        dir = -1;
                    else if (ph < h)
                        dir = 1;
                    else if ((pk = p.key) == k || (k != null && k.equals(pk)))
                        return p;
                    else if ((kc == null &&
                              (kc = comparableClassFor(k)) == null) ||
                             (dir = compareComparables(kc, k, pk)) == 0) {
                        if (!searched) {
                            TreeNode<K,V> q, ch;
                            searched = true;
                            if (((ch = p.left) != null &&
                                 (q = ch.find(h, k, kc)) != null) ||
                                ((ch = p.right) != null &&
                                 (q = ch.find(h, k, kc)) != null))
                                return q;
                        }
                        dir = tieBreakOrder(k, pk);
                    }
                    TreeNode<K,V> xp = p;
                    if ((p = (dir <= 0) ? p.left : p.right) == null) {
                        Node<K,V> xpn = xp.next;
                        TreeNode<K,V> x = map.newTreeNode(h, k, v, xpn);
                        if (dir <= 0)
                            xp.left = x;
                        else
                            xp.right = x;
                        xp.next = x;
                        x.parent = x.prev = xp;
                        if (xpn != null)
                            ((TreeNode<K,V>)xpn).prev = x;
                        moveRootToFront(tab, balanceInsertion(root, x));
                        return null;
                    }
                }
            }

扩容机制：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70]  
源码分析：

/**
         * 分析4：resize（）
         * 该函数有2种使用情况：1.初始化哈希表 2.当前数组容量过小，需扩容
         */
       final Node<K,V>[] resize() {
        Node<K,V>[] oldTab = table; // 扩容前的数组（当前数组）
        int oldCap = (oldTab == null) ? 0 : oldTab.length; // 扩容前的数组的容量 = 长度
        int oldThr = threshold;// 扩容前的数组的阈值
        int newCap, newThr = 0;
    
        // 针对情况2：若扩容前的数组容量超过最大值，则不再扩充
        if (oldCap > 0) {
            if (oldCap >= MAXIMUM_CAPACITY) {
                threshold = Integer.MAX_VALUE;
                return oldTab;
            }
            // 针对情况2：若无超过最大值，就扩充为原来的2倍
            else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                     oldCap >= DEFAULT_INITIAL_CAPACITY)
                newThr = oldThr << 1; // 通过右移扩充2倍
        }
        // 针对情况1：初始化哈希表（采用指定 or 默认值）
        else if (oldThr > 0) // initial capacity was placed in threshold
            newCap = oldThr;
        else {             
            newCap = DEFAULT_INITIAL_CAPACITY;
            newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
        }
        // 计算新的resize上限
        if (newThr == 0) {
            float ft = (float)newCap * loadFactor;
            newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                      (int)ft : Integer.MAX_VALUE);
        }
        threshold = newThr;
        @SuppressWarnings({"rawtypes","unchecked"})
            Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
        table = newTab;
        if (oldTab != null) {
            // 把每个bucket都移动到新的buckets中
            for (int j = 0; j < oldCap; ++j) {
                Node<K,V> e;
                if ((e = oldTab[j]) != null) {
                    oldTab[j] = null;
                    if (e.next == null)
                        newTab[e.hash & (newCap - 1)] = e;
                    else if (e instanceof TreeNode)
                        ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
                    else { // 链表优化重hash的代码块
                        Node<K,V> loHead = null, loTail = null;
                        Node<K,V> hiHead = null, hiTail = null;
                        Node<K,V> next;
                        do {
                            next = e.next;
                            // 原索引
                            if ((e.hash & oldCap) == 0) {
                                if (loTail == null)
                                    loHead = e;
                                else
                                    loTail.next = e;
                                loTail = e;
                            }
                            // 原索引 + oldCap
                            else {
                                if (hiTail == null)
                                    hiHead = e;
                                else
                                    hiTail.next = e;
                                hiTail = e;
                            }
                        } while ((e = next) != null);
                        // 原索引放到bucket里
                        if (loTail != null) {
                            loTail.next = null;
                            newTab[j] = loHead;
                        }
                        // 原索引+oldCap放到bucket里
                        if (hiTail != null) {
                            hiTail.next = null;
                            newTab[j + oldCap] = hiHead;
                        }
                    }
                }
            }
        }
        return newTab;
    }

扩容流程：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 1]  
此处主要讲解：jdk1.8扩容时，数据存储位置重新计算的方式  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 2]  
结论示意图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 3]  
数组位置转换示意图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 4]  
总结：  
添加数据：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 5]  
与jdk1.7的区别：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 6]  
从HashMap中取数据：  
get()流程如下：  
![在这里插入图片描述][20190523115610276.png]  
源码分析：

/**
       * 源码分析
       */ 
       public V get(Object key) {
        Node<K,V> e;
        // 1. 计算需获取数据的hash值
        // 2. 通过getNode（）获取所查询的数据 ->>分析1
        // 3. 获取后，判断数据是否为空
        return (e = getNode(hash(key), key)) == null ? null : e.value;
    }
    
    /**
     1. 分析1：getNode(hash(key), key))
       */ 
    final Node<K,V> getNode(int hash, Object key) {
        Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
        // 1. 计算存放在数组table中的位置
        if ((tab = table) != null && (n = tab.length) > 0 &&
            (first = tab[(n - 1) & hash]) != null) {
            // 4. 通过该函数，依次在数组、红黑树、链表中查找（通过equals（）判断）
            // a. 先在数组中找，若存在，则直接返回
            if (first.hash == hash && // always check first node
                ((k = first.key) == key || (key != null && key.equals(k))))
                return first;
            // b. 若数组中没有，则到红黑树中寻找
            if ((e = first.next) != null) {
                // 在树中get
                if (first instanceof TreeNode)
                    return ((TreeNode<K,V>)first).getTreeNode(hash, key);
                // c. 若红黑树中也没有，则通过遍历，到链表中寻找
                do {
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        return e;
                } while ((e = e.next) != null);
            }
        }
        return null;
    }

源码总结：

1.  数据结构&主要参数  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 7]
2.  添加 & 查询数据  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 8]
3.  扩容机制  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 9]

与jdk1.7的区别：

1.  数据结构![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 10]
2.  获取数据  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 11]
3.  扩容机制  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 12]

额外补充关于HashMap的其他问题：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 13]

1.  哈希表如何解决hash冲突  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 14]
2.  为什么HashMap具备下述特点：键值对都允许为空，线程不安全，不保证有序，存储位置随时间变化  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 15]  
    **JDK1.7HashMap**线程不安全的其中一个重要原因：多线程下容易出现resize()死循环；并发执行put()操作导致触发扩容行为，从而导致环形链表，使得在获取数据遍历链表时形成死循环。  
    此处重点分析：transfer()

/**
       * 源码分析：resize(2 * table.length)
       * 作用：当容量不足时（容量 > 阈值），则扩容（扩到2倍）
       */ 
       void resize(int newCapacity) {  
        
        // 1. 保存旧数组（old table） 
        Entry[] oldTable = table;  
    
        // 2. 保存旧容量（old capacity ），即数组长度
        int oldCapacity = oldTable.length; 
    
        // 3. 若旧容量已经是系统默认最大容量了，那么将阈值设置成整型的最大值，退出    
        if (oldCapacity == MAXIMUM_CAPACITY) {  
            threshold = Integer.MAX_VALUE;  
            return;  
        }  
      
        // 4. 根据新容量（2倍容量）新建1个数组，即新table  
        Entry[] newTable = new Entry[newCapacity];  
    
        // 5. （重点分析）将旧数组上的数据（键值对）转移到新table中，从而完成扩容 ->>分析1.1 
        transfer(newTable); 
    
        // 6. 新数组table引用到HashMap的table属性上
        table = newTable;  
    
        // 7. 重新设置阈值  
        threshold = (int)(newCapacity * loadFactor); 
    } 
    
     /**
       * 分析1.1：transfer(newTable); 
       * 作用：将旧数组上的数据（键值对）转移到新table中，从而完成扩容
       * 过程：按旧链表的正序遍历链表、在新链表的头部依次插入
       */ 
    void transfer(Entry[] newTable) {
          // 1. src引用了旧数组
          Entry[] src = table; 
    
          // 2. 获取新数组的大小 = 获取新容量大小                 
          int newCapacity = newTable.length;
    
          // 3. 通过遍历 旧数组，将旧数组上的数据（键值对）转移到新数组中
          for (int j = 0; j < src.length; j++) { 
              // 3.1 取得旧数组的每个元素  
              Entry<K,V> e = src[j];           
              if (e != null) {
                  // 3.2 释放旧数组的对象引用（for循环后，旧数组不再引用任何对象）
                  src[j] = null; 
                  do { 
                      // 3.3 遍历 以该数组元素为首 的链表
                      // 注：转移链表时，因是单链表，故要保存下1个结点，否则转移后链表会断开
                      Entry<K,V> next = e.next; 
                     // 3.3 重新计算每个元素的存储位置
                     int i = indexFor(e.hash, newCapacity); 
                     // 3.4 将元素放在数组上：采用单链表的头插入方式 = 在链表头上存放数据 = 将数组位置的原有数据放在后1个指针、将需放入的数据放到数组位置中
                     // 即 扩容后，可能出现逆序：按旧链表的正序遍历链表、在新链表的头部依次插入
                     e.next = newTable[i]; 
                     newTable[i] = e;  
                     // 访问下1个Entry链上的元素，如此不断循环，直到遍历完该链表上的所有节点
                     e = next;             
                 } while (e != null);
                 // 如此不断循环，直到遍历完数组上的所有数据元素
             }
         }
     }

***具体看下图：JDK1.7的操作***  
![在这里插入图片描述][20190523144554310.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 16]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 17]  
注：由于JDK1.8转移数据操作 = 按旧链表的正序遍历链表，在新链表的尾部依次插入，所以不会出现链表逆序，倒置的情况，故不容易出现环形链表的情况。但是jdk1.8HashMap还是线程不安全的，因为没有加同步锁保护。

1，为什么HashMap中String，Integer这样的包装类适合作为key键？  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 18]  
2，HashMap中的key若为Object类型，则需要实现哪些方法？  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 19]  
3，为什么HashMap中链表长度超过8会转换成红黑树？  
**若桶中链表元素超过8，会自动转化为红黑树；若桶中元素小于等于6时，树结构还原成链表。**  
原因：  
当hashCode离散性很好的时候，树型bin用到的概率非常小，因为数据均匀分布在每个bin中，几乎不会有bin中链表长度会达到阈值。但是在随机hashCode下，离散性可能会变差，然而JDK又不能阻止用户实现这种不好的hash算法，因此就可能导致不均匀的数据分布。不过理想情况下**随机hashCode算法下所有bin中节点的分布频率会遵循泊松分布，我们可以看到，一个bin中链表长度达到8个元素的概率为0.00000006，几乎是不可能事件。所以，之所以选择8，**不是拍拍屁股决定的，而是根据概率统计决定的。由此可见，发展30年的Java每一项改动和优化都是非常严谨和科学的。HashMap源码注释第190行左右：

* Because TreeNodes are about twice the size of regular nodes, we
         * use them only when bins contain enough nodes to warrant use
         * (see TREEIFY_THRESHOLD). And when they become too small (due to
         * removal or resizing) they are converted back to plain bins.  In
         * usages with well-distributed user hashCodes, tree bins are
         * rarely used.  Ideally, under random hashCodes, the frequency of
         * nodes in bins follows a Poisson distribution
         * (http://en.wikipedia.org/wiki/Poisson_distribution) with a
         * parameter of about 0.5 on average for the default resizing
         * threshold of 0.75, although with a large variance because of
         * resizing granularity. Ignoring variance, the expected
         * occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
         * factorial(k)). The first values are:
         *
         * 0:    0.60653066
         * 1:    0.30326533
         * 2:    0.07581633
         * 3:    0.01263606
         * 4:    0.00157952
         * 5:    0.00015795
         * 6:    0.00001316
         * 7:    0.00000094
         * 8:    0.00000006
         * more: less than 1 in ten million
         *
         * The root of a tree bin is normally its first node.  However,
         * sometimes (currently only upon Iterator.remove), the root might
         * be elsewhere, but can be recovered following parent links
         * (method TreeNode.root()).

4, 为什么HashMap中红黑树个数小于等于6时要转换为链表？  
答：长度为8，链表转树，长度为6，树转链表；中间有个差值，还可以防止链表和树频繁转换。假设8以上转为树，8以下转为链表，那么一个hashmap如果不停的插入删除，链表长度在8左右徘徊，就会不停的树转链表，链表转树，效率很低。同时红黑树的平均查找长度是log（n），长度为8的时候，平均查找长度为3；链表长度如果是6以内，6/2=3，速度也很快,基本和红黑树持平；转化为树还有生成树的时间，并不明智。

5，hashmap中的加载因子为什么默认是0.75 ？  
当时想到的是应该是“哈希冲突”和“空间利用率”矛盾的一个折中；HashMap负载因子为0.75是空间和时间成本的一种折中；这应该是个经验数字，在Open Hashing中，加载因子选得太大了，访问的时候冲突太多，会降低效率；选得太小了，会浪费大量存储空间。  
**HashMap源码第68行注释：**

* <p>As a general rule, the default load factor (.75) offers a good
     * tradeoff between time and space costs.  Higher values decrease the
     * space overhead but increase the lookup cost (reflected in most of
     * the operations of the <tt>HashMap</tt> class, including
     * <tt>get</tt> and <tt>put</tt>).  The expected number of entries in
     * the map and its load factor should be taken into account when
     * setting its initial capacity, so as to minimize the number of
     * rehash operations.  If the initial capacity is greater than the
     * maximum number of entries divided by the load factor, no rehash
     * operations will ever occur.

HashMap8比HashMap7的性能提高了8-10%的样子。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70]: /images/20220128/23a0efce453742fbb9a5b90072a8bfbf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 1]: /images/20220128/33fb99c69e084635a0bb33cb785630e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 2]: /images/20220128/8c94757e1a404a809b79db636df9855d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 3]: /images/20220128/99779f81e97c4ac7b14a77e7d06ef1f5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 4]: /images/20220128/37fd9496e08a4508945d8832ad7eba3f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 5]: /images/20220128/4442fa4a80494586a8bb5921efc16518.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 6]: /images/20220128/f6b90b0cb3fb489cac22ae080b36ba1a.png
[20190523115610276.png]: /images/20220128/4bf672f23b324b41896228911b866504.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 7]: /images/20220128/3b087a59308b4d278341167c02140c13.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 8]: /images/20220128/2247e186821c46edb4f4377819092bb5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 9]: /images/20220128/1c7333c9ffa9480fbd1a0f4cab42faf7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 10]: /images/20220128/2a9116ac31fe44d78e57bc523c347bf5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 11]: /images/20220128/0f9853775bf044b9b3cc3506f2699915.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 12]: /images/20220128/b4c300c7d24e4d2d9055b124036e30bb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 13]: /images/20220128/223f92b5f41c426492eeddb157d8f75f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 14]: /images/20220128/947a73fdc9584de689c802910be58b4c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 15]: /images/20220128/ec336864b62a400d8ad03fa2ad793c65.png
[20190523144554310.png]: /images/20220128/8b87fcb3920b450a90991fa07d837259.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 16]: /images/20220128/cf62836802fc44b3beb7d9badc4495f1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 17]: /images/20220128/7c59d5c08e0442b3b23839a7833a1e03.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 18]: /images/20220128/df882c2c97404c71af7c643a312cb4b1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RocXR6cQ_size_16_color_FFFFFF_t_70 19]: /images/20220128/f129238601ab427eac0d1b83a67edeb4.png