Lock接口与队列同步器AQS

小灰灰 2022-11-25 00:44 154阅读 0赞

## Lock接口 ##

**与synchronized锁对比**

*  在Java SE 5之后，并发包中新增了Lock接口（以及相关实现类）用来实现锁功能，它提供了与synchronized关键字类似的同步功能，只是在使用时**需要显式地获取和释放锁**。虽然它缺少了（通过synchronized块或者方法所提供的）**隐式获取释放锁**的便捷性，但是却**拥有了锁获取与释放的可操作性、可中断的获取锁以及超时获取锁等**多种synchronized关键字**所不具备的同步特性**
 *  使用**synchronized关键字**将会**隐式地获取锁**，**但**是它**将锁的获取和释放固化了**，也就是先获取再释放。当然，**这种方式简化了同步的管理**，可是**扩展性没有显示的锁获取和释放来的好**。
 *  例如，针对一个场景，手把手进行锁获取和释放，先获得锁A，然后再获取锁B，当锁B获得后，释放锁A同时获取锁C，当锁C获得后，再释放B同时获取锁D，以此类推。这种场景下，**synchronized关键字就不那么容易实现了，而使用Lock却容易许多**。

**Lock接口**提供的**synchronized关键字** **所不具备的主要特性如表所示**  
![在这里插入图片描述][20200806203246561.png]  
**Lock的API**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70]

> 这里先简单介绍一下Lock接口的API，随后的下文中会详细介绍同步器AbstractQueuedSynchronizer以及常用Lock接口的实现ReentrantLock。  
> **Lock接口的实现基本都是通过聚合了一个同步器的子类来完成线程访问控制的**。

## 队列同步器 ##

*  队列同步器AbstractQueuedSynchronizer（缩写AQS, 以下简称同步器），是用来构建锁或者其他同步组件的基础框架，**它使用了一个int成员变量表示同步状态**，**通过内置的FIFO(先进先出)队列来完成资源获取线程的排队工作**，并发包的作者（Doug Lea << 一位大佬）**期望它能够成为** **实现大部分同步需求的基础**。
 *  **同步器的主要使用方式是继承，子类通过继承同步器并实现它的抽象方法来管理同步状态**(上文也有提到Lock接口的实现主要就是这种方法)，在抽象方法的实现过程中免不了要**对同步状态进行更改，这时就需要使用同步器提供的3个方法来进行操作，因为它们能够保证状态的改变是安全的**
    
     *  \*\*getState()\*\*获取当前同步状态
     *  \*\*setState(int newState)\*\*获取当前同步状态
     *  \*\*compareAndSetState(int expect,int update)\*\*使用CAS设置当前状态，该方法能够保证状态设置的原子性。
    
    **同步器可重写的方法与描述如表所示：**  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 1]
 *  **子类推荐被定义为自定义同步组件的静态内部类**，**同步器自身没有实现任何同步接口，它仅仅是定义了若干同步状态获取和释放的方法来供自定义同步组件使用**（简单说就是只定义不实现），**同步器既可以支持独占式地获取同步状态，也可以支持共享式地获取同步状态**，这样就可以方便实现不同类型的同步组件：
    
     *  ReentrantLock、ReentrantReadWriteLock、CountDownLatch。
 *  **同步器是实现锁（也可以是任意同步组件）的关键，在锁的实现中聚合同步器，利用同步  
    器实现锁的语义**。
 *  **可以这样理解二者之间的关系：**
    
     *  锁是面向使用者的，它定义了使用者与锁交互的接口（比如可以允许两个线程并行访问），隐藏了实现细节；
     *  同步器面向的是锁的实现者，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。
     *  锁和同步器很好地隔离了使用者和实现者所需关注的领域。

## 同步器提供的模板方法 ##

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

*  同步器提供的模板方法基本上分为3类：
    
     *  独占式获取与释放同步状态、
     *  共享式获取与释放
     *  同步状态和查询同步队列中的等待线程情况。
 *  自定义同步组件将使用同步器提供的模板方法来实现自己的同步语义。

## 通过一个独占锁的示例来深入了解一下同步器的工作原理 ##

*  顾名思义，**独占锁就是在同一时刻只能有一个线程获取到锁，而其他获取锁的线程只能处于同步队列中等待，只有获取锁的线程释放了锁，后继的线程才能够获取锁**，如下方代码所示。

public class Mutex implements Lock { 
        // 静态内部类，自定义同步器
        private static class Sync extends AbstractQueuedSynchronizer { 
            // 是否处于占用状态
            @Override
            protected boolean isHeldExclusively() { 
                return getState() == 1;
            } 
            // 当状态为0的时候获取锁
            @Override
            public boolean tryAcquire(int acquires) { 
                if (compareAndSetState(0, 1)) { 
                    setExclusiveOwnerThread(Thread.currentThread());
                    return true;
                } 
                return false;
            } 
            // 释放锁，将状态设置为0
            @Override
            protected boolean tryRelease(int releases) { 
                if (getState() == 0) throw new IllegalMonitorStateException();
                setExclusiveOwnerThread(null);
                setState(0);
                return true;
            } 
            // 返回一个Condition，每个condition都包含了一个condition队列
            Condition newCondition() {  return new ConditionObject(); }
        } 
        // 仅需要将操作代理到Sync上即可
        private final Sync sync = new Sync();
        @Override
        public void lock() {  sync.acquire(1); }
        @Override
        public boolean tryLock() {  return sync.tryAcquire(1); }
        @Override
        public void unlock() {  sync.release(1); }
        @Override
        public Condition newCondition() {  return sync.newCondition(); }
        public boolean isLocked() {  return sync.isHeldExclusively(); }
        public boolean hasQueuedThreads() {  return sync.hasQueuedThreads(); }
        @Override
        public void lockInterruptibly() throws InterruptedException { 
            sync.acquireInterruptibly(1);
        }
        @Override
        public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException { 
            return sync.tryAcquireNanos(1, unit.toNanos(timeout));
        }
    }

*  独占锁Mutex是一个自定义同步组件，**它在同一时刻只允许一个线程占有锁**。Mutex中定义了**一个静态内部类，该内部类继承了同步器并实现了独占式获取和释放同步状态**。
 *  在tryAcquire(intacquires)方法中，**如果经过CAS设置成功（同步状态设置为1），则代表获取了同步状态，而在tryRelease(int releases)方法中只是将同步状态重置为0**。
 *  **用户使用Mutex时并不会直接和内部同步器的实现打交道，而是调用Mutex提供的方法**，在Mutex的实现中，**以获取锁的lock()方法为例，只需要在方法实现中调用同步器的模板方法acquire(intargs)即可**，当前线程调用该方法获取同步状态失败后会被加入到同步队列中等待，这样就**大大降低了实现一个可靠自定义同步组件的门槛**。

## 队列同步器的实现分析 ##

**同步队列**

*  同步器依赖内部的同步队列（一个FIFO双向队列）来完成同步状态的管理，当前线程获取同步状态失败时，**同步器会将当前线程以及等待状态等信息构造成为一个节点（Node）并将其加入同步队列**，**同时会阻塞当前线程，当同步状态释放时，会把首节点中的线程唤醒，使其再次尝试获取同步状态**。
 *  **同步队列中的节点（Node）用来保存获取同步状态失败的线程引用、等待状态以及前驱和后继节点**，**节点的属性类型与名称以及描述如表所示**。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 3]  
**节点是构成同步队列（等待队列，在下面中将会介绍）的基础**，同步器拥有**首节点**（head）和**尾节点**（tail），没有成功获取同步状态的线程将会成为节点加入该队列的尾部，同步队列的基本结构如图所示。

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

*  当一个线程成功地获取了同步状态（或者锁），其他线程将无法获取到同步状态，转而被构造成为节点并加入到同步队列中，而这个**加入队列的过程必须要保证线程安全，因此同步器提供了一基于CAS的设置尾节点的方法**：compareAndSetTail(Node expect,Nodeupdate)，**它需要传递当前线程“认为”的尾节点和当前节点，只有设置成功后，当前节点才正式与之前的尾节点建立关联**。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 5]
 *  同步队列遵循FIFO，首节点是获取同步状态成功的节点，首节点的线程在释放同步状态  
    时，将会唤醒后继节点，而后继节点将会在获取同步状态成功时将自己设置为首节点。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 6]  
设置首节点是通过获取同步状态成功的线程来完成的，**由于只有一个线程能够成功获取到同步状态，因此设置头节点的方法并不需要使用CAS来保证**，它**只需要将首节点设置成为原首节点的后继节点并断开原首节点的next引用即可**。

## 独占式同步状态获取与释放 ##

*  通过调用同步器的acquire(int arg)方法可以获取同步状态，该方法对中断不敏感，也就是**由于线程获取同步状态失败后进入同步队列中，后续对线程进行中断操作时，线程不会从同步队列中移出**，该方法代码如代码所示。

public final void acquire(int arg) { 
    	if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
    		selfInterrupt();
    }

*  上述代码主要完成了同步状态获取、节点构造、加入同步队列以及在同步队列中自旋等待的相关工作，其**主要逻辑是**：
    
     *  首先调用自定义同步器实现的tryAcquire(int arg)方法，该方法保证线程安全的获取同步状态， **如果同步状态获取失败，则构造同步节点（独占式Node.EXCLUSIVE，同一时刻只能有一个线程成功获取同步状态**）
     *  并通过addWaiter(Node node)方法将该节点加入到同步队列的尾部，
     *  最后调用acquireQueued(Node node,int arg)方法，使得**该节点以“死循环”的方式获取同步状态**。如果获取不到则阻塞节点中的线程，而被阻塞线程的唤醒，**主要依靠前驱节点的出队或阻塞线程被中断来实现**。
 *  **如果使用一个普通的LinkedList来维护节点之间的关系**，那么当一个线程获取了同步状态，而其他多个线程由于调用tryAcquire(int arg)方法获取同步状态失败而并发地被添加到LinkedList时，**LinkedList将难以保证Node的正确添加** **，最终的结果可能是节点的数量有偏差，而且顺序也是混乱的**。（LinkedList是线程不安全的）
 *  **节点进入同步队列之后，就进入了一个自旋的过程**，每个节点（或者说每个线程）都在自  
    省地观察，**当条件满足，获取到了同步状态，就可以从这个自旋过程中退出，否则依旧留在这  
    个自旋过程中（并会阻塞节点的线程）**。

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

> 独占式同步状态获取流程，也就是acquire(int arg)方法调用流程，如图

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

*  **由于非首节点线程前驱节点出队或者被中断而从等待状态返回，随后检查自己的前驱是否是头节点，如果是则尝试获取同步状态**。**可以看到节点和节点之间在循环检查的过程中基本不相互通信**，**而是简单地判断自己的前驱是否为头节点，这样就使得节点的释放规则符合FIFO，并且也便于对过早通知的处理**（**过早通知是指前驱节点不是头节点的线程由于中断而被唤醒**）。
 *  当前线程**获取同步状态并执行了相应逻辑之后**，就需要**释放同步状态**，**使得后续节点能够继续获取同步状态**。通过调用同步器的release(int arg)方法可以释放同步状态，该方法在释放了同步状态之后，会唤醒其后继节点（进而使后继节点重新尝试获取同步状态）。该方法代码如代码所示。

public final boolean release(int arg) { 
    	if (tryRelease(arg)) { 
    		Node h = head;
    		if (h != null && h.waitStatus != 0)
    			unparkSuccessor(h);
    		return true;
    	}
    	return false;
    }

该方法执行时，会唤醒头节点的后继节点线程，**unparkSuccessor(Node node)方法使用  
LockSupport**（在后面的会专门介绍）**来唤醒处于等待状态的线程**。

**总结：**

*  在获取同步状态时，**同步器维护一个同步队列**，**获取状态失败的线程都会被加入到队列中并在队列中进行自旋**；**移出队列（或停止自旋）的条件是前驱节点为头节点且成功获取了同步状态**。**在释放同步状态时，同步器调用tryRelease(int arg)方法释放同步状态，然后唤醒头节点的后继节点**。

## 共享式同步状态获取与释放 ##

*  共享式获取与独占式获取最主要的区别在于同一时刻能否有多个线程同时获取到同步状  
    态。  
    对比如下：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 9]
 *  左半部分，共享式访问资源时，其他共享式的访问均被允许，而独占式访问被阻塞，右半部分是独占式访问资源时，同一时刻其他访问均被阻塞。
 *  通过调用同步器的acquireShared(int arg)方法可以共享式地获取同步状态，该方法代码如代码所示

public final void acquireShared(int arg) { 
            if (tryAcquireShared(arg) < 0)
                doAcquireShared(arg);
        }
        private void doAcquireShared(int arg) { 
            final Node node = addWaiter(Node.SHARED);
            boolean failed = true;try { 
                boolean interrupted = false;
                for (;;) { 
                    final Node p = node.predecessor();
                    if (p == head) { 
                        int r = tryAcquireShared(arg);
                        if (r >= 0) { 
                            setHeadAndPropagate(node, r);
                            p.next = null;
                            if (interrupted)
                                selfInterrupt();
                            failed = false;
                            return;
                        }
                    }
                    if (shouldParkAfterFailedAcquire(p, node) &&
                            parkAndCheckInterrupt())
                    interrupted = true;
                }
            } finally { 
                if (failed)
                    cancelAcquire(node);
            }
        }

*  在acquireShared(int arg)方法中，同步器调用tryAcquireShared(int arg)方法尝试获取同步状态，**tryAcquireShared(int arg)方法返回值为int类型，当返回值大于等于0时，表示能够获取到同步状态**。因此，**在共享式获取的自旋过程中，成功获取到同步状态并退出自旋的条件就是tryAcquireShared(int arg)方法返回值大于等于0**。
 *  可以看到，在doAcquireShared(int arg)方法的自旋过程中，**如果当前节点的前驱为头节点时，尝试获取同步状态，如果返回值大于等于0，表示该次获取同步状态成功并从自旋过程中退出**。

共享式获取也需要释放同步状态，通过调用releaseShared(int arg)方法可以释放同步状态，该方法代码如代码所示。

public final boolean releaseShared(int arg) { 
    	if (tryReleaseShared(arg)) { 
    		doReleaseShared();
    		return true;
    	}
    	return false;
    }

*  **该方法在释放同步状态之后，将会唤醒后续处于等待状态的节点。** 对于能够支持多个线程同时访问的并发组件（比如Semaphore），**它和独占式主要区别在于tryReleaseShared(int arg)方法必须确保同步状态（或者资源数）线程安全释放，一般是通过循环和CAS来保证的，因为释放同步状态的操作会同时来自多个线程**。

**对比独占式和共享式释放同步状态：**

*  最大的区别是独占式在释放同步状态时，不需要通过循环和CAS来保证，只需要将后继节点唤醒，并移除后继节点的引用即可。

## 独占式超时获取同步状态 ##

*  通过调用同步器的doAcquireNanos(int arg,long nanosTimeout)方法**可以超时获取同步状态**，**即在指定的时间段内获取同步状态**，**如果获取到同步状态则返回true，否则，返回false**。该  
    方法**提供了传统Java同步操作（比如synchronized关键字）所不具备的特性**。
 *  在分析该方法的实现前，先介绍一下响应中断的同步状态获取过程。在Java 5之前，**当一个线程获取不到锁而被阻塞在synchronized之外时，对该线程进行中断操作，此时该线程的中断标志位会被修改，但线程依旧会阻塞在synchronized上，等待着获取锁**。在Java 5中，同步器提供了**acquireInterruptibly(int arg)方法，这个方法在等待获取同步状态时，如果当前线程被中断，会立刻返回，并抛出InterruptedException**。
 *  
 *  **超时获取同步状态过程可以被视作响应中断获取同步状态过程的“增强版”**，**doAcquireNanos(int arg,long nanosTimeout)方法在支持响应中断的基础上**，增加了超时获取的特性。
 *  针对超时获取，**主要需要计算出需要睡眠的时间间隔nanosTimeout，为了防止过早通知，nanosTimeout计算公式为：nanosTimeout-=now-lastTime**，其中now为当前唤醒时间，lastTime为上次唤醒时间，**如果nanosTimeout大于0则表示超时时间未到，需要继续睡眠nanosTimeout纳秒，反之，表示已经超时**。

private boolean doAcquireNanos(int arg, long nanosTimeout)
                throws InterruptedException { 
            long lastTime = System.nanoTime();final Node node = addWaiter(Node.EXCLUSIVE);
            boolean failed = true;
            try { 
                for (;;) { 
                    final Node p = node.predecessor();
                    if (p == head && tryAcquire(arg)) { 
                        setHead(node);
                        p.next = null; // help GC
                        failed = false;
                        return true;
                    }
                    if (nanosTimeout <= 0)
                    return false;
                    if (shouldParkAfterFailedAcquire(p, node)
                            && nanosTimeout > spinForTimeoutThreshold)
                        LockSupport.parkNanos(this, nanosTimeout);
                    long now = System.nanoTime();
                    //计算时间，当前时间now减去睡眠之前的时间lastTime得到已经睡眠
                    //的时间delta，然后被原有超时时间nanosTimeout减去，得到了
                    //还应该睡眠的时间
                    nanosTimeout -= now - lastTime;
                    lastTime = now;
                    if (Thread.interrupted())
                        throw new InterruptedException();
                }
            } finally { 
                if (failed)
                    cancelAcquire(node);
            }
        }

*  **在同步状态获取失败的处理上与独占式有所不同**。如果当前线程获取同步状态**失败后，则判断是否超时（nanosTimeout小于等于0表示已经超时），如果没有超时，重新计算超时间隔nanosTimeout**，然后使当前线程等待nanosTimeout纳秒（**当已到设置的超时时间，该线程会LockSupport.parkNanos(Objectblocker,long nanos)方法返回**）。
 *  **如果nanosTimeout小于等于spinForTimeoutThreshold（1000纳秒）时**，将不会使该线程进行超时等待，而是进入快速的自旋过程。原因在于，非常短的超时等待无法做到十分精确，**如果这时再进行超时等待，相反会让nanosTimeout的超时从整体上表现得反而不精确。因此，在超时非常短的场景下，同步器会进入无条件的快速自旋**。

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

[20200806203246561.png]: /images/20221124/24c81724b8a54f788407e072fbfecfb1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70]: /images/20221124/13a04510c14d4acca7dbbe086888ac09.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 1]: /images/20221124/5d8b066d3e014a30881ac267f4c9a893.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 2]: /images/20221124/67d42f3a5a224af7912f836af57d9030.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 3]: /images/20221124/45ca94cee4b84902bcaba04c1bb4be28.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 4]: /images/20221124/5640edaaf0af449bbdef521ac5465bdb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 5]: /images/20221124/6d7de81db8684b96be51534e99b1a0e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 6]: /images/20221124/487054a69df04be0ad7046878c6e98f0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 7]: /images/20221124/3ee2d7eff9e64c02b5ebe2b0045b9172.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 8]: /images/20221124/f79de76b36a2446a9d5d9d4193c7e0b8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 9]: /images/20221124/ebeb9115b1a847f48fd1940a4d096be3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 10]: /images/20221124/581d6b539b8d487b9fac60b93d238055.png