AQS详解

电玩女神 2022-02-28 11:20 210阅读 0赞

**AQS的介绍**  
AQS的全称为（AbstractQueuedSynchronizer），这个类在java.util.concurrent.locks包下面。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70]  
**AQS原理**  
AQS：AbstractQuenedSynchronizer抽象的队列式同步器。是除了java自带的synchronized关键字之外的锁机制。  
**AQS的核心思想**是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并将共享资源设置为锁定状态（**解释：就是通过volatile int state这个变量来判断该资源是否可以被当前发起资源请求的线程占用，如果state>0，那么就说明已经有线程在占用该资源了，其他线程就不能进行访问，除非state变成0，才可以申请访问该资源**），如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。  
CLH（Craig，Landin，and Hagersten）队列是一个虚拟的双向队列，虚拟的双向队列即不存在队列实例（**解释：不是真的用队列Queue去存储这些节点，而是通过某种方式维持节点之间的关系，从而使得看起来像队列**），仅存在节点之间的关联关系。

看个AQS(AbstractQueuedSynchronizer)原理图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][20190325154939140.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 2]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 3]  
模板方法模式链接：  
[https://blog.csdn.net/qq\_40241957/article/details/84898404][https_blog.csdn.net_qq_40241957_article_details_84898404]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 4]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 5]  
**解释：** ReentrantReadWriteLock是对“读操作”共享，“写操作”互斥的

**自定义同步器**  
　　同步器代码实现

上面大概讲了一些关于AQS如何使用的理论性的东西，接下来，我们就来看下实际如何使用，直接采用JDK官方文档中的小例子来说明问题  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 6]  
解释：下面的Sync类对象是上面定义的静态内部类  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 7]  
**同步器代码测试**  
测试下这个自定义的同步器，我们使用之前文章中做过的并发环境下a++的例子来说明问题（a++的原子性其实最好使用原子类AtomicInteger来解决，此处用Mutex有点大炮打蚊子的意味，好在能说明问题就好）

package juc;
    
    import java.util.concurrent.CyclicBarrier;
    
    /**
     * Created by chengxiao on 2017/7/16.
     */
    public class TestMutex {
        private static CyclicBarrier barrier = new CyclicBarrier(31);
        private static int a = 0;
        private static  Mutex mutex = new Mutex();
    
        public static void main(String []args) throws Exception {
            //说明:我们启用30个线程，每个线程对i自加10000次，同步正常的话，最终结果应为300000；
            //未加锁前
            for(int i=0;i<30;i++){
                Thread t = new Thread(new Runnable() {
                    @Override
                    public void run() {
                        for(int i=0;i<10000;i++){
                            increment1();//没有同步措施的a++；
                        }
                        try {
                            barrier.await();//等30个线程累加完毕
                        } catch (Exception e) {
                            e.printStackTrace();
                        }
                    }
                });
                t.start();
            }
            barrier.await();
            System.out.println("加锁前，a="+a);
            //加锁后
            barrier.reset();//重置CyclicBarrier
            a=0;
            for(int i=0;i<30;i++){
                new Thread(new Runnable() {
                    @Override
                    public void run() {
                        for(int i=0;i<10000;i++){
                            increment2();//a++采用Mutex进行同步处理
                        }
                        try {
                            barrier.await();//等30个线程累加完毕
                        } catch (Exception e) {
                            e.printStackTrace();
                        }
                    }
                }).start();
            }
            barrier.await();
            System.out.println("加锁后，a="+a);
        }
        /**
         * 没有同步措施的a++
         * @return
         */
        public static void increment1(){
            a++;
        }
        /**
         * 使用自定义的Mutex进行同步处理的a++
         */
        public static void increment2(){
            mutex.lock();
            a++;
            mutex.unlock();
        }
    }
    
    TestMutex

![在这里插入图片描述][2019032521191599.png]  
这运行结果充分说明了i++不是原子操作，可能发生线程安全问题

## 源码详解 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 8]  
![在这里插入图片描述][20190325221726171.png]  
解释：为什么会存在争夺的情况，原因是因为不仅仅是有后继节点线程会去抢资源，还可能会有新产生的线程也会去抢资源，所以会产生争夺现象  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 9]  
提示：下面的源码可能看不懂，下图第2张图是源码的翻版

## 3.1 acquire(int) ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 10]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 11]  
![在这里插入图片描述][20190325222814464.png]  
小疑问：上述为什么会是被中断呢？

## 3.1.2 addWaiter(Node) ##

小疑问：下面addWaiter()方法里面还有enq（）是入列（enqueue）的意思  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 12]  
![在这里插入图片描述][20190326105728392.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 13]  
——————————————————————————————————

## 3.1.2.1 enq(Node) ##

**提示：** 要注意下面的enq()方法体里面有一个for死循环，这个就是**自旋**，一直做for循环，直到CAS,执行成功return t为止  
①因为存在争用，可能多个线程入队，所以CAS操作来保证入队的原子性  
②tai节点又是volatile的，保证可见性

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

## 3.1.3 acquireQueued(Node, int) ##

![在这里插入图片描述][20190326130438657.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 15]  
\*\*解释：\*\*上述说的“如果自己可以休息”就是说本线程是否被请求中断不是自身控制的，是由外在对象改变的

到这里了，我们先不急着总结acquireQueued()的函数流程，先看看shouldParkAfterFailedAcquire()和parkAndCheckInterrupt()具体干些什么。

## 3.1.3.1 shouldParkAfterFailedAcquire(Node, Node) ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 16]  
整个流程中，如果前驱结点的状态不是SIGNAL，那么自己就不能安心去休息，需要去找个安心的休息点，同时可以再尝试下看有没有机会轮到自己拿号。

## 3.1.3.2 parkAndCheckInterrupt() ##

如果线程找好安全休息点后，那就可以安心去休息了。此方法就是让线程去休息，真正进入等待状态。  
![在这里插入图片描述][20190326150616529.png]  
**提示：** 需要注意的是，Thread.interrupted()会清除当前线程的中断标记位。

## 对acquireQueue()大总结： ##

![在这里插入图片描述][20190326150702544.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 17]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 18]

## 3.2 release(int) ##

上一小节已经把acquire()说完了，这一小节就来讲讲它的反操作release()吧。此方法是独占模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。这也正是unlock()的语义，当然不仅仅只限于unlock()。下面是release()的源码：  
![在这里插入图片描述][20190326152318490.png]  
　逻辑并不复杂。它调用tryRelease()来释放资源。有一点需要注意的是，它是根据tryRelease()的返回值来判断该线程是否已经完成释放掉资源了！所以自定义同步器在设计tryRelease()的时候要明确这一点！！

## 3.2.1 tryRelease(int) ##

下面是AQS的方法源码，需要我们去重写之  
![在这里插入图片描述][2019032615235630.png]  
　跟tryAcquire()一样，这个方法是需要**独占模式**的自定义同步器去实现的。正常来说，tryRelease()都会成功的，因为这是**独占模式**，该线程来释放资源，那么它肯定已经拿到独占资源了，直接减掉相应量的资源即可(state-=arg)，也不需要考虑线程安全的问题。但要注意它的返回值，上面已经提到了，release()是根据tryRelease()的返回值来判断该线程是否已经完成释放掉资源了！所以自义定同步器在实现时，如果已经彻底释放资源(state=0)，要返回true，否则返回false。

## 3.2.2 unparkSuccessor(Node) ##

此方法用于唤醒等待队列中下一个线程。下面是源码：  
小疑问：可以看到下面的for循环是从同步队列的尾部往前逐个遍历的，然后逐个往前遍历，直到找出最前的那个未放弃的线程（有效的）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 19]  
这个函数并不复杂。一句话概括：用unpark()唤醒等待队列中最前边的那个未放弃线程，这里我们也用s来表示吧。此时，再和acquireQueued()联系起来，s被唤醒后，进入if (p == head && tryAcquire(arg))的判断（即使p!=head也没关系，它会再进入shouldParkAfterFailedAcquire()寻找一个安全点。这里既然s已经是等待队列中最前边的那个未放弃线程了，那么通过shouldParkAfterFailedAcquire()的调整，s也必然会跑到head的next结点，下一次自旋p==head就成立啦），然后s把自己设置成head标杆结点，表示自己已经获取到资源了，acquire()也返回了！！And then, DO what you WANT!

**3.2.3 小结**  
　　release()是独占模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。

## 共享模式下的方法 ##

## 3.3 acquireShared(int) ##

此方法是**共享模式下**线程获取共享资源的顶层入口。它会获取指定量的资源，获取成功则直接返回，获取失败则进入等待队列，直到获取到资源为止，整个过程忽略中断。下面是acquireShared()的源码：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 20]

## 3.3.1 doAcquireShared(int) ##

此方法用于将当前线程加入等待队列尾部休息，直到其他线程释放资源唤醒自己，自己成功拿到相应量的资源后才返回。下面是doAcquireShared()的源码：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 21]  
![在这里插入图片描述][2019032619193416.png]  
**解释：** 从上面的这段话就可以看出，并发就比较低效，是要在代码中处理这个死局问题的

## 3.3.1.1 setHeadAndPropagate(Node, int) ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 22]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 23]  
**小疑问：** 可能这里不是很明白为什么要加上 h ==null和h.waitStatus<0?从上图可以看出p.next=null（**解释：** p是原头节点，p.next=null目的是为了回收原头节点）是在setHeadAndPropagate()函数之后执行的，说明在setHeadAndPropagate()函数体里面原头节点肯定不为null,那么为什么要在if()里面加上h ==null和h.waitStatus<0呢？

此方法在setHead()的基础上多了一步，就是自己苏醒的同时，如果条件符合（比如还有剩余资源），还会去唤醒后继结点，毕竟是共享  
doReleaseShared()我们留着下一小节的releaseShared()里来讲。  
　　![在这里插入图片描述][20190326202631715.png]

## 3.4 releaseShared() ##

上一小节已经把acquireShared()说完了，这一小节就来讲讲它的反操作releaseShared()吧。此方法是共享模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果成功释放且允许唤醒等待线程，它会唤醒等待队列里的其他线程来获取资源。下面是releaseShared()的源码：  
　![在这里插入图片描述][20190326203037442.png]  
　![在这里插入图片描述][20190326214209841.png]  
　**小疑问：** 我感觉这样做的思路岂不是互斥了吗

## 3.4.1 doReleaseShared() ##

此方法主要用于唤醒后继。下面是它的源码：

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70]: /images/20220228/8e2e3e8f1a0147139450e20a48d74e72.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 1]: /images/20220228/e286b5a028ab4f39a1761e44a074c5f6.png
[20190325154939140.png]: /images/20220228/05b5698bc16b45fba6636c863fd204d2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 2]: /images/20220228/e500883a9f1c4711b4b804320a643bf0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 3]: /images/20220228/079bb475c44e4b148e8235b7f0b7e0f5.png
[https_blog.csdn.net_qq_40241957_article_details_84898404]: https://blog.csdn.net/qq_40241957/article/details/84898404
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 4]: /images/20220228/14ce3efdb17f4892927ce3fc427eeaed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 5]: /images/20220228/710564993f6949f8a4ca0ce7b12f391b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 6]: /images/20220228/982785712ed649ec933f6a38986e28b7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 7]: /images/20220228/762d8e1f3d2e4c82920f068470ce17e2.png
[2019032521191599.png]: /images/20220228/3476b8b3849e45138b08ba48a2a7e77e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 8]: /images/20220228/7f72a38bae9e4227bf203e17734b2ae2.png
[20190325221726171.png]: /images/20220228/574b80c4b33f4b7fb4547bcaa222ea34.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 9]: /images/20220228/c480234e7acd4c299e25ebe46b3cbda1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 10]: /images/20220228/b0ef75891a8f4eeea9a0a7db0ed0cc1f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 11]: /images/20220228/33a1937df39d4b87a836c50575914862.png
[20190325222814464.png]: /images/20220228/ab7b2be8fb134d569f8fdacf96a790cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 12]: /images/20220228/8d8c4f899de24c7296ca5c818b6a9dde.png
[20190326105728392.png]: /images/20220228/84ba136c426642b1800543f2becf0b62.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 13]: /images/20220228/e091093941e445c8a0f975bccec632a9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 14]: /images/20220228/23858a0576144293b9b1b72798751e45.png
[20190326130438657.png]: /images/20220228/39a4065217eb41dea3d5f79c6fc814a3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 15]: /images/20220228/996209395a6747d4a79ad97f91a3a974.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 16]: /images/20220228/0370deebd4954c67afc5c2dadedcb70b.png
[20190326150616529.png]: /images/20220228/ddaa81b9d3f34519a25f97550008be85.png
[20190326150702544.png]: /images/20220228/24cfbbe0fe9a4a6e9492d35bcf1ddc3d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 17]: /images/20220228/533ce9677e3b426f985e8859187c49a2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 18]: /images/20220228/1a7f9cdaa03643e0bd4dea1a97d91aec.png
[20190326152318490.png]: /images/20220228/ed2f6a11349243e68f0521e2349e6e20.png
[2019032615235630.png]: /images/20220228/94fe813886714ae3862e852440847cf2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 19]: /images/20220228/bb953c3203ce4039900f7e58b4182575.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 20]: /images/20220228/bd636042aae74ae8bbce6b886bd5a5bb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 21]: /images/20220228/2fd491ceb8d845c48d0025394ea4a2f8.png
[2019032619193416.png]: /images/20220228/d1c64336fffa404c8e9bf2d45f0b95ec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 22]: /images/20220228/dad7252d8fbb41d3957eed27b5209d1d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjQxOTU3_size_16_color_FFFFFF_t_70 23]: /images/20220228/fb670dbc7b684f048ac09f60e0ea85b6.png
[20190326202631715.png]: /images/20220228/b8b694fbdc844ab096363762fc059b1b.png
[20190326203037442.png]: /images/20220228/48ae46fff5af4d64843ade8dc4ff3268.png
[20190326214209841.png]: /images/20220228/40627df308f3449cbc9404bd48ca88c0.png